Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
atomikpunk:
Hi funman and welcome to the magical world of v2 disassembly ;D
Great work up to now, but maybe some hints will get you back on track with the clip disassembly ;)
1. The firmware header is effectively 0x400 bytes long and there are 2 (almost identical) copies of the same header at 0x000 and 0x200.
2. At 0x400, there is the firmware block, this is where the sansa boots on power-up/reset. Take care however, because that block length is specified in the firmware header at 0x00C and can be calculated using firmware_length = 0x200 * firmware_size_multiplier. I am sorry however, I made a mistake in the table, you are right that the library blocks aren't at 0x400 + index*0x1e000 but at 0x400 + firmware_length + index*0x1e000. And that is for the M200, I know this value (0x1e000) is different for the E200, so it could be different for the clip too.
3. Take care that in my descriptions, I almost always remove the 0x400 byte long header from the file so addresses will probably be off by 0x400. This however really helps with the firmware analysis because the firmware is based at 0x00000000 and with the 0x400 offset, I'd need to do relative offsets all the time...
4. The firmware I used is the one right here.
Yeah sure it would be great if you could attach your little soft, I'd have a look.
If you are interested in cooperation, we could get in touch on irc/jabber/whatever. Send me your instant messenger info in PM so we could talk more easily.
(BTW, if wiki admins are reading this, please fix the directedgraphplugin, that would be nice :))
funman:
The mosquitoes don't want me to sleep so I found some weird stuff ^^
1. Ok
2. This is the first bytes of my firmware block:
0000400: 58f0 9fe5 58f0 9fe5 58f0 9fe5 58f0 9fe5 X...X...X...X...
I think in previous posts you describe this block as containing code this way:
The 16 first bytes would contain branching to 4 functions.
However it's all the same: 0x58f09fe5 so that doesn't look like it's the case here.
I should get a assembler / disassembler for the AMS cpu ...
About the block multiplier, I found that all library blocks don't have the same size for me...
I use this theory : all unknown blocks just after the library blocks in my previous message are in fact
part of the library block and represent padding. I just substract the offsets between the next block
and the current block to get their size:
The first 8 blocks are 0x28000 bytes long
The 13 following blocks are 0x14000 bytes long (2 times less)
The last library block seems to be 0x3C000 bytes (it fits in 0x14000 but 320 blocks (0x28000 bytes) follow it...
Some of the first 8 blocks would fit in 0x14000 bytes also but are then followed by 160 unknown blocks
... (0x14000bytes)
So the size is always a multiple of 0x14000, but for the 2 other firmwares I have it
differs: it's a multiple of 128*0x200 (0x10000) or 240*0x200 (0x1e000)
I will check against the 2 other firmwares if the library block sizes are always identical or can vary also.
I tried to relate this variable block size with the unknown values in the firmware header but I made no match :/
Also, by looking at the hexdump I found the Unicode certificate data at 0x473600 (3 blocks after the last header block) and I will found a way to detect it (the packet differs a bit between the different firmwares).
3.4. Ok I understand why the adresses differ, because I use this firmware also in my tests.
I attach my prog, it was meant to split the firmware in multiple files but for now it only prints the different block types with offsets and block sizes.
Note you have to edit the library block size multiplier to match the one from your firmware to avoid getting thousands of padding blocks displayed between library blocks (for now).
In the future I should make a package which fetches different firmwares from sansa ftp and check them all.
Bye ^^
atomikpunk:
Hi funman,
For the branches, this is absolutely normal because branches are all relatives! The only that it tells you is that the address of the jumps are all in sequence in the firmware, which indeed is the case.
So we have two possibilities for the clip, a library block size of 0x14000 and/or 0x28000. I'll try to have a look on my side in the next days.
I'm glad you posted your program, I'll have a look at it in the next days! Hopefully, we'll be able to check that out online together.
See ya
Edit: Ok I checked out the clip firmware file 1.1.29f. The format is definitely different than the M200. Here's a bit of what I found this morning:
0x00000000: firmware header
0x00000400: firmware
0x0001E400: first library block
0x00030800: another library block
...
It seems that some library blocks now begin with 0xDEADBEEF and I'm not sure they necessarily have all the same size.
Owh BTW, if you're looking for stuff about the AMS3525 SoC, the embedded core is an ARM922T so you can get info about it...
See ya later.
funman:
"0x00000000: firmware header
0x00000400: firmware
0x0001E400: first library block
0x00030800: another library block
..."
For me the 2nd library block is at 0x46400
"It seems that some library blocks now begin with 0xDEADBEEF and I'm not sure they necessarily have all the same size."
I think we must take 0xDEADBEEF in the literal sense: this block is dead beef aka padding ;)
atomikpunk:
Hi funman,
The first library block is at 0x1E400 and the second one is as you said 0x46400. And I can see that there are at least 2-3 more following at the same 0x28000 distance. So I guess that the lib block size on the clip is 0x28000.
About the dead beef values, it seems that the clip changed the way dead beef padding is done. They seem to only mark the first dword of each padding block as dead beef now, but I wouldn't be surprised if the following bytes were still junk.
And I stumbled upon the version number in the firmware, juste in case you were still looking for it. It is a plain string located at 0x1DF3A ;)
Edit: Ok a little something for tonight, funman and I finally got online at the same time/space continuum and found some stuff on the clip firmware. It seems that new versions don't have whole deadbeef padding, but only the first DWORD of padding blocks. That suggests that we could insert our code in there so I guess one problem's gone. Now we need to find how to listen to a button. Owh and the clip firmware as a checksum similar to the e200 one, but it is located 4 bytes earlier in the file, so the file really is a 0x200 multiple with the last DWORD being the checksum. That's it for tonight...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version