[removed]

[critor]

I've checked your test.img fields tree.

Unfortunately, it cannot be flashed correctly with BtMg because your 0x8000 HHackers field doesn't specify its size correctly (according to the TI-Certificate format).
Here is test.img structure :

Code: Select all

8000: BOOT1.5
-8070: BOOT1.5 code
8000:HHackers! (wrong size)
-8070
--8000: BOOT2
---8070: BOOT2 code
--0290
--0340
--0290
--FFF0
--3 null bytes
--code

Any way to improve the special 0x8000 field ?

And I'm not sure to understand why the Boot2 image is present in this field, and why the executed code is after it.

[parrotgeek1]

I've checked your test.img fields tree.

Unfortunately, it cannot be flashed correctly with BtMg because your 0x8000 HHackers field doesn't specify its size correctly (according to the TI-Certificate format).
Here is test.img structure :

Code: Select all

8000: BOOT1.5
-8070: BOOT1.5 code
8000:HHackers! (wrong size)
-8070
--8000: BOOT2
---8070: BOOT2 code
--0290
--0340
--0290
--FFF0
--3 null bytes
--code

Any way to improve the special 0x8000 field ?

And I'm not sure to understand why the Boot2 image is present in this field, and why the executed code is after it.

Yes, I can fix that. The calculator doesn't care, though.

This is why the boot2 is there:

It's a way to avoid reading the nand. Because I don't know how. The boot2 is stored before the exploit so that boot1.5 will copy it into RAM.

The base address of the image is 111e0000-sizeof(boot2)

Section: ADDRESS

BOOT2: 111e0000-sizeof(boot2)
PAYLOAD: 111e0000
Pointer to boot2: 111ffff8
Size of boot2: 111ffffc
OVERWRITE: 11200000

The payload decompresses the boot2 using the information at 111ffffX and then jumps to 11800000 (this code is not public yet)

[critor]

Ok, I've removed the Boot2, because I don't need it for my tests :
- made your script assume the Boot2 size is 0
- commented the boot2 image concatenation

Commented everything in the ControlX main.
Added at the start of the main :

Code: Select all

   asm("ldr r1,=0x00000C12");
   asm("mrc p15,0,r0,c2,c0,0");
   asm("str r1,[r0,#4]");
   asm("ldr r0,=0x00000000");
   asm("mcr p15,0,r0,c8,c7,1");

And at the end of the main :

Code: Select all

   while(1);

Seems to work in firebird. By triggering the debugger and typing d 0 the Boot1 seems to be there.

Uncommented 2 screen output lines :

Code: Select all

   asm("ldr r1,=0x00000C12");
   asm("mrc p15,0,r0,c2,c0,0");
   asm("str r1,[r0,#4]");
   asm("ldr r0,=0x00000000");
   asm("mcr p15,0,r0,c8,c7,1");
/* ... */
   init_screen();
   clearLines(SCREEN_BASE_ADDR,0,SCREEN_HEIGHT-1);
/* ... */
   while(1);

Perfect, the screen turns black.

Just uncommented other init lines at the start of the main, no Flash I/O for the moment...

Code: Select all

   asm("ldr r1,=0x00000C12");
   asm("mrc p15,0,r0,c2,c0,0");
   asm("str r1,[r0,#4]");
   asm("ldr r0,=0x00000000");
   asm("mcr p15,0,r0,c8,c7,1");
   int i,j;
   uint8_t uninstalled=0;
   ut_disable_watchdog();
   menu=(is_key_pressed(KEY_CTRL)) || (is_key_pressed(KEY_ESC) && is_key_pressed(KEY_MENU) && is_key_pressed(KEY_MINUS));
   if(is_key_pressed(KEY_DOC) && is_key_pressed(KEY_ENTER) && is_key_pressed(KEY_EE))
      maintenance=1;
   startstatus=1;
   memset(status,' ',STATUS_SIZE);
   status[STATUS_SIZE]=0;

   asicflags = ((*(volatile unsigned int*) 0x900A002C)>>26)&0b11111;
   
   init_screen();
   clearLines(SCREEN_BASE_ADDR,0,SCREEN_HEIGHT-1);
/* ... */
   while(1);

... and suddenly it won't work any more.
Firebird complains about :

Error (00000000): Cannot modify currently executing code block.

[parrotgeek1]

is_key_pressed assumes some boot1 variables exist in RAM. read the keyboard from the registers manually

[critor]

Does it have anything to do with a "Error (00000000): Cannot modify currently executing code block." message ?
Doesn't it just mean that the payload became too big ?

Anyway, I've just commented calls to the is_rc_pressed() syscall and still the same message.

[parrotgeek1]

Does it have anything to do with a "Error (00000000): Cannot modify currently executing code block." message ?
Doesn't it just mean that the payload became too big ?

Anyway, I've just commented calls to the is_rc_pressed() syscall and still the same message.

I don't know. I'm still working on my own loader.

[critor]

Which could mean the loader would have to be quite small with your exploit (no/minimalist user menus)...
... or to to take the place of the Boot2 in your current image, in order to be loaded and jumped to before 111E0000 in an acrobatic way.

[critor]

Modified your mkexploitReal script to take the image to be loaded below 0x111E0000 as a 1st parameter.
Be it the Boot2 or something else, like ControlX.

Rebuilt ControlX with a base address of 0x111D5000.
Padded its binary to size 0xB000.

Now for the payload at 0x111E0000 :

Code: Select all

void _start() {
   unsigned dummy;
   __asm volatile(
      "0: mrc p15, 0, r15, c7, c10, 3 @ test and clean DCache \n"
      " bne 0b \n"
      " mov %0, #0 \n"
      " mcr p15, 0, %0, c7, c7, 0 @ invalidate ICache and DCache \n" : "=r" (dummy));
// map Boot1
   asm("ldr r1,=0x00000C12");
   asm("mrc p15,0,r0,c2,c0,0");
   asm("str r1,[r0,#4]");
   asm("ldr r0,=0x00000000");
   asm("mcr p15,0,r0,c8,c7,1");
// run ControlX
   asm(
      ".arm \n"
      "ldr pc, =0x111D5000   \n"
   );
}

Unfortunately, the last thing with the pc doesn't work in firebird, why ?...

Code: Select all

Breakpoint at 0x111e0000
111e0004: 1afffffd   bne   111e0000
111e0008: e3a03000   mov   r3,00000000
111e000c: ee073f17   mcr   p15,0,r3,c7,c7,0
111e0010: e59f1014   ldr   r1,[111e002c] = 00000c12
111e0014: ee120f10   mrc   p15,0,r0,c2,c0,0
111e0018: e5801004   str   r1,[r0 + 004]
111e001c: e3a00000   mov   r0,00000000
111e0020: ee080f37   mcr   p15,0,r0,c8,c7,1
111e0024: e59ff004   ldr   pc,[111e0030] = 111d5000
Error (00020000): Bad PC: 00020000

[critor]

Improved the code, so that ControlX doesn't need to be rebuilt with a different base address :

Code: Select all

#define PAYLOAD_BASE 0x111E0000
#define LOADER_BASE  0x10000000
#define LOADER_SIZE  0xA900

void _start() {
   unsigned dummy;
   __asm volatile(
      "0: mrc p15, 0, r15, c7, c10, 3 @ test and clean DCache \n"
      " bne 0b \n"
      " mov %0, #0 \n"
      " mcr p15, 0, %0, c7, c7, 0 @ invalidate ICache and DCache \n" : "=r" (dummy));
   unsigned long int *i=(unsigned long int*)(PAYLOAD_BASE-LOADER_SIZE),*j=(unsigned long int*)LOADER_BASE;
// copy ControlX image to 0x10000000
   while(i<(unsigned long int*)PAYLOAD_BASE)
      *j++=*i++;
// maps Boot1 to 0x00000000
   asm("ldr r1,=0x00000C12");
   asm("mrc p15,0,r0,c2,c0,0");
   asm("str r1,[r0,#4]");
   asm("ldr r0,=0x00000000");
   asm("mcr p15,0,r0,c8,c7,1");
// launch ControlX
   asm(
      ".arm \n"
      "ldr pc, =0x10000034   \n"
   );
}

The controlx.img.tns file (0xA30E bytes for ControlX 4.5) given as a (fake) Boot2 image to the mkexploitReal script has to be padded to 0xA900.
Strangely, if it's smaller Boot1.5 seems to crash, although it won't crash if it's null.

The ram content looks ok :

Code: Select all

Breakpoint at 0x111e0000
Breakpoint at 0x10000034
10000000  80 0F 00 00 00 2E 80 4A-43 54 52 4C 58 20 20 20   �.....�JCTRLX   
10000010  20 20 80 13 35 30 46 80-13 35 31 30 80 2E 00 06     �.50F�.510�...
10000020  34 2E 35 2E 30 20 80 2E-00 00 80 88 10 00 00 00   4.5.0 �...��....
10000030  0E A3 00 00 F0 4F 2D E9-D4 4F 9F E5 D4 3F 9F E5   .�..�O-��O���?��
10000040  D4 2F 9F E5 03 00 94 E8-00 2C 83 E5 B5 DF 4D E2   �/��..��.,����M�
10000050  00 20 A0 E3 08 20 83 E5-00 2C 83 E5 30 30 8D E2   . ��. ��.,��00��
10000060  03 00 83 E8 B1 0E 00 EB-00 60 50 E2 01 60 A0 13   ..���..�.`P�.`�.
10000070  14 00 00 1A 08 20 84 E2-03 00 92 E8 38 30 8D E2   ..... ��..��80��

But it seems ControlX is then crashing :

Code: Select all

10000038: e59f4fd4   ldr   r4,[10001014] = 10007db8
1000003c: e59f3fd4   ldr   r3,[10001018] = 90060000
10000040: e59f2fd4   ldr   r2,[1000101c] = 1acce551
10000044: e8940003   ldmia   r4,{r0-r1}
10000048: e5832c00   str   r2,[r3 + c00]
1000004c: e24ddfb5   sub   sp,sp,000002d4
10000050: e3a02000   mov   r2,00000000
10000054: e5832008   str   r2,[r3 + 008]
10000058: e5832c00   str   r2,[r3 + c00]
1000005c: e28d3030   add   r3,sp,00000030
10000060: e8830003   stmia   r3,{r0-r1}
10000064: eb000eb1   bl   10003b30
10003b30: e92d4007   stmdb   sp!,{r0-r2,lr}
10003b34: e28d3008   add   r3,sp,00000008
10003b38: e9030003   stmdb   r3,{r0-r1}
10003b3c: e59f302c   ldr   r3,[10003b70] = 10009b20
10003b40: e5933000   ldr   r3,[r3]
10003b44: e12fff33   blx   r3
00019974: 00000000   andeq   r0,r0,r0
00019978: 00000000   andeq   r0,r0,r0
Error (00020000): Bad PC: 00020000

Either the copy gets corrupted, either there is something else which is different in this context.

[critor]

May come from uninitialized Boot1 variables at 0x19974+, indeed.
Here are the normal steps with ControlX 4.5 :

Code: Select all

Breakpoint at 0x10000034
10000038: e59f4fd4   ldr   r4,[10001014] = 10007db8
1000003c: e59f3fd4   ldr   r3,[10001018] = 90060000
10000040: e59f2fd4   ldr   r2,[1000101c] = 1acce551
10000044: e8940003   ldmia   r4,{r0-r1}
10000048: e5832c00   str   r2,[r3 + c00]
1000004c: e24ddfb5   sub   sp,sp,000002d4
10000050: e3a02000   mov   r2,00000000
10000054: e5832008   str   r2,[r3 + 008]
10000058: e5832c00   str   r2,[r3 + c00]
1000005c: e28d3030   add   r3,sp,00000030
10000060: e8830003   stmia   r3,{r0-r1}
10000064: eb000eb1   bl   10003b30
10003b30: e92d4007   stmdb   sp!,{r0-r2,lr}
10003b34: e28d3008   add   r3,sp,00000008
10003b38: e9030003   stmdb   r3,{r0-r1}
10003b3c: e59f302c   ldr   r3,[10003b70] = 10009b20
10003b40: e5933000   ldr   r3,[r3]
10003b44: e12fff33   blx   r3
00019974: e92d4038   stmdb   sp!,{r3-r5,lr}
00019978: e59f2060   ldr   r2,[000199e0] = ffff3ffe
0001997c: e59f3060   ldr   r3,[000199e4] = 900e0000
00019980: e5832000   str   r2,[r3]
00019984: e59f3058   ldr   r3,[000199e4] = 900e0000
00019988: e5933000   ldr   r3,[r3]
0001998c: e3130003   tst   r3,00000003
00019990: 1afffffb   bne   00019984
00019984: e59f3058   ldr   r3,[000199e4] = 900e0000
00019988: e5933000   ldr   r3,[r3]
0001998c: e3130003   tst   r3,00000003
00019990: 1afffffb   bne   00019984
00019984: e59f3058   ldr   r3,[000199e4] = 900e0000
00019988: e5933000   ldr   r3,[r3]
0001998c: e3130003   tst   r3,00000003
00019990: 1afffffb   bne   00019984
00019984: e59f3058   ldr   r3,[000199e4] = 900e0000
00019988: e5933000   ldr   r3,[r3]
0001998c: e3130003   tst   r3,00000003
00019990: 1afffffb   bne   00019984