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!

While reading various security advisories the author missed while on vacation, there noticed a Pixel anti-rollback notice. This indicated that a vulnerability occurred in the bootloader of the device, making it a major risk and adding an anti-rollback feature to it. Since there was no public information besides there being a bug and it says RCE, the author of the post decided to find and exploit the bug.

The ARM specification for the boot process is going from the Primary Boot Loader (PBL) ->BL1->->BL2->BL31->Trustzone(TZSW) and ABL. BL1 performs late architectural and platform specific initialization and runs the second BL image, which simply loads BL3. BL3 sets up he runtime services for the CPU and helps pass control to the operating system. The bootloader is in likely in BL1 because its the furthest down in the chain that isn't in ROM.

To find the vulnerability, they downloaded versions before and after the patch. By comparing with bindiff, it probably wouldn't be the hardest thing in the world to find the patch for the security issue. They used bindiff on the most of the fastboot commands for each of the binaries. From this, they identified a small bit of code that was removed from the command handlers.

There were low level commands that the fastboot console has access to - flash:raw. However, part 2 appears to refer to a vulnerability in the bootloader but doesn't actually mention what it is. Instead, they claim there's a vulnerability that allows for some sort of write primitive. So, I'm a little confused here.

To build a working exploit, they setup an emulator with Unicorn. The typical workflow for emulation is creating the emulator, setting up the memory in the same way as the image, initializes the device and execution. To top it off, hooks must added to native functionality that cannot be emulated.

With the debugging environment setup, the hacking can be done. To get a nice read/write primitive, we can probably reuse existing code. The internal commands (without handlers) download for reading content and upload for writing content.

Overall, the posts are mildly confusing, as not everything is laid out perfectly. In particular, the vulnerability is not defined well and the wording in the second post can be confusing. However, the process for reverse engineering, emulation and exploit methodology was very interesting!