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.

• DSP/CPU: TexasInstrumentsTMS320. This is a multicore device consisting of a ARM926EJ?-S CPU core and TMS320vc5409 DSP.
• Secondary CPU: ATMEL MEGA165PV. The Atmel AVR line has great support of open source developement tools (GCC et all). It's referred internally as "HID", and it's used as an interface to external devices - handles display sleep & wakeup, for example. Interfaced via SPI.
• Power Management: TI TPS 65021. Interfaced via I2C?.
• LCD: 2.2 inch - CT022TND4 V.6 M1-B
• SDRAM: Samsung K4M51323LC-DN75
• USB 2.0: TNETV105. Not to be confused with TI's TNETV105 (DSP/CPU bundle), this handles USB for the device. The TMS320 has an internal USB controller but it is disabled on boot. Interfaced via VLYNQ.
• Codec: Ti AC3106I. DAC and stereo power amplifier, with programmable filters. Most likely interfaced via I2C?.
• EEPROM: Atmel AT88SC? - 64kbit fused, cryptographically secure. Holds individual device information such as USB deviceid, MAC address and device certificate. Interfaced via I2C?.
• Flash: Sandisk SDINB1-4096. 4GB iNAND flash module. Holds bootloader, linux kernel, persistent variables, platform and filesystem.

• WIFI: Murata (chip has the MAC address engraved on it - vendor digits are 00:13:E0) - possible model numbers start KK6T6?... or LBWA-.... Interfaced via SPI.

Clock speeds

These are obtained from the initialization code on the linux kernel patch for the Connect:

• TMS320 ARM core: 120 MHz
• SDRAM: 72 MHz
• TMS320 DSP core: 72 MHz
• DMA coprocessor: 144 MHz

TMS320 general purpose I/O pins mapping

This is the detail for the known GPIO pins in the Connect:

TMS320 memory maps

Physical memory:

Virtual memory:

(..more to come..)

Flash:

This memory map is UNCONFIRMED - use at your own risk!

(..more to come..)

Power managment

After loading the Linux kernel, the TPS 65021 is programmed via I2C? (/usr/share/lua/5.1/pwrfix.lua) - devices' I2C? address is 0x48.

• Device is set to PWM mode (register 0x04 = 10110010b).
• Core voltage set to 1.5V (register 0x06 = 00011100b).
• Codec and USB power line (LD02) to 1.8V, LCD display module (LD01) to 2.85V (register 0x08 = 00110110b).

HID (ATMEL MEGA165PV? microcontroller)

The HID handles external devices - it is interfaced to the CPU via its built SPI interfase, clocked at 200 KHz.

This device is initialized on boot - the firmware loaded on it is located on /lib/clicky165.bin. The Fuse high byte register is set to 0xd1 (OCD and JTAG enabled, watchdog always on, uses reset vector), while the fuse low byte is set to 0xC2 (divide clock by 8, enable clock output, use clock source 1).

Once programmed, it accepts commands (via SPI) which are defined in /usr/include/hidif.lu. These are used to control & query external devices:

Sync sequence is CMD_SYNC -> CMD_VER -> CMD_FILL -> CMD_CLOSE, while command sequence is CMD_SYNC -> command -> CMD_CLOSE -> CMD_FILL Communication to this device is handled by /usr/bin/hidtool, which is a binary file.

Device also seems to work as a watchdog.

Atmel AT88SC? EEPROM and USB.

This device is read by the /bin/setupenv script - it retrieves both deviceid and MAC address and loads them into the $deviceid and $mac environment variables, respectively. Other environment variables (/etc/setupenv) are:

• Manufacturer:"SanDisk"
• Product name: "Sansa Connect"
• Vendor ID: 0x0781
• Product ID: 0x7480 (MTP more), 0x0F02 (Ethernet-over-USB mode), or 0x7482 (recovery mode)
• Product revision: 0x0101

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.

USB ID 0781:7481 is used for writing .SRR files to Flash, while 0781:7482 acceses the "Zaprecover" service (complete with a kernel module!!!), which handles dumping files to the filesystem.

Once linux is loaded, recovery mode is signaled by a persistent variable ("recoverzap") stored in flash. This flag is only removed after a sucessful recovery operation, so there's no way to exit recovery mode once entered without running the recovery operation (and therefore wiping the unit) with the stock initrd file.

Recovery sequence

• Turn off the device completely (hold power key for 10 seconds)
• Turn the device on while holding volume-up and the right button (above the wheel)
• The device will boot showing a "recovery needed" indicator. On this mode the device exposes the USB ID 0781:7481, which zsi_fw.exe communicates to. This is NOT handled by linux - so it's either the linux bootloader or maybe even a previous instance of software. This mode is persistent after reboot.
• Once the USB cable is connected the indicator is changed to "recovery in progress".
• After a suceessful firmware load with zsi_fw.exe, the device will attempt to boot the vmlinux image (after a small delay). If the device reboots to recovery mode something went wrong with the firmware load. otherwise Linux will boot correctly and go to recovery mode, exposing the USB ID 0781:748 (Zaprecover service) and displaying a "starting recovery" message (with a yellow clock on top). How the device determines it has to go into recovery mode after boot is unclear - most likely it's because the flash filesystem is wiped after a firwmare write.
• Once a platform load is started with zaprecover.exe the message changes to_"receiving software"_.
• Once finished, the message now changes to "verifying software" (signature check), then "installing software" (a message reading _"can't find image_" might flash briefly). The device proceeds now to extract the platform into the filesystem.
• After a small delay, if everything went ok the device should now reboot to the familiar Sansa loading screen (with the five color balls).

ZAP recovery service

Once linux is loaded, on recovery mode the device loads a kernel module called "zaprecover" (/bin/usb_switch_zaprecover), listening on 0781:7482. The driver is interfaced with /usr/bin/zsi_zap, which tells the module how many files to expect and where to store them. On recovery mode, it waits for both the platform file and signature to be sent, in that order (/etc/rc.recover):

/usr/bin/zsi_zap -f /disk/zap/ZAP.tar.gz -f /disk/zap/ZAP.tar.gz.sig

The device won't leave recovery mode unless both files are downloaded correctly and the signature is checked. The data protocol used by the zaprecover service is still uknown, but the source for it is freely readable on the kernel patch.

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"), compiled with GCC v3.4.5. On top of this it uses Busybox and uClibc.

Bootloader

The bootloader is named rrload, which is apparently rrload, again from Cadenux. Strings in the bootloader, and application code, talk of a devkey, which may enable a serial console, rshell etc.

Comparing the actual rrload sourcecode to the binary file available in /bin/removeme/rrload.chopped shows that either the bootloader was either heavily modified or is completely new code. The Connect bootloader accepts only a new image format (srr) instead of the ones supported by rrload (rrbin and Motorolas' srec). It also validates GPG signatures on the firmware files, and has hardware-specific code for HID and power management initialization.

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:

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.

In the /bin/removeme folder we found what seems to be a bootloader flash image, complete with a loading script. The flash image is named rrload.srr.chopped, which is (presumably) the rrload image without the .srr header, as it's dumped directly to flash (cat ./rrload.srr.chopped > /dev/mtd0)

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

Encrypted files

.e files are encrypted with Blowfish (a patent-free symmetric block cipher, details), using a 192-bit key. Both the key and initialization vector for the cipher are obtained from a SHA-256 hash (details) generated from info on the file:

• 4-bytes containing the last subversion number from the file, expressed in base-13 (big-endian). For example, given the file everest_initrd_ext_prod_1.1.1.50239.srr.e, the last subver number is 50239, which is 143191 (0x00022F57) in base-13. If this value isn't present it is set to 0x6E0ACCCB (1846201547).
• 4-bytes containing file size (big-endian). In our example, filesize is 1783824 (0x001B3810).
• The complete filename of the encrypted file. In our example, "everest_initrd_ext_prod_1.1.1.50239.srr.e".

• Key = 0x5928DB44795A317AA37ECE1FAE8EC269FC787E26FFB179ED
• IV = 0x3DCD5A05A346AC40.

SRR file format

SRR files are straight binary files with an attached 16-bytes header detailing loading information, and a 2048-byte footer containing a GPG signature. Most likely, SRR stands for "Signed RRbin"; it includes the same data RRbin does, plus the GPG signature footer. Otherwise, the format is completely different.

Signatures

All the files transferred to the Connect must be signed. Signatures used on all recovery files are 280 bytes long, with the GPG key ID 0xD9F1EC060FA0EFA9 (listed as ""). This is a SHA-1 hash encrypted with RSA using a 2048-bit key. The public key is available on the unencrypted initrd images; currently the private key is unknown. Both the bootoloader and initrd scripts will accept files signed with "" or "ZSIDevKey".

Files transfered via zsi_fw.exe include signatures as a part of the uploaded .SRR file. Platform files need the signature to be sent separately.

 <ZSIProdKey> 

 ZSIDevKey 

 EverestEnsky <EverestEnsky@ensky.com> 

 <key.FF.manufacturing> 

 <key.FF.transfer> 

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

The upload process simply transfers the given .srr file through USB (ID 0781:7481) - if it's encrypted, it's decrypted on the fly. The program first transfers the 16-bytes header and then the rest of the file in 64-bytes blocks.

zsi_fw.exe - Reading from device

zsi_fw.exe allows reading data from the device - it's invoked in this mode during the recovery process to retreive a device ID. The only parameter that matters is the "-r" switch - the rest is ignored.

c:\Archivos de programa\SanDisk\Sansa Connect Device Recovery\cmdline>zsi_fw.exe -r 4000000 kk
ZSI FW load starting.
Open USB Device start
found a device!
Attempting to open \\?\usb#vid_0781&pid_7481#5&29b63fa7&0&2#{184954e0-9128-11db-b606-0800200c9a66}
opened device!
completeDeviceName = (\\?\usb#vid_0781&pid_7481#5&29b63fa7&0&2#{184954e0-9128-11db-b606-0800200c9a66})
Opened successfully.
data completeDeviceName = (\\?\usb#vid_0781&pid_7481#5&29b63fa7&0&2#{184954e0-9128-11db-b606-0800200c9a66}\PIPE01)
Opened successfully.
ID: 00350cde0cddccfbeb92ec830300348c

In this mode the process reads 32 bytes from the device which are dumped as a string. Transfer type is USB control transfer (request type = 0x00000000, value = 0x0000AAAA, index = 0x0000AAAA)

zaprecover.exe - Writing platform to device

zaprecover.exe writes files to the devices' filesystem.

c:\downloads\Sandisk_Sansa_Connect\test>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
ZSI FW load starting.
Found encrypted file: yeverest_zap_ota_rel_ext_prod_1.1.1.50371.tar.gz.e
Found unencrypted file: yeverest_zap_ota_rel_ext_prod_1.1.1.50371.sig
found a device!
Attempting to open \\?\usb#vid_0781&pid_7482#5&29b63fa7&0&2#{088db354-111f-11db-9804-b622a1ef5492}
opened device!
completeDeviceName = (\\?\usb#vid_0781&pid_7482#5&29b63fa7&0&2#{088db354-111f-11db-9804-b622a1ef5492}\PIPE01)
found a device!
Attempting to open \\?\usb#vid_0781&pid_7482#5&29b63fa7&0&2#{088db354-111f-11db-9804-b622a1ef5492}
opened device!
completeDeviceName = (\\?\usb#vid_0781&pid_7482#5&29b63fa7&0&2#{088db354-111f-11db-9804-b622a1ef5492}\PIPE00)
...................................................................................................Done!
.Done!

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.

The device can be crashed by sending a lot of random data to the open port 8088. Under Linux (substitute 192.168.1.128 for your device's IP address):

dd if=/dev/urandom bs=1 count=100000 | nc 192.168.1.128 8088

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.