Sandisk Sansa Connect

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

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

[Lysander]

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.

[Lysander]

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.

[PromisedPlanet]

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.

[Lysander]

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.

[Lysander]

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.

[deathforgets]

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.

[Lysander]

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.

[PromisedPlanet]

I have a Sansa Connect that I'm willing to donate for Rockbox purposes.  Let me know if interested.

[RichterSkala]

is there something that prevents you from just patching the bootloader to skip the signature check? Can we patch the bootloader?

[Lysander]

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

[saratoga]

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).

[Lysander]

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:

• 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  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).