Rockbox Technical Forums

Rockbox Development => New Ports => Topic started by: Lysander on September 04, 2009, 08:40:02 AM

Title: Sandisk Sansa Connect
Post by: Lysander on September 04, 2009, 08:40:02 AM
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
Title: Re: Sandisk Sansa Connect
Post by: GodEater on September 04, 2009, 08:54:42 AM
That wiki page is pretty much up to date - no-one's made any more significant progress than that to my knowledge.
Title: Re: Sandisk Sansa Connect
Post by: Lysander on September 04, 2009, 09:04:21 AM
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
Title: Re: Sandisk Sansa Connect
Post by: Lysander on September 08, 2009, 11:26:40 PM
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...
Title: Re: Sandisk Sansa Connect
Post by: Lysander on September 15, 2009, 09:30:52 PM
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.
Title: Re: Sandisk Sansa Connect
Post by: Lysander on September 18, 2009, 08:50:50 AM
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.
Title: Re: Sandisk Sansa Connect
Post by: AlexP on September 19, 2009, 08:47:23 AM
Excellent work - it'd be great to see something appear on the connect.
Title: Re: Sandisk Sansa Connect
Post by: zivan56 on September 20, 2009, 03:14:24 PM
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).
Title: Re: Sandisk Sansa Connect
Post by: Lysander on September 20, 2009, 05:59:21 PM
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...
Title: Re: Sandisk Sansa Connect
Post by: funman on September 21, 2009, 01:31:59 PM
Good work!

If you hear of cheap (~50€) players which can be get in Europe, I'd like to join the project!
Title: Re: Sandisk Sansa Connect
Post by: Lysander on September 21, 2009, 01:35:37 PM
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...  ;)
Title: Re: Sandisk Sansa Connect
Post by: Lysander on September 23, 2009, 06:35:23 PM
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.
Title: Re: Sandisk Sansa Connect
Post by: saratoga on September 28, 2009, 11:52:04 AM
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. 
Title: Re: Sandisk Sansa Connect
Post by: Lysander on September 28, 2009, 12:05:57 PM
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.
Title: Re: Sandisk Sansa Connect
Post by: Looks_Confused on September 29, 2009, 11:26:22 AM
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...

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
Title: Re: Sandisk Sansa Connect
Post by: Lysander on September 29, 2009, 12:47:53 PM
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...

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

No, they're not needed. .SRR.E files are decrypted on the fly; in fact, the loading process (zsi_fw.exe) takes unencrypted .SRR files just as well. These are sent directly to the device - a 16 byte header indicates the loading parameters for the bootloader / linux service (where to load, how many bytes, entry address). The decryption needs a key which can be obtained from the file itself, i detailed this process in the wiki. This means that the file (minus the header) is sent more or less straight to Flash.

Now, what does need a key is the platform file. The lovely thing here is that the signing of the platform is checked by a script in initrd base layout... which takes no signature at all!  ;D. Modyfing this script should be trivial - right now i'm working on mapping the memory space and flash usage in order to be sure that i don't overwrite anything in the process.
Title: Re: Sandisk Sansa Connect
Post by: Lysander on October 02, 2009, 01:46:03 AM
I've been updating the wiki page with my findings these past days - since i basically write things up as i run across them, it might be a bit unorganized and probably with errors here and there. My excuses in advance  :-[

Right now i'm interested in fetching whatever i can about the hardware from the firmware files, then map the Flash (so i can now exactly where i can load binaries) and start modifying it... i'll probably add write/read capabilites to my tool so i don't have to switch over to Windows every time i want to try something out.

20/10 update: I'm working on dumping Flash though the zsi_fw interface. If this works i would not only have a full flash backup but i could also map Flash memory.

02/11 update: So far i've only managed to replicate the "read" functionality of zsi_fw.exe, which returns a device ID via a USB control transfer.
Title: Re: Sandisk Sansa Connect
Post by: Lysander on December 02, 2009, 07:49:42 PM
Well, after several (failed) attempts to read the devices' Flash via USB, i decided to skip right to modifying the initrd file (disabling key verification for the platform file and enabling all network services, including ftp and telnet) and just give it a go. This turned to be a minor modification and the resulting CramFS file was exactly the same size as the original one.

Thing is, i've just noticed these .SRR files have attached a 2048-byte footer. Without this, the device won't boot after uploading the files to the device, and it seems to be present in both .SRR files:

everest_vmlinux_ext_prod_1.1.1.50239.srr:

001abf50  89 01 15 03 05 00 47 22  18 72 d9 f1 ec 06 0f a0  |......G".r......|
001abf60  ef a9 01 02 32 0c 07 fa  02 4c 53 db f4 d6 7b 5e  |....2....LS...{^|
001abf70  c8 53 eb 8d 32 5c c5 c4  11 f7 a3 8a 07 93 55 90  |.S..2\........U.|
001abf80  90 95 1d f3 1f b8 9d 6d  62 87 db 3d 39 ac 9b 4d  |.......mb..=9..M|
001abf90  79 e5 12 b5 20 65 b1 93  99 2f c5 50 9a 9e 54 dd  |y... e.../.P..T.|
001abfa0  3c 12 1e 2f 21 92 f4 8d  10 ec 79 cf 1c 1e 3f 9b  |<../!.....y...?.|
001abfb0  09 bc f5 8e ca 61 35 04  92 e1 5f 56 79 cb 0e 10  |.....a5..._Vy...|
001abfc0  e2 e3 f0 6e 49 e9 a1 81  f7 dc 04 9f 0f 2a 40 bc  |...nI........*@.|
001abfd0  4d 29 0a ce 2a 7d 09 24  c5 03 7b fc 87 be f4 b5  |M)..*}.$..{.....|
001abfe0  ea 0a d3 af 83 c6 4b 62  b8 6b fc 47 94 f5 21 fb  |......Kb.k.G..!.|
001abff0  14 73 a1 4d 5a d3 56 3b  28 f5 2d 29 32 76 3e a2  |.s.MZ.V;(.-)2v>.|
001ac000  ad 2e b8 07 d5 14 ef 34  81 48 5e 4d a0 99 77 c2  |.......4.H^M..w.|
001ac010  b9 a7 bc 1f 0f 74 50 02  fe df 8d 89 f3 c9 d2 31  |.....tP........1|
001ac020  87 65 4c b7 2d a5 be 87  15 e2 6c 0e ed 65 e7 6d  |.eL.-.....l..e.m|
001ac030  56 28 c7 2a 37 c5 23 d8  a6 95 c4 e0 5c e3 27 b2  |V(.*7.#.....\.'.|
001ac040  43 f9 42 db 1f a2 68 25  d9 b2 33 34 3a 33 ef 19  |C.B...h%..34:3..|
001ac050  ba af 1e 27 af f7 38 c5  37 54 af 23 b2 8e 73 38  |...'..8.7T.#..s8|
001ac060  bc 62 8c 73 c4 b0 c7 e8  00 00 00 00 00 00 00 00  |.b.s............|
001ac070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
001ac750


everest_initrd_ext_prod_1.1.1.50239.srr:

001b3000  89 01 15 03 05 00 47 22  18 72 d9 f1 ec 06 0f a0  |......G".r......|
001b3010  ef a9 01 02 2e b7 07 fd  16 b0 85 cd e5 fc e5 85  |................|
001b3020  ea ec 3a 21 72 af 8b 9a  06 5e 3a 41 13 67 94 60  |..:!r....^:A.g.`|
001b3030  e6 50 12 9b 1c 20 56 ea  49 35 43 e1 30 c5 20 42  |.P... V.I5C.0. B|
001b3040  3f 64 37 b6 dc 3c 80 23  f3 40 9f f3 49 97 9a 60  |?d7..<.#.@..I..`|
001b3050  d9 88 a6 18 6d 58 6c 77  d6 57 f2 8d ac b6 97 8f  |....mXlw.W......|
001b3060  75 5a 84 00 0a 2e ce c8  77 7b 37 3b e4 6e d5 9f  |uZ......w{7;.n..|
001b3070  4a 03 94 0f ad ee 4d 30  cd 15 4a 94 7d c6 22 8d  |J.....M0..J.}.".|
001b3080  60 01 d7 e9 78 5c 95 f7  28 9a 91 fb 5e 0d b9 83  |`...x\..(...^...|
001b3090  8f 67 0d 06 4b b7 72 0b  2b 7c 9f 03 4a 84 46 54  |.g..K.r.+|..J.FT|
001b30a0  1e 67 72 25 03 88 7b a1  5d 27 b0 4c 9d 99 b2 15  |.gr%..{.]'.L....|
001b30b0  42 64 50 41 72 97 75 31  76 c1 76 fb ca b6 c3 4d  |BdPAr.u1v.v....M|
001b30c0  99 5b 5b 7d 48 7f ab 46  5b c4 02 12 13 15 e4 59  |.[[}H..F[......Y|
001b30d0  b2 50 a2 08 73 09 6c c4  51 b6 79 a7 88 5c ce 91  |.P..s.l.Q.y..\..|
001b30e0  cb 9f 16 78 07 31 7b f5  0d 61 51 37 cc 09 92 a8  |...x.1{..aQ7....|
001b30f0  9c 27 ca 47 96 d9 b2 75  4e 76 65 1d d2 0c 78 3d  |.'.G...uNve...x=|
001b3100  b7 db 5b d5 09 64 4d 61  9a 9b 11 8a 55 41 1e db  |..[..dMa....UA..|
001b3110  01 2b e9 7a a0 4c d2 27  00 00 00 00 00 00 00 00  |.+.z.L.'........|
001b3120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
001b3800


Right now i have no idea what these footers could mean, and the device won't accept new .SRR files without it, so more work ensues... any ideas?

Update: It's a GPG signature (the first 280 bytes of it, the rest is zeros). Amazing - does this means the bootloader is validating signatures? I see no references to this in either the linux kernel or the initrd contents. Anyway, there's a load of keys in both the initrd file and bootloader image, i'm trying those.
Title: Re: Sandisk Sansa Connect
Post by: PromisedPlanet on December 06, 2009, 10:24:49 AM
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...  ;)

Actually the WiFi can still receive Yahoo Launchcast (now CBS Radio) music streams, and view photos on Yahoo Flickr.  FWIW.
Title: Re: Sandisk Sansa Connect
Post by: Lysander on December 09, 2009, 02:09:28 PM
Been digging a bit more. All files uploaded to the device are signed with the hey <ZSIProdKey> - for example:


lys@Shoshone ~/downloads/Sandisk_Sansa_Connect/recovery_files $ gpg --homedir ~/downloads/Sandisk_Sansa_Connect/recovery_files/initrd_1.1.1.50239/root/.gnupg --verify -v yeverest_zap_ota_rel_ext_prod_1.1.1.50371.sig yeverest_zap_ota_rel_ext_prod_1.1.1.50371.tar.gz
gpg: WARNING: unsafe permissions on homedir `/home/lys/downloads/Sandisk_Sansa_Connect/recovery_files/initrd_1.1.1.50239/root/.gnupg'
gpg: Signature made Tue Oct 30 14:03:14 2007 ART using RSA key ID 0FA0EFA9
gpg: using PGP trust model
gpg: please do a --check-trustdb
gpg: Good signature from " <ZSIProdKey>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 1D03 6612 33DE 440C 8792  CDFC D9F1 EC06 0FA0 EFA9
gpg: binary signature, digest algorithm SHA1


The only private key i could found in the recovery files is <key.FF.transfer>, which (so far) i have no idea what it could be used for. ¿Perhaps online transfer?:


lys@Shoshone ~/downloads/Sandisk_Sansa_Connect/recovery_files $ gpg --homedir ~/downloads/Sandisk_Sansa_Connect/recovery_files/initrd_1.1.1.50239/root/.gnupg -K
gpg: WARNING: unsafe permissions on homedir `/home/lys/downloads/Sandisk_Sansa_Connect/recovery_files/initrd_1.1.1.50239/root/.gnupg'
gpg: please do a --check-trustdb
/home/lys/downloads/Sandisk_Sansa_Connect/recovery_files/initrd_1.1.1.50239/root/.gnupg/secring.gpg
---------------------------------------------------------------------------------------------------
sec   1024D/C24F1D9B 2006-03-21
uid                   <key.FF.transfer>
ssb   1024g/28DC1565 2006-03-21


So, it's confirmed. I was wrong - the bootloader does check for signatures on SRR files. So right now is either finding the private key or an alternative so the bootloader skips this verification.
Title: Re: Sandisk Sansa Connect
Post by: Lysander on December 18, 2009, 08:36:38 AM
Updated the wiki with more detail. The private keys requiered for signing are (unsuprisingly...) nowhere to be found. Signing new files means breaking 2048-bits RSA :'( so, i moved along to the bootloader.

After some careful analysis, i'm thinking the bootloader has little to do with the stock rrload - it's either heavily modified, or a completely new piece of code. The original rrload uses different file formats for transfer (srec or rrbin versus SRR), doesn't support USB, and doesn't check for file signatures, while the new one has also a lot of hardware-specific code for bootup (HID, display and power management initialization). This is based on th bootloader image available on the initrd files, which happens to be named rrload.chopped, and has a string identifiying it as "ZSI Stiletto Bootloader, Bootloader Version: 50239-2007-10-25-08:56-zbuild@linbld6"

Right now i'm trying to dissasemble/decompile this image, to see if i can make some sense out of it.

Title: Re: Sandisk Sansa Connect
Post by: deathforgets on December 27, 2009, 08:42:17 PM
I am truly inspired and hopeful by (what appear to my ignorant eyes) amazing efforts, Lysander.  Though I have no programming experience, I thought I would inquire as to anything I might do to help with this effort?  I have in my hands two Sansa Connects, that in an ideal world one would hope to make it possible to connect through most wireless routers (including those with http:// sign-in mechanisms) and open it up to streaming Pandora/Slacker.

If there is anything you might suggest I can do to assist you - please let me know.  In the spare time i can find here and there, I am willing to learn from you or anyone else with more experience in the fields necessary to make this project happen.
Title: Re: Sandisk Sansa Connect
Post by: Lysander on December 27, 2009, 11:19:24 PM
Thanks for the kind words man  :)

As for what to do next, i really don't know - besides messing arround with assembler or cryptography :( As it stands right now is either finding a private key to sign the uploaded files (practically impossible) or finding a workarround in the bootloader (hard, but likely doable - the binary is available). ¿Perhaps donating one to someone willing to help?

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.
Title: Re: Sandisk Sansa Connect
Post by: PromisedPlanet on December 28, 2009, 08:52:05 AM
I have a Sansa Connect that I'm willing to donate for Rockbox purposes.  Let me know if interested.
Title: Re: Sandisk Sansa Connect
Post by: 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?
Title: Re: Sandisk Sansa Connect
Post by: Lysander on December 28, 2009, 01:46:09 PM
is there something that prevents you from just patching the bootloader to skip the signature check? Can we patch the bootloader?

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...
Title: Re: Sandisk Sansa Connect
Post by: saratoga on December 28, 2009, 07:04:01 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.

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).
Title: Re: Sandisk Sansa Connect
Post by: Lysander on December 29, 2009, 06:34:13 AM
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).

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


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.
Title: Re: Sandisk Sansa Connect
Post by: saratoga on December 29, 2009, 09:30:34 AM
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.
Title: Re: Sandisk Sansa Connect
Post by: mcuelenaere on December 31, 2009, 05:50:40 AM
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).
Title: Re: Sandisk Sansa Connect
Post by: Looks_Confused on January 06, 2010, 11:50:11 AM
Maybe we should consult with the SFLC on this.  I think part of the GPL is that you are required to supply whatever it takes to get things working.  So, for instance, you can't supply the source code in an encrypted format, without providing a way to decrypt it to get access.  Really, this is exactly the sort of situation that originally prompted RMS to create the GPL and Free Software.  However, if Zing pulled a Tivo, there may not be much that can be done.

Since Dell bought Zing, there might be some interest in looking into this.

Regards,

Hans
Title: Re: Sandisk Sansa Connect
Post by: Lysander on January 06, 2010, 01:01:44 PM
I thought about this too. To be perfectly clear - all i know so far is:


If the bootloader happens to be GPL then Zing/Sansa/Dell should be obliged to release the sourcecode for it, including modifications, which would be great :) But it's a long shot. I'll see about contacting the SFLC foundation if i find more compelling evidence for sure.
Title: Re: Sandisk Sansa Connect
Post by: Llorean on January 06, 2010, 05:10:55 PM
I think part of the GPL is that you are required to supply whatever it takes to get things working.  So, for instance, you can't supply the source code in an encrypted format, without providing a way to decrypt it to get access. 

Depends on which GPL. In the case of GPLv2 you're basically just required to provide the same source code you use. That does more or less mean the source code can't be encrypted, but it doesn't mean you have to provide any specialty compilers, or any tools you use to encrypt or sign the binary so that the player will accept it.

The GPLv2 basically just covers the necessity of distributing source if you distribute the binary, and that even modifying the code doesn't prevent this requirement. If it's GPLv3 there are a greater number of protections in place to ensure that you need to provide some of what's necessary to actually use the code.

At least, if my understanding is correct.
Title: Re: Sandisk Sansa Connect
Post by: Lysander on May 04, 2010, 08:46:05 PM
Just to keep anyone posted... right now i'm switching jobs, so my spare time to dedicate to the Connect is pretty much zero these days.

What we would need right now is to dissasemble an ARM binary and find out if there's any way of skipping the signature checking in the bootloader. I have one obtained with HexRays, but it's far from usable - i just managed to label and disect a few labels and subroutines. If anyone's up to the task, PM and i'll give you the details.
Title: Re: Sandisk Sansa Connect
Post by: Lysander on February 08, 2011, 04:41:19 PM
It's been a while, but i decided to take another stab at the bootloader, so right now i'm working on the actual signature validation subroutine (offset 0x172c on the rrload.ssr.chopped bootloader image i've found on the filesystem). Hopefully i'll be able to find some way to bypass the signature validation.

9/Feb update: The file validation process starts with the calculation of both a SHA-1 and SHA-256 checksums of the received srr file. These functions are clearly identifiable and seems to be the same used on OpenSSL's crypto library though is hard to tell, since most hashing implementations are pretty much alike.

Anyway, funny thing is both are promptly discarded; they're just dumped as a hex string to a (presumably) serial port through a printf() function.

The actual validation is then performed by a subroutine at offset 0x7168. This one is pretty weird and it doesn't look a RSA implementation - it's certainly not similar to OpenSSL's RSA_verify(), but it's awfully difficult to tell the way C compilers optimize for ARM. More work ensues...

14/Feb update: Bootloader is definitely based on rrload. All initalization routines are identical to the C sourcecode.

28/Feb update: The file verification calculates a SHA-256 hash of the whole received file, which is then memcmp'ed against a hash value retrieved by a separate subroutine. I'm still working on that one, but from the looks of it the bootloader is validating the GPG signature of the source file.

The usb loading routines look fairly well designed, with no obvious flaws. Still have to get deep into those.
Title: Re: Sandisk Sansa Connect
Post by: desowin on November 03, 2011, 07:59:30 AM
I have posted patch adding initial Sandisk Sansa Connect support - http://www.rockbox.org/tracker/task/12363 (http://www.rockbox.org/tracker/task/12363)

There is hardware modification involved to bypass signature check. This is rather good enough for developers who are interested in porting Rockbox to it, but unfortunately definitely not good for a typical user.

The bootloader has not been throughfully checked - but it calculates SHA-1 sum, although the final result printed on UART is not SHA-1 sum - I haven't managed to figure what actually is being printed.
Title: Re: Sandisk Sansa Connect
Post by: AlexP on November 03, 2011, 08:01:42 AM
Excellent work, I might dig out the soldering iron if I'm bored this weekend :)
Title: Re: Sandisk Sansa Connect
Post by: desowin on November 03, 2011, 10:20:00 AM
Excellent work, I might dig out the soldering iron if I'm bored this weekend :)

Looks like I haven't stated it explicitly - to get command shell access (which I've used to flash the bootloader) it is required (currently, as no OF remote exploit exists) to use JTAG to do memory-patch of bootloader (go into recovery mode first), and then load modified initrd image.
Title: Re: Sandisk Sansa Connect
Post by: AlexP on November 03, 2011, 11:09:06 AM
Excellent work, I might dig out the soldering iron if I'm bored this weekend :)

Looks like I haven't stated it explicitly - to get command shell access (which I've used to flash the bootloader) it is required (currently, as no OF remote exploit exists) to use JTAG to do memory-patch of bootloader (go into recovery mode first), and then load modified initrd image.

Maybe not here, but you certainly did in your blog post - I'd just forgotten since I read it.
Title: Re: Sandisk Sansa Connect
Post by: desowin on November 14, 2011, 08:03:34 AM
Given that we have working sound on device, I would like to gather more developers.

I can handle hardware modding of device (includes soldering JTAG+UART connector) for any interested Rockbox developer (postage to be covered by interested developer, preferably europe).

As I have ordered, back in June, few small PCBs for JTAG+UART to standard JTAG 2x10 and UART<->USB (using MCP2200), I could give away that bare PCB (or populate it with elements if you cover the costs (assuming I have those available in my dumpbox)). The design of that PCB has a minor fault albeit it can be hacked (one additional wire; "contracting" the pins of IC) to working condition.

Due to limited amount of connectors I have (and they are quite hard to get), this service has priority on existing developers. For everyone else, contact me in private and we'll see what can be done (expect fee, which will be lower if you have some exploit achievements and you are planning to investigate OF for remote shell exploits).
Title: Re: Sandisk Sansa Connect
Post by: wodz on November 14, 2011, 04:39:20 PM
Maybe this is stupid question but why don't you run rockbox as an app? With native rb you loose network connectivity right?
Title: Re: Sandisk Sansa Connect
Post by: desowin on November 15, 2011, 03:09:29 AM
Maybe this is stupid question but why don't you run rockbox as an app? With native rb you loose network connectivity right?

Quite a few kernel modules are closed-source (this includes DSP. AIC3X is handled in binary, non-free, library). Moreover I am not interested in setting up obsolete toolchain just to build binaries that can be run on the target. I am not interested in updating the Linux distribution that is being run there.
 
Well, network subsystem could be added to Rockbox at some point in the future, I think. Anyway, at current point you don't loose anything, as OF doesn't allow you to connect (without workarounds; and you have to downgrade OF to have network support at all) to the network.
Title: Re: Sandisk Sansa Connect
Post by: desowin on May 21, 2021, 04:52:20 AM
Reviving the thread as OF bootloader contains arbitrary code execution vulnerability. The exploit is available at https://github.com/desowin/zsitool/blob/master/exploit.md (https://github.com/desowin/zsitool/blob/master/exploit.md). Rockbox bootloader can be installed using only Open-Source tools (no need to rely on any official firmware packages).
Title: Re: Sandisk Sansa Connect
Post by: unilock on November 14, 2021, 08:05:20 PM
Hi all,

I bought a Sansa Connect recently. After softbricking it almost immediately, I restored the original firmware (OF) to version 1.2.0.58335 (latest from SanDisk), and installed Rockbox version a4e422db9e-211113 (latest commit as of writing this). All using desowin's zsitool (https://github.com/desowin/zsitool), of course.

Issues I've come across:

BTW, it's neat that I can edit the files on the (normally inaccessible) internal flash via Rockbox. I edited some files to see if I could re-enable Wi-Fi functionality, but haven't been able to reboot into the OF to test it since installing Rockbox...

UPDATE: After letting the player run for a while, the Volume buttons are working now?? Music starts playing automatically when selected, too! The Play/Pause button was even able to start an MP3 once, but after that reverted to its previous behavior. Apparently, the Power button can also be used to stop playing music entirely (i.e. the "square" icon instead of the pause icon). The rest of the buttons still work as stated above.
The speaker also works, which is cool!

What I haven't tested:

Any functionality I haven't mentioned works fine, as far as I can tell - though I doubt I've tested everything.

I'll report more issues as I find / remember them, if wanted. Let me know if you all need me to do anything in particular.

One last question: when updating Rockbox, do I need to update the bootloader (flashed via zsitool) as well? Or do I just need to update the files in the .rockbox folder on the micoSD card?

EDIT: It does seem that the Sansa Connect will automatically power off, even when plugged in. Although this doesn't happen while playing music... Maybe it's the "Idle Timeout" after all.
Also, after a reboot, I'm still able to play music through the speaker! I didn't have to wait after the player booted at all.

EDIT2: I forgot to mention: the player treats every USB connection as data+power (as opposed to just power), even if it's connected to a power brick (not a computer). This causes issues with the bootloader.
When cold-booting, the device tries to connect to a non-existent computer over USB, but times out. It appears to then load the Rockbox firmware, which seems to work, but it gets stuck on the splash screen and needs to be hard-rebooted.

EDIT3: I left my Connect plugged in, charging, and playing music overnight. In the morning, I found it had powered off. Based off of Rockbox's "running time", I'm guessing it was on for only 45 minutes to an hour.
Also, when I powered it back on in the morning, I got the "Low Battery - Charging" screen (built into the ROM); force-rebooting it fixed that, and Rockbox reported the battery as being at 100%. So I guess calibrating it worked!

EDIT4: After leaving it plugged in for a few hours, the Connect reported the battery as being around 65%, despite being fully charged. I guess the calibration did NOT work.
Also, I've made some progress towards booting the OF - you have to hold the "Left" button (below the screen and above the scrollwheel) while coldbooting the player. It will then look for vmlinux.bin and initrd.bin (https://www.rockbox.org/tracker/task/12363) on the SD card (not the internal storage). I tried copying the vmlinux and initrd SRR files from the "no-wifi" Sansa Connect Recovery Tool (https://kb.sandisk.com/app/answers/detail/a_id/863/~/sansa-connect-recovery-tool), renaming them to BIN files, but had no such luck - the bootloader would get stuck on "Loading initrd.bin".

EDIT5: I got the OF to boot!! I just had to remove SanDisk's magic (the first 16 bytes) from both vmlinux.bin and initrd.bin. Although now it's stuck on the "sansa" screen with the five colored circles; probably because I messed with the OF too much. I'll see what I can do about that, if anything...

EDIT6: Indeed, it was becuase I had edited some strings file, and the Connect didn't like that. Though I'm not sure what the root cause of the issue was; I had replaced a particular strings file in my firmware version 1.2.0 filesystem from the same file from version 1.1.2, which should've worked fine, as I could see no other significant differences between the 1.1.2 and 1.2.0 filesystems / initrds. I guess it had to do with the kernel? So strange...

I figured out the above issue by looking at the "error.txt" log file in the root of the Connect's internal filesystem, which one can access via Rockbox. It'll contain any errors the OF ran into the last time it was started.

EDIT7: By the way - after reverting the edits I made to that strings file I mentioned earlier, and changing a few other files in the internal filesystem (namely some XML files), I *was* able to enable the old Wi-Fi-oriented options on the Sansa Connect. It was even able to list available Wi-Fi networks! I didn't try connecting to any, though; I'm pretty sure that wouldn't work, anyway, due to the Connect trying to ping a no-longer-existent URL in order to verify the connection. Might be possible to change the URL it tries to connect to, though, by messing with the internal FS / initrd... not much of a point in doing so, though.
It would be much more interesting to implement Wi-Fi functionality on Rockbox, I imagine. Multiplayer DOOM when??