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

[sucitrams]

dd says, that there is no space left. dmesg shows 1024MB.

[fragilematter]

Maybe it's somehow connected to the fact that I can't read more than 113.4MB from my sansa. Either that or you've damaged your nand/usb controller or something else from your player.

Perhaps you could try this (it's not directly related but it might help): sometimes the sansa lags when connected to the usb, and linux's usb stack keeps waiting for it. I found that it helps running a lsusb, it somehow makes the player to respond and connect properly to the usb.

[funman]

sucitrams you still have hope: the recovery mode is present.

leave it for one day or two, and try again to put the OF
Now at least we know that we must only use the recovery mode to put safe firmwares

In the meantime I attach a diff for mkamsboot.c which will keep the total file size, while shifting the content after the firmware block.

The firmware produced passes my various checks at being a normal firmware, but only testing will confirm if it's usable or not.

Note: the patch could be extended to reserve maximum size (128kB firmware block) and check for bootloader size, I will do that if this first patch works

[atomikpunk]

Well I don't want to look like giving lessons or anything because I'm as curious as you guys, but I thought we would discuss the modified firmware before flashing it to a device :'(

Did you add a dummy 0x200 bytes and update the firmware header? If not, then the firmware can't do anything good... It looks for the library blocks 0x200 bytes earlier each time, which happen to be in the DEADBEEF area most of the time (if not all). So the firmware looks at a wrong header, which gives it wrong addresses where to load the data to, wrong addresses of executable routines, wrong addresses of variables, etc. So in short, the CPU writes about anything anywhere, which results in crashed player.

And if fact, I don't know if my memory fails me but I think I saw absolute routine addresses at some places in the firmware, so anything moved and bam...

However, if you still can load up the "recovery mode" with a firmware like this, it definitely confirms that this mode's code is located somewhere else than in the firmware and is good news. So I guess that with some work, the device should be unbrickable.

[fragilematter]

I quickly tested the patched mkamsboot.c

The output was this:

Code: [Select]

gcc -o amsinfo -W -Wall amsinfo.c
gcc -o mkamsboot -W -Wall mkamsboot.c
arm-elf-as -o test.o test.S
test.S: Assembler messages:
test.S:0: Warning: end of file not at end of a line; newline inserted
arm-elf-ld -e 0 -o test.elf test.o
arm-elf-objcopy -O binary test.elf test.bin
./mkamsboot e200pF.bin test.bin patched.bin
Original firmware size - 0x0001d81c
Padded firmware size - 0x0001da00
	Shifted by 1 blocks
Bootloader size - 0x00000074
New padded size - 0x0001da00
original firmware entry point: 0x00000128
New entry point: 0x0001d820

Flashed successfully, all the functionality is there (I didn't to a thorough test, but it seems OK) and the inserted test.s code also works.

I think sucitrams tried to directly dd a firmware update image to the nand, but, as I've shown earlier, the firmware update expands the firmware to 30MB, or at least it appears that way on my nand dumps.

[funman]

great !!!

Can you test this one which will allocate the biggest size possible (0x100 * 0x200 = 128KB) for the firmware block ?

If it's fine I'll test it on the Clip and ask someone to commit the patch

EDIT: attached corrected patch

[atomikpunk]

Hey oh one second, the biggest possible should be 0xFF since the firmware header allocates 1 byte for the "firmware size" field...

[fragilematter]

The output is this:

Code: [Select]

gcc -o amsinfo -W -Wall amsinfo.c
gcc -o mkamsboot -W -Wall mkamsboot.c
arm-elf-as -o test.o test.S
test.S: Assembler messages:
test.S:0: Warning: end of file not at end of a line; newline inserted
arm-elf-ld -e 0 -o test.elf test.o
arm-elf-objcopy -O binary test.elf test.bin
./mkamsboot e200pF.bin test.bin patched.bin
Original firmware size - 0x0001d81c
Padded firmware size - 0x00020000
New firmware size - 0x00020000
Bootloader size - 0x00000074
New padded size - 0x00020000
original firmware entry point: 0x00000128
New entry point: 0x0001d820

But, unfortunately, it still needs some work. The inserted code works ok, but the firmware freezes after completing the sansa logo animation.
It's almost midnight so I won't try to recover it now, it's time for me to get some sleep.

I'll check back tomorrow as soon as I get back home. Cheers!

atomikpunk: thanks for the try, but I was quicker
OTOH, holding the power button for a few seconds to power the e200 off works  even if the firmware is messed up.

[funman]

Hey oh one second, the biggest possible should be 0xFF since the firmware header allocates 1 byte for the "firmware size" field...

I would think it is rather 1 word, but it should be checked indeed.

Try using 0xFF as the new size instead of 0x100 (3 occurences) in the last patch,
or increase the shift value in the first patch.

Note: this should be tried on several firmware versions to ensure it works flawlessly.

fragilematter and sucitrams thanks for testing

EDIT: the patch was wrong, it wouldn't shift the library blocks (memmove() case not made, as show fragilematter's output). I updated it, can you retest?

[atomikpunk]

Maybe you are right, I did look back at the wiki to refresh my memory (no pun intended) and saw that this "multiplier" is aligned on a 4 bytes border, so it could indeed be a dword. But again, I'd have a look at the OF to see if there are hardcoded addresses that could be messed up with a displacement.

Another interesting test would be to know where the ROM is located in memory and if we can access library blocks directly from the at-boot CPU memory map or if we need to configure something before being able to do so...

Anyhow, that's it for tonight

[fragilematter]

I restored the sansa (worked perfectly), then patched mkamsboot and tested. This is the output:

Code: [Select]

gcc -o amsinfo -W -Wall amsinfo.c
gcc -o mkamsboot -W -Wall mkamsboot.c
arm-elf-as -o test.o test.S
test.S: Assembler messages:
test.S:0: Warning: end of file not at end of a line; newline inserted
arm-elf-ld -e 0 -o test.elf test.o
arm-elf-objcopy -O binary test.elf test.bin
./mkamsboot e200pF.bin test.bin patched.bin
Original firmware size - 0x0001d81c
Padded firmware size - 0x0001da00
New firmware size - 0x00020000
Bootloader size - 0x00000074
New padded size - 0x00020000
Calling memmove(buf + 0x00020400,buf + 0x0001de00,0x00edfc00)
original firmware entry point: 0x00000128
New entry point: 0x0001d820

The firmware starts OK, our code works, but I can't see any text. Maybe the string addresses are hardcoded. I'll drop some screenshots on http://drop.io/sansahack as soon as i copy them from the camera.

Edit: after playing one song there probably was a write at a wrong address on the nand, because now I get corrupted graphics on the boot logo and then it locks up. After a few more starts and forced shutdowns it just lights the leds and the display illumination...

[sucitrams]

@fragilematter:

Thats my problem too. I think we can forget it. 

EDIT: Now if I read out my NAND wit dd, dd stops at 14MB because of "readout errors". But I opened the firmware that was on the flash with a hex editor.
From 00000000 - 004FFEC7 everything is "00". But then the firmware begins.
I think my NAND is damaged, because many times I tried to delete the corrupted Firmware, /dev/zero, but its still there.

[fragilematter]

Okay, I tried to restore it with the small image and it was writing everything correctly, but after unplugging and connecting it back to the usb it went into the recovery mode again. So I dd-ed the big (119MB) image I dumped the first time, and that solved the problem.

I think it wasn't booting because the fat was probably damaged, but I can't test my theory because I didn't think of making a dump of the bad firmware from the nand. And I wouldn't like to brick it again just to test that theory.

Guys, anytime you've got something else to test, I'm (and my sansa) still up for the job.

Sucitrams: I don't know what happened exactly to your e200, but I managed to restore mine 3 times by now, and I didn't encounter any write errors in the recovery mode. Don't try to zero the nand, I don't think that would be a very wise idea. Try to get to a usb 1.1 machine and dd the big image nicely. I'll look for a place to upload it and give you the link in a pm. I hope you'll be able to restore it

[andva]

Try to get to a usb 1.1 machine and dd the big image nicely.

For the record, you can force Linux to use all devices in USB 1.1 mode by rmmod'ing the ehci-hcd module, so there is no need to hunt for an ancient machine.

Great job, guys!

[gevaerts]

For the record, you can force Linux to use all devices in USB 1.1 mode by rmmod'ing the ehci-hcd module, so there is no need to hunt for an ancient machine.

You can do something similar on windows : disable the EHCI controller(s) in the device manager