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.