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!

A group of engineers from NCC Group decided to enter Pwn2Own for a printer. With Pwn2Own, an unauthenicated and remote user must be able to compromise a device or application to become root in its default setting. While starting the hacking on this product, they could not find any. Hence, they bought a very similar model (from the same company) for the time being.

Once they got their hands on the printer , they wanted to reverse engineer the device. Sadly for them, there was a big road block: the device firmware was encrypted online. Time to enter the world of hardware hacking!

First, they identified a serial connector on the device labeled JRIP1 (J is for Jumper). Although they were hoping for an easy shell into UBoot or the Linux OS, it only a log showed up and RX (Receive) appeared to be disabled. This may be been done via e-fuses on the SoC or z zero-ohm resistor; if the resistor approach was taken, it may have been possible to re-enable it. But, they had other means to get the firmware.

Early on, they identified a NAND flash that likely had the firmware of the device. They removed the flash chip using a hot air rework station. Once there, they used a programmer with an adapter for their programmer to read the contents of the flash. Once done, they used the rework station to add the NAND flash once again, demonstrating a successful move. They claimed this only took an hour, which is absolutely wild to me!

With the firmware in hand, it was time to analyze it! First, they remove the OOB data, which is used for error correction codes and flags for the blocks. Once this is removed, they can see the TIM (Trusted Image Module) header in the first hundred bytes of the binary. Within this image are 4 images then the firmware of the chip directly after this in the form of UBI volumes.

By using the ubi_reader tool to extract the 7 images that it detects. The volumes represent partitions used by the device, some of which are file systems. To interact with this file system the author used a NAND flash simulator kernel module, which uses RAM to imitate a physical flash device. After mounting this partition with a few more kernel modules, we are good to go! We can now interact with the file system in a Read Only fashion.

The format of the image after all of the reverse engineering was discovered to be as follows:

• TIMH – Trusted Image Module header, Marvell-specific
• OBMI – first bootloader, written by Marvell
• OSLO – second bootloader (U-Boot)
• TRDX – Linux kernel and device tree
• Base - SquashFs filesystem with binaries.
• Copyright – raw data
• Engine – squashfs filesystem contains some kernel modules for motors, belt, fan, etc.
• InternalStorage – UBI FS image for user data (writable)
• Kernel – compressed Linux kernel
• ManBlock – raw data, empty partititon
• MBR – Master Boot Record, contains information about partitions: Base, Copyright, Engine, InternalStorage and Kernel

Overall, I really appreciated them going through the whole process of taking control of the device. Most of the time, the details of getting access to the binaries and getting a good debugging environment are left out. It was shocking to me how much work it was to load the partition once it was there to the Linux kernel! I'm super happy to see this process documented though.