r0ket

The r0ket uses a mesh-network to convei time, highscore and other messages. To protect these values from evil hackers, the mesh encrypts and signs messages sent to the mesh using a secret key, stored read-protected on the flash of the processor.

Looking at the firmware-source uncovers a severe bug in the font-handler (commit). Here, a static sized buffer of 600 bytes (charBuf) is filled with data read from the font-file. The amount of data is dependent on the width and the height of the font divided by 8.

height = (font->u8Height-1)/8+1

Setting u8Height to 255 results in a height-value of 32. With a maximum width of 255, width*height can reach 8160 bytes, which is nearly the size of the whole SRAM of the chip (8KB). objdump then shows that the charBuf is located somewhere at the beginning of SRAM (0x10000bb0 in my case). The buffer is not located on the stack, so one cannot immediately overwrite the return address.

A modified firmware (reveals the stack-pointer at the relevant code in DoChar to be around 0x10001560 (__asm( “mov %0, sp\n” : “=r” (x) :);) However, the actual overwrite will happen somewhere deeper (f_read → memcpy …) but this is not so much of interest.

To test stuff, I inserted the blink code (from l0dable/blink.c) into the firmware and used objdump to retrieve its address. Now I create a custom font, with a height of 255 and a width of 78 (0x1560-0xbb0/32 + 1 = 78) (play around a little with these values if it doesn't work at first). The font format is a little obscure:

 u8Width // 0 normal, 1 compressed
 u8Height
 u8FirstChar // first char present in font
 u8LastChar  // last char present in font
 uint16_t extras // number of additional chars present
 extras * uint8_t extra_char
 u8Width // width of this char
 char data[];
 ...

The data part is then filled with the desired return address and make sure, that you pad correctly, so that the return address actually starts at a 4-byte boundary.

After a couple of hours of no success, you will learn about ARM’s thumb mode which requires you, to add 1 to the destination address. Loading the font, my r0ket now starts blinking :D yay

Time, to write an exploit that dumps the rom to the dataflash. It’ll be located at the charBuf address, so we use the l0dable build process (which loads the binary into sram and executes) but adopt for the location using a custom .ld file.

MEMORY
{
    sram(rwx): ORIGIN = 0x10000bc4, LENGTH = 600
}
INCLUDE ram.ld

Now all that’s left to do, is to fill the charBuf with the compiled binary, and pad the rest of it with address of charBuf (+1!). Running it dumps the ROM. And fortunately the exploit works without modifications on the original firmware.

Extracting the keys from the dumped ROM is then easy, if you compare it to a self-compiled on with known keys and location, as the surrounding data will stay mostly constant.