Rockbox Development > New Ports

Sandisk Sansa Connect

(1/9) > >>

Lysander:
Hello. I'll be receiveing one of these units in a couple of days, and i would like to thinker with it a bit to see if Rockbox could be ported to this device, or atleast extend its functionality.

I've been reading the Connect wiki (http://www.rockbox.org/twiki/bin/view/Main/SansaConnect), and what sparked my interest is the fact that the files are transfered to the device unencrypted, and that the only signed image is the platform, - or am i missing something here?

My idea was to find a way of encrypting/decrypting those .e files, and start thinkering with the vmlinux image, to see what could be done with it. Being a standard 2.6 kernel with some patches should give some room for experimenting. I haven't been able to find much info on the bootloader (rrload). I'm an electronic engenieering studient, and i have some experience with embedded developement though not with hardware hacking  :) Still, it seems like a fun proyect to work on.

So, my question is - has anyone got beyond what's explained in the wiki page (which is quite a bit)? Any pointers, particularly on dealing with the bootloader? Thanks

GodEater:
That wiki page is pretty much up to date - no-one's made any more significant progress than that to my knowledge.

Lysander:
Well, the Connect should arrive some day next week. I'll play with the Sansa loading utility to see if i can find a way to decrypt those image files in the meantime

Lysander:
Making some progress over a (messy) decompilation of zsi_fw.exe. So far i can tell that the encrypted/decrypted status is determined solely by the '.e' extension and is implemented by a cypher function which i'm still working on.

The key seems to be generated by a SHA-256 hash of the final part of the version number on the filename (50239 from everest_initrd_ext_prod_1.1.1.50239.srr.e, for example) parsed as a base-13 integer and then converted to big-endian, the file size (also converted to big endian) and the complete file name. This would have been much harder to figure out if it weren't for the OpenSSL identification strings in the binary.

Once i have this part confirmed it's time to move on to the actual encryption, which i hope isn't as troublesome  >:(

09/09/2008 update: Cypher code is a mess and really hard to follow after decompilation. Using a 256-byte key and knowing zsi_fw.exe uses OpenSSL, the most likely candidate is AES-256; i'll start working on a test program to confirm this.

The write-to-usb process works by transferring first a 16-bytes header from the file, and the rest of the image in 64-bytes blocks. Each block is unencrypted separately. Info on th .srr header is sparse, but from what i've gathered from the wiki and the rrload page (http://www.cadenux.com/bsp/rrload.html#para32), i expect it to be something like:

Magic marker (4 bytes): aa bb ff ee
Load address (4 bytes)
Entry address (4 bytes)
Number of bytes (4 bytes)

10/09/2008: Cypher is Blowfish, using a 192-bit key. I'm still working on the key and IV initialization, but it seems that i might have this one finished soon...

Lysander:
Success!  ;D I managed to decrypt those ugly .e files - i'll be posting the details on the wiki page in a while. Wrote myself a small program to work with these, and it works flawlessly...


lys@Shoshone ~/downloads/Sandisk_Sansa_Connect/hacking/srrtool $ make -f srrtool.mak all && ./srrtool info everest_initrd_ext_prod_1.1.1.50239.srr.e everest_vmlinux_ext_prod_1.1.1.50239.srr.e yeverest_zap_ota_rel_ext_prod_1.1.1.50371.tar.gz.e
make: Nothing to be done for `all'.
SRR Tool v1.0.0 - (C)2009 Lisandro Pin

Info for 'everest_initrd_ext_prod_1.1.1.50239.srr.e' (file 1 of 3)
   File size      = 1783824 bytes
   Encrypted      = yes
   Encryption key = 5928db44795a317aa37ece1fae8ec269fc787e26ffb179ed
   IV             = 3dcd5a05a346ac40
   Load address   = 0x20004004
   Entry address  = 0xffffffff
   Num. of bytes  = 0x00381b00

Info for 'everest_vmlinux_ext_prod_1.1.1.50239.srr.e' (file 2 of 3)
   File size      = 1754960 bytes
   Encrypted      = yes
   Encryption key = a31a11dd29623e5eb7d3b6ad27d21f7db45f09bd081c9dc3
   IV             = fb4c889cd602de37
   Load address   = 0x00800001
   Entry address  = 0x00800001
   Num. of bytes  = 0x40c71a00

Info for 'yeverest_zap_ota_rel_ext_prod_1.1.1.50371.tar.gz.e' (file 3 of 3)
   Header not found! (not a valid SRR file?)

All done


Note that the .tar.gz file has no SRR header info, for obvious reasons :)

16-09-2009: Updated the wiki page with details.

Navigation

[0] Message Index

[#] Next page