glibc: -1, phatbox: 0, bushing: 1 (yay bootrom)

[bushing]

So it turned out that glibc sucks a lot and i could not get ANYTHING to work that I compiled with it, not even a "hello, world!" program. So, I tried "diet libc", and it worked fine.  Turns out my rom dumper program was correct as originally written.

Here's the scoop (so far) on the boot rom:

Code section: 0x0 - 0x9a38 (39480 bytes).  Of this, the first 7k are code to set up the processor, intialize the hard drive and read files out of the fat32 filesystem.  Yes, you got it -- they used a whole 32k for the friggin' entirety of RSAREF, to do the crypto checking.

Data section: 0x9a38 - 0x1095c  (28452 bytes)

The first 300ish bytes are just miscellaneous data, containing the following strings: 'BOOTLOADLOG', 'BOOT0-0', 'BOOT0-1', 'Failed', 'BOOTo-2', 'BOOT0', 'Successful', 'rc.sh', 'rc.sig', 'BOOT9-X', 'BOOT9', 'phatd', 'phatd.sig', 'BOOTB-X', 'BOOTB', 'linux', 'linux.sig', 'BOOTF-X', 'BOOTF', 'ramdisk', 'ramdisk.sig', 'BOOT*-X', 'BOOT*', 'init=/bin/bash'.

There are then 100 RSA public keys (like we've seen in several other spots), and another 800ish bytes of data that look like a table of some sort -- they might even be a logo or a bitmap? hard to say.

It's empty (0xFFFFFFFF....) until 0x20000, where it repeats -- I guess maybe they didn't hook up one of the address lines?

From here, my first attempt at breaking this is going to be to patch the crypto verify function to always return true -- but that's not until A. I get a user-mode flasher working and B. I decode enough of this code to verify that it's not going to checksum itself somewhere and lock up so I can't ever reflash it and have a dead board.

-b

[judb]

I have two boards.. and I would figure we could perhaps find a way to replace the flash chip with a socketed flash perhaps that we could use to test these with?

aadec check the flash image somehow but we might be able to fix that or just ignore / replace aadec depending on if its only used for audible.  if its used for audible then I say we ditch it and dont worry about it.

Also can you email me a copy of the rom image?

[judb]

Oh yeah, one more thing, have you tried comparing the keys in the rom image to the keys stored on the drive to see if they are the same?  I am wondering if we replace both sets with our own if we could sign our own code by chance...

[bushing]

Oh yeah, one more thing, have you tried comparing the keys in the rom image to the keys stored on the drive to see if they are the same?  I am wondering if we replace both sets with our own if we could sign our own code by chance...

Yes!

Here's what we have in the way of keys, as I see it so far:

* Boot rom, 51d, phatd:  100 public keys [identical between these three sources]
* pkeys2.e: 100 public keys [a different set?]
* pkeysa.e: some number of private keys, encrypted?
* hidden in beginning of hard disk: 100 *private* keys, but I don't think they match any of the other keys.  (not positive on this point)

Resoldering a socket would be nice, but what a pain... sheesh.  Do you think it would be better to replace all the public keys with our own... or just nuke the code that does all the checking?  

-b

[judb]

Well, im thinking it might be possible to replace all the keys with the SAME one, just do it in 100 places.. OR maybe we can patch the rom and phatd.. but you'd have to patch a lot of stuff I think.  

One thing I would be interested in is since there are two copies of the boot rom image (which makes sense) what is the order for flashing and the order for booting?

I would THINK the flash process would write the image the first time into the second half of the boot rom space then have the system reset itself from the new image.  if the boot fails you still have a working copy of the boot rom in the first section so they can recover from a failed flash upgrade ... if the boot is sucessful it would then rewrite the first section of the flash ... this would also explain why the flash process takes so damned long.

So, that being the case, if we could nuke the first flash image with our modified code we could maybe switch back and fourth between each image.

Perhaps using a socket we could wire a switch to shift the pins to have the box boot from other areas of flash?  Like get two flash chips, one with the phatnoise rom and one we can hack and just switch back and forth by changing the address pins on our mod board.  This would be needed till we get the box cracked and then can provide a flash util and script to break the box.

I could see sending out a boot CD much like the phatnoise repair CD that places all the scripts and images in place on a DMS and then you just pop it in.. flash the box and your done.. now you can upgrade your drive!  

[bushing]

Well, im thinking it might be possible to replace all the keys with the SAME one, just do it in 100 places.. OR maybe we can patch the rom and phatd.. but you'd have to patch a lot of stuff I think.  

One thing I would be interested in is since there are two copies of the boot rom image (which makes sense) what is the order for flashing and the order for booting?

I would THINK the flash process would write the image the first time into the second half of the boot rom space then have the system reset itself from the new image.  if the boot fails you still have a working copy of the boot rom in the first section so they can recover from a failed flash upgrade ... if the boot is sucessful it would then rewrite the first section of the flash ... this would also explain why the flash process takes so damned long.

So, that being the case, if we could nuke the first flash image with our modified code we could maybe switch back and fourth between each image.

Perhaps using a socket we could wire a switch to shift the pins to have the box boot from other areas of flash?  Like get two flash chips, one with the phatnoise rom and one we can hack and just switch back and forth by changing the address pins on our mod board.  This would be needed till we get the box cracked and then can provide a flash util and script to break the box.

I could see sending out a boot CD much like the phatnoise repair CD that places all the scripts and images in place on a DMS and then you just pop it in.. flash the box and your done.. now you can upgrade your drive!  

Modifying the code *should* be easy -- there is one common piece of code that takes a signature and a key and says "yes, that's valid" or "no, it's not".... just have to patch it to always say yes.  That may be as simple as changing one byte.

As far as the bit about the flash banks -- that's an interesting idea ... unfortunately, there are only two different ways to figure out whether this is the case:

1. write to part of the flash, maybe part that's blank, and see if the change is made in both places

2. we can see if all of the address lines are actually connected from the CPU to the flash chip.  If not, yes, we can wire a switch to the high address line to switch between the two banks.

The way to check that is ... the flash chip has 17 address lines (A0-A16), which makes sense because 2^17=131072 = 128k  ... * 16 bits at a time = 256kbytes / 2mbits.  If the board were using  all of this memory, we would expect the pins A[0]-A[16] on the CPU to be connected to A0-A16 on the flash, respectively.

If it were not using the whole 256k (ie only 128 was connected), then we would expect that pin A16 on the flash chip to not connect to the CPU -- instead, it would be connected to ground or positive supply voltage, preferably through a resistor....

-b