Skip to content

Blob Reversing

Jump to bottom Edit New page
ckuethe edited this page May 17, 2015 · 34 revisions

The USB Armory is intended to be a fully open platform. While this is mostly true already (uBoot, Linux, and userland are open source) our trust is rooted in some magic hidden inside the i.MX53 ROM and its proprietary High Assurance Boot system.

Begin by extracting the boot ROM:

# imx53_bootrom-dump 0 16 > bootrom-0-16k.bin
# imx53_bootrom-dump 0x404000 48 > bootrom-1-48k.bin

Use the ROM to ELF converter to produce an ELF image that can be easily loaded into disassemblers like Hopper or IDA.

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.

Eventually the firmware of the SD cards should also be analyzed. Once we get HAB to work, a hostile SD card should be less of a concern. Bunnie did some interesting work that may be useful: [1] [2] [3] [4] [5]

Things to consider:

  • Be lazy. If you can write a tool to automate drudge work, do it.
  • Try to identify the X.509 certificate parser
  • Try to identify PKCS #1 signature verification
  • Try to find the DCD/IVT parser
  • Identify the SHA256 implementation 0x40a00a
  • i.MX53 has a USB downloader: find instructions relating to USB
  • expect to find errors and contradictions in the documentation. Registers are misnamed, entire memory regions are teleported around. ugh.
  • The eFuse map is in the 25 page addendum at the end of the main reference manual. Ugh.
  • SAHARAv4 is used if possible: look for references to memory address 0x63ff8000
  • When secure boot is active, the processor will probably reset if signature checks fail. Look for resets...
  • Look for patterns. Lots of 0x53f____ or 0x63f____ are probably register accesses; lots of 0x0040____ are probably be pointers.
  • Look for small values like 0x00000005 or 0x00000010 at the end of a list of other pointer-like numbers. If there are n or 2*n, you might be looking at an array a of objects and its length... maybe.
  • 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, eg. sub_218_wait_for_pll_ready or reset_watchdog
  • name related functions consistently, eg. watchdog_reset, watchdog_reload, watchdog_shutdown, watchdog_configure_interval, ...
  • watch out for un-decoded bytes before a procedure, or procedures that don't begin with "push ... lr". The procedure detector may have guessed wrong.
  • watch out for disassembly that doesn't make sense. the example below is probably interpreting a lot of zeroes as code.
...
0040ebd4         movs       r0, r0
0040ebd6         movs       r0, r0
0040ebd8         movs       r0, r0
0040ebda         movs       r0, r0
0040ebdc         movs       r0, r0
0040ebde         movs       r0, r0
...

###Useful Tools

###Functions

  • 0x000574 enable clock gates for peripheral (NOTE: 0-20 are valid, still a few cases to identify)
    • case 1: eSDHC1
    • case 2: eSDHC2
    • case 3: eSDHC3
    • case 4: eSDHC4
    • case 5: I2C1
    • case 6: I2C2
    • case 7: I2C3
    • case 8: ECSPI1
    • case 9: ECSPI2
    • case 10: CSPI
    • case 15: UART1
    • case 16: UART2
    • case 17: UART3
    • case 18: UART4
    • case 19: UART5
  • 0x001be0 main()
  • 0x001d86 setup exception vectors, copy rodata, do secure init, jump to main()
  • 0x404000 read GPIO pad status
  • 0x404010 write GPIO data
  • 0x40407e write IOMUXC control register
  • 0x404090 refresh watchdog timeout counter
  • 0x40409e setup watchdog
  • 0x4040f2 disable watchdog power down counter
  • 0x404924 enter USB/UART polling loop, if activity is detected, run serial downloader
  • 0x405b9c __aeabi_memcpy()
  • 0x405c44 wait for n general purpose timer ticks to elapse
  • 0x405c72 set general purpose timer OF1 trigger value
  • 0x405c92 get general purpose timer OF1 value
  • 0x405ca0 disable general purpose timer
  • 0x407a86 memcpy()
  • 0x407a9a appears to extract 1/2/4-byte integers from a buffer (ASN.1 parser?)
  • 0x407ab6 copies 1/2/4 byte from one pointer to another
  • 0x40a00a start of SHA256-related functions
  • 0x40bff8 appears to extract integers and change their endianness (ASN.1 parser?)
  • 0x40e2bc decode SIGFPE reason to string
  • 0x40e364 possibly a puts() implementation
  • 0x40e508 return from exception
  • 0x40e510 disable interrupts for entering deep sleep mode
  • 0x40e55c exception vector(s) target
  • 0x40e568 reset vector target; init registers, disable interrupts, setup stack
  • 0x40e5b0 write L1 TTEs
  • 0x40e624 zero target memory region in 32 bit chunks, like bzero()
  • 0x40e674 copy 32 bit aligned words (part of __aeabi_memcpy family)
  • 0x40e6c8 disable data and instruction caches
  • 0x40e76c invalidate data cache
  • 0x40e884 shutdown MMU
  • 0x40e8f4 wait for interrupt
  • 0x40e8fc disable VFP (CP11 and CP10 access)

###rodata contents

  • SHA256 initial registers are at 0x40f094
  • SHA256 round constants are at 0x40f0b4
  • USB descriptor structs are at 0x40fa36 - 0x40fb9a
  • USB identification strings are at 0x40fad4
  • USB VID/PID is at 0x40fa38 and 0x40fa3c

Reading List

Add a custom footer
Add a custom sidebar
Clone this wiki locally