Reverse engineering a board with no schematic
The machine still runs. The company that built the controller board inside it does not, or stopped answering, or discontinued the product line years ago. Nobody has the schematic, the BOM, or the source for whatever firmware is on the microcontroller. There’s just a board, a bag of spares that’s down to the last two units, and a process that stops if this fails. That’s the point most reverse-engineering requests start, and it’s almost never about curiosity — it’s a production line, a piece of test equipment, or a deployed product that outlived its original design records, often the same situation an end-of-life notice on a key part forces on a board that does still have its files.
What “reverse engineering a board” actually means
It’s not one task. It’s four, and they don’t all apply to every job:
Netlist extraction — figuring out what’s connected to what, so the board can be redrawn as a schematic. This is the part everyone pictures, and on a simple two-layer board it’s mechanical: photograph both sides, trace copper visually or with continuity beeps, build the connectivity in a CAD tool net by net.
Component identification — reading part markings and cross-referencing them to real part numbers, values, and packages. Passives are usually easy; ICs with sanded-off or house-coded markings are the hard case, and sometimes an unsolvable one.
Functional understanding — knowing not just what’s connected, but why. A netlist tells you a pin goes to a resistor and then to ground. It doesn’t tell you that resistor sets a current limit, or that the pin is a comparator threshold, or that removing it changes a timing constant that matters. This step is where an engineer, not a tool, does the work.
Firmware recovery — reading back what’s on the microcontroller, if it’s needed and if it’s possible at all. This is the piece most likely to hit a wall, and worth understanding separately from the other three.
A given job might need only the first two — enough to source a compatible replacement board or requalify a supplier. Or it might need all four, because the goal is a drop-in redesign around parts that are still available.
Multilayer boards change the job
A two-layer board is visual inspection and patience. A four-layer or six-layer board is not, because the inner layers aren’t visible from either side. Getting at them means either X-ray inspection, which shows via structure and inner-layer routing without touching the board, or mechanical delayering — sanding or milling the board down one layer at a time and photographing as it goes, which is destructive and consumes the sample. X-ray is faster and non-destructive but needs access to the equipment and doesn’t resolve fine-pitch traces as cleanly as a direct photograph of a sanded layer. Delayering gives a clean image but only works once per board, so it only makes sense with more than one unit in hand, or with a unit that’s already failed and has nothing left to lose.
Either way, a multilayer board takes materially longer than the layer count alone suggests, because each inner layer has to be correlated against the ones above and below it — a via that looks like it terminates on layer two might continue to layer four, and getting that wrong produces a schematic that looks plausible and is wrong.
The component that won’t identify
Every reverse-engineering job eventually hits an IC with the top marking ground off, or a house number that doesn’t cross-reference to anything, or a chip epoxy-blobbed directly onto the board with no package to read at all. There are a few ways forward, in order of how much they disturb the part:
Circuit context first. Before touching the part physically, trace what’s around it — power rails, clock or crystal connections, what talks to it on which pins, decoupling values. A lot of ICs are identifiable by role alone: an 8-pin part with two crystal pins, VDD, VSS, and two lines running to a connector is very likely a UART bridge or a simple microcontroller, and that narrows the search a long way before any destructive step.
Datasheet and pinout matching. Package outline, pin count, and pinout pattern narrow a family fast, especially combined with what the circuit context already suggests. Distributor parametric search tools are built for exactly this kind of narrowing.
Decapsulation, as a last resort. Removing the epoxy package to expose the die can reveal a die-marked part number, or in the absence of one, allow the die itself to be photographed and analyzed. It’s destructive, it needs the right chemistry and equipment to do safely, and it doesn’t always yield an answer even after the part is opened — some dies carry no visible identification at all. It’s the option to reach for only after context and pinout matching have both failed.
Firmware is a different problem entirely
Recovering the connectivity of a board is a hardware problem. Recovering what’s running on the microcontroller is a security problem, and modern parts are built to make it hard on purpose. Most current-generation microcontrollers — STM32, Nordic nRF52/nRF53, Microchip SAM and PIC parts with readout protection — ship with a debug-port lock the vendor calls something like readout protection (RDP) or a code-protect fuse. Once that bit is set at the factory or by whoever programmed the part originally, attaching a debug probe over SWD or JTAG returns nothing, and the vendor does not provide a backdoor. This is by design: the same protection that stops a competitor from lifting a product’s firmware also stops the product’s original owner from getting it back once the source is lost.
There are documented voltage-glitching and fault-injection attacks against readout protection on specific silicon revisions of some of these families, published by security researchers as proof-of-concept. They are not a service anyone offers as a routine repair path — they require part-specific research, specialized equipment, a real chance of destroying the sample, and in most jurisdictions a real question about whether extracting someone else’s IP without authorization is legal at all, separate from whether it’s technically possible. Reverse engineering a circuit for interoperability or repair is on much firmer ground than extracting a copy of proprietary firmware; treat the two as different problems with different answers, not points on the same spectrum.
The practical implication: if a board’s value is in its firmware and RDP is enabled, plan for a rewrite, not a recovery. That’s usually less painful than it sounds, because reverse engineering the hardware — every peripheral, every I/O pin’s function, every timing-critical signal — hands over exactly what’s needed to write new firmware that reproduces the original board’s behavior, running on the original part or a modern replacement. The schematic comes back either way; the question is only whether the old binary comes back with it.
What the output should look like
A reverse-engineering job that stops at “here’s a picture of the traces” hasn’t produced anything usable. The deliverable that’s actually worth having is a schematic in a real CAD tool — KiCad is the obvious choice if nothing else constrains it — with every part identified against a current, sourceable part number, not just the one that was on the original board if that part is itself obsolete. That distinction matters: reverse engineering a board that exists because its original parts went end-of-life, and then redrawing it around parts on the same discontinued footing, solves nothing. The schematic should get requalified against current supply the same way a fresh design would.
What to send us
If a board needs to be turned back into a schematic — because the company that made it is gone, the documentation was lost, or the part on it just went obsolete and a redesign needs a starting point — send the board itself (or clear photographs of both sides if it can’t ship), whatever spares exist, and what the end goal is: a like-for-like replacement, a modernized redesign, or just documentation for a part that still works but nobody understands. That last question changes how deep the job needs to go, and it’s worth answering before any board comes off the shelf.
Have a working board and no drawings for it? We recover the schematic and produce buildable files.
Tools for this topic
- BOM risk checkPaste a bill of materials and get a lifecycle and availability verdict per line before you order.
- PCB trace impedanceTrace width for a target impedance, or the impedance of a width: microstrip and stripline, single or differential pair, with 4-layer stack-up presets.
- Voltage dividerVout from Vin and two resistors, or the best standard pairs for a target Vout — with tolerance range and load effect.
Related notes
- Moving a legacy Altium or Eagle design into KiCadWhat KiCad's importers convert, what they silently drop, the checks that prove the new files match the old board, and what to export before a license dies.
- Checking a chip's longevity before designingHow to read ST, NXP, TI, Microchip and Nordic longevity programs, what each one actually promises, and the checks to run before a part goes on the schematic.
- Substituting a ceramic cap on long lead timeThe checks that decide whether a backordered ceramic capacitor can be swapped: DC bias, dielectric, voltage rating, ESR, height and board flex.