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!

Unisoc is a semiconductor company that is commonly put on Android smart phones. The authors decided to review the Boot process of these chips.

The first step is extracting the BootROM in order to look at the code. Since this is etched into the hardware, there is no reason for this to be public, making it much harder to get. They choose to look at a Teclast phone and a Motorola phone.

Secure boot was not burned into the fuses and the private key is reused from the Unisoc Github repo. By booting this into recovery mode, the BootROM, this could be easily dumped. For the Motorola device, they had to reverse engineer the SDL (secondary boot loader) to try to find an issue, since the previous trick didn't work.

FDL1 is in the recovery process that is normally loaded from the BootROM. Once FDL1 initializes the system memory, it goes into FDL2 using a USB protocol. While parsing this data, there is no limit on the amount of data that can be sent but it is in a static buffer. This results in a buffer overflow that can be used to get code execution to dump out the BootROM.

The recovery mode on the Unisoc chip exposes 5 commands via UART and USB to start FDL1. The command cmd_start took in a user controlled target address and wrote user controllable writable data. This feels like a vulnerability by design!

The USB command dispatcher takes in an index used to execute a function from a list of pointers. However, it does not validate the index. This means that a section of code could be jumped to in an unexpected way. However, this is in the ReadOnly section of memory, making it not trivial to exploit.

The USB data transfer reads in data byte by byte. When doing this, it writes to a static buffer on the stack without validating the size, leading to an out of bounds write issue. A similar exists in the USB command dispatcher as well.

Boot loaders are supposed to verify the next stage is allowed to execute, which is doing using cryptography. While reviewing the verification check on the secondary boot loader, they noticed there were two types of certs: contentcert and keycert. For whatever reason, the contentcert performed 0 validation and return correctly.

The RSA function had a buffer overflow when using a key greater than 2048 bits. Since the overflow occurs in global buffers (unlike the bugs from before), this can be used to smash the stack and get code execution on the chip.

Overall, the vulnerabilities were fairly straight forward buffer overflows or design decisions that led to issues. The article really shines in showing the difficultly of auditing BootROMs from an access perspective and sharing the boot process in general. Great article!