Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

This is the final in a four part series of breaking the secure boot of a Zynq FPGA device. The Zynq family of boot images all contain a set of Register Initialization Lists; this is used prior to the heavily lifting of the bootrom. The RIL's are for hardware initialization including clocks, muxes. power and several other things.

What are the security protections on this? As one would expect, these are covered by secure boot cryptographic signatures. Additionally, there is an allowlist of addresses that can be used. These restrictions include no DMA destination/sources, which were implemented because of pre-release exploits abusing this feature. The signature does have a flaw though: it is only checked after they are parsed and used, creating the potential for security flaws.

To test out these addresses, the author wrote a script to emulate the ROM using Unicorn. To test the allowlisting functionality from above, they directly called the function do_register_init_lists to see what was accessible. In modern systems, there are multiple DMA sections. From testing out all of the addresses, they noticed that the SDIO (Secure Digital In/Out, which is communication to an SD card) controller was NOT blocked for writing.

What does this mean? Boot via SDIO is fair game at this point in the secure boot process. Since this is the case, the author thought "Can I set my own DMA block size into registers?" Sadly, this did not work out, since the ROM resets all of the SDIO config registers with each command. However, it does NOT clear out the DMA base address register. Since this is the case, the pointer to this object will in the 512 byte page buffer.

Since the DMA base address register was never cleared, we can write to the location that this points to in the ROM. The author points out that 0x7068c contains a pointer to the boot function operation to use. Overwriting this with an address of our choice would lead to a compromise. Hurray!

The author ran into a caching issue (along with many other things) since caching at this level is weird; working around this appears to be a complicated problem. To built the full image to compromise secure boot, the author has a script on their Github as well. Overall, this is a really cool post on compromising the secure boot process. Check your signatures early on! :)