Rockbox Technical Forums
Rockbox Development => New Ports => Topic started 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
-
That wiki page is pretty much up to date - no-one's made any more significant progress than that to my knowledge.
-
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
-
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...
-
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.
-
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.
-
Excellent work - it'd be great to see something appear on the connect.
-
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).
-
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...
-
Good work!
If you hear of cheap (~50€) players which can be get in Europe, I'd like to join the project!
-
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... ;)
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
I have a Sansa Connect that I'm willing to donate for Rockbox purposes. Let me know if interested.
-
is there something that prevents you from just patching the bootloader to skip the signature check? Can we patch the bootloader?
-
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...
-
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).
-
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 ;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.
-
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.
-
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).
-
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
-
I thought about this too. To be perfectly clear - all i know so far is:
- rrload (the original, by RidgeRun) IS GPLed. Based on this, any derived work Cadenux might have done with it should be GPL as well.
- The exact nature of the bootloader used in the Connect is based on guesswork (strings, mostly). It does seem to be atleast derived from rrload, with a lot of added specialized functionality for the device. Again, this is not confirmed. RidgeRun allows proprietary licencing of rrload as well.
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.
-
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.
-
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.
-
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.
-
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.
-
Excellent work, I might dig out the soldering iron if I'm bored this weekend :)
-
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.
-
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.
-
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).
-
Maybe this is stupid question but why don't you run rockbox as an app? With native rb you loose network connectivity right?
-
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.
-
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).
-
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:
- I had to compile the bootloader (commit a4e422db9e) myself, as I don't see it anywhere on the site nor in the auto-built rockbox.zip. Maybe that's good though, since this port isn't quite finished. Or I just missed it in the ZIP...
- I can't figure out how to boot into the original firmware (OF). The SansaConnect wiki page states that holding the "PREV" button on boot will allow the user to do so, but either I can't find that button, or it simply isn't working. (Every button works in the OF, from when I was last able to test.)
- .
- This may be related to the above - it seems the keymap is very wrong. What works:
- Power button. I can press it to boot the device (probably not related to Rockbox) and hold it down to power off the device. I can also use it to exit some menus; mostly in the "Debug" submenu.
- Hold switch. It works as expected, turning off the backlight (and LCD after a second or two) and the buttons when turned ON (hold), and vice versa when turned OFF (unhold).
- Scrollwheel. Works like an iPod, except it physically rotates instead of swiping your finger across the surface. However, see below...
- Select button. Does as you would expect.
- Back button (left of scrollwheel). I can use it to go up within most menus and rewind music.
- Forward button (right of scrollwheel). I can use it to fast-forward music.
- Home button (top of scrollwheel). It shows the current playlist when in the "Now Playing" menu, so I'm assuming it's working as the hotkey.
- Play/Pause button (bottom of scrollwheel). It exits the "Now Playing" menu. See below...
- .
- What *doesn't* work:
- Scrollwheel - When scrolling in one direction, the selection will occasionally change in the *opposite* direction - e.g., if I'm scrolling to the left, the selection will occasionally go down. This usually only lasts for a single menu option, as in the selection will change in the usual direction after moving backwards once (it's almost unnoticeable when scrolling quickly).
- Scrollwheel - After mounting the device on a computer via USB, then ejecting it and removing the cable (returning to the Rockbox menu), the scrollwheel will cease to function until any button is pressed, e.g. the select button or the back button. Even the Volume buttons work to fix the scrollwheel!?
- Play/Pause button - it exits the "Now Playing" menu. On the main menu, it opens the "Shuffle / Repeat" menu. It doesn't play nor pause music. So I can't listen to music. See below as well...
- Volume buttons - they don't do anything, as far as I can tell.
- "Left" and "Right" buttons (under the screen) - they also do not do anything.
- .
- Rather than just the Play/Pause button, playback may be broken entirely, as none of the music I select from the "Files" menu starts automatically (tested with FLACs and MP3s).
- The battery reports being 40% charged when, in the OF, the battery is at 100%. I'm trying to calibrate it now to see if that fixes it, though I'm having some trouble as I'm not sure how to keep the player on without being able to play music.
- Occasionally, the player will suddenly power off, before the "Idle Timeout" is exceeded. Though I may be wrong; it could be that I simply hadn't noticed the timeout had been exceeded.
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:
- The 3.5mm aux port
- Plugins, besides "oscilloscope" (to keep the screen on while calibrating battery)
- Whether if what does/doesn't work (buttons, audio playback) is retained after a reboot
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??