# Will you extract firmware via chip-off if the device has no exposed debug interface? **slug:** `faq-chip-off-firmware-extraction` · **URL:** `/knowledge/faq/chip-off-firmware-extraction/` · **reviewer:** Tatiana ### 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?](/knowledge/glossary/embedded-linux/) - [What is FreeRTOS?](/knowledge/glossary/freertos/) - [What is Secure boot?](/knowledge/glossary/secure-boot/) ---