Bringing the Curtain Down on Flash Protection

The speaker bought a small VHF/UHF radio transceiver module, a surface-mount board with a built-in power amplifier, hoping to add digital voice modes that its stock firmware did not support. The module's microcontroller was a Renesas part with little public documentation. Its flash was protected by a seven-byte ID code that the boot ROM checks before allowing any memory access. A published timing attack depended on a status pin this chip did not expose, and the comparison appeared to run in constant time.

Power analysis over hundreds of thousands of unlock traces produced nothing useful, because the slow internal clock introduced heavy jitter. The breakthrough came from changing the target. Instead of glitching the unlock comparison, the speaker aimed crowbar glitches at flash page reads while the chip was locked. A successful glitch returned a 256-byte page instead of nothing. That data could be sliced for candidate ID codes and each one tested. A tool automated the sweep until a matching code unlocked the device and the full flash could be dumped.

The main takeaway is that fault injection is within reach of a newcomer with inexpensive equipment, and that a tight, automated loop and patience matter more than perfect timing. The talk also argues for archiving datasheets and tools for obscure parts, since their documentation can disappear quickly. Later decapping of the die showed the part shared silicon with other members of its family.