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.
- PCB Basics
- Khan Academy Course on Electrical Engineering
- Electronic Components Explained (The Engineering Mindset)
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.
Subscribe to our blog
Be first to learn about latest tools, advisories, and findings.
Thank You! You have been subscribed.
Recommended Posts
You might be interested in these related posts.
Mar 13, 2026
Winning CTFs: A Proving Ground at HackMex & Ekoparty
Feb 26, 2026
Introducing CloudFox GCP: Attack Path Identification for Google Cloud
Feb 19, 2026
AI & Security Risks: Reviewing Governance and Guardrails
Feb 09, 2026
Most Security Programs Test a Fraction of Their Applications. That Changes Today.
Facts Only
A red team engineer at Bishop Fox designed a custom hardware tool for cloning access badges during physical security assessments.
The existing tool was fragile and unreliable in field conditions.
Commercial alternatives were expensive, closed-source, or lacked adaptability.
The engineer had no formal electrical engineering background or prior PCB design experience.
The project involved learning electrical engineering basics, reading datasheets, and consulting an experienced engineer.
AI tools like ChatGPT were used but required verification due to inaccuracies.
The tool powers itself and an external badge reader via USB-C Power Delivery negotiation.
A key insight involved understanding signal behavior (low-side switching) to control power flow correctly.
The final PCB design worked reliably in field conditions.
Resources included KiCad for PCB design, Khan Academy’s EE course, and YouTube tutorials.
The engineer emphasized that curiosity and persistence outweighed formal credentials.
The project was completed as part of Bishop Fox’s red teaming activities.
Executive Summary
An engineer without formal electrical engineering training successfully designed and built a custom hardware tool for physical security assessments after identifying gaps in existing commercial solutions. The project, undertaken at Bishop Fox, involved creating a durable, field-ready badge cloning tool to replace fragile alternatives. The process required learning electrical engineering fundamentals from scratch, including reading datasheets, consulting experienced engineers, and leveraging AI tools—though with caution due to inaccuracies. The engineer emphasized iterative learning, testing assumptions, and embracing discomfort as key to overcoming the steep learning curve. The final product met operational needs, demonstrating that unfamiliar domains are more accessible than they appear. The narrative underscores the value of curiosity, persistence, and community support in tackling complex problems outside one's expertise.
The account also highlights the unforgiving nature of hardware design compared to software, where small errors can render a system nonfunctional. The engineer's reliance on mentorship, reference designs, and incremental validation illustrates a pragmatic approach to bridging knowledge gaps. While AI tools provided initial guidance, their limitations necessitated cross-referencing with authoritative sources. The project’s success challenges the notion that formal credentials are prerequisite for meaningful innovation, instead advocating for a problem-solving mindset and willingness to engage with uncertainty.
Full Take
This narrative is a compelling case study in self-directed learning and the democratization of technical skills. At its core, it challenges the gatekeeping myth that complex domains like hardware engineering are inaccessible without formal training. The strongest version of this story is one of empowerment: by breaking down the problem into manageable pieces, leveraging mentorship, and embracing failure as part of the process, the engineer transformed a "pipe dream" into a functional tool. The account is refreshingly honest about the frustrations—AI hallucinations, misinterpreted datasheets, and the unforgiving nature of hardware—while still celebrating the incremental wins.
Yet, the narrative also subtly reinforces a Silicon Valley-esque "just do it" ethos, which can overlook systemic barriers like access to mentors, time, or resources. The engineer’s success hinged on having a patient expert to sanity-check ideas—a privilege not everyone enjoys. Additionally, the focus on individual persistence might inadvertently downplay the role of structural support (e.g., employer encouragement, open-source tools) that made the project feasible. This isn’t a flaw in the story but a reminder that "just try" advice often assumes a safety net.
The deeper pattern here is the tension between specialization and generalist problem-solving. As technology advances, the ability to bridge disciplines—even superficially—becomes a superpower. But this also raises questions: How do we scale mentorship for those without existing networks? What risks arise when non-experts design safety-critical systems? The engineer’s humility in verifying AI outputs and seeking feedback models a responsible approach, but the story doesn’t grapple with cases where such caution isn’t exercised.
Ultimately, this is a story about agency. The engineer’s journey mirrors the broader shift toward "learn in public" culture, where documentation of struggle becomes as valuable as the end product. For readers, the takeaway isn’t just "you can do this too" but "how might you structure your own learning to mitigate risk?" What if the project had failed—would the lessons still hold value? And how do we distinguish between healthy discomfort (growth) and reckless overreach (e.g., DIY medical devices)?
Counterstrike scan: If this were part of a coordinated campaign, it might aim to erode trust in formal education or promote a "move fast and build" mindset without safeguards. However, the content’s emphasis on verification, mentorship, and iterative testing aligns poorly with such a playbook. The narrative’s integrity lies in its transparency about limitations—no false promises, no glossing over failures. It’s a genuine call to action, not manipulation.
Patterns detected: none
Sentinel — Human
The article exhibits strong human authorship signals, including a distinct personal voice, erratic stylistic patterns, and contextually rich technical storytelling. No significant indicators of synthetic generation were detected.