Sandisk Sansa Connect

[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!  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.

[Lysander]

I've been checking the file everest_initrd_ext_prod_1.1.1.50239.srr , which is an encrypted ROMFS (cramfs) file. Inside it we find the base layout for the device, including binary files, scripts and the works.

From what i've seen, both the recovery process (/etc/rc.recover) and signature checking (/usr/share/LUA/5.1/checksig.lua) are handled entriely by userland applicactions and scripts. If the device doesn't check the signature on the initrd file, this would allow us to upload a modified version without signature verification and then modify the platform to our hearts' content.

Before starting the main processs (/disk/zap/assets/System/runzap, from the platform file) the init process has a lot of commented-out services, which could be enabled. For example, if the variable $nfsserver is set before the main init script (in /bin/setupenv) the device will try to mount a NFS share in /home.

Also, the crypto-secure EEPROM is apparently used to retreive MAC and deviceid. Again, this is done by a small script (bin/setupenv) so this is completely modifiable as well.

I can upload these unencrypted images if anyone's interested.

[AlexP]

Excellent work - it'd be great to see something appear on the connect.

[zivan56]

Nice work.  FYI, for anybody looking to grab a Sansa Connect... they can be had for ~$40 USD shipped brand new in box (eBay, Amazon, etc).

[Lysander]

For whatever is worth, i received my Connect about a week ago and it's a damn impressive player - excellent UI, design, sound quality and battery life. I just can't wait to start modding this one  :'(

Right now i'm working on the devices' memory map and generating .SRR to upload. I'm pretty confident about the header format, but the addresses contained make no sense whatsoever to me (load address, entry address and number of bytes). I expected a plain mapping of the devices' 4 gigs, but if the header values are correct (and they seem that way), this is not the case.

Load address should be the starting address in where the device stores the given binary - i expect separated blocks for vmlinux kernel image, initrd (base layout) and platform (player utilities and file memory), which is mounted by a fstab entry:


none            /proc           proc    defaults        0 0
none            /dev/pts        devpts  gid=5,mode=620  0 0
none            /sys            sysfs   defaults        0 0

none            /var            ramfs   defaults        0 0
none            /tmp            ramfs   defaults        0 0

# ZSI Added
/dev/mmcblk0p1  /disk           ext3    defaults,noatime        0 0


Entry address should be the execution starting point of any binary image and Number of bytes should be, well, the number of bytes to upload According to the Cadenux documentation, "...while the EntryAddr and NumBytes are computed by the mkimage script. In cases where the input image does not represent an executable, but rather represents a file system, then the EntryAddr will not apply and mkimage will simply supply a default filler value. For those that are curious, there is additional usage information contained within the document header of the mkimage script.". So, it makes sense to have an entry address of 0xFFFFFFFF for the initrd image, and i presume this is how the bootloader / userland image loading utils determine if we're loading a kernel or not.
Having that mkimage document header would be really nice!

And again, the number of bytes for each .srr are a bit of a mystery. I still have no idea what they represent or how they're computed, but they have nothing to do with image sizes or even maximum size for each possible memory block...

UPDATE: Thought the ATMEL uC could be the main CPU of the device - the TI DMS320 DSP allows to disable its internal ARM core to be used purely as a DSP. Still, all the binaries in the initrd image are ARM... i'm updating the wiki page with a bit more detail.

Update 2: I'm a retard  The header is stored in little-endian format, and this makes the byte number exactly the filesize minus the header (16 bytes). Will continue working on the memory map with this. The srr tool i was working on keeps growing, and it can now show info, decrypt and extract binaries from SRR files. The correct header info should then be...


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
gcc  -Wall -lcrypto -o srrtool srrtool.c
SRR Tool v1.5.0 - (C)2009 Lisandro Pin

Info for 'everest_initrd_ext_prod_1.1.1.50239.srr.e' (file 1 of 3)
   Encrypted      = yes
   Encryption key = 5928db44795a317aa37ece1fae8ec269fc787e26ffb179ed
   IV             = 3dcd5a05a346ac40
   Type           = SRR file
   Load address   = 0x04400020
   Entry address  = 0xffffffff
   Num. of bytes  = 0x001b3800

Info for 'everest_vmlinux_ext_prod_1.1.1.50239.srr.e' (file 2 of 3)
   Encrypted      = yes
   Encryption key = a31a11dd29623e5eb7d3b6ad27d21f7db45f09bd081c9dc3
   IV             = fb4c889cd602de37
   Type           = SRR file
   Load address   = 0x01008000
   Entry address  = 0x01008000
   Num. of bytes  = 0x001ac740

Info for 'yeverest_zap_ota_rel_ext_prod_1.1.1.50371.tar.gz.e' (file 3 of 3)
   Encrypted      = yes
   Encryption key = 4034d0352460a005c6467e1c7e08d56bb57ef2ec5a7ad33d
   IV             = 8dd60124270fd7b8
   Type           = GZIP file

All done!


Update 3: There's some very interesting info on the kernel source patch attached in the wiki page - including some memory mapping and initialization procedures! I'll give this a closer look during the week.

Update 4: As stated in the wiki file, the devices exposes two different IDs (0781:7481 and 0781:7482) in recovery mode. The first one is apparently only used for writing, while the second one is used for reading. I was planning to add writing capabilities to my tool, but i'll work on the reading - a full flash dump and a backup of the bootloader code would be great. More work on zsi_fw.exe ensues...

[funman]

Good work!

If you hear of cheap (~50€) players which can be get in Europe, I'd like to join the project!

[Lysander]

Good work!

If you hear of cheap (~50€) players which can be get in Europe, I'd like to join the project!

I had mine for about 70 dollars here in Argentina, which is roughly 48€. I beleive the Connect is a very nice player, modified or not. The only drawbacks i can think of are that the device is MTP only and its WiFi is pretty much useless without the Yahoo Music service. I hope to improve on these... 

[Lysander]

Been working on the kernel patch - there's a LOT of initialization code by Cadenux for devices that aren't used in the Connect, so it's a tad hard to follow. I'm updating the wiki page with my findings.

[saratoga]

UPDATE: Thought the ATMEL uC could be the main CPU of the device - the TI DMS320 DSP allows to disable its internal ARM core to be used purely as a DSP. Still, all the binaries in the initrd image are ARM... i'm updating the wiki page with a bit more detail.

Its an 8 bit microcontroller, so its not likely to be the CPU.  On the Creative TMS320 players, an 8 bit microchip (PIC) is used for interfacing buttons.  Presumably this is due to a lack of GPIO pins on the TMS SOC requiring an extra chip to work as a mux/keypad scanner. 

[Lysander]

Its an 8 bit microcontroller, so its not likely to be the CPU.  On the Creative TMS320 players, an 8 bit microchip (PIC) is used for interfacing buttons.  Presumably this is due to a lack of GPIO pins on the TMS SOC requiring an extra chip to work as a mux/keypad scanner. 

Yep. Possible uses are interfacing buttons or external devices (the TMS320 has a single hardware select line). I found overlapping GPIO definitions in the patch so this is a possibilty...

Update: In the LUA library, the uC is reffered as "HID" (human interface devices?) and it handles, at least, the display wake & sleep. So it's quite probable it handles buttons as well.

[Looks_Confused]

Success!  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...

Are you able to create encrypted files?  Or just decrypt the .e files.  In other words, were you able to obtain the encryption keys.  I think this will be required to load firmware on the Connect.

Regards,

Hans