Rockbox Development > New Ports
Sandisk Clip Sport
wzdd:
I'd appreciate your comments! The decrypted thing is an sqlite database (as I'm sure you know). There is a table in there named FileTable, which contains a file named FWDec.al. This is a mips32r2 binary which I'm pretty confident does decryption of the firmware. In that file, at file offset 0xb1c, begins a function which references a section of RODATA in order to decrypt. The basic routine looks like this (transcribed):
--- Code: ---int func_b1c_c(uint8_t *enc)
{
int i, chunk;
uint8_t scratch[32];
// Select a decryption key between 0 and 31
uint8_t key_idx = enc[998] & 0x1f;
// Load the 32-byte key
uint8_t *key = &rodatakey[key_idx * 32];
// Calculate the first 20 bytes of a key... # b4c
for (i = 0; i < 20; i++) {
uint8_t xored = enc[1000 + i] ^ key[i];
enc[1000 + i] = xored;
scratch[i] = xored;
}
// And then copy the first 20 bytes of that calculated key into the rest of the key. # b80
for (i = 20; i < 32; i++) {
scratch[i] = scratch[i - 20];
}
// Use the calculated key to descramble the rest of the block. #bac
for (chunk = 0; chunk < 31; chunk++) {
for (i = 0; i < 32; i++) {
enc[(chunk * 32) + i] ^= (scratch[i] ^ rodatakey[(chunk * 32) + i]);
}
}
return func_abc_c(enc - 1, enc + 1000, 1001);
}
--- End code ---
The input to this is a chunk of the firmware. The location varies with the firmware but it's always 16-byte aligned.
However, in both the firmware files I've examined so far (the Sweetpea one, the Github one), the portion of text named "rodatakey" is filled with zeroes. Consequently the firmware upgrade routine fails. So three options: 1) I have decompiled this incorrectly and the key is somewhere else (hard to say where, because all the bytes in FWDec.al are accounted for -- most of it is code, and there is a bit of data corresponding to the tables rockbox already contains). 2) Something funky happens at firmware install time (maybe this thing is modified in place?). 3. Something funky happens at runtime (same idea).
wodz:
--- Quote from: wzdd on June 10, 2015, 02:24:00 PM ---... also, the US212A_DEMO.fw file from the Github linked upthread actually works and produces a usable media player -- or at least it would if I could read Chinese. EDIT: It's somewhat easy to navigate to the settings menu and change the language to English, after which this firmware is actually quite a bit nicer than Sandisk's, but the top of the display is cut off.
--- End quote ---
Does it actually play music with this firmware? If so I'd say memmap derived from github linker scripts is correct which in turn would mean rockbox port is not feasible.
wzdd:
I played an AAC with it and recognisable sound came out (actually it was distorted, but it sounded like a codec thing: it was the right speed, but the balance between different frequencies of the music was all wrong). So I'll go with "yes", though if you'd like I can do more extensive testing tomorrow.
Sucks to hear re RockBox. I'm still interested in reverse engineering the thing, maybe via USB capture from that firmware uploader. (Has anyone reverse engineered the protocol for this already?) Slightly less interested now that it seems that ADFU mode is part of the uploaded firmware, so I'm likely to brick my device (though maybe I can just not upload that part).
pamaury:
Actually the ADFU mode is not part of the device itself: the hardware has a hardware rescue mode accessible by shorting the NAND pins, but it also has a software recovery mode which uses the same code has the hardware one, except that it display a picture on the screen. At least those are my findings from playing with the sport.
wodz:
pamaury: Are you able to upload sw adfu when the player is in hw adfu mode? I mean short nand pins and upload image extracted from recovery image linked above?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version