Sandisk Clip Sport

[pamaury]

Hi,
I'm posting this for a reference. I bought the Sport player and tried to use the JTAG pins without any luck so far. At the moment, the player doesn't seem to respond to the jtag commands at all. Maybe it is disabled or my soldering is wrong or my wiring is bad, there could be many problems involved. I noticed a TEST_MODE pin too, I thought it could switch pins between JTAG and other functions, I tried to pull it low (it's pulled high by default) but it didn't seem to change anything. I also tried to short couple NAND pins on boot and it appears that the software recovery mode is the same as the hardware recovery mode, except for the displayed message on the screen. At least they have the same USB interface. So at this point, I'm quite stuck. The remaining option is to desolder the NAND and read its content but I don't have the soldering skills/tools to do that. Or find out why JTAG doesn't work.

[shmerl]

Fact is, physical sdcards in mobile need to die. The next thing that needs to die is emulated sdcard support in Android for legacy support. This, in time, will happen.

Thanks, no thanks. sdcards are very useful to be able to boot alternative OS from some device without wiping the original. This dummifcation of mobile devices is beyond annoying. Luckily there is enough demand for such thing, that devices with more hackable options will still be released (Jolla handset and tablet for example).

[wzdd]

Has anybody got a datasheet for the atj2127 processor, or indeed any official or unofficial technical documentation at all?

[wodz]

There is also this: https://github.com/Suber/PD196_ATJ2127. The linker scripts are inline with what action's web page claims about this chip.

[wzdd]

Quick update (but nothing useful yet) -- the FWDec.al file from that PD196 repo seems quite likely, but running it over a firmware image (after fixing up code and data references) produces an error.  It seems like there is a reference to a key in RODATA which is all zeroes in this image. This is rather similar behaviour to something I found about previous firmwares in this chat log: http://www.rockbox.org/irc/log-20131107

Hopefully next week I will be able to dump the NAND flash, which is presumably descrambled.

[pamaury]

@wzdd: if you can dump the NAND flash, that would be very interesting to see if we can disassemble the code and figure out the encryption process for firmware image. Although I still think the port cannot be done because of the very amount of memory.

[TPMJB]

Hey .

I bought sport. Any chance to get rockbox working on it? I'm not a dev and I have no idea bout programming.
Thx in advance!

It doesn't look like there's currently anything working for it. I hope something comes out soon, as I've #REKT my fourth clip zip in a row by using it as an MP3 player (I don't understand why they don't make these sweat proof)

[wzdd]

Okay, some interesting progress. I discovered that this player is the same as the SweetPea 3:

http://www.sweetpeatoyco.com/index.php?route=information/knowledgebase&article=33

On that page there is a) an UPGRADE.HEX file (encrypted), but also b) an upgrade.fw file, which rockbox's atjboottool can decrypt. That page also links to a Windows program which you can use to flash the fw file. I flashed the file to my Clip Sport: to do that I had to boot the Sport in ADFU mode, which I got into by holding the volume-up button while powering on.

I used the Windows tool to flash the firmware, and it worked: the device rebooted and now shows up as a USB disk called "SWEETPEA". Unfortunately the display and buttons are different, so I can't figure out how to use my device. I wouldn't recommend doing it yourself.

However we now have a tool which can flash these .fw files to the Clip Sport in ADFU mode, plus a decrypted firmware. So in theory we should be able to write something which creates .fw files, i.e. does the opposite of atjboottool. Then we will be able to flash unencrypted firmware to the device.

Also, the unencrypted firmware should in theory have the decryption tables required for the UPGRADE.HEX file, so some analysis should allow us to create UPGRADE.HEX files.

[wzdd]

Ah, for future reference, to get the Sweetpea-flashed Clip Sport back into ADFU mode, hold down power until the device turns off, then hold down menu, then release power and release menu when the device shows up in the ADFU installer. EDIT: To do the same to the Github-demo-flashed firmware, set the language to English, then enable firmware updates from the tools menu: by default you can't get the firmware into ADFU mode, so you have to flash a .HEX at this point.

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

[pamaury]

Hey,
that sound like very interesting news, great finding I'll try to have a look at the decrypted image, see if I can find the missing decryption part.

[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: [Select]

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);
}

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]

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

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?