|
SanDisk Sansa Connect
History/Background
The Sansa Connect is designed by Zing System Inc. (part of Dell), who showed off a WIFI device for listening to streaming radio stations, without any onboard storage. A prototype device was announced, but never put into production. Screenshots of the time show a similar UI design to the current Sansa Connect.
The Sansa Connect has 4Gb of onboard flash storage, as well as a Micro-SD slot, capable of using SDHC cards in the newer firmware versions.
Hardware
AnythingButiPod performed a basic disassembly.
Further to this: the EMI shield is a frame and clip-on top shield - only the frame is soldered to the main PCB. The frame visually obscures some of the chips.
CPU: TexasInstrumentsTMS320
Secondary CPU (???): ATMEL MEGA165PV
Power Management: T TPS 65021
LCD: 2.2 inch - CT022TND4 V.6 M1-B
SDRAM: Samsung K4M51323LC-DN75
VOIP(!!!): Ti TNETV105
Codec: Ti AC3106I
EEPROM: Atmel AT88SC - 64kbit fused, cryptographically secure
Visually obscured chips:
WIFI: Murata (chip has the MAC address engraved on it - vendor digits are 00:13:E0) - possible model numbers start KK6T6... or LBWA-...
Recovery Mode
Recovery Mode can be reached by completely powering down the device (by holding off for 10 seconds). Holding the volume-up and right keys while powering the device back on switch it to recovery mode. In recovery mode the device uses different USB IDs (0781:7481 and 0781:7482, vs 0781:7480 in normal operation) - if installed under Windows the Sansa Connect Device Recovery software will automatically launch when a Connect in recovery mode is connected.
There does NOT seem to be any way to exit recovery mode once entered without running the recovery operation (and therefore wiping the unit). Rebooting the device (by holding power for 20+ sec) still results in the device booting into recovery mode.
Software
OS
Zing are using an OS and bootloader from Cadenux "Embedded Linux Solutions". The Sansa Connect runs a modified 2.6.4 kernel (although Nmap reports "Linux 2.4.20 - 2.4.32, Linux-based embedded device"). On top of this it uses Busybox and uClibc.
Bootloader
The bootloader is rrload again from Cadenux. Strings in the bootloader, and application code, talk of a devkey, which may enable a serial console, rshell etc.
User Interface
The UI is written in .NET, running on Mono, along with various shell and LUA scripts. I would speculate this part was written inhouse by Zing. The filesystem integrity (at least partially) is verified by GPG.
WIFI update - it will automatically perform an over the air upgrade using it's WIFI connection. It periodically opens an SSL connection to zing.net, presumably to check for newer versions.
Application update - the windows only "Sansa Connect Device Recovery". This downloads several files from zing.net over SSL, and saves them locally to a hidden folder "RecoveryImages". The files it downloads are:
| Filename |
Size (bytes) |
Function |
| everest_initrd_ext_prod_1.1.1.50239.srr.e |
1783824 |
filesystem |
| everest_vmlinux_ext_prod_1.1.1.50239.srr.e |
1754960 |
firmware |
| yeverest_zap_ota_rel_ext_prod_1.1.1.50371.sig |
280 |
platform signature |
| yeverest_zap_ota_rel_ext_prod_1.1.1.50371.tar.gz.e |
17248792 |
platform |
The function names come from the update log. The .srr extension is listed in the rrload documentation as "A RidgeRun inspired format, rrbin is a tagged image binary format used for downloading either executable files or data files such as file systems. This format is very efficient..."
Although the .e files are encrypted, during the recovery process they are transmitted over USB to the Connect in the clear - using USBSnoop I was able to capture logs of the update process, and using grep, sed and perl I was able to convert these into binary files.
The two everest files (filesystem and firmware) were sent first as a single transfer to the Connect (USB ID was 0781:7481) using zsi_fw.exe (which is in cmdline directory of sansa connect recovery tool) - the start of this transfer was a vmlinuz image, followed by a Compressed ROMFS image (look for the "45 3d cd 28" magic string). The ROMFS contains the root filesystem - Busybox, uClibc, init scripts (some in LUA), public GPG keys for verification... and in the /bin/removeme folder what seems to be a (partial?) bootloader flash image.
The platform file is then sent (USB ID of 0781:7482) - this is a 17Mb .tar.gz containing LOTS of png images, .NET dlls for the UI, more LUA scripts, XML config files and other binaries (freetype, libcurl, libglib, libjpeg, libssl and Mono).
Filemon sugests that platform file is sent using zaprecover.exe (which is in cmdline directory of sansa connect recovery tool), it keeps reading platform file by 497-byte blocks.
Actual recovery can be done from commandline (assuming you've run the "normal" recovery atleast once to download recovery images, and you've put those in cmdline directory, and you're issuing those commands being chdired there):
zsi_fw.exe -w everest_vmlinux_ext_prod_1.1.1.50239.srr.e everest_initrd_ext_prod_1.1.1.50239.srr.e
zaprecover.exe -t 600000 -f yeverest_zap_ota_rel_ext_prod_1.1.1.50371.tar.gz.e yeverest_zap_ota_rel_ext_prod_1.1.1.50371.sig
Uploading firmware to device
zsi_fw.exe -w everest_vmlinux_ext_prod_1.1.1.50239.srr everest_initrd_ext_prod_1.1.1.50239.srr
ZSI FW load starting.
Found unencrypted file: everest_vmlinux_ext_prod_1.1.1.50239.srr
Found unencrypted file: everest_initrd_ext_prod_1.1.1.50239.srr
Open USB Device start
found a device!
Attempting to open \\?\usb#vid_0781&pid_7481#5&1b0f9047&0&2#{184954e0-9128-11db-b606-0800200c9a66}
opened device!
completeDeviceName = (\\?\usb#vid_0781&pid_7481#5&1b0f9047&0&2#{184954e0-9128-11db-b606-0800200c9a66})
Opened successfully.
data completeDeviceName = (\\?\usb#vid_0781&pid_7481#5&1b0f9047&0&2#{184954e0-9128-11db-b606-0800200c9a66}\PIPE00)
Opened successfully.
Loading: 1008000 16809984 1754944
Done!
Loading: 4400020 4294967295 1783808
Done!
Magic markers seems to start with "aa bb ff ee". Those are:
for vmlinux:
aa bb ff ee 00 80 00 01 00 80 00 01 40 c7 1a 00
for initrd:
aa bb ff ee 20 00 40 04 ff ff ff ff 00 38 1b 00
Those bytes are in header of .srr file.
At 001b:3010 of everest_initrd_ext_prod_1.1.1.50239.srr there's gpg key sign.
everest_vmlinux_ext_prod_1.1.1.50239.srr also includes gpg key sign, it's located at 001a:bf50.
Those are signed with key D9F1EC060FA0EFA9 which is named " <ZSIProdKey>"
Open ports
When connected via WIFI, the device has TCP port 8088 open, which appears to be a web server. The headers returned are:
Connection: close
Server: ZING-0035/1.1.1.50239 (xxxx; en-us) ZAP/1.1.1.50371 BOOT/24655 libcurl/7.16.0 OpenSSL/0.9.8a
404 Not Found
where xxxx is the 32 character long hex unique Device ID (visible in the Connect firmware under Settings -> Info -> Software Versions).
There don't appear to be any open UDP ports.
Free Software
The PDF that ships on the Sansa Connect CD includes a section called "Open Source Licences" and includes:
busybox
curl
Ezxml
Freetype
GPG
Linux
mDNSresponder
Mono
libpng
openssl
SSLeay
resample
Uclibc
wpa_supplicant
zlib
There are broken links in the PDF to the Sansa site to download modified source versions of the GPL licensed software. Instead these downloads are available from the Zing site, substituting zing.net for sandisk.com in the links: busybox, GPG, Linux, Mono, resample and Uclibc. Also attached is a diff created against the vanilla 2.6.4 kernel release.
|
|
Copyright © 1999-2008 by the contributing authors.
|
|
atmel_mega165.pdf 
lsusb-normal.txt 
sansaconnect-2.6.4.patch.bz2 
connect-back.jpg 
