Rockbox Development > New Ports
Sandisk Sansa Connect
Lysander:
I've been checking the file everest_initrd_ext_prod_1.1.1.50239.srr , which is an encrypted ROMFS (cramfs) file. Inside it we find the base layout for the device, including binary files, scripts and the works.
From what i've seen, both the recovery process (/etc/rc.recover) and signature checking (/usr/share/LUA/5.1/checksig.lua) are handled entriely by userland applicactions and scripts. If the device doesn't check the signature on the initrd file, this would allow us to upload a modified version without signature verification and then modify the platform to our hearts' content.
Before starting the main processs (/disk/zap/assets/System/runzap, from the platform file) the init process has a lot of commented-out services, which could be enabled. For example, if the variable $nfsserver is set before the main init script (in /bin/setupenv) the device will try to mount a NFS share in /home.
Also, the crypto-secure EEPROM is apparently used to retreive MAC and deviceid. Again, this is done by a small script (bin/setupenv) so this is completely modifiable as well.
I can upload these unencrypted images if anyone's interested.
AlexP:
Excellent work - it'd be great to see something appear on the connect.
zivan56:
Nice work. FYI, for anybody looking to grab a Sansa Connect... they can be had for ~$40 USD shipped brand new in box (eBay, Amazon, etc).
Lysander:
For whatever is worth, i received my Connect about a week ago and it's a damn impressive player - excellent UI, design, sound quality and battery life. I just can't wait to start modding this one :'(
Right now i'm working on the devices' memory map and generating .SRR to upload. I'm pretty confident about the header format, but the addresses contained make no sense whatsoever to me (load address, entry address and number of bytes). I expected a plain mapping of the devices' 4 gigs, but if the header values are correct (and they seem that way), this is not the case.
Load address should be the starting address in where the device stores the given binary - i expect separated blocks for vmlinux kernel image, initrd (base layout) and platform (player utilities and file memory), which is mounted by a fstab entry:
none /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
none /sys sysfs defaults 0 0
none /var ramfs defaults 0 0
none /tmp ramfs defaults 0 0
# ZSI Added
/dev/mmcblk0p1 /disk ext3 defaults,noatime 0 0
Entry address should be the execution starting point of any binary image and Number of bytes should be, well, the number of bytes to upload :) According to the Cadenux documentation, "...while the EntryAddr and NumBytes are computed by the mkimage script. In cases where the input image does not represent an executable, but rather represents a file system, then the EntryAddr will not apply and mkimage will simply supply a default filler value. For those that are curious, there is additional usage information contained within the document header of the mkimage script.". So, it makes sense to have an entry address of 0xFFFFFFFF for the initrd image, and i presume this is how the bootloader / userland image loading utils determine if we're loading a kernel or not.
Having that mkimage document header would be really nice!
And again, the number of bytes for each .srr are a bit of a mystery. I still have no idea what they represent or how they're computed, but they have nothing to do with image sizes or even maximum size for each possible memory block...
UPDATE: Thought the ATMEL uC could be the main CPU of the device - the TI DMS320 DSP allows to disable its internal ARM core to be used purely as a DSP. Still, all the binaries in the initrd image are ARM... i'm updating the wiki page with a bit more detail.
Update 2: I'm a retard >:( The header is stored in little-endian format, and this makes the byte number exactly the filesize minus the header (16 bytes). Will continue working on the memory map with this. The srr tool i was working on keeps growing, and it can now show info, decrypt and extract binaries from SRR files. The correct header info should then be...
lys@Shoshone ~/downloads/Sandisk_Sansa_Connect/hacking/srrtool $ make -f srrtool.mak all && ./srrtool info everest_initrd_ext_prod_1.1.1.50239.srr.e everest_vmlinux_ext_prod_1.1.1.50239.srr.e yeverest_zap_ota_rel_ext_prod_1.1.1.50371.tar.gz.e
gcc -Wall -lcrypto -o srrtool srrtool.c
SRR Tool v1.5.0 - (C)2009 Lisandro Pin
Info for 'everest_initrd_ext_prod_1.1.1.50239.srr.e' (file 1 of 3)
Encrypted = yes
Encryption key = 5928db44795a317aa37ece1fae8ec269fc787e26ffb179ed
IV = 3dcd5a05a346ac40
Type = SRR file
Load address = 0x04400020
Entry address = 0xffffffff
Num. of bytes = 0x001b3800
Info for 'everest_vmlinux_ext_prod_1.1.1.50239.srr.e' (file 2 of 3)
Encrypted = yes
Encryption key = a31a11dd29623e5eb7d3b6ad27d21f7db45f09bd081c9dc3
IV = fb4c889cd602de37
Type = SRR file
Load address = 0x01008000
Entry address = 0x01008000
Num. of bytes = 0x001ac740
Info for 'yeverest_zap_ota_rel_ext_prod_1.1.1.50371.tar.gz.e' (file 3 of 3)
Encrypted = yes
Encryption key = 4034d0352460a005c6467e1c7e08d56bb57ef2ec5a7ad33d
IV = 8dd60124270fd7b8
Type = GZIP file
All done!
Update 3: There's some very interesting info on the kernel source patch attached in the wiki page - including some memory mapping and initialization procedures! I'll give this a closer look during the week.
Update 4: As stated in the wiki file, the devices exposes two different IDs (0781:7481 and 0781:7482) in recovery mode. The first one is apparently only used for writing, while the second one is used for reading. I was planning to add writing capabilities to my tool, but i'll work on the reading - a full flash dump and a backup of the bootloader code would be great. More work on zsi_fw.exe ensues...
funman:
Good work!
If you hear of cheap (~50€) players which can be get in Europe, I'd like to join the project!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version