Rockbox Development > New Ports
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:
--- Quote from: funman on July 31, 2008, 07:43:04 AM ---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.
--- End quote ---
OK, but will this work on other players but the clip? Well, let's see if it even works for the clip :)
--- Quote from: funman on July 31, 2008, 07:43:04 AM ---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.
--- End quote ---
Nice idea, looking forward to see your results!
--- Quote from: funman on July 31, 2008, 07:43:04 AM ---Did you check utils/AMS/hacking in the rockbox subversion repo ?
--- End quote ---
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:
--- Quote from: tobi-lu on July 31, 2008, 08:41:08 AM ---
--- Quote from: funman on July 31, 2008, 07:43:04 AM ---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.
--- End quote ---
OK, but will this work on other players but the clip? Well, let's see if it even works for the clip :)
--- End quote ---
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.
--- Quote from: tobi-lu on July 31, 2008, 08:41:08 AM ---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) ^^
--- End quote ---
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...
--- Quote from: funman on July 31, 2008, 07:43:04 AM ---So far we can address all the firmware file, not only the firmware block !!
--- End quote ---
That's great news! Fortunately, you didn't brick your player ;D
--- Quote from: funman on July 31, 2008, 07:43:04 AM ---Maybe I could check that the code is the one I wanted before jumping (or branching if you prefer) with cmp ..
--- End quote ---
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:
--- Quote from: funman ---Don't forget to swap the bytes when you read them from xxd !
--- End quote ---
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"?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version