The client believed the router was well-hardened. They had done work to lock it down. UART was disabled or protected in a way that prevented the standard serial console approach. From the outside, the attack surface looked thin. My engagement was to determine whether the hardening was sufficient.
When software-level access paths are closed, you go to hardware. I desoldered the flash chip from the board.
Flash chip desoldering is straightforward if you have the right equipment and know what you are working with. A hot air rework station, the right nozzle, a steady hand, and the chip comes off without damage and can be read in an external programmer. I dumped the contents to a disk image and started working through it.
The image was partially encrypted. The root partition was LUKS-encrypted, which is a reasonable security control. The boot partition, however, was not encrypted. This is a common pattern in embedded Linux devices because the bootloader needs to be able to read and execute from the boot partition before any decryption key is available. The design assumption is that the root partition's encryption protects the sensitive content, and the boot process handles key management.
The problem here was that there was no TPM involved. No hardware root of trust, no sealed key storage. The boot partition contained everything needed to decrypt the root partition at startup, because it had to. There was no other mechanism for the device to boot unattended. When the boot partition decrypts root at startup without any hardware-bound secret, the decryption key derivation logic is, by definition, accessible to anyone who can read the boot partition. Which I now could.
I extracted the initramfs from the boot partition and found the binary responsible for the decryption step. I loaded it into Ghidra and started working through the key derivation logic. I also found publicly available information about the encryption implementation that documented the approach that had been used, which confirmed what I was seeing in the binary and gave me the parameters I needed. The key derivation scheme was not strong. It relied on static device identifiers in a way that made the derived key recoverable from the firmware image alone.
With the key derivation logic understood, I decrypted the root filesystem. I added an SSH backdoor and a root user to the decrypted image, re-encrypted it, reflashed the chip, and resoldered it to the board. When the device booted, I had root access via SSH.
The technical recommendation was clear: hardware-level encryption tied to a TPM or equivalent hardware security module. The fundamental weakness in this design was that the decryption key was derivable from the firmware itself, with no hardware-bound component that would require physical possession of the device in its original trusted state to unlock. A TPM binding the key to the specific device hardware would require an attacker to have both the firmware image and the original device, making the offline attack I performed either impossible or significantly more difficult.
The client had done meaningful hardening work. The UART lockdown was real. But the threat model for that hardening had not included an attacker willing to desolder a chip, and the key management design had not been evaluated under the assumption of an attacker with physical access to the firmware. Those are different threat models, and the gap between them was where this engagement found its result.