bootloader info

[bushing]

I'm still in the thick of this, but I wanted to post a little about what I've discovered about the bootloader to the group, in case it gives anyone any ideas.

Here is an outline of what the bootloader does:

Code: [Select]


error(n) will be shorthand for "flash green LED n times and then start flashing it forever and hang"

code begins at 0x00000000 (flashrom start)

Initialize CPU state (enable MMU, enter supervisor mode)
copy first 0x5000 (20K) of code into external SDRAM, starting at 0xC0005000
jump to 0xC0005000


initialize UART1, set to 152000 8N1
initialize system registers: SYSCON[123], MEMCFG[12], PADDR, PADR, PEDDR, PEDR
intialize beginning of ram (0xC0000000+0x4000) to some bizzarro table of unknown purpose :)
Turn on green LED

Reset IDE drive 0, enable read look-ahead (caching)
Read partition table, or error(6)
Check partition table for 0xAA55 magic code, or error(7)
Check partition 1's drive type and make sure it's either 0x1B or <= 0x11 (?), or error(8)
Read partition 1 boot sector, or error(9)
Check bootsector  for 0xAA55 magic code, or error(10)
Read in info from bootsector
Find BOOTLOADLOG *


BOOT0:
Read drive model and serial
Write "BOOT0-0 OK" to bootloadlog

Read drive signature from last sector before partition 1 starts
Log "BOOT0-1 OK" if this succeeds, otherwise write "BOOT0-1 Failed" and error(11)

Verify drive model and serial against drive signature sector
Log "BOOT0 Successful" if this succeeds, otherwise write "BOOT0-2 Failed" and jump back to start of BOOT0

BOOT9:
Verify signature of "rc.sh" against "rc.sig"
Log "BOOT9 Successful" or "BOOT9-X Failed" and jump back to BOOT0


BOOTB:
Verify signature of "phatd" against "phatd.sig"
Log "BOOTB Successful" or "BOOTB-X Failed" and jump back to BOOT0

BOOTF:
Load "linux" (kernel) into memory at 0xC0038000
Verify kernel against "linux.sig"
Log "BOOTF Successful" or "BOOTF-X Failed" and jump back to BOOT0

BOOTF:
Load "ramdisk" into memory at 0xC0C00000
Verify ramdisk against "ramdisk.sig"
Log "BOOT* Successful" or "BOOT*-X Failed" and jump back to BOOT0

Turn off green LED

Clear out memory at 0xC0023000  + 0x4000
Write kernel boot param struct at 0xC0023000
(command line = "init=/bin/bash")

Jump to kernel!


Some key notes:
* I can't figure out where it's putting this BOOTLOADLOG data.  It looks like it's looking for a file in the PHTSYS partition called "BOOTLOAD.LOG", or it could be "BOOTLOADLOG" (not sure about the long filename support).  I tried making a 0-byte file called BOOTLOAD.LOG, and it didn't do anything ... maybe it has to be a non-zero-byte file (as it's probably not smart enough to allocate space)

* It is using keys pulled from a table of 100 public RSA keys -- the same as in phatd and 51d.  I can't figure out which key it's using -- the code that does that looks like it might be intentionally obfuscated.  

I think at this point I'm going to start looking through the linux version of plsign to try to gain some insight into the sig file format, so we can figure out what key it uses for what.

Does anything here inspire anyone?

Ben

[judb]

so it never checks itself (the flash / boot loader) against any keys?  interesting.  If there is a way to patch the code to return true for those keys would you know what that is already?

[bushing]

so it never checks itself (the flash / boot loader) against any keys?  interesting.  If there is a way to patch the code to return true for those keys would you know what that is already?

Oh, sure.  Figuring out what code to patch there is easy.

Figuring out how to reprogram that flash chip with patched code, however...

-b

[judb]

You get me the code and I'll see if I can get it flashed.

[bushing]

You get me the code and I'll see if I can get it flashed.

Well, ok.  I hesitate here, because I can't be positive this will work, not having tested it myself.  But, the simplest patch I can make would be just two bytes.

Here is the patch:

Offset	Old	New
01B80	00	01
01B87	08	E8

Here's what this represents:

Code: [Select]


(this was all rebased to 0xC005000 to reflect the copy to RAM, so subtract that to get actual rom image offsets)

ROM:C0006B5C ; int __cdecl do_verify_stuff(char *buf,char *signature,void *keyinfo)
ROM:C0006B5C do_verify_stuff                         ; CODE XREF: load_and_verify_file
ROM:C0006B5C                                                                                ......; load_and_verify_ramdisk ...
ROM:C0006B5C                 STMFD   SP!, {R4,R5,LR}
ROM:C0006B60                 MOV     R5, R0
ROM:C0006B64                 MOV     R4, R2
ROM:C0006B68                 LDR     R3, [R1],#4     ; r3 = first byte of sig data (the first 4 bytes of
ROM:C0006B68                                         ....................; a sig file are the length of the rest of the
ROM:C0006B68                                                                 ................; signature, in bits)
ROM:C0006B6C                 MOV     R0, R1          ; r0=signature address
ROM:C0006B70                 MOV     R1, R3          ; r1 = r3
ROM:C0006B74                 MOV     R3, R1,LSR#2    ; r3 = r3 / 4
ROM:C0006B78                 BL      crypto_scramble
ROM:C0006B7C                 CMP     R0, #0
ROM:C0006B80                 MOV     R0, #0                                 <<<<<<<<<<<<<<<<<<<< change to MOV    R0, #1 (return code for success)
ROM:C0006B84                 LDMEQFD   SP!, {R4,R5,PC}     <<<<<<<<<<<< change to LDMFD (always return instead of return if R0=0)
ROM:C0006B88                 MOV     R0, R5
ROM:C0006B8C                 MOV     R1, R4
ROM:C0006B90                 LDMFD   SP!, {R4,R5,LR}
ROM:C0006B94                 B       verify_stuff
ROM:C0006B98                 MOV     R0, #0
ROM:C0006B9C                 RET
ROM:C0006B9C ; End of function do_verify_stuff



Before we put your board on the line, anyone out there care to comment on my handywork here?

-b

PS FWIW, crypto_scramble is the function I've been stuck on for a few days... I hope that SOMEONE out there at PN is laughing right now, because at least someone would be having a good time!

[sbingner]

is this code in any of the .bif files?  if so we may be able to use progpld to rewrite it...

[bushing]

is this code in any of the .bif files?  if so we may be able to use progpld to rewrite it...

Progpld only works for programming the XILINX CPLD (like an FPGA, if that helps ...) that sits between the '51 and the headunit and acts as glue logic; it's an entirely different beast than the flash chip.

I actually have code written that should work to reflash ... it just doesn't work.

-b

[judb]

http://www.emulation.com/cgi-cfm/insert_quantity.cfm?part_number=CLIP%2D048%2DTS01%2DFLEX
this may help us reflash the box.. but it wouldnt be feasible to be the hack method for everyone.. it might just help us unlock the door.