Skip to content

Blob Reversing

Jump to bottom Edit New page
ckuethe edited this page Apr 19, 2015 · 34 revisions

The USB Armory is intended to be a fully open platform. In order for this to be true, everything must be available for audit: apps, kernel, bootloader, and firmware.

There is a boot rom dumper which will allow us to inspect the ROM inside the i.MX53. Eventually inspect the firmware of the SD cards should also be analyzed.

# imx53_bootrom-dump 0 16 > bootrom-0-16k.bin
# imx53_bootrom-dump 0x404000 48 > bootrom-1-48k.bin
# cat bootrom-0-16k.bin > image.bin
# truncate --size 4m image.bin
# cat bootrom-1-48k.bin >> image.bin

Consult §7.4.1 of IMX53RM (i.MX53 Multimedia Applications Processor Reference Manual); figure 7-2 illustrates the memory mapping.

Additionally, §7.10 describes some functions of the HAB library:

The RVT table contains the pointers to the HAB API functions and is located at 0x00000094

The HAB ... includes a software implementation of SHA-256 for cases where a hardware accelerator cannot be used. The core RSA signature verification operations are performed by a software implementation contained in the HAB library. The main features supported by HAB are X.509 Public key certificate ... [and] CMS signature format support

Also of interest is §7.4.5 which says:

The exception vectors located at the start of iROM are used to map all the ARM exceptions (except the reset exception) to a duplicate exception vector table in internal RAM. During the boot phase, the iRAM vectors point to the serial downloader in iROM.

Hopper is awesome for this.

Things to consider:

  • X.509 certificate parser will be found
  • RSA signature verification will be found
  • i.MX53 has a USB downloader: find instructions relating to USB
  • SAHARAv4 may be used: find instructions that call it
  • When secure boot is active, the processor will probably reset if signature checks fail. Look for resets...
  • get friendly with the datasheet and register maps. there's a really good chance that every time you see 53fd4000 something nearby is messing with the clock control module. take a few passes through the assembly listing and annotate potential register accesses
  • as you reverse things, name your subroutines descriptively until you understand their true names eg. sub_218_wait_for_pll_ready
  • sometimes the call graph makes more sense, other times the pseudocode is easier. switch back and forth, name memory locations, annotate function names until it all makes sense
  • watch out for disassembly that doesn't make sense. the example below is probably interpreting a lot of zeroes as code.
...
0040abd4         movs       r0, r0
0040abd6         movs       r0, r0
0040abd8         movs       r0, r0
0040abda         movs       r0, r0
0040abdc         movs       r0, r0
0040abde         movs       r0, r0
...

Observations

  • the boot rom operates mostly in Thumb mode
  • there are a few places where the processor will apparently deadlock itself
  • USB identification strings are at 0x40bad4
  • SHA256 initial registers are at 0x40b094
  • SHA256 round constants are at 0x40b0b4
  • SHA256-related functions start at 0x40600a
  • 0x40a2bc is a function that seems to explain math errors
  • 0x407ff8 appears to extract integers and change their endianness (ASN.1 parser?)
  • 0x403a9a appears to extract 1/2/4-byte integers from a buffer (ASN.1 parser?)
  • 0x403ab6 copies 1/2/4 byte from one pointer to another

Reading List

Add a custom footer
Add a custom sidebar

Clone this wiki locally