Rockbox Development > New Ports
Sandisk Sansa Connect
Lysander:
--- Quote from: Looks_Confused on September 29, 2009, 11:26:22 AM ---
--- Quote from: 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...
--- End quote ---
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
--- End quote ---
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.
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:
--- Quote from: Lysander on September 21, 2009, 01:35:37 PM --- 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... ;)
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version