SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[funman]

Hi,

In my opinion it is legal to disassemble a firmware for research practices, but not redistribute copy/pasted code from reverse engineering. Depending from where you live the situation may be different, hire a lawyer for more details

I have a commented disassembly for ida pro of a m200 firmware, but atomicpunk's one may be more up to date

++

[notlistening]

Hi All,

Just started gathering all the information from the forums into the wiki. If you have any files that require online storage please send me a PM as I am creating a share on MSN skydrive giving us about 5gb to play with. To be given access to add files please MSN or PM me a msn ID.

Any forwarded attatchments by e-mail will be put online when I have the chance. I want to create a one stop share for all resouces. Any feedback or suggestions would be appreciated.

sansadev@hotmail.com

Not setup a file structure yer but will do this as needs be.

https://cid-b1e4fc71fbc55227.skydrive.live.com/home.aspx This is an example of the share.

ATM there is full read rights for everyone and limited access to add/modify.

Tom

[atomikpunk]

Hi again,

Well I'm not too sure about legality of publicly sharing disassembled code and such stuff so I think we should stay on the safe side and keep those for ourselves. But be sure I'd be happy to share our knowledge  with those interested in helping out. Simply contact me in private and we'll talk about this.

I didn't play long yesterday but I think I may have found something vaguely similar to a resemblance of an hold button handling stuff in the firmware On the clip, I think it may look like something similar to pin 3 on port A If that's the case, it would be nice because it would be very simple to read (activate the GPIO module, put the pin in the "input" direction and read it!)

I'll look more closely and try to find something similar in the e200 firmware so that Daniel could safely try it.

[Llorean]

Yes, if you're disassembling the original firmware, it still falls under any restrictions it was distributed under which usually means nobody else can redistribute it.

[saratoga]

You could probably distribute a diff against a dissassembly of the OF however.

[fragilematter]

Hey people!

Funman, you said bridging the nand pins made a 0MB partition detected. Because my arm assembly is especially lacking (general assembly too - I only studied mmix assembly on an emulator this year at university), I tried to find out what the partition might contain on my e250v2.

Since I don't use windows, no 0Mb disk was detected, but I could see that the sansa is connected with lsusb. The connection worked both in ehci mode (usb2.0 - hi-speed) and in uhci mode (usb 1.1 - full speed) and the sansa's leds and screen stayed off.

I was able to dump (using dd) 119MB of data for several times, but each time it ended with a I/O error and the sansa disconnected. The dump is similar to the OF (e200pF.bin, version 3.01.16), with only some bytes missing or blocks displaced.
dd's output is this:

Code: [Select]

dodo@dodo-laptop:/media/data$ sudo dd if=/dev/sdb of=sansa4.bin
dd: reading `/dev/sdb': Input/output error
232160+0 records in
232160+0 records out
118865920 bytes (119 MB) copied, 244.232 s, 487 kB/sIf I tried to run lsusb immediately after, it hanged for a while (about 10 seconds - probably it was still trying to communicate with the sansa) and then displayed the devices - no sansa. Unplugging and repeating the whole short pins + connect usb algorithm made it reconnect every time.

Also, I was edited the dump and wrote it back. dd completed successfully, and the changes where permanent (and, thankfully, my sansa still works):

Code: [Select]

dodo@dodo-laptop:/media/data$ sudo dd if=copy\ of\ sansa4.bin of=/dev/sdb
232160+0 records in
232160+0 records out
118865920 bytes (119 MB) copied, 563.092 s, 211 kB/s
I've uploaded the results of my poking around (images, the dump and utils output) here: http://drop.io/sansahack. So you could try moving data to and from that disk ignoring its size, maybe you get your clip working again

Thanks for the great progresses made so far thread, and I hope we'll see rockbox running on this quite powerful device!

[funman]

Welcome fragilematter

When you look in dmesg output you should see the size of the mass storage device detected, in my case it is 0 so I can not do anything.

I tried writing to the device anyway, but it failed.
I tried reading (limited to 512 bytes maximum), plus the data was never the same each time I read it (with a new processus)..
I quickly noticed it was my own memory I was viewing (I could see Firefox strings), that means I can't not read/write ANYTHING from the device; the recovery mode is then completely useless ...

I'll try download your dump when I have a decent connection, hopefully we can make room for our own code there.

If you can run some tests that'd be great, since you are in the elite of e200v2 owners for having a recovery mode
The e200 have one, the m200 and clip (m300) have none, maybe it was not allocated at factory time, because every SoC has this functionality built in.

Good luck

[fragilematter]

Ouch, I'm sad to hear that 

You mentioned dmesg, and I did a quick check:

Code: [Select]

[12070.741776] usb 3-2: new full speed USB device using uhci_hcd and address 13
[12070.908282] usb 3-2: configuration #1 chosen from 1 choice
[12070.936456] scsi12 : SCSI emulation for USB Mass Storage devices
[ 4822.719062] usb-storage: device found at 13
[ 4822.719067] usb-storage: waiting for device to settle before scanning
[12076.730961] usb-storage: device scan complete
[12076.733961] scsi 12:0:0:0: Direct-Access     UNDEF    storage          1.0  PQ: 0 ANSI: 0
[12076.736952] scsi 12:0:0:1: Direct-Access     UNDEF    storage          1.0  PQ: 0 ANSI: 0
[12076.751909] sd 12:0:0:0: [sdb] 2006528 512-byte hardware sectors (1027 MB)
[12076.754904] sd 12:0:0:0: [sdb] Write Protect is off
[12076.754912] sd 12:0:0:0: [sdb] Mode Sense: 00 00 00 00
[12076.754917] sd 12:0:0:0: [sdb] Assuming drive cache: write through
[12076.765897] sd 12:0:0:0: [sdb] 2006528 512-byte hardware sectors (1027 MB)
[12076.768893] sd 12:0:0:0: [sdb] Write Protect is off
[12076.768901] sd 12:0:0:0: [sdb] Mode Sense: 00 00 00 00
[12076.768905] sd 12:0:0:0: [sdb] Assuming drive cache: write through
[12076.768912]  sdb: unknown partition table
I also see the I/O errors.

Code: [Select]

[14054.706188] end_request: I/O error, dev sdb, sector 232128
[14054.706194] printk: 55 messages suppressed.
[14054.706199] Buffer I/O error on device sdb, logical block 29016
[14054.706210] Buffer I/O error on device sdb, logical block 29017
[14054.706216] Buffer I/O error on device sdb, logical block 29018
[14054.706221] Buffer I/O error on device sdb, logical block 29019
[14054.706227] Buffer I/O error on device sdb, logical block 29020
[14054.706232] Buffer I/O error on device sdb, logical block 29021
[14054.706238] Buffer I/O error on device sdb, logical block 29022
[14054.706243] Buffer I/O error on device sdb, logical block 29023
[14054.706249] Buffer I/O error on device sdb, logical block 29024
[14054.706254] Buffer I/O error on device sdb, logical block 29025
[14054.706339] sd 13:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
[14054.706347] end_request: I/O error, dev sdb, sector 232368
Just guesswork, but it might work if I try unbuffered transfers (although risky) or fire up my old workstation with usb 1.1 and check out what I can dig up.

Best wishes!

[atomikpunk]

Hi guys,

if you read earlier in this thread (if posts are still there), you will see that the e200 is the only model (so far) that we know has this special mode. Daniel_at discovered that mode but I and funman haven't been able to see it with both the m200 series and the clip series so we're guessing that this mode is only available on the e200 series (maybe the fuze?).

However, it is nice to see that someone else has been able to see this mode and that makes one more able to test custom firmwares

[fragilematter]

The

(so far)

part is what I was counting on. It seems implausible that the m series and clips don't have a debricking method if the nand gets messed up, so maybe there is one, we just have to find it 
Anyways, I'm going to piece together an old PC, install some Linux distro and try to get a reliable connection to the sansa. I'll report back my finds.

Edit: I went ahead and tested and I still get only 119MB from the nand, but I'm figuring that it should be enough to dd a OF image in case things go wrong. I'll be around in case you have any code to test 

Cheers guys!

[atomikpunk]

It seems implausible that the m series and clips don't have a debricking method if the nand gets messed up, so maybe there is one, we just have to find it 

Well in fact there is one, we have a plain ol' JTAG port at hand in case something goes wrong... Which is in fact better than anything else for debugging and unbricking. The downside is people need to be able (and willing) to open their device, solder some wires, wire a JTAG to parallel port adapter and hack a bit.

But I doubt sandisk made effort to implement something else for the cost of those devices. In case something goes wrong, they replace the device and throw the defunct one on ebay

I have something I'd like to test on the e200 series. I think that GPIO pin A3 may be the hold button. you can try that if you are comfortable with arm assembly and disassembly tools, or I can build a test firmware if you prefer. You and/or Daniel could then test it on your e200.

[fragilematter]

Well, basically I should configure the pin for input at base(0xC80B0000?!)+4, read it and load the read value into a register, compare it with what we are looking for and branch if equal to the code that should indicate the successful read.

Theoretically it shouldn't be too hard, practically I don't have any experience and you haven't said if you want the code to run before the jump to the OF or after the OF initializes everything. Drop me a test.s (or whatever code you want run and where you want it) and I'll test asap!

[philibuster]

Clip is on woot right now for 19.99+5 shipping. Granted, it's the clip so it has the small ram, but hey, it works for hacking, right?

[funman]

fragilematter I checked the dump of your recovery partition and it contains the firmware, although it is a bit different:

After ~32MB the firmware is not validated by my tool, it might be because the real disk begin.
Which version of the firmware are you using? Is it available for download on the Sansa forums or anythingbutipod ?
Note: from ~17MB to ~32MB I see 0xdeadbeef padding, maybe we can insert code in this place ?

Can you modify the test.S / mkamsboot.c to use this offset instead of the end of the firmware block ?
You can calculate any offset in this area and modify mkamsboot.c to use your offset instead of reading the offset from the firmware file.

Also, the byte at offset 0x1FF is 0x46, on all other firmwares it is 0xFF, can you overwrite this byte to any value, and the corresponding byte at 0x3FF to the same value and see if the OF still boots ?

[fragilematter]

Hey funman, thanks for taking the time to have a look at that stuff.
The firmware is e200pF.bin version 3.01.16, so it's the European version with FM - http://daniel.haxx.se/sansa/v2/e200/SansaE200_plusF3_01_16.7z. The last part of the dump (I haven't checked where it starts exactly) does appear to contain the music database, with file paths and tags, so it should be on the real disk.

Since it's midnight here (GMT+2), I'll work on it tomorrow as soon as I get the time. I'll try changing the bytes at 0x1FF and 0x3FF first and check the effects, than I'll go about modding mkamsboot

So, I'll check back tomorrow, hopefully with some results.