BSidesSF 2026 - Lessons Learned from Building Custom Hacker Hardware (c4m0ufl4g3)

We got Jonathan aka Camouflage with us. Uh, lesson learned from building custom hacker hardware. So, over to you, Jonathan. >> All right. Thank you. Before we begin, let me give you a little background about what I'm going to talk about today. Once upon a time, my friend and colleague Jeremy Miller and I set out to build our own hacker hardware. And we did. Uh, long story short, we released it at Defcon 30 in Bsides Las Vegas under the title Injectal and Hide. But that's not what I'm here to talk about today. I'm not here to tell you what it does and all of its capabilities because we've done that. The background to this story is that

when we set out to do this, we noticed quickly that everybody talks about their project and what it does and you know, look at us, but nobody talks about the journey they took to get from a proof of concept all the way through to a final uh product, right? So, we decided to document our journey so that we can share it and hopefully the rest of you guys can learn from our lessons and be the next ones up here presenting on your own project. All right, with that, welcome to my talk. A little bit about myself. My name is Jonathan Fischer. I have over nine years in the infosc industry. All that has been focused on

the offensive side of things. But prior to joining infosc, I spent about a decade designing, implementing, and programming electrical control systems for operational technologies. So, think factory automation, think machine controls for offhighway vehicles, right? While doing this, I implemented and designed a lot of control systems that included radio controls, custom wire harnesses, embedded programming, um, specking out that complete system of sensors, all that fun stuff. Over time, I started to develop an interest in hardware, IoT, and RF security and made my transition over. Now, it's not as easy as it sounds, but I did get here. All right. Since joining the industry, I've done some things. I've spoken about them at some conferences. Maybe you've seen me, maybe

you haven't. But that brings us to the standard work disclaimer. I'm here as an independent researcher. Everything I say today and everything you see is my own and not that of my current or previous employers. All right. How did this come about? Well, once upon a time, Jeremy and I were presented with the rare opportunity to spend some time doing research. And we were both hardware focused and still are. So we started talking, what do we want to do? This was shortly after the NSA ant catalog had been released and the rubber ducky was still big. OMG cable was definitely making waves. I think the demon seed was released around this time. And so we started looking at the

commercial devices and wondering will they fit into our application for red team usage for the immediate and long term. and we're weighing the pros and cons and we finally decided that while they were good, they wouldn't do everything we wanted to do because we had some ideas and we wanted to stay viable. So, we thought, well, we got the time. Let's see what it would take to build our own. So, we decided to. The first step for this was we had to map out our goals because if you guys do your own projects or do any testing, you know that you're going to get scope creep if you don't define it first. So we set out and

defined our goals. Our goals look something like this. First of all, we want to use less common protocols. Now if you are familiar with hardware implants like ours, um ESP32s are common everywhere. How does everybody connect to these implants? Well, they connect over a hidden AP. If everybody's using a hidden AP, what am I going to look for? A hidden AP. So we want to do something different than everybody else. We want to hide. We want to be more covert than what's out there. We want to be difficult to identify. Now, if I have an OMG cable in my hand, I'm not going to be able to tell from a legitimate charging cable just with the

naked eye. However, they are victims of their own success. Everybody's going to think twice about plugging in a random charging cable, right? So, if I approach an op with a charging cable, will I succeed right away? I want to look different than everybody else looks. I want to surprise people. If I get discovered, can I change it so that in the next operation word doesn't get out and I'm being compromised. Hand in hand with that is if we build our own, maybe we can change what we look like so we can hide different places. Can I be in a keyboard? Can I be in a mouse? Can I be in a conference room speaker? You know, something to

think about. All this plays into the longevity of our platform and our ability to stay covert. complete ownership. A lot of commercial devices claim to be open source, but are they really? When they say that, a lot of times they're referring to the payloads. The payloads are developed by the community and contributed. When you go looking for the firmware, you get uh quite often the response of, well, that's where the magic sauce is. No dice. Now, that's all fine and good if I'm testing, but if I'm handling customer PII or PHI, I don't want to be the one that lost it. So if I develop my own, at least I know that the data is being

handled in a manner that I feel is safe. And the same goes for any open source project. If you can audit that data, you're at least most of the way there. Custom features. If we could have used commercial products and expanded on what they could do, we probably wouldn't have wasted the time to do our own. But you can write a custom payload. Try adding another radio to an a commercial product. Most of these are not like the flipper where you have GPIO pins exposed for your use later. Right? And finally, one of the unique things we wanted to do that nobody was doing is we wanted to be scalable. If I'm doing a hardware implant like ours, so ours for

instance was man in the milling keystrokes between the computer and the keyboard or the yeah computer and keyboard. If I deploy that in a corporate environment, I'm going after one computer, right? I have to be very targeted and especially with rotating cubes these days, I have to somewhat time out my event so that I get the, you know, the credentials I want or whatever I'm looking for. However, if I can scale this from one uh particular PC to let's say entire floor, what if I take over the entire dev floor? What if I take over the entire building? I'm going to drastically increase my chances of success and get that data that I want for my op.

So, now that we know what we want to do, where do we start? Well, every idea has to start somewhere. So, let's start with the proof of concept. For us, it made the most sense to look at commercial off-the-shelf components. Let's prove out we can do this the cheapest and quickest way possible. So, we started with a 8 fruit tree kit M0, an Arduino Nano 33 IoT board, two Sparkf fun XB3 thing plus boards. Now, I'm going to say that as the Spark Fun board or the XB board in the future cuz that's a mouthful. All right. And a custom C2. Now, the custom C2 is written in Python 3, but I'm not going to get into again what it

does. We've talked about that in the past. I'll talk about the software as it relates to the hardware, but today's main focus is the hardware side of the house. All right, if you can't tell, this is the Adafruit uh Trinket M0. And it's pretty apparent why we started with this. It's small. This thing's about the size of a quarter. If we're lucky, we can implant this in a keyboard or wherever we want to start. All right. And the price is right. $10. That's two coffees, right? I can handle that. But we can flash it with the Arduino bootloadader. So, we can start with industry supported um IDE and some mature libraries. So, that's a huge

bonus for us. It'll help us get going faster. And it already comes with a dedicated USB serial line. So we already have that keystroke coming in or the data going out to the computer that's already covered. We don't have to do any additional overhead for that. One thing to note is it runs the microchip ATMmail SAMD21 chip. All right. Now the next board slightly different a little bit longer blue not black but what else makes this unique? This is the Arduino Nano 33 IoT board. Now, I'll be honest with you. When I started this project, I just bought this board because it looked really cool and I was dying to use it for something. So, it

worked its way in. All right. It's small. Jeremy actually got this and the Trinket M0 into his old school keyboard. Um, so there's that, but you're not going to get them in a keyboard today. Lower cost $25. Still not breaking the bank. We can manage that. I should note this is all self-unded which is why I'm citing costs. All right. Also runs Arduino bootloadader so we have a common IDE which helps streamline things. What's that extra cost get us? It gets us multiple serial lines exposed. Now now we can start adding peripherals where we couldn't with the trinket M0. Otherwise we could have just stuck with that one. But we still have that dedicated USB host line. So now we got

USB in USB out. Perfect for man-in-the-middle attacks. Finally, this board offers BE functionality. So, as an implant, I'm not going to be very covert if I'm running wires to communicate with it, right? People are going to notice that right away. So, we need some sort of wireless interface and uh we started with BL here. And this also runs the SAMD21 chipset. If you're noticing a pattern, it's not an accident. What makes the SAMD21 special for us? Well, it's common. It's very common across Arduino boards if you've ever looked at them. What this means for us is it's stable. It's got a lot of product support. It's been developed quite often or frequently and very mature libraries

out there supporting it already, which also means it's readily available. Right? If they're across all these production boards, we should be able to find them. And when they're mass-produced like that, they're cheap. This chip was 80 cents, I think, when we started. Now, due to recent activities and such, they're about $4. So, they're not so cheap anymore, but they were 80. And it's low powered. It runs at 3.3 volts. So, this is something we can power from the USB bus. And like I said, it has the host libraries already, but it also has the HID or the HID libraries for human interface devices like keyboards and mice. So again, we don't have to do the

overhead here. We can stand on the shoulders of giants and get going faster. Now, the Spark Fun board. This board is also different. This one's red and it also has a radio on it. All right. A little bit about this board. It's $60. So now we're creeping up in there in price. All boards to uh together are still less than $100. So that's not too bad. This one's programmed in Micro Python. So I'm not using the Arduino IDE here, but Micro Python is pretty straightforward. And we run BLE. So now we have that interface to talk to the boards in our implant. But we also have another radio, the XB Digime Mesh radio. Now, if you're not

familiar with this, this is the XP. It's made by Digi International, who specialize in IoT radios. This particular one runs a proprietary protocol called Digime Mesh. So, think ZigGB like, right? But this is how we're achieving our mesh networking and our scalability. So, we can now build out our network and jump air gap systems with this mesh. The radio itself is easily hidden. If you're just using the radio, it's the size of a stamp, so it fits the profile we're looking for. The radio is only $25. It's less than half the cost of that board altogether. We already have the ability to do some encryption on the traffic, so I don't have to worry about implementing that

myself. That's always a huge plus. But you're probably more concerned about range, right? Advertised uh range on this line of sight indoors is 300 ft. Let's be honest, that's real uh unlikely we're going to hit that. We're going to be in a keyboard in a noisy environment with lots of metal, lots of wires. If I can hit 100 ft, even in an office complex, that's plenty of room for me to get to another spot where I can drop another node, another repeater, another implant to keep building out that mesh. So, I'll take that distance all day long. Now, that's all fine and good, but if I can only do five nodes, still not going to get me very far. Fortunately,

with this radio, we can do up to a,000 nodes in our deployment. That's 1C2 and 999 nodes before we even have to do anything with the network architecture. So, when I say take over an office complex, I mean you can take over an office complex if you want. If you're a visual thinker like I am, this is what the circuit looks like. You have the keystrokes going into the Trinket M0, passing along the data to the Arduino board over to the PC. Now, we're relaying out over Bluetooth to what we'll call an extender. The idea at the time was this is something you could plug in behind a monitor, easily hide power with the USB power behind it, and

then as the keyboard got near, it would auto detect it and start relaying the data. And then it meshes out to the other um extenders and the C2. All right, so we got a proof of concept. Where do we go from here? You're going to notice a theme throughout this presentation. We do this in steps because if you've ever built your own project, you have to take steps as you go. Cite what you did, what you learned, and where you want to go. So that's our approach today. All right. If you program an Arduino board as a hit device from the computer, if you go back and plug it in the same computer, it's not going to recognize

it. You do have to delete that original Arduino driver. Otherwise, you're going to waste a lot of time looking for the device. A little quirk. I don't know if it still exists that way today, but it did at the time. But more importantly, we had a lag. We had a half a second lag. Now, it doesn't seem like a lot, but when you type a key and a half a second later it appears on the screen, it's going to drive you nuts. Nuts enough to the point where you're going to rip that keyword out or you're going to find the implant, right? You're going to start investigating. Either way, bad for us. So, we're already at a point in

our project where where we might be at a showstopper. So, where do we go from here? Well, we have to eliminate that lag. Our thought at this particular point was that extender was handling both Bluetooth and the XP protocol and we're probably overloading it. So, we got to test it out. So, that brings us up to our first prototype. We have the Trinket M0. Now we have two now 33i2 boards. The second nano board is offloading that B uh processing, two XP boards or spark boards and it looks a little something like this. All right. So now we're adding a board to the extender. Not ideal, but if we can't get that uh rid of that leg, it doesn't

really matter, right? And this is what it looks like on a breadboard. Now it looks fairly straightforward, right? We got some communication lines, power and ground. But I will tell you this is probably the most interesting step from my standpoint in our entire um project. And why is that? Well, we learned that the Spark Fun board would not talk to the Arduino board. And try as we might, we're using UART, right? This is a well-known protocol. Everybody uses it. Easy to establish. We proved it out that the Arduino boards could talk to each other, but nothing could talk to the Spark Fun board. So, we dugging or we dug into the sample code, you know, tried every which way to

get that working. Double checked our pin outs, looked at the documentation. Everything says it should work. So, I finally swallow my pride. I call up Spark Fun and say, "Hey guys, I'm an idiot. I can't get this going. What's happening?" Moment of silence. And the tech rep says, "Well, about that." Um, so I know it's on the product literature, but it's not implemented yet. You just sold me a board without UART. Thanks. Thanks, guys. So, now we're going, well, we really want that radio. What do we do? Maybe we look at something like I squared C. I'm like, all right, we'll pivot. So, I sent Jeremy the new wiring diagram. I start working on the code and I get a phone

call. It works. What do you mean it works? Said, "No, no, I got it working." I'm like, "Okay, fine. Give me your code." Well, I didn't change the code. All right, Jeremy. What do you do? Why is it working? He's, "Well, I just wired it up the way you told me." Well, it's not working on mine. Let's go through what you did. So, he shows me a picture and I start laughing. I'm like, "Jeremy, you put the wires on the wrong side of the board." When he did that, he pulled the clock pin down to ground and magically it fails over to you art working. Raise your hand if you ever thought that would work. We didn't.

Neither did Sparkf fun. So we call it Sparkf fun. We're like, "Hey guys, we have you art working. Really don't like how we did this. Please explain it." And the tech rep said, "Well, I'm going to have to get with the engineers." Cool. A week later, we get a reply from the engineer. And it goes a little something like this. In the physical universe as we know it, there's no way that that would ever work. You're imagining things. Well, Jeremy and I laugh because he's got it working over across the nation from me. So, it's repeatable. So, my response to that was, well, we have UART. You don't. For a low, low price, you too can have UART.

They did not take us up on our offer, unfortunately. So, where do we go from here? Well, as much as I like hacking things, I don't want to hack their board to keep it working in our project. So, it's time to move on. We'll get rid of that board. If we can establish reliable communication between our nano board and a radio, then that board is just a pass through. Can we do it? Well, yes, we can. that particular radio has UART already. So where do we go from here? We get rid of that board. So now our prototype looks a little something like this. We have the Trinket M0, two nano boards, now two XBs,

and now our extender is getting just a tiny bit smaller, a little bit cheaper, but hopefully more functional. And now this is what the extender looks like just as a prototype. What did we learn by doing this? Well, we learned that we did in fact establish um reliable communication over UART between the board and the radio. Fantastic. We're already moving forward. But more importantly, we got rid of the lag. So, we are a viable project again. We are free to move forward. But at this particular point, we also met our operational goals from a software standpoint, right? We did everything we wanted to as far as functionality. Now it's time to focus on the hardware.

So the next two logical steps are can we reduce the number of boards and can we shrink our footprint so we can actually implant this and not get detected. One of the ways to do that is drop B. Right? I said I wanted to use less common protocols. BL is common and anybody with a smartphone can sniff out a device beaconing out. So let's drop it. And while we're at it, we can fill up the memory rather quickly on a deployment if we're getting a hold of somebody that does a lot of typing. So, let's add some storage and ensure that we can walk away for a week and come back and get the keystrokes later.

All right. So, that brings us to the next prototype where we have a trinket M0, a nano 33 IoT board, two uh XP radios, a micro SD card, and a partridge in a pair tree. No, I'm just kidding. But this is what we look like now. And for all intents and purposes, this is the uh circuit we're running today only represented with C's components. We are men in the milling with the two boards. We have the SD card for storage and the radio beaconing out to other implants in the CT. All right. Now, this is the Arduino or sorry, the Trinket M0 wired up to the PCB keyboard to the radio and an SD card.

This is the rat's nest that I call the uh implant at this particular point in the project. Not pretty, but it works. What did we learn? Well, when we moved the radio down to the Arduino board, we had to add a softwaredefined UART interface because we ran out of dedicated ones. Now, you'll see this referred to as a sircom or serial communication line. And it's very easy to add in Arduino if you pay attention to the variant file. If you don't, you're going to be chasing your tail wondering why your pin outs aren't working. So, if you haven't seen the variant file, it looks a little something like this because the software pin numbers don't

always correlate to the hardware pin numbers, which don't correlate to the pads. So, it's pretty easy to get it confused. So, pay attention to that file and save yourself a bunch of headaches. But more importantly, we learned we're still fully operational. We can move on. All right, we got rid of the BLE. We're still operating at minimal capacity here. So the only real step from here is we got to shrink the footprint. We got rid of as many boards as we could think possible. So now we got to shrink the size so we can actually implant it. The only way to really do that is look into a custom PCB. But before I decided to go down that

path, I wanted to prove out one last step. Can I work with the chips outside of production boards? So, I ordered up a couple dev boards from Sparkfund that specialized for the SAMD21 chips just to prove to myself. All right, so we got this uh dev boards, we got the two radios, and we got micro SD card and we still have the same circuit, but now we're stripped away from those production Adafruit and Arduino boards. Now, ideally, we just throw an enclosure on these two boards and we hide them in an environment and we don't have to build a custom PCB. In reality, those things are massive and they're bright red. I'm not hiding that anywhere where

nobody's going to notice, right? So, unfortunately, I still have more work to do, but at least I can test out whether or not I can work with the chip. From here, we learned that we can work with those dev boards. They're flashed with Sparkfund bootloadaders. We uploaded some simple um UR tests and just to test out everything would communicate. The pin assignments would work and the radio would work and we were good. So the next step the onlywhere we can only place we can go is build a custom PCB. Now, this is going to be the most intimidating step in our entire process because Jeremy and I at this point had talked about building uh custom PCB, but

neither one of us had ever done it. Not something even on our radar up to this point. So, where do we start? Well, like I said, we were self-funded. So, we decided to look into design suites. If I have to pay 10 grand for software license, I'm done. I'm not going any further. Right? Fortunately, we came across Easy EDA, which is a uh free software suite. Lots of tutorials online. Pretty easy to get started. Uh for me, it had the lowest learning curve, but you're going to notice that Kyad or Keycad, depending on how you want to pronounce it, is probably the most prominent one in the industry. It's free, got a lot of support, a lot of

flexibility, a lot of features, but I think the learning curve is a little bit steeper. Now today I use both because both have strengths and weaknesses. So learn one, learn two, and do yourself a favor. We had looked at allocart from Sparkf fun. This is a another free version, but we were already past what this could do. We were doing two sideboards with two microcontrollers and they couldn't handle it. Maybe they can today. It's an option. And note, there are more out there, but these were the ones that we came across. Now, if price isn't an issue and you got your company backing, I recommend taking a look at Eagle or Altium. They seem to

be the uh for front of the paid versions. But because I'm self-unded, I didn't get all the fancy features, so no days for me there. All right. Now, we know we can design a PCB. Where do we start? Well, with electronics, you're probably going to want to start with schematics. So let's start defining that. Now this could also be intimidating. I have a strong background in electronics and electrical theory, but I'm not an electrical engineer. So where do we start? Well, you don't have to worry about this cuz what do we know at this point? We know we had an Adafruit board working and Arduino board working. The Arduino board was the most uh capable,

had the most peripherals. So why don't we just look at the schematic for that? It's open source. I don't have to design this board from scratch. I can start here and start removing the components that I didn't use, leave the ones I did, and the components I don't know what they do. Maybe it's time to start figuring that out, right? Or worst case, you just leave them on the board. So, we have that schematic. One of the ways we can help narrow down or understand the board is look at each individual component. This is the recommended circuit for the power on the SAMD21 chip. It's got a very thick manual with a lot of things

about it in there, right? And most of these components do. If they want you to do something their way, it's there. So, go ahead, dig into the documentation and figure out what's going on. Long story short, RTFM. All right, we know the circuit or at least relatively so. What are some things we have to consider when we're designing our own PCB? Well, first of all, we have to power it. Where are we getting power? What does that look like? How are we going to connect to the board? How are we going to connect the board to the system? How are we going to program the chips once they're on the board? Now, we got to put stuff on the board.

What does that look like? If you never design a PCB, there's footprints and mountings of various types. PCB size. Are we limited by space constraints? Are we trying to fit this into something special? What does that look like? Can we go multi-layer? If you've never built a PCB or don't know anything about them, you can add multiple layers to a PCB to make running those wire traces or copper traces uh less cumbersome so they don't run into each other, right? As you do so, the board gets thicker, which isn't usually a big deal, but your price goes up and you start limiting the vendors that will build your board for you. So, something to consider there.

And finally, are we missing any components that we need? We talked about those recommended circuits and you know all those other components on the boards. Are we sure we have everything? All right. Now, I'll take you through what we looked at on each of these steps. First of all, power. For us, we were tapping into the USB bus, so we should have a relatively stable power supply, provided we're not overloading the bus. By spec, uh USB 2.0 0 gives us 5V DC and 500 milliamps max. All right, but if you remember earlier those SAMD21 chips, they run at 3.3 volts. So, how are we going to approach this without frying the chips? Well, we're going to

throw a voltage regulator in there. In particular, a low voltage low volt can't even talk today. Low voltage dropout regulator. Now, this will give us a span of anywhere from 2.4 volts to 5.5 volts input. So, we can cover that entire range of USB power in and take the uh dropping power and still have a steady output. So, we don't have a brown out condition if we do start overloading that bus. And this particular one gives us this 3.3 volts out and 1 amp max. Now, this is more power than the USB can put out. However, I do not want my voltage regulator to be the choking point in power, right? I want that to be the bus

itself. All right, so now we got power covered. How are we going to connect to it? Well, in our project, we already know we're connecting to a keyboard and a PC. So, USB is obvious. But if we're going to go inside boards or have some other implementations, right, maybe we need to uh think of something else. What about wire leads? Do we want to splice into a cable in the field and tuck it away somewhere? Could be a viable option. Solder pads. What if we're going inside a device and that already has wires we're going to uh cut into? Maybe we just want solder pads on it, right? Maybe we want to build a custom

enclosure around the cable we're cutting into. It's also a viable option. And we're probably going to need a debugging interface, something to program this with. So, that'll be something we have to consider. Remember, we wanted to add functionality. Maybe we put header pins on there, you know, much like a Raspberry Pi. Something to expand on or we'll have to just redesign the board. These are all things that we took in account when we were designing it. Now, if you've never dealt with components on PCB before, you get a variety of footprints. Footprints are what they look like when they go on the board. Now, how many people here know what uh TQFP or QFN stand for? I got one hand.

All right. Lucky for everybody else, I brought pictures. All right. TQFP stands for think quad flat package. Fancy way of saying I got these little arms and feet that hang off the side of the chip. All right. When this goes on the board, it's nice for me. I hand solder with a soldering iron. I can put probes on the legs. I can put the soldering iron on the legs. However, those legs fall off very easily and they bend. And when that happens, say bye-bye to your chip. All right. So, advantages and disadvantages. Now, QFN stands for quad flat no leads. Now, this is ideal if you can do solder paste. I don't like solder paste, so I

stayed away from this one, but it does shrink your footprint if space is of concern on your PCB. Something to think about at least. Other things to think about, do you have a grounding pad on the bottom of your device? If you're like me and you're trying to avoid solder paste, eventually it's going to catch up with you and you're going to have to use it here because you're not going to use a soldering iron on the bottom side of your device. And for radios, you got to pay attention to copper keypote areas. You can't run copper traces under the chip in that area, otherwise you're going to interfere with your radio. So, be aware

of that. Again, this is all in the manual, so read the manual. through hole design. It's probably what everybody's most common with. You get those axial leads coming off the uh the LEDs, the resistors, things like that, right? Through hole is exactly the way it sounds. It's a hole straight through every layer of that board to the other side. Makes it easy to hand solder, but it's prevents you from being able to run traces and adds obstacles. So, it can really disrupt the flow of your board. If you're not going to do through hole, you're probably going to look at something like SMT. Now, you'll see SMT. SMD stands for surface mount technology or surface mount device. Fancy way of

saying I got these little solder pads I'm going to stick it on to on one side of the board. All right. And finally, we have to pay attention to our SWD interface. Now, this is our first cyber squirrel tangent of the day. If you don't know what SWD stands for, it's serial wire debugging. Think stripped down J-tag for ARM controllers. It runs on two wires. But what we're concerned about today is this is how we're programming the boot loaders and the program into the chip. All right. In order to do that, we have to interact with the SWD interface through something like a Sega JLink adapting down to an adapter or a connector. We use the Allax J-Tech

adapter which conveniently ends in the standard connector for SWD connections. Adafruit sells a breakout board here for it. So there's one available if you're doing it on breadboards. And of course we have to flash it with some sort of software. So we're using the microchip at Mal Studio because we're using microchip controllers. All right. So we can program with the chip. Now, where do we go? Well, let's get back to it. I've worked with dev boards. Now, can I prove out I can work with a single chip? The best way to do that is with a test socket. So, this little guy here is nothing more than a breakout for every individual pin on that uh microchip. All those little

legs can now be mapped to uh points on a prototyping board. So, I wired up power and ground and USB in and uh the two USB wires for USB just to see if I could work with a rod chip purchased from a vendor. At this particular stage, I learned that if I loaded it with the Sparkfund bootloader, I didn't need that recommended circuit. It just worked. Awesome. It's going to simplify my design, right? But I'm not using the Sparkf fun bootloader or libraries. I'm using the Arduino. Flash it with the Arduino bootloader. no ice wouldn't work. So, I started combing through the recommend circuit and found I need a minimum of two of the recommended

capacitors to get it working. Now, I'm going to go ahead and give microchip the win on this one because I decided to implement the full recommended circuit. I didn't want to find out down the road that uh I was cheaping out on, you know, 5 cents a product to uh then find myself dead in the water later because I was pushing the limits. So, they got the full recommended circuit. But more importantly, at this stage, I proved out I can work with a raw chip from anybody that I order, but it might need some extra components. All right, where do we go from here? Well, we got half of it working. Let's build the entire thing on a breakout

board. All right, let's do that. Well, this is where the second cyber squirrel tangent comes in. Remember that thing called the chip shortage? Yep. That's when we got hit with it. It's now about the time we want to work with raw chips is about the time we can't get the raw chips. So, what do we do? Well, we're hackers, right? We'll find a way. So, Microchip has this fancy little thing called uh programming service where you can put a program on a chip, order it, and they'll send you a sample. Great. After rotating through a few emails, they started catching on and my lead times went over a year. So, that wasn't viable anymore. So, we started contacting local board

shops. Can you will you sell us chips? The answer was no. Can't blame them. They're protecting their supply, too. Well, maybe eBay. So, funny story about eBay. Uh, we were starting to find some devboards on eBay and we're buying a bunch of them. Now, the guy we were buying them from got really curious why we needed five dev boards at a time. And so we started talking to him and he actually ended up building a production run for us at Defcon of our boards. So that did pay out a little bit, but that took a while to uh nurture that relationship. So it didn't keep us moving at the time. What did though was sacrificing existing boards. Do you

remember the cost on that Trinket M0? $10. You know what the availability was? Readily available. So, we were running $10 chips just to keep going. But, you know, you decolder some chips, you keep going. The fact that we were able to keep going was priceless at this point. All right. So, we can go forward. Let's do that. The next step is to build that full mockup. So, I busted everything out on the protoboards just to prove out I could do it. And we built it. Looks good, right? Not so much, but it worked. It worked as designed, right? So, if you notice, I'm doing a lot of work before I jump down the path of

design custom PCB. I'm trying to get all my foundation built before I do what I consider the more complex steps. Where do we go from here? Now, I do have to design that PCB. I can't put it off anymore. So, I got my circuit built, got it on a schematic, right? because we've kind of been building that out this entire time. So, I start laying out the components one by one and start running the traces. Now, we could talk all day about how to design a PCB. I'm probably not the best person to talk to about this because I don't know what an EE knows about the proper way to do this. What I can tell

you is I ran the traces and it worked all right. But I'll let you guys look at the tutorials because it's more than the time I have allotted today. But so you know what it looks like. This is what it looks like. All right. Front and back of the PCB. You can see kind of the uh components and the traces run. My first design looked a little something like this. Now, this is about as ugly as it gets. If you notice, I thought I had the bright idea of putting a chip on both sides to make it easier for me to solder. I'll tell you, don't do that. Fun fact, when you heat up one

side of the board, you heat up both sides of the board and one chip tends to fall off. So, I was playing a lot of back and forth to get that thing soldered together. I got there. All right. But more importantly, what did I learn after testing this out? I learned solder paste is not my friend. We were not on speaking terms. I grew up hand soldering with a soldering iron, soldering wire, and 16 gauge automotive wire. Right now, I'm on a PCB trying to solder this thing by hand. And uh where I couldn't I used solder paste, made a mess, refloat it, made a mess, refloat it, made a mess. You get the point, but

either way, we're on speaking terms now. Took a little bit. But probably most importantly at this step, don't cheap out. Just go buy yourself a digital microscope if you don't have one. This one was $100 online, but I could finally start seeing what I was doing on that PCB. And if you've ever worked with like 04 O2 components or smaller, you can lose them on the end of your soldering iron if you're not careful. So, this will at least help you find them back if you're lucky. However, when you do this, also note, you got to be careful with the coffee. Two cups. Two cups is all I could have before it looked like I was

soldering during an earthquake. So, be uh be careful with that. But most importantly at this stage I learned that I did not have the polarity of my uh serial communication line between the microcontrollers correct. Now I wired it correctly when I built it but I didn't draw it correctly in the schematic. All right, time to get that flopped over. So the next steps let's go ahead and get that switched. And while I'm redesigning the board a little bit, let's just go ahead and move those chips to the top and save myself some frustration later. All right. So, I redesigned it, reran the traces, and now I got a much cleaner, more professional looking design and much

easier to solder as well. Now, if you look a little harder at this board, you might notice a little something different. Yep, the radio changed. Thank you. Chip shortage. Now, we had to pivot to a different radio mounting style. All right, what did we learn at this phase? Well, I didn't learn the first time my polarity was switched between my radio and my other chip. So, apparently I like wasting time and money and ordering stuff from China. So, I ordered more boards, switched that line around. And oh, yep. And we ended up on our final PCB release. We'll see if that catches the mic. All right. Um, this is the board we released at Defcon. All right. So, at this

particular point, we had that manufacturer building them for us. And lucky for us, he did. We got him. We got to hand him out. And I kid you not, the day after Defcon, he went dark. So, he was like, "Yeah, I'm going to put this up on my site and sell it." Never heard from him again. Don't know what happened there, but uh back to the drawing board, right? Thankfully, we open sourced it for everybody. I redesigned it so that it would be more readily available with parts from uh like JLCPCB or something like that. Did some design modifications for it after some feedback and some real world usage. Made it more friendly for 3D

printed cases. Add some mounting holes, a little bit more square design for keying, things like that. Right. Got rid of the header pins so that I could use the SWD connectors on top. Uh, now if you look real closely, you notice they're not perfectly square. I'm still hand soldering these. Uh, prefer not to. So, spend a little extra money and have them prefabbed at the factory if you can. All right. And I think we got a little time, so I'll talk about this radio. Uh, one of the happy accidents for this radio is that we had to move to a header style connector. And it wasn't intended, but what it allowed us to do in the future was build hats for that.

So, we could actually field swap different radios on the fly. So, um something good came out of the chip shortage after all. All right. Uh with that, I mean, I hope I can inspire you guys and give you guys some of my learning lessons so you guys can go approach it and build your own and be the next ones up here that I get to sit and watch. All right, with that, I'd like to give a special shout out to Jeremy Miller, the co-creator of Inject on the Hide, the FF for helping us disclose our research responsibly, Soldier Forran and Redfish for their mentorship, and last but not least, the wonderful Bside staff and volunteers for making this happen.

Now, if you're interested in the project, thank you. If you're interested in the project, feel free to scan the random QR code at the security conference. If you don't trust the code, the links are up there. Um, go to our GitHub. We have all of our information available. Feel free to hit us up on Twitter or social media or ask a question in the Discord. Otherwise, just go to injectal-high.com and it'll redirect you to the repo, too. So, thank you. Thank you for your time. >> Awesome. That was very eye opening. If you want to buy a board, buy a couple of them for sure. Can we have a big round of applause for Jonathan?