Rockbox Development > New Ports

Sandisk Sansa Connect

<< < (6/9) > >>

Lysander:

--- Quote from: RichterSkala on December 28, 2009, 01:43:22 PM ---is there something that prevents you from just patching the bootloader to skip the signature check? Can we patch the bootloader?

--- End quote ---

Yes, the fact that it should be uploaded via the same bootloader, which insists on checking signatures. It just happens someone left an binary image of the bootloader laying arround in the filesystem, otherwise we'd be screwed...

saratoga:

--- Quote from: Lysander on December 27, 2009, 11:19:24 PM ---I've tried not to upload files present on the Connect to the wiki because i really don't know what's copyrighted and what's not. The bootloader is likely GPL, but who knows... if anyone wants the binary file for the bootloader PM me and i'll happily give you the details.

--- End quote ---

You probably shouldn't upload those if possible.  Instead just giving a description of how to extract them should be fine I think (unless its prohibitively difficult).

Lysander:

--- Quote from: saratoga on December 28, 2009, 07:04:01 PM ---You probably shouldn't upload those if possible.  Instead just giving a description of how to extract them should be fine I think (unless its prohibitively difficult).

--- End quote ---

Not really - it's just annoying. In detail, the process is:


* Grab yourself an initrd encrypted file (.srr.e) - these can be downloaded with the recovery software
* Decrypt it using Blowfish (key and IV can be computed with the process described on the Wiki). Check the first 4 bytes of the obtained .srr file - if the decryption was sucessful they should be AA BB FF EE
* Extract the payload data from the .srr file - chop the first 16 and last 2048 bytes from it.
* You should now have a standard CRAMFS file, which can be mounted (mount -t cramfs -o loop file mountdir)
* The bootloader image can be found in mountdir/bin/removeme/rrload.srr.chopped
There's even a key/IV combo for an initrd file in the Wiki, if you don't feel like doing the math  ;D That should be all. On the other hand, i've been pondering about some things yesterday.

I'm still unconvinced that the bootloader is actually checking GPG signatures. It's not that it can't be done, but it might very well be it just validates keynames and hashes (there's some info embeeded on every signature package), specially when you consider the complexity of the process and the resources constraints the bootloader must endure. There are strings mentioning SHA1 and SHA-256 hashing, maybe it's as simple as that... ¿Is anyone aware of a GPG-checking bootloader, on any other portable device?

On the other hand, the original rrload soucecode is laid out so it can be easily extended to add new load formats (modifying btldr_pi.c). Maybe this means the original, much simpler formats are still supported.

I'll get on to these as soon as i can spare some time.

saratoga:
There are bootloaders/ROMs that check cryptographic hashes.  All the new ipods do for instance (2G Nano and 6G Classic and newer) using an onboard cryptographic coprocessor.  Some of the PP devices and the Gigabeat S do as well, its jut that in those cases the check was highly flawed and could easily be by passed.

mcuelenaere:
Also, don't forget there's HMAC-SHA1 and HMAC-SHA256, which use a shared key to "encrypt" the hash (this is used on the Creative Zen series players); so it's probably not as easy as just generating the SHA-1 hash.

Though, as you have the bootloader you say, the key should be in there somewhere (if HMAC is used at all).

Navigation

[0] Message Index

[#] Next page

[*] Previous page