Firmware & Reverse Engineering

At a glance

• Outcome: Reflashed firmware and VPD board-identity data on ultrasound parts across 60+ models with manufacturer and custom tools, and turned the procedures into repeatable, checked runs. A firmware-recovery process restored previously unusable systems subsequently sold for approximately $50,000 combined.
• Status: Used in production at Sonovision, a working ultrasound repair shop, from Jan 2025 through Aug 2026.
• Role: Solo: did the bench work and analysis; reviewed AI-assisted tool code.
• Contribution: I did the bench work and the Ghidra, QEMU and GDB analysis, and wrote the format specs each tool was built from. AI drafted the Python and Rust tool code from those specs; I reviewed and fixed it.
• Validation: The Rust CLI matched the vendor Windows utilities’ output byte for byte on the same inputs. Each procedure ran on spare or donor boards before a customer machine, and every run backs up first, reads twice and compares after writing.
• Stack & libraries: Python, Rust, Ghidra, QEMU, GDB, flashrom; a CH341A SPI programmer, JTAG/SWD and UART consoles, a multimeter.
• Source: Private. Vendor names and step-by-step procedures are withheld.
• Limitations: Covers only the hardware families on the bench.

At Sonovision I diagnosed and repaired ultrasound machines across 60+ models. Much of that work was at the firmware level, the low-level software stored on chips inside a machine. I reflashed that software and each board’s identity data on many different parts, sometimes with the manufacturer’s tools and sometimes with tools I built. When a file format had no documentation, I worked out its layout with Ghidra, a tool for reading compiled code, and by comparing that code with what went in and out of it. I built Python and Rust tools so anyone on the bench could run those procedures.

I reprogram the startup chip while it’s still on the board, using a small USB programmer and a clip. Every job reads the chip twice and compares the two copies before it writes anything, then checks the result. For a board’s identity chip, I built a Python tool that edits it from inside the running machine through a hardware library already on the system. The chip never leaves the board. The tool verifies each field’s built-in error check and backs up the chip before every write, because one bad write can permanently disable a board. Two of the manufacturer’s Windows programs became one tested Rust tool. The manufacturer’s .NET service programs now run on Linux through Mono, with Wine as a fallback, behind one command-line tool and a local web page.

The same procedures turned dead stock into inventory. I developed a firmware-recovery process that restored previously unusable systems. Those systems were subsequently sold for approximately $50,000 combined. That figure is their combined sold value, not profit or the value of one machine.

One machine worth $5,000–$7,000 had one of its two drives locked, with the password stored encrypted in its firmware. The other drive was unlocked and served as a reference. I ran the machine’s own operating system in QEMU, an emulator, and stepped through its startup with a debugger to find where the drive gets unlocked. From that code, I rebuilt the steps that encrypt the stored password. Then I tried candidate values from likely memory locations until one matched, ran it through those steps, and unlocked the drive with a DOS disk utility.

Every procedure backs up first, reads before it writes, compares after it writes and keeps a record of what it did. These tools ran in production at the shop through Aug 2026. The same analysis fed the compatibility data in Parts Intelligence. The shop’s daily tools are in Repair Shop Automation. Vendor names and step-by-step procedures stay private.