FAQ
Will you extract firmware via chip-off if the device has no exposed debug interface?
Yes, when the engagement scope includes hardware-level analysis, the client supplies sacrificial samples, and the chip-off path is the right call against the threat model — not as a default. Chip-off is destructive; we agree on it as a scoping decision, not as a unilateral testing decision.
Short answer
Yes, when the engagement scope includes hardware-level analysis, the client supplies sacrificial samples, and the chip-off path is the right call against the threat model — not as a default. Chip-off is destructive; we agree on it as a scoping decision, not as a unilateral testing decision.
What chip-off means
Chip-off firmware extraction is the physical removal of the storage chip (eMMC, NAND, NOR, eMMC-NAND combo) from the printed circuit board, followed by reading the chip on a programmer or specialized reader. The technique is used when no software-accessible path to firmware exists — no JTAG, no SWD, no UART bootloader interface, no exploitable network service, no available firmware-update package from the vendor.
The technique is destructive: the sample is unlikely to function after the extraction unless we follow with a re-ball / re-solder process that the engagement scope and budget rarely justify. For this reason chip-off is a scoping decision, not a default test step.
When we do it
Engagement frames where chip-off is the right call: - The client has a stated threat model that includes adversaries with physical access (lost / stolen device classes, deployed-field tampering) - Software-side extraction has been attempted and exhausted - The firmware binary is not otherwise available (vendor refused to share, no public update package, no SDK exposing the binary) - Client has supplied 3+ sacrificial units (we typically need at least 2-3 to account for damage in the desolder process)
When we do not do it
We do not chip-off as the first extraction attempt on a device that has an exposed UART pad, has a documented firmware-update mechanism, or where the SDK or vendor portal makes the firmware binary downloadable. The non-destructive path is faster, more repeatable, and produces the same artifact.
Related
- What is Embedded Linux? - What is FreeRTOS? - What is Secure boot?
---