I am an electrical engineer working on hardware, embedded systems, and practical reverse engineering. I write up the projects when the details are useful enough to share.
Selected Work
Hardwear.io 2026 CTF 1st Place Winner
Won the Hardwear.io 2026 CTF with James Rowley.
Embedded.fm 519: The Password Is All Zeros
James Rowley and I spoke with Elecia and Chris about safecracking, security, and the ethics of doing a bad job. The episode follows our DEF CON 33 talk, Cash, Drugs, and Guns: Why Your Safes Aren’t Safe, including our safecracking research, legal pressure from a Securam’s lawyers, and how the Electronic Frontier Foundation’s Coders’ Rights Project supported us.
We also covered practical connected-device security baselines: the U.S. Cyber Trust Mark, NISTIR 8259, NISTIR 8259A, NISTIR 8259B, ETSI EN 303 645, and the EU Cyber Resilience Act.
We also discussed related stuff liks reverse engineering tools such as Ghidra, fail0verflow the basis of our microcontroller exploits, and our Hardwear.io talks on breaking into chips by reading the datasheet and extracting protected flash with STM32-TraceRip.
Security for the Rest of Us: What Matters and Where to Start
In this session, we take a practical look at embedded cybersecurity for developers and product teams building connected devices and trying to make sense of the security landscape. We walk through the major regulations and expectations that shape connected-device security today, such as the FDA’s guidance, the EU’s Cyber Resilience Act (CRA), and the U.S. Cyber Trust Mark, along with the product requirements they introduce.
We start with the first steps small teams can take to close the biggest gaps. This includes early wins like generating and using SBOMs, identifying the tasks that continue long after a device ships, and sorting out which requirements truly matter for your product. We also cover cloud-specific topics such as secure architecture, provisioning, and lifecycle planning.
We spend time looking at what real attacks actually look like, why attackers target even “unimportant” devices, and how we can evaluate and verify our own products. Along the way, we explore how to talk about risk in business terms, what “good enough” looks like for consumer hardware. By the end, you will have a clear and practical picture of the baseline safeguards every connected-device team should put in place and how to implement them.
Cash, Drugs, and Guns: Why Your Safes Aren’t Safe
James Rowley and I presented:
When Liberty Safe was found to have provided safe unlock codes to authorities, it made us wonder; how was it even possible for Liberty to do this? Our talk will cover the vulnerabilities we found and journey into the various families of locks made by SecuRam, the OEM of safe locks used by Liberty Safe and other Safe vendors. Our exploration began with an “analog” lock from Liberty Safe but quickly expanded to SecuRam’s “digital” lock lines, where we found a debug port that allowed access to all firmware and data. Through this, we discovered that codes are stored on the externally accessible keypad, rather than securely inside the safe (as well as other issues). These locks, deployed widely in consumer, and commercial safes at major retail chains exhibit vulnerabilities that enable opening them in seconds with a Raspberry Pi. We invite you to our session to see us crack UL-certified High-Security Electronic Locks live!
References:
- Liberty Safe providing safe codes to LE link
- fail0verflow blog on RL78/G13 dumping link
- Past DEF CON talks on e-locks:
- DEF CON 23 (2015) - Hacking Smart Safes - On the Brink of a Robbery - First talk about hacking into electronic safes
- DEF CON 24 - Plore - Side channel attacks on high security electronic safe locks - First talk about attacks on very basic consumer electronic locks
- Work done by Somerset Recon on the BLE version of Securam Lock (B01) link
See our slides for detailed citations.
Hackers Went Looking for a Backdoor in High-Security Safes - and Now Can Open Them in Seconds
WIRED covered my research with James Rowley into Securam safe locks.
DEF CON 33: 1st Place Automotive CTF
Placed 1st in the Car Hacking CTF at DEF CON 33 with James Rowley and OBD2_Obliterators.
Annoyingly, the Car Hacking CTF was not a Black Badge event for DC33.
PIC16F One-Chip Lock-In Amplifier
I shared this demo with the Microchip Technology Inc. Sensor Function Group, recovering a signal from below the noise floor, with just a few lines on a PIC16F.
With just a few lines of code, an alternating addition or subtraction, you can implement a Lock In Amplifier on a PIC16F letting you recover mesaurments form below the noise floor.
Tracing the Untraceable: Extracting Protected Flash with STM32-TraceRip
We circumvented the readout protection of the STM32G0 processor family using a novel platform, STM32-TraceRip. This tool allows us to collect runtime execution traces from the processor, even with active protection settings in place. We developed a unique algorithm to reconstruct protected flash memory contents using sparse intermediate values captured during the boot-up CRC process. This technique can target a wide range of STM32 chipsets, including STM32G0, STM32C0, STM32F0, STM32F1, and others.
Bootup CRCs are a common feature of robust systems, making this technique widely applicable. In addition, this technique can enable black box coverage guided fuzzing of embedded systems.
No DAC? No Problem
Based on my research reverse engineering the Microchip CLB I built a 16bit sigma delta DAC with no external components other than some external filtering. In order to fit this in I had to fill every single gate in the fabric, this required amnual place and route fo the fabric, the build toold don’t support designs enarly this dense.
I won the 2025 Configurable Logic Design Challenge with this project. Microchip also produced a video covering my build.
Time to Digital Converter
Based on my research reverse engineering the Microchip CLB, I built a Time to Digital converter on the PIC16F13145 with no external components that had a 1.2ns RMS error. Leveraging illegal design and construction teniques like unclocked latches and manual routing and configutration.
Reverse Engineering the Microchip CLB
Microchip added a very cool peripheral called the Configurable Logic Block (CLB) to there new PIC16F13145 microcontroller family. It’s essentially a small FPGA (32 LUTs) that can connect to the internals of the chip.
However, they don’t document how to configure it yourself, only referring you to their online configurator tool that submits jobs to an API that places and routes to LUTs.
The [CLB] Interface does not appear as an SFR in the Register Map and is not directly user-accessible; it is accessible only through a programming system such as Microchip MPLAB® Integrated Development Environment (IDE) that supports programming the CLB. - PIC16F13145 Datasheet
So I decided to reverse engineer it myself!
Teaching New Tricks to an Old Micro: Breaking into Chips By Reading the Datasheet
Renesas (formerly NEC) claims their 78K0S Series processors have no ability to read out their flash contents through the programming interface. Yet, we identified two methods to do exactly that - regardless of the protection settings used. Even after 40 years on the market, these chips are still used in actively marketed products, including consumer security products.
In this talk, we will take you through our journey of identifying both these readout methods, and our approach of reading between the lines - as, believe it or not, both our methods are more or less described in the datasheet, albeit in different terms. We will also be sharing tools and documentation to exploit these two vulnerabilities, and a disassembler for this processor family.
Using an Oscilloscope to Peek Below the Noise Floor
James Rowley and I gave a talk on how Lock in Amplifers work, avoiding the compelx phasor math that norma;lly clouds hgow it works and isnted giving an intutuve explanation. We also demonstrated and released a software package that turns any Oscilloscope into a lock in amplifer.
Characterizing the Raspberry Pi Pico ADC
The RP2040 datasheet has a woefully underspecified Analog to Digital Converter. I cahrctized it’s analog preformance inclduign detailed descriptions of how each ADC apramater is defiend and measured.
I uncovered and reported a significant erratum with the ADC (RP2040-E11). The SAR feedback capacitors had incorrect ratio sizes caused by parasitic extraction errors, which manifested as large DNL issues.
60MHz Bandwidth 250Msps Probe-Scope
I worked with James Rowley to build a “Probe-Scope” the idea was to have a USB oscilloscope in a probe formfactor, a Oscilloscope probe on one end and a usb port on the otehr.
It targeted a $100 per-channel price point and was pwoered by a PIC32MZ2048EF, Lattice MachXO2 FPGA, HyperRAM, AD9481 250 MSPS 8-bit ADC, ADRF6518 variable-gain amplifier with a programmable filter.
1 Square Inch 20msps Oscilloscope
I built one-inch by one-inch oscilloscope for the The Return of the One Square Inch Project with James Rowley. It’s built around the PIC32MZ EF processor; it uses the processors 4 ADC cores interleaved to reach 20 MSPS.