Sandisk Sansa Connect

[Looks_Confused]

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

[Lysander]

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.

[Llorean]

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.

[Lysander]

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.

[Lysander]

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.

[desowin]

I have posted patch adding initial Sandisk Sansa Connect support - 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.

[AlexP]

Excellent work, I might dig out the soldering iron if I'm bored this weekend

[desowin]

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.

[AlexP]

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.

[desowin]

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).

[wodz]

Maybe this is stupid question but why don't you run rockbox as an app? With native rb you loose network connectivity right?

[desowin]

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.

[desowin]

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. Rockbox bootloader can be installed using only Open-Source tools (no need to rely on any official firmware packages).

[unilock]

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, 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 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, 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??