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!

Das U-Boot - the universal boot loader, is a bootloader for embedded boards for ARM, MIPS and several other processors. This is typically installed early on in the boot process to initialize things components. It has support for an unreal amount of things, such as various drive types, a network and USB stack...

U-Boot has an interactive shell that is turned on by default. If enabled on embedded devices, attackers can modify or dump the firmware quite easily. The article contains many ways of doing this, such as using TFTP, over USB or even over serial.

Using TFTP, we can boot into a modified file system to backdoor the device. Pretty neat! They mention a tool called DepthCharge as well. This is a tool for jailing U-Boot with a lot of automated information dumping. If you're doing an audit of U-Boot, this appears to be the tool to use.

The age-old trick of modifying the init script to be set to /bin/bash did not work. So, instead, they choose to modify the flash memory chip with their own version. They dumped the code, used unsquashfs to unpack the file system, backdoored it, resquashed it and wrote it back.

The bootdelay variable is used to determine how long to wait prior to booting into the OS. If this is set to -1 or -2, this check is skipped entirely. Practically, this means that it's not trivial to get into U-Boot shell. To bypass this, a forced error in the reading of flash will drop you into a U-Boot shell - this is called Pin2Pwn. Can we stop this!? You can't.

The variables bootdelaykey and bootstopkey are passwords for stopping/delaying autoboot. If you don't know these passwords, then you can't go into the shell (even with a glitch like before). This is simply a plaintext password in an ENV variable. By either reading this from the NVRAM or brute forcing the password, it's still possible to break in. bootstopkeysha256 is similar but a sha256 hash.

This begs the question: how do we secure U-Boot?

• Sign and authentication U-Boot with a secure chain of trust.
• Disable the autoboot interrupt and the serial console.
• Ensure that bootargs for Linux are not trivial to modify.

Overall, a very in-depth post! I didn't cover everything in my recap since some of it is already in my notes. But, will be a go to article for U-Boot going forward.