Accidental Engineer: Building My First Hardware Tool the…

TL;DR: We needed a more durable, field-ready badge cloning tool for physical security assessments, so I decided to build one myself despite having no formal hardware background. The process meant learning electrical engineering fundamentals from scratch, validating everything, and accepting that hardware punishes bad assumptions. AI and online resources helped, but only when paired with datasheets, testing, and advice from experienced engineers. The biggest takeaway: unfamiliar domains are more learnable than they seem, and the only real barrier to entry is deciding not to start.

This post is a story about curiosity, persistence, and what happens when you decide to step outside your comfort zone. It is about seeing a problem that needs to be solved and choosing to engage with it, without knowing whether you will succeed or fail along the way.

Rather than focusing on technical details or clever design choices, this post focuses on the learning process itself. It describes what happened when I committed to solving a problem in an unfamiliar space and worked through uncertainty, incomplete understanding, and repeated course correction. While this story involves designing computer hardware, the underlying principles apply to any discipline.

By the end of this post, I hope to encourage you to take the leap on whatever project you have been putting off because you are worried that you will not be able to do it. Even if you fail, you will almost certainly learn something valuable through the journey. If you have been putting off a project because it feels out of your lane, whether that is hardware, firmware, or something else entirely, this is your sign to try anyway.

The Problem

As part of our red teaming activities at Bishop Fox, we perform physical security assessments where we try to (legally) break into a client's facility. Often, that involves cloning access badges, so we can slip into an area without using lockpicks or other burglary tools. Our existing tool for capturing badge data was fragile in the field. It worked… until it didn't.

Commercial solutions exist, and some of them work quite well. However, they come with tradeoffs. They tend to be expensive, their firmware is often closed source, or adapting their behavior or adding features is not straightforward. In practice, field durability and deployment constraints mattered far more to us than impressive specifications on paper.

We needed something that fit the way we work and the conditions we often find ourselves in.

What I Knew Going In (Which Was Not Much)

I do not have an electrical engineering (EE) background, nor have I taken a course in EE. Until recently, I had never designed a printed circuit board (PCB), but it was something I have wished to do for a long time. The idea of creating something I could build and hold in my hand that would perform a task was a pipe dream. The barrier to entry seemed so high. Terminology sounded like a foreign language, and concepts seemed to fly over my head.

I have always been interested in how things work in general. With computer hardware, that manifested itself as board-level laptop repair, experimenting with firmware, a significant amount of self-teaching through YouTube, and trial and error. There is, however, a substantial difference between repairing something and designing it from scratch. When I looked at a circuit board, I wondered what the components were and how they worked together to make the electrons go where they needed to. I had never thought about grounding, power negotiation, or board layout. I knew what a MOSFET was…more or less.

Deciding to Try Anyway

What pushed me forward was not confidence so much as curiosity, combined with a willingness to be uncomfortable.

I spent a great deal of time doing the unglamorous parts of learning hardware. I read datasheets line by line, searched for explanations of concepts I did not yet have the vocabulary for, and studied how other people had solved similar problems. I compared reference designs, followed application notes, and tried to understand not just what a component did, but what it was used for and why.

I leaned heavily on people as well. I asked a very patient friend with EE experience to sanity-check ideas, explain where my mental model was wrong, and tell me when I was overcomplicating things. I asked questions early and often, and learning from his experience was invaluable. He saved me from going too deep down the wrong rabbit holes multiple times.

Along the way, I also used tools like Google, YouTube, and ChatGPT to help fill in gaps. In practice, that usually meant using them as explainers or sanity checks, a way to validate that I was thinking about a problem in the right direction or to get unstuck on terminology, so I could continue researching on my own. One note about AI though: it was a helpful tool to get a broad understanding of a concept, but it made a lot of mistakes. It told me about components that did not exist or specs that components did not really have. If I had blindly followed AI's suggestions, the resulting PCB would not have worked. So, my advice is that if you are going to use AI in your journey, be careful and verify what it is telling you with independent sources.

No single source gave me a finished solution. Progress came from stitching together partial understanding from many places, testing assumptions, breaking things, and then returning to the documentation again.

Learning Just Enough to Keep Going

I would like to relay a moment during the design process that stuck with me. The board powers itself and provides power to an external badge reader by negotiating with the power supply over USB-C, much like a laptop or phone. I was trying to control when power was allowed to flow based on whether USB-C Power Delivery negotiation had succeeded, and I was having trouble wrapping my head around it.

At the time, I was thinking entirely in terms of intent. Power to the rest of the components should be off until negotiation succeeds, and then the board and the attached reader should turn on. This protects the components on the PCB that need steady, reliable power. I knew there were common components used to switch power electronically, but I did not yet have a clear mental model for how control signals and component behavior interacted.

When I talked through it with my friend, he pointed out that the Power Delivery negotiation signal coming from the integrated circuit (IC) I used behaved differently than I assumed. I had thought that when power was negotiated, the IC would pull the power negotiation signal high with a positive voltage. In reality, when power was negotiated, the IC pulled the signal low (to ground). The component I was trying to control needed positive voltage to know when to turn on.

Once that was clear, the solution stopped feeling mysterious. Rather than forcing one part to behave differently, I could add a small intermediary whose only purpose was to translate between the two behaviors. The hardware itself had not changed; my understanding of how to reason about it had.

When my friend summarized the idea with a short phrase ("low-side switch"), it was less about the specific circuit and more about vocabulary. I finally had the right words to search for examples, read documentation, and confirm that the approach made sense.

That pattern repeated itself throughout the project. Small clarifications led to better questions, which led to better searches, which sent me back to the datasheet. This time with enough context to understand what I was reading.

The Part Nobody Warns You About

Hardware is unforgiving in a way software often is not. Assumptions get punished. Small details matter. A single flaky connection can make the entire system feel haunted. You do not really debug so much as methodically remove uncertainty.

At some point, my mindset shifted. Instead of trying to finish quickly, I focused on understanding why something worked or did not. Progress slowed, but confidence grew. I stopped feeling like I was guessing and started feeling like I was learning.

When It Finally Worked

Eventually, the board powered up. Everything behaved the way it was supposed to. Power and badge data flowed. The tool did the thing it was designed to do, reliably, in the field.

I realized that I had not crossed some forbidden line by attempting hardware. I had simply learned something new.

What I Took Away From This

What stuck with me most was how learnable all of this turned out to be. You do not need to know everything up front, and you do not need formal credentials to build something real. Curiosity, persistence, and a willingness to ask questions go a long way.

Fear of a domain is often the biggest barrier to entry.

Additional Resources

Here are some resources that helped me along my journey.

I used KiCad (an open-source PCB design suite) to create a schematic and layout for my PCB, but there are other software packages for Electronic Design Automation (EDA). I suggest you try a few to see what feels right to you.

Accidental Engineer: Building My First Hardware Tool the Hard Way