Rockbox Development > New Ports

Sandisk Sansa Connect

<< < (7/9) > >>

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:

--- Quote from: Looks_Confused on January 06, 2010, 11:50:11 AM ---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. 

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page