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!

Many iPods were jailbroken back in the day. However, many of them survived the craze without being touched. To the author, this is unacceptable! So, they went down the rabbit hole of Jailbreaking the iPod nano 5G+.

The iPod Nano tech stack is different other devices. Instead of running iOS/XNU, it uses an embedded RTOS that is based around the RTXC kernel. This is not a security based kernel but has literally zero research into it. The early devices use a PortalPlayer SoC but the 3G+ use a Samsung S5L87xx SoC.

The boot flow is as follows:

1. BootROM: The on-die boot to get the system going. It performs just enough operations in order to load the second stage bootloader.
2. Second Stage Bootloader: Loading from either NAND/NOR depending on the device. Brings up other peripherals like the LCD screen, DMA and DRAM. Once it's loaded these, it loads the main firmware.
3. OS/Disk/Diags: There are several modes that can be used. First, the main OS can be booted. This uses the Image1 format, which was used by early iPod systems. Second, there is a disk mode (unsure what this is) and a diagnostic mode.

When booting into system recovery, the BootROM goes into USB DFU mode called WTF. The WTF system verifies the image then boots. This means that the USB stack can be attacked! The author didn't have access to the BootROM of these devices though; they were the first to look at them! From prior hacks, they did have good notes from previous hackers, BootROM from 2G, 3G and 4G and decrypted firmware from these devices. This was a good starting point for looking for new bugs.

The previous jailbreak was down via X509 parsing - Pwnage 2.0. They didn't see any obvious new bugs here though. While looking through the USB stack, they would an extremely straight forward buffer overflow. A crafted USB setup packet with a large index is used fora write into the usb handlers without any boundary checks! This means we have a an out of bounds access of USB handlers. What can we do?

Effectively, we can treat some of the fields after usbHandlers in State as a code pointer to jump to. These are offsets 0x64 + (0x1c * n) and 0x68 + (0x1c * n) for N in 0..255. From experimentation, they learned that wIndex to 3 with a class request will treat the uint at 0ffset 184 in the State as a code pointer and execute it. In that location, there's a counter called ep0_txbuff_offs that can be used.

The device can send over what's in the buffer and receive data for the buffer as well. Using this, we can use a value between 0x0-0x600 as the address to jump to. At address 0x3b0 is the ARM instruction blx r0, which will jump to the address at r0 which is an argument in the USB::HandlePendingSetup call. This means that the USB setup packet will run as ARM code! The DFU buffer is 136 bytes, which is more than enough instructions to get stable code execution.

With the 4G tackled, with a known attack, we can now go after the 5G. Luckily enough, using the same code as before will cause a crash but the code execution doesn't work. They created an oracle to try to find the gadget from before. If they made the code jump to 0x000, then a reset would occur. Otherwise, something else would have happened. They jumped to the DFU buffer and executed the same shellcode as before.

With the stable exploit, they were able to boot their custom firmware over USB. With this, the BootROM can be dumped and Linux can be booted from. Overall, an interesting blog post on reverse engineering and blind exploitation.