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

[tobi-lu]

Hi people!

I just read through this whole thread, the wiki page and the haxx page and now I also want to try to contribute to this.
My player is a e250v2. Right now, I don't know very much about firmware reverse engineering, but I'm really interested and willing to learn.


funman, I just tried your tool on the file e200pa.bin (md5sum 12563ad71b25a1034cf2092d1e0218c4, from http://daniel.haxx.se/sansa/v2/e200/e200v203.01.16a.zip). The assertion on line 131 fails, because at 0x3C the file contains 00 50 00 00. It's the same in the 2nd block, at 0x23C there's also 00 50 00 00.

[edit]
argh, sorry, I didn't read the wiki page well enough.
I have attached a quick fix for the tool. Perhaps it could be done better, but it works.
[/edit]


cu
Tobi

[funman]

Hi tobi,

thanks for interesting into this beast
It's the first time I do this also and I don't know ARM assembly, but like everything that can be learned ...

atomikpunk gathered a lot of info already, but more eyes on the firmware are welcome!
The reverse engineering is quite advanced but a few things are missing like access to the buttons.
Once this is done we can insert code which will run only if a button is pressed to avoid bricking the device.

The problem is that in the firmware there is a few room left, but yesterday we discussed with atomik_punk about that:
Some firmwares (like the clip) present padding blocks in this way:
The first DWORD is 0xdeadbeef and the following 0x1FC bytes are junk so we could probably insert code in there rather at the end of the firmware block.

I think I will test that tonight: put a magic string in a padding block and browse memory to find this string: if found, return immediately to the original firmware code, else sleep for 10 seconds or so.
<edit>
I couldn't wait for the night I tested it right away
So far we can address all the firmware file, not only the firmware block !!
Next step is put a big piece of code in a padding block and jump to it, then come back, but I feel reluctant ..
Maybe I could check that the code is the one I wanted before jumping (or branching if you prefer) with cmp ..
I attach the test.S I used with utils/AMS/hacking in rockbox's svn repository: of course you will have to edit the magic value (your firmware should be the same size). Don't forget to swap the bytes when you read them from xxd !
</edit>


Did you check utils/AMS/hacking in the rockbox subversion repo ?

If you want to discuss over msn/jabber send me your address in PM or /query funman on freenode

About your firmware, this is true that some have 0x00500000 at 0x3c (and +0x200 because the 2 first blocks are identical except for their first byte).

I just found such a firmware yesterday and corrected my code for that. I also added a check for the whole firmware checksum (the last DWORD of the file)

I have a fuze firmware which shows these bytes, however I have another fuze firmware which doesn't show them ... strange

I attach an updated version of my prog with a Makefile, so you can run "make test" and it will check the assertions against all files in the directory which ends in bin or BIN (like sansa firmwares..)

thanks, see you

[tobi-lu]

The problem is that in the firmware there is a few room left, but yesterday we discussed with atomik_punk about that:
Some firmwares (like the clip) present padding blocks in this way:
The first DWORD is 0xdeadbeef and the following 0x1FC bytes are junk so we could probably insert code in there rather at the end of the firmware block.

OK, but will this work on other players but the clip? Well, let's see if it even works for the clip

I think I will test that tonight: put a magic string in a padding block and browse memory to find this string: if found, return immediately to the original firmware code, else sleep for 10 seconds or so.

Nice idea, looking forward to see your results!

Did you check utils/AMS/hacking in the rockbox subversion repo ?

Not yet, but I read about it. Have to look at it.


As for chatting: Where do you come from? You could update your profile with your local time (if it's not correct now) so it's easier to communicate
But I don't have much time to spend on the sansas until saturday ~4pm (UTC+2h) ^^

cu
Tobi


(edit: typos)

[funman]

The problem is that in the firmware there is a few room left, but yesterday we discussed with atomik_punk about that:
Some firmwares (like the clip) present padding blocks in this way:
The first DWORD is 0xdeadbeef and the following 0x1FC bytes are junk so we could probably insert code in there rather at the end of the firmware block.

OK, but will this work on other players but the clip? Well, let's see if it even works for the clip

Well we have to try ^^
I suppose all firmwares will skip blocks which begin with 0xdeadbeef but on some firmwares they were bored enough to fill all the block with this pattern.

As for chatting: Where do you come from? You could update your profile with your local time (if it's not correct now) so it's easier to communicate
But I don't have much time to spend on the sansas until saturday ~4pm (UTC+2h) ^^

Ok done, I'm UTC+2 also
I'm from France but atm I work in the Netherlands (where I got my sansa Clip 1GB FM)

See you

[tobi-lu]

Aah I didn't see your edit till now ^^ I've been watching here all the time for you to post some news...

So far we can address all the firmware file, not only the firmware block !!

That's great news! Fortunately, you didn't brick your player

Maybe I could check that the code is the one I wanted before jumping (or branching if you prefer) with cmp ..

Well, if it is possible, why not... you don't want to produce a paperweight, do you? So being careful is never wrong.


Thanks for the piece of code (test.txt).

Bye
Tobi

//edit:
Could you please explain this:

Don't forget to swap the bytes when you read them from xxd !

In your code, you use MAGICVAL = 0xcfcfcc92. What's the original value that you put inside the firmware file? (Why are there swapped bytes at all?)
And what do you mean by "xxd"?

[funman]

Aah I didn't see your edit till now ^^ I've been watching here all the time for you to post some news

So far we can address all the firmware file, not only the firmware block !!

That's great news!

Well it needs double checking, because I tried putting some code to be executed in a padding block, and my checks failed.

The whole sleep loop is 5 instructions = 5 * 32 bits, so I decided to check each of the 5 words (which I knew) before branching to that offset, i.e.

if(instruction1==read_instruction1 && instruction2==read_instriction2 ...) jump_to_sleep();
boot_now();

but the clip was always booting immediately so it was not reading the correct code ...

I verified that I was reading at the file offset - 0x400 (firmware header) so I don't know what happened.

So I wanted to verify the 1st word: 0xdeadbeef, to be sure I was in the padding block.

Maybe I could check that the code is the one I wanted before jumping (or branching if you prefer) with cmp ..

Well, if it is possible, why not... you don't want to brick your player, do you? So being careful is never wrong.

But I recompiled/upgraded too quickly and I miss something ....

the code ran was:

Code: [Select]


ldr r3, =0x30400
ldr r2, [r3] /* load the word we are checking */
ldr r1, =0x38100000 /* verify that it's a pointer to the OF (0x138) */
cmp r1,r2

beq boot1
### missing r1 assignement ### damn !!
b boot

boot1:
mov r1,#0x500000 /* ~ 5 seconds */
b boot

boot: /* sleep loop */
subs r1, r1, #1
bne boot

ldr pc, original_entry #jump to OF
I added the "b boot" because I was tired waiting for my sansa to boot but I forgot to fill r1 which holds the number of seconds to wait !!

It could be any 32 bits value, and according to echo `$((0xffffffff/0x500000*5))` I can wait for an hour or more before seeing my clip lcd screen enlight ...
I hope there isn't something like a watchdog timer which resets the device, will see tomorrow if it's bricked or not (else I will have to explore my room for the ticket).
<edit>It works !! It took more than one hour to boot but I got my Clip back and could put the original firmware on it, the adventure continue</edit>


Also I tried to not increase the firmware block size (there is code in mkasmboot to handle that but since all the firmware files I have seen have the same size, I prefer not to try...) so I had to comment some code

If you want to experiment, be VERY careful because there is no easy way to recover your sansa (except with JTAG maybe..).

Something I looked into was to try to get some random bit and conditionally branch on OF when it's 1.
That way if your code is broken, you have 1 chance out of 2 to boot the OF and update it.

I tried reading from the registers but my tests always gave the same value (maybe there is some code ran before the sansa firmware which initializes them, or they are initialized when the hardware is powered, I don't know)

[tobi-lu]

Hi!

I just don't manage to get a successful cmp, my e250 always waits 5secs before starting.

This is what i have done:

• Take the unmodified firmware file e200pa.bin (from http://daniel.haxx.se/sansa/v2/e200/e200v203.01.16a.zip)
• Open it in a hex editor
• Go to 4 bytes before the last checksum: address 0xEFFFF8 in firmware file
• Substract 0x400 from this value --> 0xEFFBF8
• Write this into test.S: .equ    MAGICOFF,    0x00effbf8
• Edit firmware file at address 0xEFFFF8 to say 74 6F 62 69 (the value i've chosen)
• Now here comes the problem: what should I write into MAGICVAL? According to what you told me in jabber, it should be 0xf6479626. But that doesn't work, I have to wait 5 sec...

Can you tell me ehat I am doing wrong?

Thanks
Tobi

[daniel_at]

Hey guys!

Cool to see some FW-hackers starting to get it started here. I'am not that used to ARM's and that stuff. But if someone wants to try a live session via IM with me, I am able to try various stuff on my E280 - because I can reliable unbrick it, if something went wrong. (As described in my earlier posts)
So testing new code could be faster and less nerve-racking.

My timezone is MESZ (UTC+2) and im quite often online... just conntact me via PM, than we can exchange IM-addresses (prefered Jabber).

Daniel

[funman]

• Edit firmware file at address 0xEFFFF8 to say 74 6F 62 69 (the value i've chosen)
• Now here comes the problem: what should I write into MAGICVAL? According to what you told me in jabber, it should be 0xf6479626. But that doesn't work, I have to wait 5 sec...

The ARM CPU is little endian, so when you read a value from memory, the bytes are read in a
"reverse order" : least significant byte first.

When you edit the file with an hex editor your will see 74 6F 62 69
But the value (MAGICVAL) is 69 62 6F 74

Tell us if that works

[tobi-lu]

Well, I've tried it, and also tried to put the magic value to another position in the file...
But it didn't work

daniel_at, can you please try this on your e280? Should be the same as with my e250, but who knows ^^
And have you seen my pm? If it didn't arrive for some reason, you can also find my jabber id in my profile (under YIM).


bye
Tobi


//edit:
I've been experimenting quite a lot now... My result is that it's NOT possible to access anything outside the firmware block using this method. The very last thing I can access is the 00 00 00 00 at 0x1DE18, which is right at the beginning of the first library.
I think the library starts exactly at 0x1de1c, and not at 0x1de00 as calculated by 0x400 + 0x200 * firmware_size_multiplier.

[funman]

I've been experimenting quite a lot now... My result is that it's NOT possible to access anything outside the firmware block using this method. The very last thing I can access is the 00 00 00 00 at 0x1DE18, which is right at the beginning of the first library.
I think the library starts exactly at 0x1de1c, and not at 0x1de00 as calculated by 0x400 + 0x200 * firmware_size_multiplier.

Maybe it is possible on the CLIP and not on other models, I will test again this evening to be sure I didn't misinterpret the results.

I don't understand well what you mean : from 0x1de00 to 0x1de18 (well - 0x400) you can see:
0x38220100 0x00000d30 0x70220e30 .. etc ?

[tobi-lu]

I don't understand well what you mean : from 0x1de00 to 0x1de18 (well - 0x400) you can see:
0x38220100 0x00000d30 0x70220e30 .. etc ?

I came to the conclusion that 0x1de1b still belongs to the firmware, because when i used the 00 00 00 00 as magicval and 0x1de18 - 0x400 = 0x1da18 as magicoff, i didn't have to wait 5sec. When i used the next word, i had to wait, so it couldn't be accessed.

But I could be wrong here...

[atomikpunk]

Hi,

great job guys

Maybe it would be wise that everyone share which firmware version their working on so to be clear...

Tobi-lu, did you try to read those just before 0x1de18? Something like 0x1de14?

[funman]

Tobi that value could also be 0x00000000 for other reasons
Try checking 3 or more consecutive values to be sure

I am using only the CLIP 01.01.29 firmware for now, I pasted the link to download it on anythingbutipod.

EDIT:
I tried again reading past the firmware block and my tests failed, I tried with the .S file I posted here so I think I was very tired and imagined that the test had succeeded :/

NEWS:
atomic_punk has likely found the function for scanning keypad:
The function is at 0x32B4 (+0x400) on the m200 firmware of atomik_punk
A very similar function is at 0x35CC (+0x400) on my clip firmware

Unfortunately we couldn't find one on the e200 firmware of daniel_at, this is sad because he has the hability to recover from bricked state

See you soon for updates

EDIT2:
As discussed with the hackers, it would be wise to execute our code after some stuff has been initialized.

EDIT3: /!\ DO NOT USE /!\ I HAVE BRICKED MY CLIP /!\

The firmware works this way currently:
0x0 LDR PC, somewhere
0xsomewhere LDR PC, do_stuff
0xdo_stuff
....
0xOFFSET1 BL main


The current mkamsboot.c will replace the code at 0x0 by LDR PC, OUR_CODE, and make the last instruction of OUR_CODE be LDR PC, somewhere, so it branches back to the OF.

I modified mkamsboot.c to do this:
at OFFSET1 it becomes LDR PC, OUR_CODE
and the last instruction of OUR_CODE be BL main

WARNING WARNING
The code executed at theorical offset 0xdo_stuff has hardcoded absolute offsets to the end of firmware, so the code you put in here will be modified before it is ran.
It's an efficient way to brick your Sansa, just like I did


I attach the patch to utils/AMS/hacking/mkamsboot.c
EDIT: use a correct mask when writing the relative offset of BL instruction.

Note: this is experimental code (and NOT TESTED yet on the Sansa), it assumes that there is a BL instruction just after our 1st jump, and wil read all the firmware to find one.

Your test.S file must begin with an instruction, not with .word 0.


Also I took the conversion code to translate instructions in utils/disassembler/arm/disasm_arm.c but I may have forgotten something, so double check with a disassembler that your new firmware does what you want !!

Now to you hackers to write some wise code to be executed

[tobi-lu]

OK I just read this a few times, now I think I understand what you have done with mkamsboot.

But what do you mean by this:

Also I took the conversion code to translate instructions in utils/disassembler/arm/disasm_arm.c

What's the purpose of disasm_arm.c? And what did you use it for?

As discussed with the hackers, it would be wise to execute our code after some stuff has been initialized.

Do you think you can access other parts of the firmware file then? Or access the buttons easier?
Hm, I'd like to understand it, could someone perhaps send me a chatlog?


Thanks
Tobi