Firmware & Reverse Engineering

At a glance

• Outcome: Hardware the official path treats as bricked comes back, and expert-only recovery rituals become runs that anyone on the bench can repeat and verify.
• Status: Reached production use in a working repair shop.
• Role: Solo.
• Stack & libraries: Python and Rust tooling; Ghidra, captured I/O, and ground-truth test vectors for the analysis side.
• Source: Private. Some methods are the whole value and are easy to copy once spelled out, so specifics here are deliberately vague.
• Validation: Integrity checks on every write, so a fix can be verified rather than trusted, because the failure mode is a permanently dead board.
• Limitations: Bound to the hardware families I had on the bench.

Overview

Low-level work on the firmware inside hardware I serviced: reading, writing, and recovering BIOS and EEPROM images; repairing board identity and configuration data; and reverse engineering the parts that aren’t documented. The goal each time was to turn expert-only, one-shot procedures into tooling that’s fast, repeatable, and hard to get wrong.

What I worked across

• BIOS / SPI flashing on a range of boards: dumping, reflashing, and recovering firmware images, including bringing back boards the official path treats as bricked.
• EEPROM and board-identity data: inspecting and repairing the configuration and identity regions hardware relies on, with integrity checks so a fix doesn’t quietly corrupt something else.
• Reverse engineering the undocumented parts: disassembly and analysis (Ghidra, captured I/O, ground-truth test vectors) to understand a format or protocol well enough to work with it safely.

A case that stuck with me

A machine’s drives were locked behind an encrypted volume whose password was itself stored, encrypted, in firmware memory, and the only description of the encryption scheme lived in the compiled binaries sitting on those same drives. Working back through the binaries, I figured out how the scheme worked and, crucially, what to even search for, then recovered the password and unlocked the pair of drives. That turned a $5,000–$7,000 machine bound for the junkyard back into a working system.

It’s the kind of problem I like: the answer is in there somewhere, and the job is reasoning out where to look.

What made the tooling different

• It scripts procedures normally done by hand, so an hours-long expert ritual becomes a repeatable, auditable run.
• Where possible it drives devices through their own built-in software and system calls instead of fighting the hardware from outside, which means fewer moving parts, less risk to the device and more consistent results.
• Built in Python and Rust, to do the specific jobs the vendor tools on our bench handled badly or not at all. That is a claim about our hardware families and our workflow, not a general one about the industry tools.

A note on detail

Some of the reverse-engineering methods are the whole value and are easy to copy once spelled out, so I keep those specifics deliberately vague. Happy to walk through the general approach in the right context.