Hacking and Coffee

Privacy Policy

Fri, 13 Mar 2026 00:00:00 -0500

The Entire Privacy Policy

As a small business, we believe that the Privacy Policy should be small and simple as well.

As much as we’d like to not store anything, we unfortuantely have to store some information. Here’s how we store it, when we delete it, and what we do with it.

How you can Improve Privacy with us

Hacking & Coffee has a number of End-to-End Encryption (E2EE) options for communicating with customers to limit access by our providers, including:

Signal
PGP
Wire Whilst not E2EE, we also can accept email via Proton mail address. We are currently in the process of migrating our email to default to Proton Mail.

Communications

No Adverts - Hacking & Coffee will communicate as necessary with customers and prospective customers. We do not perform any advertising via email, SMS/MMS, phone, or mail.
SMS/MMS - We will only text you if we are provided a mobile number for communication related to work via Opt-in consent. Data and carrier rates may apply. No mobile information will be shared with third parties/affiliates for marketing/promotional purposes. All other categories exclude text messaging originator opt-in data and consent; this information will not be shared with any third parties

Data we Store

Active conversations - We store Email and/or SMS as needed to continue operations or provide support with you.
Contact Information - We store contact information containging a combination of Name, Email Address, Phone Number, or Address as needed to perform work. We will only use the information provided. We do not scrap or gather information for lead generation.
Work Product - We store what is needed to perform the work in scope. This may include Photographs, Computer Aided Design (CAD) documents, Code, Documentation of systems, or other media. Information gatheredfrom the customer stays their intellectual property unless otherwise agreed in writing. Information provided as a work product by Hacking & Coffee, or its derivative businesses, remains as usable IP of Hacking & Coffee LLC unless otherwise agreed to. Photography of Tailly Ho Photography will be owned by the customer upon delivery of final product & payment, and Tailly Ho Photography will request separate permission to use it for promotional purposes.

Who can Access & Where

Hacking & Coffee - Members of Hacking & Coffee have access to business data. Currently Hacking & Coffee operates as a single member LLC. Should this change, this policy will be updated accordingly. Hacking & Coffee primarily operates out of the State of Washington
Designated Contractors - When a contractor is required for specific needs, they will be introduced nad terms of data will be discussed explicitly prior to sharing.
Google Workspace(Email, Calendar) - Most of ur data is moving to End to End encryption, however email, calendar, and certain document systems use Google Workspace. Due to our former European operatoions this operates under Google Ireland. Customers may request a PGP key or alternative communication method to honour their privacy settings.
Proton - The Swiss workspace company stores encrypted copies of Data such as Documents, but cannot access data themselves. Our email will eventually transition to Proton, and active customers will receive a communication when that happens.
Zoom(Phone) - Zoom manages our business phone and SMS operations at this time. Signal is available as an alternative, as well as other platforms such as Discord or Telegram. Data policies for those methods of communication apply. We will always move a conversation to Signal where possible.
Autodesk(CAD) - Autodesk Fusion360 is currently used for Computer Aided Design (CAD) where applicable. This is a cloud synced service, and files generated will fall under the Autodesk Privacy Policy.
Github(Code) - Code development projects generally run out of Github. Upon request we can self-host isolated Gitlab servers for specific needs.

Data Removal

Data Removal Requests - Hacking & Coffee will honour all data removal requests for customers.Hacking & Coffee will honour all data removal requests for customers. Removal requests can be granular upon customer request, such as removing specific CAD files or similar.
Removal Timeline - Hacking & Coffee will remove data within 7 days upon acknowledgement of receiving the request. If this timeline cannot be met, communication will be provided with the adjusted timeline and reason behind it.
Personal Information - * Hacking & Coffee will proactively delete any Personal Information not necessary for communication after the completion or termination of associated work. This includes, but is not limited to, Access Codes for facilities, logins for computer systems, biometrics (including body measurements for any custom fabric work). Medical information will be proactively removed unless ongoing work is discussed, in which case only the minimum information required for safe operation will be maintained (such food to avoid bringing to a customer site for allergy purposes).

Outside of the two exceptions defined in the next section, Hacking & Coffee does not share any data without explicitly asking for consent directly.

Exceptions to this Polixy

If we receive a lawful request for data - We will fight for privacy rights but may not always have the ability to prevent information seizure by the Authorith Having Jurisdiction (AHJ) in the related matter. Unless a gag order is in effect, we will never provice this information without informing you.
If an active, former or prospective customer harrasses, intimidates, or otherwise causes problems resulting in termination of services or harm to us or our customers we reserve the right to keep information to preserve evidence. We reserve the right to share this information for purposes of prosecution or safety of others where applicable.

Outside of the above sole exception, the following terms apply to all other data and personal information.

]]>

Cybersecurity Consulting Services

Mon, 07 Apr 2025 00:00:00 -0500

Who We Are

I am Hon1nbo, and I am a Red Team operator with over 15 years of technical experience in the field. I specialise in scenarios where “the gloves are off,” and there is a goal to obtain by almost any means available.

“We?”

I will often use the Royal “We” for these services, as depending on the nature of the project I have associates that may or may not be onboarded; these are colleauges I have worked with for a number of years. Generally when you hire Hacking & Coffee, you hire Hon1nbo.

Consulting Services

Our general consulting services contain your usual full-scope, adversarial red team operations. However, we have broad experience in a variety of niche spaces and training:

Hardware Security Testing for embedded devices an OT
Tamper Evident detection & forgery testing
Speaking services at events for educational purposes
Application Security testing

All of our consulting work can be done from static or dynamic perspectives.

Contact Hacking & Coffee

To learn more about our offerings, reach out to us via ourSecure Messaging System) to discuss your needs. Depending on the work required we may be able to furnish some sample reports.

~Hon1nbo, Proprietor, Hacking & Coffee LLC

]]>

RIP LinkTree worker; Long Live LittleLink Worker!

hon1nbo — Mon, 07 Apr 2025 00:00:00 -0500

LinkTree

was handy, and I made some graphics that actually fit. But Ireally wanted to use my domains. I did a workaround in which I setup a reverse proxy with Cloudflare workers. This worked, but broke alot. You see, LinkTree sets up Cross-Origin Resource Sharing (CORS) policies. For sensitive services this would have been a good thing. For account management, a good thing. For an always-public link sharing site? Just silly.

Well, I did something even sillier. So to reverse proxy this service we had to handle the static content as well as dynamically loaded assets. Of course, them putting it all on a single domain would have been too easy. So I did some fancy rewriting scripts. But these broke a lot as they updates their services under the hood. So recently, with more breakages causing the images to fail to load, I decided to toss the tree out to the curb.

LittleLink

F/OSS replacement for LinkTree, and runs on Cloudflare pages without even having to run a build? Entirely static assets? Updated CSS with modern services? Yeah, I should have done this waaaayyyyy back.

So thanks LittleLink for making my life easier.

You can see how I runhttps://hon1nbo.com usinglittlelink inMy Repo.

Cheers,

]]>

The Tail

Mon, 25 Nov 2024 00:00:00 -0600

There is a lot of history behind my tail. It has been to hell and back with me, and can easily be spotted in a crowd. Well,allegedly.

I myself do not know why people assert I have a purple and black tail attached to the back of me. It has gotten rather annoying, and really needs to stop. In light of wanting these allegations to stop, about me being something called a “furry” and having grown a tail, I have decided to prove it does not exist once and for all. I shall collect evidence to show the tail does not exist, and continue to post details that people assert are true about this mythical tail.

-H

]]>

About Me

Fri, 22 Nov 2024 00:00:00 -0600

First and foremost, the alleged “tail” has itsown section if you are inquiring about this imaginary purple ball of fluff. Seriously people, grow up. Still here? Ok.

I am Hon1nbo, and I am a Red Team operator; I tend to keep my professional and independent work separate, and this site is devoted to my independent work. Here I post about things I disclose, code I release, and projects I support. In fact, some of them I think I may have invented. Legal abuse techniques are patent pending. What do you mean I can’t patent filing paperwork in the county court system to inject a Cobalt Strike Beacon payload into a target with a cease and desist and unwitting process server? Blah, they’ll approve it.

Moving On.

In the meantime while I clean up the dust, and drive the minions to compile the large amount of content in my archives, you can sit there hitting refresh ad-infinitum.

]]>

FAQs

Fri, 22 Nov 2024 00:00:00 -0600

Who are you?

I am a hacker who tinkers for the fun of it and to satisfy the basic human nature of lighting things on fire. I have this thing called a job. I get paid when I take selfies in other people’s vaults in the middle of the night. I don’t know if it is real.

What do you do?

I think the better question is what don’t I do? I have built electronics to my heart’s delight, dabbled in Radioactivity, made a small business profit with Thermite redox reactions, taught myself lock picking at the tender age of 13 since I regularly got locked out of the house (no joke, my parents didn’t trust me with a key), I have worked with a dozen traditional art forms (plus a few I made up), insulted someone attempting to hack my server through an FTP console, played sports, shot some crummy short films (and some awesome high speed vids), and programed a radio at 3 in the morning using a Speak-n-Spell to call “CQ Field Day, this is ** Fried Chicken, may I take your order please?”

Then there is my day/night job. I take selfies inside of other peoples’ offices and vaults, I crack open safes, and I drop those SQL tables off at my friend Bobby’s house (who is suspended from school for some reason).

Why do you do these things?

Here’s why:“We choose to go to the moon. We choose to go to the moon, we choose to go to the moon in this decade and do the other things,not because they are easy, but because they are hard,because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.” – John F. Kennedy, 12th of September, 1962

Are you certifiably insane?

I assure you, I am not. My tail told me so.

But then why are you talking to yourself in the comments?

I’m not, I’m talking to you!

But aren’t you typing this?

… By using the differential equation(d^2)x/d(t^2)*Y + (dx/dt)*F + R = 0, I can integrate the equation, reject the value of yourReality and useu substitution to solve thatYour face is the derivative of myFist

]]>

Pardon the Dust

hon1nbo — Fri, 22 Nov 2024 00:00:00 -0600

The old site

was wordpress and is falling apart… then again, the entire Wordpress ecosystem is failing too so whatever. It’s been due for an overhaul for quite some time. I have a backlog of projects and research to do writeups on, so I decided it’s time to revamp things. Thanks0xDezzy for helping in your spare time to work on formatting this with me. I’ve run a handful of Hugo instances now but I’ve been too swamped working on my long distance move, so it’s been a huge help.

Once the content is migrated over,

and the formatting fixed up a tad, this will migrate to Apex domain and I’ll keep the wordpress site on a subdomain for a little while but I expect all updates to happen here.

Cool Stuff Ahead

Once we settle the formatting, there’s bound to be cool stuff updated here as I have quite the backlog. Stay tuned for exciting and dull work such as:

BGP Shenanigans
My infamous talk onSocial Engineering & The Human Condition
The BSidesDFW badge writeup and lessons learned as a first time conference badge maker
Outrageous Home lab: 50 Gbps residential service, Zero Trust, and a whole lotta tunneling
Who knows, maybe even my uncensored contributions toRainmaker’s social engineering talk that was censored by the US Department of Justice because ofFurry related things.

Cheers,

]]>

Datacentre Shutdown

hon1nbo — Wed, 03 Apr 2024 00:00:00 -0500

It was a long time coming, but we finally reached shutdown day for primary services. So naturally, half the links on this site to status monitors, mirrors, and other resources are broken. Some services such as this blog were moved to SaaS for the time being, others completely shutdown.

It’s on my back burner, but this blog will get a revamp. I have a backlog of content to start publishing as well once it gets cleaned up.

To all of our former customers, we thank you for your patronage. To all those who downloaded from our mirrors, we are sorry that you now have to use slower alternatives

But seriously, it’s been a wild ride. We started hosting around 12 years ago. Thank you all.

]]>

Site & DC Migrations

hon1nbo — Wed, 31 Jan 2024 00:00:00 -0600

Things are messy as I move stuff around. May be a while. Most updates I post on Twitter/BlueSky these days.

Check back in a while; I’m hoping to release some writeups in mid-2024

]]>

My Github: Why the Emptiness?

hon1nbo — Wed, 14 Oct 2020 00:00:00 -0500

I recently got an ask:

why is my github relatively empty?

I’ve worked on a lot of fun stuff, and I seemingly fork a lot of things that end up sitting there. Well the easy answer is to say that most of my work is in private repos / gitlabs. But that doesn’t cover every case.

To start, I had a lot of repos on my public github that were made, and had basically nothing done. These are usually when we have an idea amongst a group of friends and in the early stage I’d throw up a repo to have it. They’d get invited and most of the time things fizzled out. Other projects to work on, or the idea just wasn’t there. But it acted kind of as an anchor to remember the project and toss things if we actually did anything.

But why the forks with no new commits?

The majority of it has to do with the nature of my consulting job. I have shop rights for some things, but not for all. Any time I need to tweak a project to make it work for whatever I’m doing, I typically try to fork it first. That way if I am allowed to push whatever it is back upstream, or want to, I can. More often than not I can’t. Either the code is disgusting and barely functional because I had to write it on the fly, or it would somehow get murky legal waters between client and employer. Often they’re one-offs to do something that’s already an edge case, and often not valuable to upstream devs as they’d also become responsible for maintaining it if I pushed it. I like to write most of my code like I assume the next guy is a homicidal psychopath that knows where I live. However, in practice this is not always feasible due to time constraints. For example this project I bashed out in about 4-5 hours of panic after I was asked to save a botched project at the last minute:https://github.com/hon1nbo/BCTt )

That’s an example of when I had more time than a lot of the tweaks and scripts I’ve used. I also made a config script and the README for that before I pushed it, as originally the client-specific secret was hard coded. That’s a project that I made for an edge case, but actually was usable outside my specific needs. In my work however, I’m more often trying to make tools work in client-specific cases, where either the need doesn’t exist outside their network or I’d be giving too much away by sharing it.

So most of the code sits, or gets scrubbed. I have a lot of personal projects on private repos still I’ve been mulling the release of.

]]>

The End of an Era

hon1nbo — Wed, 08 Jul 2020 00:00:00 -0500

It is with a surreal sense of melancholy I announce that on July 15th, 2020, I will be shutting down the last of our user hosting. It has been a long, winding journey for my peers and I.

The research projects

and personal things will continue here, but it’s time. There are a few branches at the root of this decision: the departure of customers due to their own ends of operation, prospectives that do not follow through with basic requests for information such as amperage requirements or IP justifications eating time I could spend elsewhere getting a serious client, and ultimately COVID causing an inability to spin up new customers.

This marks the end of an era for me, and I’ll spend the rest of this post

looking back on this journey.

I hosted my first website on the public internet back when I was in Form IV of schooling. I had made my first web pages in the late 90’s as I was required to learn HTML in primary school. This public page was different though, as it was meant for engaging people rather than a personal project. Before Facebook was public, and privacy was non-existent on other media, I had decided to setup a forum for my class of 40-odd schoolmates. It was a safe haven for us: no teachers, no parents. We could be ourselves and talk about life, the universe, and everything. Back then I had enough linux under my belt to run some distributed computing but never learned much about the network protocols that backed my Beowolf cluster and 3d rendering farms, as various things abstracted it away. This would ultimately prove to be a changing experience, as I was caught trousers down with a Security Incident. For various reasons, mostly laziness on the sysadmin side to focus on the PHP coding and re-purposing an existing machine in my parents bedroom, I loaded a Windows XP system with a WAMP stack. I logged in one day and I had a ton of alerts from the system anti-virus. It was talking about all these ports being scanned from the LAN and network attacks. I panicked; to be perfectly honest, netsec wasn’t a skill of mine at the time. I was more befuddled when I logged into the system that was supposedly breached to find not a shred of information. In the resulting panic, I did some stupid changes and ended up bricking the xp box. I had the SQL backups in hand, and decided it was time I learn linux for more than just abstracting away the computational tasks from the application level, and start getting more into network services. As curious as I was even then, I had a serendipitous find of a Linux distribution with a focus on security. Neat!

That distribution was Backtrack

(then r2 or r3 I believe). As someone unfamiliar with it, I tumbled down the rabbit hole all exploring it. Whilst it dawned on me during the next hour of playing with it that it was far from a secure operating system itself, it was excellent for me to learn about the network security I clearly lacked. In a bit of passion for a new interesting thing, I decided to install the LAMP stack on backtrack anyway and use it as a jumping point to learning AppSec and NetSec. The first challenge? Learning some intricacies about memory paging, chroot, and how to migrate a live-cd operation of a website pushed into production mode without taking the system down.

That last part was, admittedly, foolishness on my part for not paying attention after getting caught up playing with the tools in the live CD. For you see, after playing with those tools I set about my original task of installing and pushing the site back to prod… I never stopped and actuallyinstalled the operating system. Well, by the time I realised this schoolmates were already chatting away. F*&#ing hell.

Some of you that caught the Backtrack version may already be having a laugh at my expense, others may not realise how much I screwed the pooch: in those days, Backtrack did not have an installer. To make a persistent install required getting OS contents onto disk, remounting runtime directories and popping chroots out of memory back to disk. Not too bad, except I didn’t want to take the system down. This meant learning about file handlers, process deadlocks and spinlocks, etc for dealing with active mounts for processes. This actually ended up being a useful skill, as I’ve used it in red teams extensively for sneaking data onto NFS mounts with hot-mounting points to avoid taking offline services that are talking to the same mounts. But I digress, onto the show.

Fast Forward

to Form VII. I’m at the point where I’ve been evading most of the administrators at my school so I can get my schoolmates football fix on the computers, running a shadow IT WiFi network for games when the monks looked away. I’d taken to optimising the networks of family and friends for some stuffing for my coffers in my spare time. As graduation came around, two fellow nerds from a nearby school schemed with me on a business idea. Content Management Systems had been growing in popularity, and there was money to be made in building out sites for them. We setup a Partnership under the name Geeks at Work Solutions. It was pretty easy work for the most part: we’d get media and design desireables from the client, we built the site and templated things out, did custom integrations and styles as needed. Simple stuff.

Well, after we started having 2-3 projects going at once the services of GoDaddy really lost their lustre. I looked at some refurb server gear at a local shoppe, and decided to drop a box in a Colocation facility. It was cheaper for us than the GoDaddy garbage, we had better control, and we could actually test mail functionality without hitting walls of bloody shared IPv4 on those systems. This made for an interesting ask of us. As we started handing over sites developed on this gear, customers started coming back saying it was faster with us than anywhere they tried. We got asked to host and, after some optimising and tweaking for multi-tenancy, we started offering shared hosting. Before we knew it just that alone was paying all of our costs. Requests came in from one customer to host their nephew’s or someone’s minecraft server. We gave it a VM on the box and apparently we were the talk of his friends, and things just grew from there. To spread our name we started hosting F/OSS mirrors and Speedtest.net. For some time, in Dallas, one downloading firefox would get a notice “This download provided by Geeks at Work Solutions” and we got some business from it, but never did determine just how much exactly. Either way it was a good way to give back to the community as I studied more InfoSec in the background.

We moved out of the by-the-u colos and settled in a facility with a full cabinet. From here we started setting up Orchestration, hypervisor clusters, SANs, etc. We kept things fairly small; this was just a side gig. We weren’t even doing web development or CMS work at this point; some nerds were paying upwards of $200/mo for minecraft servers that could run with 100 players at once in creative mode.

The milk overfloweth.

And thus was the first test of commitment:we married our cow.

All of our servers depended on Bukkit; a community project that, out of the blue, basically shuttered and one of the core devs started issuing DMCA notices against their code in the repository. There’s a long backstory to this but, as a side gig with no legal team, it wasn’t worth the risk to us for offering as a service and use the various integrations and management consoles that now had drastically changed their license schemes. We let existing customers stay, and pivoted to offering generic VPS services. These were not nearly as successful, but there was enough business to keep the lights on. We used the excess capacity for personal projects: I did training and research on InfoSec, I let some buddies have space for dev work, and I expanded on hosting mirrors for various F/OSS groups. We dropped Speedtest.net because they started demanding dedicated 10G and we weren’t going to pay for that just to have our name on their board.

This was the status quo

until about 2017. I was out of university, and the ethereum mining craze was having another bout. I arranged with the colocation facility a cage with a number of high power drops and charged miners for stable power and networking. We didn’t mine much ourselves, but the miners paid for the cage. We had an arrangement with the facility to drop the cage when the craze died down on a non-contractual basis. But with this extra space, one of the partners wanted to make the hosting a serious business and more than a passive side-gig. This was already complicated, as one of the three of us was in med school and the other had been passive due to commitments from their own consulting work. We settled on a goal: I was to develop better customer management and automation for most of the typical tasks, and he had to get up to speed on networking and our environment. I invested personally into the business with new hypervisors, licenses for management software, new SANs, bandwidth, etc. It was a pretty penny, but I considered investing in my business something to pursue.

We get a few months into the build out, and I grow concerned. The partner was behind on their training, buried in their consulting. After trying to push through it happened: over dinner with some friends, he throws a lightning bolt into the discussion. He was backing out of the hosting business, simply because he’s sick of it. Just like that, I had no partner left that could be the second admin; I was a truck factor of one, and even for a small shop it wouldn’t be acceptable for any of our customers. Having contractual obligations to some users for disaster response that can’t be met, they had to drop. Without the second admin it’s not worth pursuing the expansion. I decide to cut my losses, as I’d only be digging deeper into the Geeks’ grave. With more customers gone as I start pushing them out, the mining craze ends for that season. It also happens that the datacentre I was in lost quite a bit of money on the craze so, despite the several breaches of SLA and contract they’ve made with us, decided to fight for paying additional months on a cage that we had in writing we could leave with two weeks notice. Well, this would have needed to be fought as a UDAAP lawsuit since the fine print says one thing but all the statements elsewhere said another. As I’m fighting this, with finances out of pocket paying that datacentre bill in the interim since the partner refused to cough up their personal liabilities (as is the nature of partnerships in the states), the next life changing event happens.

At this time, I was working for a cybersecurity consulting firm. It was good money, I just moved into a better apartment, gotten a cat. Then the manager apparently decided to cover up some unethical practices by using his ability to threaten to fire me if I don’t participate in said practices. With the head of HR on maternity leave there was no one for me to escalate to. My attorney looked at the information for the incident and advised me to walk immediately; as in same day, if I spent another hour at my desk working for them I could be implicated. So, the principal consultant for this cyber security firm on a massive staff aug contract with a dozen people just walked out of a client office. Suddenly without income, still with a several thousand dollar per month hole-in-my-skirt, I have to make some critical decisions. I ended up settling with the datacentre provider because I couldn’t afford the time to fight it when dealing with the issue that came up with my employer. I moved the remaining servers and clients to a new LLC, and dropped them into a different facility with much smaller, but more manageable, resources. These 5-odd remaining clients weren’t much, but they paid for the rack I used to continue training on my goals and performing independent research.

This was the birth of Hacking & Coffee

At this point my hosting wasn’t for businesses, or for profit. It just paid for me to do cool things in cybersec. I was up front with my customers about this; there were no rules as long as I don’t get complaints from my carriers. The performance was raw, the bandwidth unmetered. They were given cut-throat rates. At this point in time about 3/4 of my rack were sublettors. Why did I sublet that much space for only using 1/4 rack myself? I needed multiple carriers, and this was the bulk of the cost. Most of my personal research at this time involved BGP on public networks. Whilst the project bore some fruit, I ran into roadblocks involving a conflict of interest with my employer and the research was put on hiatus. I resumed this research much later, and will wirte about it here soon. I additionally used the mass of IPs I acquired to help with setting up C2 forwarders and test environments for non-attribution. I used the excess hypervisor capacity to spin up an EDR test range for payloads in my red team work. It was bliss. I never expected it to last forever, but I did at least hope that those remaining clients would stick around. As finding a new customer to replace one isn’t easy when there is no client management, no space for them to grow to several units of rack space after dropping one. The users I had knew what this was, and so did I.

I had the first drop in 2019. The user had personal financial trouble, and that’s fine. I ate the difference, but it was about 10% of the rack cost now onto me. As another dropped it was a similar situation. I kept running it anyway since I could afford it.

Then COVID came along

I usually could get a new customer for a while to fill the void, but with COVID datacentres in this region started putting moratoriums on non-critical repairs. This means no new customer drops. I wasn’t able to bring people in, and others left because their own lives were upended by the pandemic.

Simultaneously, my funds for research started getting cut back as an austerity measure from my primary employer. At this point I’m holding for a few months whilst I try to find some new customers that can commit once hardware drops can happen. I’m unsuccessful, not because of lack of interest but the demographics of those that contact me. Most are sysadmins who seem to have never planned out a colo. Stumped at determining amperage requirements, how to plan for spare hardware for a rando NOC tech to slap in, and whether their systems had the right voltage power supplies, (seriously; it’s actually kind of impressive to find servers with 120v only power for a world dominated by 208v in the states). I’ve wasted an number of man-hours fielding those requests. I never respond to larger businesses, since I know I couldn’t support most of them anymore.

With only these types of prospectives, and COVID dragging on, I made the decision. Hosting by small groups had already gone the way of the dinosaur, and cloud prices have dropped dramatically since I started this long journey from being 10x costlier for the resources, to now being $5 VPS instances. I resolved to keep some systems for research and personal things, but all the customers have been given notice.

It’s been a wild, weird, and ultimately insightful journey. I’ve honed skills, made industry contacts otherwise impossible, and I’m known by many people as “that wolf with the really fast Arch mirrors.” I’m proud of the work I did and despite the ups and downs,

I’ll miss it.

I’ll continue to host the F/OSS mirrors, though they may not be as fast as they once were. At the very least I still want them for myself, but might as well let others have at it.

So long hosting, and thanks for all the phish,

P.S: for those already asking as they’ve heard the rumors about this, I donot know of what that one big mail-business client of mine will do. I still don’t have a plan from them, and we’re 1 week out now. I’ve already had to disconnect them once; I wouldn’t put it past them to have it happen again.

]]>

Red Team Laptop & Infrastructure (pt 1: Architecture)

hon1nbo — Wed, 28 Feb 2018 00:00:00 -0600

I get a lot of questions about my laptop, ranging from “Windows or Mac?” to “do you have a preferred chipset for Ethernet NICs.”

Well, with the exception of “neither” to the first question, most things will vary. Rather than talk about specific hardware or version choices, I’m going to talk about Architecture; in future posts I’ll talk about specific ways of implementing my Infrastructure architecture for supporting penetration testing, but for now we will focus on the high level. This design is Reasonably secure in the right hands, fast, and extremely flexible.

Requirements

Let’s start with some basic requirements for an assessment laptop.

Reasonably Secure
Granular network control
Access to assessment firm domain / internal resources, whilst having access to client side systems
Long term storage of tools, documents, and other artifacts
Tech Agnostic

That last item tends to be the tricky part; in red teaming, one never knows what they will encounter and usually they will want the most capability on hand, and no restrictions on what their machine can talk with or plug into. At the same time, said things being plugged into may pose hazards, especially to machines that have multiple client tenants.

The Architecture

High-Level Breakdown

At a high level, the pentesting laptop is basically a hypervisor with a minimalist user interface, and all the actual work is broken up into VMs. Before anyone says “This is Qubes!,” the issue here is that the Xen beneath Qubes doesn’t get a long with some items in the field, and this has a far higher level of granularity. Qubes’ design, and best role, is a defensive endpoint; it is not designed for offensive work, and does not contain the testing required to ensure a stable build like Kali Linux for purposes such as pentesting and exploitation. I’m still keeping my eye on the Qubes project though in general, and do run it on some of my other hardware.

Each client or project is given a linked clone of the associated base VM. This allows for lighter disk space requirements, as well as ensures only a few VMs need to be regularly updated and configured.

We have three networking zones, and one independent VM.

PfSense independent VM
Trust zone
DMZ
Dirty Zone

Networking

The PfSense controls routing between the zones, of which Trust contains items such as a Domain joined windows box for internal corporate access, as well as VMs containing proprietary items; the DMZ contains items that aren’t explicitly malicious, but not trusted either. This is general web browsing, scouring for known exploits in what may turn out to be unsavory places, etc; then there is the Dirty zone, from which all attack traffic and malware originates or is inspected. Zones can talk to only the network resources they need, and nothing else, and are enforced through the PfSense firewall. The Trust zone is only granted outbound to the corporate VPN endpoints; the DMZ has general internet access, but nothing else; and the Dirty zone is granted access to the clients’ networks for their respective work.

Wait, “clients” plural? This is where this architecture really shines. Often, a team will find members are pulling double duty with multiple clients. Sometimes is because of license limitations needed across multiple projects, sometimes it’s just the availability of the talent. Regardless, we can all agree that it would be bad of attack traffic for one client started hitting another. Let’s face it. VPNs suck; they drop, they stutter, and clients often have vastly different ideas of what traffic can go over them. Some clients provide VPNs that tunnel everything, some only provide VPNs that tunnel items in their address range. This means that, in the end, you can end up with a lot of traffic go over the local network that is undesirable. Such traffic can get you caught easily by even crappy network monitoring systems, and some may choose to take down something it shouldn’t.

Using PfSense, we can create rules for where each specific VM can go out to. No out of scope items sent, no dangerous exploits mistakenly sent to that delicate legacy system rather than that stubborn system you’ve been poking at.

Practical Hardening

We all know that theoretically a hypervisor is robust and secure; practically, things are a bit more complicated than that. The most common exploits are usually environmental rather than on the core hypervisor: VM extensions like copy/paste and virtualized interfaces, or attacks like Spectre. However, the systems can still be reasonably secure. Most importantly, they can be reasonably secure whilst still being usable.

Disk Encryption

Full Disk Encryption (FDE) is a matter of debate among some experts. Should I use something like LUKS (software FDE)? Should I splurge for an OPAL compliant Self Encrypting Drive (SED)?

Well, the answer will depend partly on your threat model, and choice of hardware other than the drive itself. Software FDE is known vulnerable to cold boot attacks on s1-3 sleep states or a locked screen, and when Direct Memory Access (DMA) interfaces are available. These DMA interfaces include Firewire, Thunderbolt, USB 3.0+, and PCIe. Exploiting these, depending on the system configuration, is possible but not always trivial. SEDs are resistant to these attacks, the key is never in memory, and there is zero performance hit. However, they are vulnerable to a hot swap attack in which the data lines are connected to a different machine whilst keeping the drive powered and unlocked.

Attacking SEDs versus software FDE systems is well documented and out of the scope of this write up. Personally, I chose to go the SED route, as my laptop hardware enforces a drive power cut for it’s OPAL configuration on soft reboots and data loss. However, this should be evaluated based on your hardware at hand.

Extensions

The guest extensions are a must when using the desktop environments rather than headless VMs, but we can mitigate the risks. Items such as copy/paste are disabled by default, and enabled on a case by case basis. Simple enough

But what about the Shared Folders? The host machine may have, across all VMs and storage, a history of clients, reports, and exploits that are not yet public. Kali Linux, on the other hand, is not a very secure OS (though it can be; stop running everything as root!). How can we mitigate attacks?

First off, don’t mount folders unless you have to; I set my base images to have the configurations for it but disable auto-mounting. When a VM needs it, I flip the switch and specific a specific path.

Second, mount the shared folder on the host with a local bind. Using this, one can set an enforced fmask, dmask, and noexec that disables execute bits on files and enforces permissions. This prevents a VM from writing items in another user’s context on the host machine, and from the setting of execute / setuid bits on files. It’s a neat trick, and using the local bind allows for doing this to specific folders on the host machine. If storing data on a separate partition, mount the partition using the normal means with these flags rather than a bind.

Look, we’ve already solved the practical attack vectors!

The Bigger Architecture

In the bigger scheme of things, having a local kick-ass laptop build is nice but it can do more. Let’s take a look at how I tied this into a red team support infrastructure.

In the support infrastructure we have a PfSense image running in a provider such as Google Cloud, with backend C2. This can, of course, run on any externally available environment.

Using site-to-site tunnels, we can secure all the VMs on the laptops without burdening each one with a VPN connection individually, rather letting the PfSense image handle the load. This helps mitigate effects VPN tun and tap interfaces have on toolchains, which often break as the local network changes. At the same time, the external address of the cloud PfSense image is accessible to our C2 payloads, such as Beacon.

But let’s say your tool needs a direct callback; thanks to the site-to-site, the cloud PfSense can forward the connection to the respective red team member. Each team member can open ports and forward as needed, either to their laptop (which the local PfSense can send to a specific VM), or to a backend compute instance such as a Cobalt Strike teamserver. It is always recommended to separate various red team phases into separate servers, and thanks to multi-WAN support in PfSense, the same routers and rule systems can handle multiple C2 points between the same team and set of resources, following the entire engagement life cycle.

At a high level, this is how I run most of my infrastructure for a red team engagement; in the future I’ll write up some specifics on how to get it running. PfSense has amazing documentation, and I wholeheartedly recommend it for anyone who needs a featureful and reliable routing and firewall system.

Cheers,

]]>

Unique Policy of Transferring Usernames by Telegram

hon1nbo — Thu, 01 Jun 2017 00:00:00 -0500

Telegram has been around for a little while now, and its user base is growing. However, despite their attempts to be the secure system to beat out the larger social networks, they have one particularly alarming policy: They will transfer a username unilaterally from an established account to another.

It recently came to the attention of a larger audience after a user, who had the handle@saman, had his account taken over by someone who claimed the handle on other services, described in detail in aMedium post.That user was in fact acting maliciously, however Telegram’s official policy would affect users even in cases where the other accounts are legitimate.Here is the verbatim policy, reproduced below:

Q: What do I do if my username is taken?
Telegram usernames are distributed on a first come — first serve basis.
We understand that certain usernames are part of an online identity for some of us. If your desired username is already taken, we will be happy to help you acquire it for your account or channel, provided that you have that same username on at least two of these services: Facebook, Twitter, Instagram.
This is concerning to say the least
I wrote aninitial response on Telegra.ph, however it was not comprehensive and covered only one case (poorly I might add, since it was written quickly I implied that a conversation already existed in a current state when I said they talk regularly).
So here I present a set of conditions this policy does not account for, and reasons why most large providers have set a long agreed upon industry standard fornot reissuing usernames or handles.
Let’s have the following users:
Bob: the user who had @bob taken from him
Alice. A potential victim, and a friend of Bob’s
Charlie: A potential victim, who has not yet talked with Bob on Telegram but Bob already had shared contact details with. Could be a business contact, an acquaintance, etc
Eve: The Evil user, who wants to either impersonate Bob as a goal, or convince Alice or Charlie of something using Bob’s trusted status amongst them
Let’s also have the following conditions to exploit this:
Bob does not have his handle registered on at least two of the three services Telegram describes. Bob may not have these because he is unaware of the Telegram policy and simply does not use them, the services are blocked in his geopolitical region (government censorship, etc), he may not want his real name tied with this handle for privacy or safety reasons (LGBTQ discrimination, abusive ex-partners, etc. Facebook Real Name Policy), or he may not want to violate their terms of service by opening an account purely to squat on the handle when not using that particular service (Instragram ToS, using a fake name on Facebook) – n.b: none of the services Telegram allows for this to “verify” who should have the account themselves allow a handle to be taken in such a fashion, as industry standards dictate. The only exception is Trademark disputes, which require legal action and only apply in cases where the username was originally registered with Malice.
Eve can register the handle on the services. This is considered a trivial action, as Eve is not acting within the law necessarily and may break Terms of Service to create such accounts.
So what does Eve do after registering the handles on two of the three services? She only has to request that Telegram transfer the handle to her.
Bob receives the notice, but none of his contacts do. There are two possible ways a contact knows that Bob has lost his handle:
If Bob can communicate it manually to all of them, or there are a lot of contacts (Bob may miss one).
If Bob and the contact have an established conversation that is currently active, but this assumes a user never resets their device, that they don’t clean up conversations that have not had activity in some time, nor that there is an established contact in the first place (not possible if a handle is provided on say a business card, and that user has not contacted him yet). Items like Business Cards have long spans in which they may still be used by the recipient, similar to how long users may inadvertently messaged an old email address not knowing if the user had moved on. Hence, why organizations like Google do not reassign email users.
This can cause a lot of havoc, especially in the case where one has, I don’t know, dropped over a thousand business cards at networking events with that handle? Or if someone has had this handle listed on every major service they use (which, as the Streisand Effect shows, even if trying hard the Internet never forgets as it is cached somewhere, somehow).
Below is a basic attack path for a common conversation amongst furries with an established handle (at least allegedly around me… don’t know why people say they see me at FurCons, or why people say I have a purple tail and ears. I find the accusations outrageous).
See how this can quickly become a problem? Since Charlie does not have Bob as a phone contact, the handle is the only method of opening a communication channel. @Charlie would have no way of knowing about the name change. Why does Telegram allow this? Telegram don’t have a clear answer to why they believe this is a non-issue.. They say the policy is as it is because their legal team is small, but if there was an actual Trademark dispute then it would be a different scenario in the first place (and a court makes that determination, not Telegram). I have had some interesting discussions on twitter, but no productive explanation came of it. Some defending Telegram blame IG/FB for something that they have no control over (i.e. Telegram’s policy choice), but that has not been an official answer either (and would be an unacceptable one if they officially said that)
I guess I’ll wait to see how this plays out in the long term. I already found some juicy targets should I be more thanthinking maliciously, and chose to act. I hope Telegram chooses to make the right decision and get with the rest of the major players in handling username transfers (i.e. don’t).
One other comment, though not from Telegram, was that this policy had been in place for 4 years and this was the first trouble. Well, this is a common argument amongst developers in general for considering something a non-issue. It is not a good argument; it just means there hasn’t been incentive to exploit it yet (either due to user base size, or lack of interest). There are well documented cases of stealing user handles (including the extremely rare single character twitter handles). At the same time, I have seen this argument made for reasons not to patch critical systems, and not deploying best practice. My personal favourite has been a client that claimed “we won’t fix this because it’s behind a firewall & VPN, so these trivial RCEs are not exploitable.” Now, I didn’t say it was easy to exploit, but they were trivial to fix as well but the developers wanted to push features in that change window instead of fixes. Well, I got a good laugh a week or so later when an 0day for that particular firewall dropped, and sure enough they got pwned almost instantly. I guess Karma has a good sense of humor.
]]>

Serving Malware via Physical Legal Documents

hon1nbo — Tue, 07 Jun 2016 00:00:00 -0500

I have decided to post about a personal trick I created and have used for quite a while. Given that most process servers are private entities, rather than actual members of the court, they are ready for hire without filing an actual legal process. Thus, it is possible for an official looking person to arrive at a target and present the payload in person without ever leaving a trace of your identity. This physical legal document has successfully gained my administrator credentials from targets that normally have a high level of security awareness, and usually catch phishing attempts.

Below I show a sample of the “Cease and Desist” order I created (client information redacted). I had sent emails from a “cyberlaw clinic” webpage earlier, expecting them to not be trusted. I even said in the emails that “official documents will be arriving shortly,” and that “this email copy in PDF form is for reference only.” The PDF was not spiked. However, the website was with some browser exploits (and a decision to “require” javascript to view the site).

Upon being served the document, by an authentic and unwitting process server, the target will try to react as this is a legal notice. Usually, this involves writing a reply. If they reply by email, then I can spike the PDF of subsequent exchanges. However, some may note that there is no return address specified in the document. This is intentional, as it drives users to the infected website to find the address or phone number of the legal counsel. This causes the victim to open a malware infested webpage that they otherwise may avoid and, in the case of my targets, disable their browser protection plugins such as NoScript.

Phishing is always going to catch some victims off guard, but there tend to be stubborn targets. Given the nature of the legal system in most modern countries, including the USA, it is worth noting that most people will want to get a legal threat off their table as quickly as possible. Combined with the knowledge that incidents such as employees using corporate networks for nefarious purposes leads to this as a useful attack vector. Companies receive notices such as this cease and desist fairly often, and respond with the usual “the employee has been fired/disciplined/otherwise dealt with.” However, given that law firms have power to do significant damage, and almost universally do not have PGP signed emails or documents, there is little a business can do to avoid opening the affected law firm site or emails in one way or another. Risk here can be mitigated by sandboxing the unknown source in a virtual environment. For the administrator I last targeted with this, an additional recommendation was to not use an administrator account for daily activities but rather a standard account, leaving the admin credentials for when actually performing admin duties.

]]>

Capacitor Pulser Bank (v2)

hon1nbo — Wed, 06 Apr 2016 00:00:00 -0500

(another project from the archive)

I built a capacitor pulse bank a while back. It was installed into a large suitcase, and was using large electrolytic capacitors (so no super-fast rise times, but a fairly decent amount of energy density for the cost).

Caps: 6x caps rated 5600uF @ 500V ==>E =(1/2)C(V^2) =4.2 kiloJoules of energy.

The Pulse Bank was designed to fit into a Pelican 1600 case for durability and ease of transit. The case included a wired remote control, the capacitors, and a triggered spark gap. It was fairly simplistic in design, but useful for a time. While most of my project videos and files were lost in a set of failures long ago (who would have expected an entire RAID 6 and backup system to go within the same week), these photos are here at least as what was recoverable.

TKTK images

]]>

Underwater Remote Operated Vehicle Project

hon1nbo — Sat, 01 Jan 2011 00:00:00 -0600

A Remote Operated Vehicle, or an ROV for short, is any vehicle that is remotely controlled. This term, however, generally applies to remotely operated underwater vehicles, and that is precisely what this project is. My goal was (and in a sense still is) to create an ROV with live cameras, room for expandability, internet control, full maneuverability, and a true variable ballast buoyancy control system (similar to what Submarines and SCUBA divers use, rather than make a neutral system and use props which is boring).

This project was undertaken as a project during my time in high school, and is something I intended to pick back up at a later date. With SBCs and hobby level PLCs becoming ubiquitous, I think this can be done quite well should I try it again. This is here to show what was feasible on a shoestring budget in 2010, with zero machine shop access and a single studcent working on it. I even got it controlled over the internet from an iphone with a live camera feed by the time I was done. Honestly, I’m proud of that for the time it was.

The below is the report I presented to my high school senior project advisor, who coincidentally worked on a submarine for years so maybe it was fitting or maybe it was terrifying. This much time later, I can hardly remember.

Introduction

The goal of this project is to make a Remote Operated underwater Vehicle (commonly referred to as an ROV). This ROV will have live cameras, full maneuverability, and full control from an electronic control device on the surface. The applications are very diverse, from an educational venture to an underwater camera rig for film (both entertainment and research filming), to a rig capable of operating tools underwater too long for technical scuba diving. The unit, measuring at 45x20x22 inches, is large enough to support cameras and other items, yet small enough to fit in the back of a large SUV. The ROV has a few main components: theControl Interface, theROV Main Body, theROV-to-Surface Tether, and theROV Electronics. All descriptions before the full work documentation are of the current system, for older design refer to the work log itself farther down the page

The Control Interface

The controls can be incorporated into any electronic device capable of operating over a standard WiFi or Ethernet network, such as a laptop or, for experimental purposes, a Cell Phone. All control is done using a web browser such as Internet Explorer or Firefox. Firefox is my preference because it is easier to customize, and I can use GreaseMonkey to help modify my control web page to make things easier on the ROV web server. These controls allow propulsion in all three dimensions and control over any other apparatuses that may be attached as accessories to the ROV as well as display a live video feed from the mounted cameras. A custom program for a laptop will eventually be written using Visual Basic for simplicity, but at this point in time a standard iPod Touch has done wonders controlling the ROV over a WiFi connection using the web browser. Also, by using a Sony PSP (PlayStation Portable) to view the live video feed also via a wireless connection, it is possible to have all of the controls fit inside one’s pocket and even control the unit from anywhere in the world over the internet, the only downside to this is that the live camera feed over the internet would have a potentially low refresh rate when long distances are involved. If a laptop is used as the control interface, it can have real time control and two live camera feeds on display simultaneously.

The Main Body

The hull is a surprisingly tricky and important part of the ROV. Not only does it have to provide structural support for all of the parts, but it also has to be waterproof at depth for extended periods of time while allowing the ability to service the components in the field. Also, counter to intuition, it must be very heavy. Why must it be heavy? With the volume inside the hull, the air per unit volume weighs much less than any water per unit volume, and therefore it adds a significant amount of buoyancy. This must be counteracted in two ways: add weight to the hull, and consume air volume with either a smaller hull or heavier objects which take up free space. My design has multiple considerations: I have an open frame of PVC tubing surrounding the hull reducing buoyancy and making resistance to movement decrease as well as making mounting and removing components easier, I have a double hull for all of the electronics, such that if the primary hull is breached, the secondary hull will hold off until the unit can surface (the double hull also takes up extra internal volume, thus reducing buoyancy); there are two sets of Electrical feed through that keep water out of the electrical wiring and out of the hull by using modular waterproof electrical connectors, each supporting up to two devices, and a fixed and sealed connection between the hulls. The hulls also use a lid opening such that it is easy to open and modify the interior yet the latches provide enough force on the seal to operate at depth. Inside the double hull system, the electronics take up a large amount of room and add weight, reducing buoyancy. After all of this, it still has a lot of room for improvement. The current design uses Pelican Cases as the primary and secondary hulls, specifically a 1600 and a 1520 respectively. These will not tolerate at depth greater than a few feet alone, but by using a double hull system and by adding some modifications, I believe I can make these handle much deeper waters possibly up to 50 feet after factoring in possible problems. Also, with my current design, there is still enough air volume on the inside to require more than 75 pounds of Static Ballast to sink the ROV, without the Buoyancy Control attached which might drop off a few pounds. The final issue I will address in the future is the polycarbonate mounting sheet I used to mount the pelican cases and propulsion. It is only 1/8 Inch and there is only PVC crossbeam underneath it to aid the two horizontal supports on the edges. I will likely both increase the thickness and add in more cross supports in the revised framework I am building

The Tether

Another seemingly unimportant, but very critical, component of the system is the usage of a tether extending from the ROV to the surface, where it is either terminated at a computer or a Networking Device for WiFi or internet control. The most common misconception is that a wireless control would be better in almost all ways. Well, it is not and in fact it is much worse and, potentially, dangerous! Before I explain the benefits of a tether, let me explain why wireless is a bad idea as I cam commonly questioned on this matter by everyone I discuss this project with. First off, even though I am licensed by the FCC (Federal Communications Commission) to build and modify my own transmitters including devices for Radio Control (R/C), the frequencies at which data communication operates with high performance cannot penetrate water without an absurd amount of transmitting power. I may be licensed for up to 1.5 kW of transmitter power, but it is impractical to use that much and problematic. The frequencies which can penetrate water more readily, some of which I am licensed to use, are impractical for several reasons. First, the antennas at these frequencies are very large, some of them several hundred feet long wires. Ok, lets assume I was willing to wire across the surface of the water. Then, the wire would have to remain stable, the insulation on the wire has to be constantly maintained due to corrosion from salt water etc, otherwise a deadly amount of electricity could go into the water, and destroy the transmitter. Now, lets assume that this could be managed and I assure you it can with care, but it removes all practicality from the ROV after adding a significant amount of work. At these frequencies, data transmission rates are relatively slow, and this would make the live video feed near impossible. Also, this would allow for possible interference from other transmitters in the world operating on these frequencies. Where in the world? All over because these frequencies have a high rate of propagation, and will travel for hundreds of miles. On top of all of these drawbacks, if the ROV fails there is no means to surface it without either sending down another one or risking a diver. When a tether is used, it counters all of these drawbacks and adds several features. It allows for a very high, real-time data stream in both directions; it gives a means to retrieve the ROV in case of a failure by using a winch attached to the tether; it doesn’t consume a large mount of power; it can be made impervious to interference; it is actually cheaper than the transmitters required for wireless; and it is easier to maintain and operate. The tether on this ROV is comprised of two things; a standard SC Fiber Optic Cable, and a Vinyl Sheath to protect the fiber optics from being torn at. When I get the chance, I will also add in a steel cable to make retrieving the ROV easier once deeper waters are involved. The Fiber Optic Cable has advantages over using copper: it is thinner, lighter, does not carry an electrical current, and can run very long distances without need for an amplifier. With low grade “multi-mode” SC cable, my Fiber Media Converters can support up to a full mile of cable. There also are a few plumbers pipe insulation pieces spread around the tether to add a slightly positive buoyancy. The tether only dives when the ROV dives, thus drag is reduced because the minimum amount of tether is underwater.

The ROV Electronics

The last main components are the Electronics on the ROV end. These electronics take a command from the surface, and actuate the mechanics of the ROV. There are a few subsections here: the Power Supply, CPU, Network Control, Power Switching, Propulsion, Buoyancy Control, Water Leak Detectors, and the A/V System.

The Power Supply is composed of two batteries, a 12 Volt 3.4 Ah Sealed Lead Acid (SLA) battery for the main electronics and propulsion, and a set of 8 AA batteries which are temporarily providing 12V for the Buoyancy control circuit until a second SLA is purchased. AA batteries are not very suitable for such an application, but for pure testing purposes they have done just fine. The buoyancy control unit needs a dedicated power supply for the time being due to the current failsafe method described later on. The primary battery, the SLA, provides 12V to the CPU, A/V system, and the Power Drive Circuit which require 12V, and by using a regulator in parallel with the other devices it also supplies 5V to the Fiber Optic Media Converter and, once the video system is fully installed, 9V to the Ethernet Switch. This SLA battery will be instead used for Buoyancy Control once another, higher capacity, battery has been purchased. All power supply batteries and regulators, as well as the main power switch and fuse, are in an isolated compartment made from a standard Otterbox, which is also waterproof for extra security. This is good in case any battery decides it doesn’t want to live anymore and explodes due to a short or other freak occurrence.

The CPU is an Arduino Diecimilla using an ATMEGA168 chip running at 16 MHz. The programming is a combination of my code, and the Inventgeek Ethernet Outlet code which I used as a tutorial for Arduino Ethernet control, which this is my first ever project using. The Arduino runs an HTTP web server using a purchased ethernet shield (the official design) and this ethernet shield is connected via a small CAT5 patch cable to the Fiber Optic Media Converter to communicate over the tether to the surface. When the A/V system is fully operational, all three networked devices will be connected via a standard ethernet switch. The arduino is controlled via a web browser of a simply homemade program which can send an HTTP request. Rather than have the arduino web page have several buttons, I am instead using the URL to control the unit as I can just bookmark the controls, operate on low power internet devices such as a cell phone, and it frees up programming space for future expansion. Even if I wanted the buttons, I got errors I could not resolve when I tried to add more than one button. The arduino has 4 of the 14 digital I/O pins reserved for the ethernet shield, six digital I/O pins reserved for propulsion and buoyancy control, and one pin is being reserved for a Parallax Ping Ultrasonic Range Finder. This leaves few I/O pins unless I use shift registers, but I plan to upgrade the arduino to a Dual Core Design I have used in the past, in which two arduinos communicate via I2C, or possibly to an Arduino Mega. The CPU is located in a dedicated Otterbox along with the Fiber Optic Media Converter to keep it isolated in case of a hull failure or another unforeseen event.

The Network Control is handled the arduino ethernet shield operating in cooperation with a ConnectGear Fiber Optic Media Converter, which converts a standard CAT5 connection to a SC fiber optic connection. To the arduino and any other networked devices, it doesn’t even appear to be there. When the video system is fully installed, it will also share the fiber media converter with the Arduino on a micro-sized five port ethernet switch. All devices are accessible via standard networking protocols, and allows the addition of axillary ethernet controlled devices such as a secondary CPU, additional networked cameras, and other accessories.

The Power Switching Circuit takes the signal from the CPU and drives the higher voltage/current devices, such as the propulsion, buoyancy control, and other miscellaneous components. The circuit uses Optoisolators to protect the CPU from a voltage spike which can easily occur with motors and solenoids, and also make it easier to prevent ground loops from forming which could cause a power surge or other form of interruption interfering with CPU operations. The optoisolators in turn drive NPN power transistors which are mounted to a piece of Copper Clad Board which acts as a 12V bus line and as a basic heat sink. I should not need a more proper heat sink for a while, as the transistors are operating far below their capacity and non-continuously.

Propulsion for the ROV is provided with submersible Rule non-automatic Bilge Pumps. These act similar to the Impeller on a jet ski, providing a flow of water out of a nozzle which provides thrust. This keeps the moving parts contained, and less likely to become jammed. However, even though they need less maintenance they need more diligent work when there is a problem. Also, when I make the move to a Propeller Design which offers higher efficiency, I can use the waterproof motors from these pumps to drive the propellers. For forward propulsion, a 1100 Gallon Per Hour (GPH) pump is used mounted aft. For turning, two 500 GPH pumps are used mounted forward on both sides. Reverse propulsion is currently not installed due to cost considerations, but the electronics and electrical connections are there for when I get another pump. A nice feature about this propulsion system is that it has a rather low Impulse (change in force per unit time), allowing for rather smooth movement ideal for a camera system.

The Buoyancy Control for the ROV is currently handles by a modified Scuba Diver Buoyancy Compensator Device (BCD). A BCD works by having a large flexible, though not necessarily elastic, bag which stores air and increases in volume to gain a positive buoyancy. To reduce buoyancy, the air is allowed to escape and thus decrease the bag volume. The BCD I am using supports up to a 45 pound shift in buoyancy. The static ballast is set to have the ROV retain negative (sinking) buoyancy naturally, and when the BCD is half inflated it becomes neutrally buoyant (hovers neither sinking nor Surfacing). When the BCD is fully inflated the ROV becomes positively buoyant and it surfaces. To control the BCD electronically, I have installed Solenoids to actuate the rubber seals on the air intake and air dump valves. This has proven problematic as it is very hard to dial in the spring strength such that the high air pressure from the air tank and BCD do not crack open the valves. Currently, until I can acquire parts for a more efficient and conservative buoyancy control unit, I am letting air seep into the BCD and programmed the electronics to either keep the air dump valve open or open it frequently so that there is never enough air at one given time to have positive buoyancy until either I close the valve via controls, or the air tank loses enough air such that it becomes buoyant itself such that the ROV will surface (yes, when an aluminum Scuba tank drops below a certain amount of air pressure it becomes buoyant. Steel tanks exhibit this behavior as well, but do not necessarily overcome their heavier weight with the added buoyancy). This also is beneficial for the time being because if the electronics fail or the battery dies the ROV will naturally surface because the dump valve will automatically close. This is also why the buoyancy control has a dedicated battery: it runs constantly until I can get proper electric air valves rated for at least 150 PSI.

The Water Leak Detectors are ready to install, but have not been yet due to time constraints getting this project ready for a school grade. However, I will document them as if they were installed because the design will not change and they are next on the list of to-do’s. There are multiple detectors: in between the primary and secondary hulls, inside the main electronics compartment, and inside the camera enclosures. The water sensors are just about as basic as it gets: two electrodes, one connected to a positive voltage and the other connected to a pin on the CPU and separated by a non-conductive gap. When water bridges this gap the voltage is registered by the CPU and measures are taken to protect the hardware. The CPU will warn the operator and start to surface automatically unless the operator overrides the alert (and yes, there are times when I might want to do that). To make the water sensors more reliable, I am etching a zig-zag pattern onto a large PCB and placing them in various locations in the different compartments based on these considerations: where water will possibly enter, where the water will collect, and where the water can do damage. The primary water sensors, for the hull and electronics, will be on the same CPU input. However, the other ones will be dedicated for aforementioned reason of intentionally allowing the water to come in (test coatings on circuits, experimental, etc).

The A/V System has yet to be installed, but as with a few other subsystems it is ready to install once I have time. It is comprised of two live cameras, one reserved for piloting the ROV and the other as an auxiliary camera for different angles or a higher quality camera for film use. The pilot camera is a basic miniature camera that I use because it is only $10, so if it fries it is easy to replace. The video feeds from the cameras are standard composite, though with a slight change in hardware I can support HD or Ethernet Network cameras. The composite feed goes to a Sony Location Free video system which supports two A/V devices and sends the video stream over a network. This is similar the the more well-known SlingBox, but cheaper and it supports the PSP allowing for more compact display and control for certain applications. The location free unit also can use IR sensors to control the A/V devices, and I could use this as an alternate method of sending commands in case of a CPU failure or for controlling auxiliary devices such as audio systems, or even the cameras themselves. I am also considering using the audio signal from the pilot camera to perform sonar operations if the parallax Ping does not perform well in this situation, but this remains to be seen.

The Build Progress

The design was conceived just before Spring Break in March of 2010 and I ordered the first components. The ROV in its basic form and functionality was due to my school as of May 3, 2010. This project will be continued for a long time, as I can mix various forms of electronic skills, science, experiments, research, and fun into this project.

Listed below are the components I started out with, including the items discarded from the design and excluding the second design items until farther in the work log. All progress is in Chronological Order unless otherwise noted and rather than make an individual entry for every step, progress was lumped into several day periods of similar or rapid work.

——————————————————————————-

TKTK setup new gallery for photos on new website

April 18, 2010

I started building the Power Drive Circuit for the electronics board and I installed and sealed the wiring between the CPU Otterbox and the rest of the board. I used TIP101 transistors which I have used for countless applications without issue. However, I think part of the reason I never had issue is that I never had many connections close together as usually I just need one for a small circuit that isn’t as sensitive as this. Needless to say, after building and doing a basic test of this board it was obvious that I needed to just get some standard NPN Transistors, but I decided to finish the rest of the surrounding board to avoid putting off the rest of the work. One thing this part of the build taught me is that Rainbow Ribbon Wire is Awesome! – Especially when breaking out of ribbon wire is needed and a large number of wires are present, I may be using a dip connector on one end but I have to be able to tap directly into the wires in the future.

The CPU Otterbox with wiring installed. As it turns out I later noticed at the end of the build that I skipped a pin on the Arduino, but that pin was not used until final testing so I never noticed!

April 20, 2010

I rebuilt the Power Switching Circuit, and used a fresh piece of green Protoboard which turned out to be a death sentence for two day’s worth of work (under the laquer was a complete 2d matrix of tracelines nearly invisible with laquer to the naked eye. Fried everything). The board was supposed to just be solder pads for each hole with no traces. I also installed Terminal Blocks for the connections to the pumps etc so that when I remove the board from the ammo case I can take the board away from the case as I work at a desk and just make general maintenance and testing easier. I also mounted a fuse holder and a three position key Switch (on-off-on) onto the Power Supply Otterbox. Why a key switch? With a key switch, because it is made for security it is very difficult for it to be affected by jerking, motion, and so forth. Also, it has a very low profile, and it keeps me from rapidly turning anything on without thinking (which has happened in the past). I have not yet installed another power switch to use between the time of activating the key and loading the electronics into the case, but that was a bonus feature I didn’t care about then but do need to add in the future.

April 22, 2010

I started testing my water seals with the newly installed third waterproof electrical connector and the PVC Compression Fitting. To install these I used tin snips to help widen the hole as the spoon drill method took over an hour a hole. As it turns out, these seals did not want to hold at all. The holes were slightly irregular and deformed such that making the proper seal was very difficult, especially due to the difficulty in shaping the steel of the ammo case.

Therefore, I decided to move on and use a couple of Pelican Cases. Two of them are nested like russian dolls, a 1600 and a 1520. This was done to help with the pressure over a large pelican case, and to help mitigate the fact I had an upcoming deadline with little time to acquire new parts. The larger 1600 will be kept for this job, while the inner 1520 is used in such a way that I can still use it for other things. I also mounted the 1100 GPH bilge pump for forward propulsion. I also acquired a BCD from a local scuba shop for cheap, so I will be modifying that for Buoyancy Control .

April 26, 2010

I started testing out my Arduino Code, but had problems making the connection between the arduino and the computer stable. It would work, then it wouldn’t work and was very unpredictable. I then pulled out an old router and set the Arduino gateway to the router to see if things would become smoother, and they did. Plus, with the addition of this router I gained WiFi control over the unit. I even got the iPod touch control working within minutes of adding the router. The next issue was adding more than one button to the arduino web page. I have never used the arduino ethernet shield before this project, so forgive me if it is something obvious that I am missing. What I ended up doing is having one button (for show) and controlling everything with the URL commands. Here is the Arduino code (with old additions of code commented out, but left for historical purposes):

NOTICE: This code has been reported to not compile under the new versions of the Arduino IDE.

#include 
#include 
// This code was modified from the Network Outlet code available from InventGeek to suit an ROV Program
// I modified this code because I used it as a basic tutorial for Arduino Ethernet coding
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; //physical mac address
byte ip[] = { 192, 168, 1, 110 }; // ip in lan
byte gateway[] = { 192, 168, 1, 1 }; // internet access via router
byte subnet[] = { 255, 255, 255, 0 }; //subnet mask
Server server(80); //server port
//int speakerPin = 13; // speaker connected to digital pin 9
//int ledPin = 1; // LED pin
int ballastfloodpin = 4;
int ballastdrainpin = 2;
int rightbilge = 3;
int leftbilge = 5;
int reversebilge = 7;
int forwardbilge = 9;
//int inputPin3 = 3; // choose the input pin (for a pushbutton)
int val = 0; // variable for reading the pin status
boolean LEDON = false; //LED status flag
String readString = String(30); //string for fetching data from address
void setup(){
Ethernet.begin(mac, ip, gateway, subnet);
// pinMode(ledPin, OUTPUT);
// pinMode(inputPin3, INPUT); // declare pushbutton as input
pinMode(ballastfloodpin, OUTPUT);
pinMode(ballastdrainpin, OUTPUT);
pinMode(rightbilge, OUTPUT);
pinMode(leftbilge, OUTPUT);
pinMode(reversebilge, OUTPUT);
pinMode(forwardbilge, OUTPUT);
digitalWrite(ballastfloodpin, LOW);
digitalWrite(ballastdrainpin, LOW);
digitalWrite(rightbilge, LOW);
digitalWrite(leftbilge, LOW);
digitalWrite(reversebilge, LOW);
digitalWrite(forwardbilge, LOW);
Serial.begin(9600);
// pinMode(speakerPin, OUTPUT); // sets the speakerPin to be an output
}
void loop(){
Client client = server.available();
if (client) {
while (client.connected()) {
if (client.available()) {
char c = client.read();
if (readString.length() < 30)
{
readString.append(c); //store characters to string
}
if (c == '\n') { //if HTTP request has ended
// ledstatus(); //LED Status Sub
//htmlcontent(); //LED Html Content Sub
floodstatus();
drainstatus();
rightstatus();
leftstatus();
reversestatus();
forwardstatus();
// htmlcontent(); //LED Html Content Sub
readString=""; //clearing string for next read
client.stop(); //stopping client
delay(100);
}
}
}
}
}
void htmlcontent(){
Client client = server.available();
client.println("HTTP/1.1 200 OK"); // now output HTML data starting with standart header
client.println("Content-Type: text/html");
client.println();
client.print("");
//client.println("Activate Outlet

");
//client.println("Flood Ballast

");
// client.println("Drain Ballast

");
// client.println("Right Bilge

");
// client.println("Left Bilge

");
// client.println("Reverse Bilge

");
// client.println("Forward Bilge

");
client.println("DIVE!!!

");
// client.println("Surface

");
// client.println("Right Bilge

");
// client.println("Left Bilge

");
// client.println("Reverse Bilge
");
// client.println("Forward Bilge
");
// client.print("Outlet status: ");
// if (LEDON)
// client.println("ON");
// else
// client.println("OFF");
client.println("

");
client.println("");
}
void floodstatus(){
if(readString.contains("L=1")) //lets check if LED should be lighted
{
digitalWrite(ballastfloodpin, HIGH); // set the LED on
digitalWrite(ballastdrainpin, HIGH);
//LEDON = true;
// delay(1000);
// digitalWrite(ballastfloodpin, LOW);
Serial.print("DIVE");
}else{
//digitalWrite(ledPin, LOW); // set the LED OFF
//LEDON = false;
}
}
void drainstatus(){
if(readString.contains("L=2")) //lets check if LED should be lighted
{
// digitalWrite(ballastdrainpin, HIGH); // set the LED on
//LEDON = true;
// delay(1000);
// digitalWrite(ballastdrainpin, LOW);
digitalWrite(ballastfloodpin, LOW);
digitalWrite(ballastdrainpin, LOW);
Serial.print("SURFACE");
}else{
// digitalWrite(ledPin, LOW); // set the LED OFF
//LEDON = false;
}
}
void rightstatus(){
if(readString.contains("L=3")) //lets check if LED should be lighted
{
digitalWrite(rightbilge, HIGH); // set the LED on
//LEDON = true;
delay(6000);
digitalWrite(rightbilge, LOW);
Serial.print("RIGHT");
}else{
// digitalWrite(ledPin, LOW); // set the LED OFF
// LEDON = false;
}
}
void leftstatus(){
if(readString.contains("L=4")) //lets check if LED should be lighted
{
digitalWrite(leftbilge, HIGH); // set the LED on
// LEDON = true;
delay(6000);
digitalWrite(leftbilge, LOW);
Serial.print("LEFT");
}else{
// digitalWrite(ledPin, LOW); // set the LED OFF
// LEDON = false;
}
}
void reversestatus(){
if(readString.contains("L=5")) //lets check if LED should be lighted
{
digitalWrite(reversebilge, HIGH); // set the LED on
//LEDON = true;
delay(6000);
digitalWrite(reversebilge, LOW);
Serial.print("REVERSE");
}else{
// digitalWrite(ledPin, LOW); // set the LED OFF
// LEDON = false;
}
}
void forwardstatus(){
if(readString.contains("L=6")) //lets check if LED should be lighted
{
digitalWrite(forwardbilge, HIGH); // set the LED on
//LEDON = true;
delay(6000);
digitalWrite(forwardbilge, LOW);
Serial.print("FORWARD");
}else{
// digitalWrite(ledPin, LOW); // set the LED OFF
// LEDON = false;
}
}

I also made the BCD control valve: TKTK image

Results

Now where are the final testing results? Currently, I don’t know. I had this report handed in to my instructor back in high school. I had thrown together a crappy website before for project docs, but I never completed the documentation there. In the years since, with hard drives lost and my, in hindsight, misplaced distrust of public cloud. I have since done end-to-end protection so I will use some cloud services. Hopefully one day I can find and recover the last test videos of it with the BCD data (which also happens to be the first certified dive of a buddy of mine as a scuba diver when he helped film it… so two people at least care about it).

]]>

Hacking and Coffee

Privacy Policy

How you can Improve Privacy with us

Communications

Data we Store

Who can Access & Where

Data Removal

Data Sharing

Exceptions to this Polixy

Cybersecurity Consulting Services

“We?”

Consulting Services

Contact Hacking & Coffee

RIP LinkTree worker; Long Live LittleLink Worker!

LittleLink

The Tail

About Me

FAQs

What do you do?

Why do you do these things?

Are you certifiably insane?

But then why are you talking to yourself in the comments?

But aren’t you typing this?

Pardon the Dust

Once the content is migrated over,

Cool Stuff Ahead

Datacentre Shutdown

Site & DC Migrations

My Github: Why the Emptiness?

why is my github relatively empty?

But why the forks with no new commits?

The End of an Era

The research projects

looking back on this journey.

That distribution was Backtrack

Fast Forward

The milk overfloweth.

This was the status quo

This was the birth of Hacking & Coffee

Then COVID came along

I’ll miss it.

Red Team Laptop & Infrastructure (pt 1: Architecture)

Requirements

The Architecture

High-Level Breakdown

Networking

Practical Hardening

Disk Encryption

Extensions

The Bigger Architecture

Unique Policy of Transferring Usernames by Telegram

Q: What do I do if my username is taken?

This is concerning to say the least

Serving Malware via Physical Legal Documents

Capacitor Pulser Bank (v2)

Underwater Remote Operated Vehicle Project

Introduction

The Control Interface

The Main Body

The Tether

The ROV Electronics

The Build Progress

April 18, 2010

April 20, 2010

April 22, 2010

April 26, 2010

Results