Rockbox Development > New Ports
Creative Zen Vision:M
quetzalcoatl:
--- Quote from: mcuelenaere on August 22, 2008, 11:55:38 AM ---This is as far as I get now, but I'm stuck at the cluster chain's stuff.
I can't figure out what the structure of the cluster chain is, where it's located and how I need to find the data that belongs to the file attached to the cluster..
--- End quote ---
i've just put all the current notes into the root/notes on the SF
what you need most now is notes/minifs/fs.txt:
- remember that 'sector' = 512bytes for the whole drive
- remember that 'cluster' = 8 sectors for the whole drive
line 13: the layout of the volume. the cluster IDs in second column are for yours drive. those are clusters of the VOLUME, not drive. minifs volume tends to start at drive's sector number one, as its seen in the volume table in MBLK
line 24, 26: structure of the "cluster chain". a single cluster chain is a structure consisting of some data and the 'chainlist' (a list of _logical_ clusterids that describe the file's contents' location). the cluster chain looks like:
- uint32 unknown
- "chainlist", the list of uint16, constant-length, 0xFFFF-terminated, padded with 0x0000 to the end
- uint32 unknown2
- uint32 number of entries on the 'chainlist'
warning: the whole 'cluster chains' part of the volume is a sequential list of consecutive clusterchains. placed one by one, from the first to the last, so finding the right clusterchain is relatively easy. BUT the size of the clusterCHAIN is not chosen well by the designers, it doesnt multiplicate to the size of cluster. the easiest way to find the right chain is to calculate its address in terms of BYTES on the drive (not secotrs, not clusters) and then translate the address to clusters/sectors.
a "logical clusterid" is a cluster ID offsetted by the beginning of the volume's dataspace. if the file's clusterchain says that a logicalclusterid is 0x0123 and the minifs's dataspace starts at cluster 0x4321, then the REAL in-volume clusterid is 0x4321+0x0123 = 0x4444, and there you should look for the file's contents
[ and the in-volume clusterid = 0x4444 of course points to the drive's physical sector = 0x4444 * clustersize + minifsstart = 0x4444 * 8 + 1]
line 39: the structure of the directory/direntry
blahblah, please se the notes..
the most important is that, there are 2 identical numbers - and those are the file's clusterchain's numbers. i don;t know why two of them, they're always the same, so whatever.
mind that that all names are in char on yours volumes, not wchar_t as the notes may state!
GuybrushThreepwood:
Hi! :) I've succeeded in building the zenutils sorces under Linux (it was very easy and I haven't found any problem): it's clear that something is wrong with my Windows build environment. I would do my best to find a solution to this and, if I would succeed, I would report the results here. I hope it could be useful to someone else who could want to do the work under Windows.
By now, I've to report a problem: even the newer version of update_extract fails to extract the firmware from the updater package; perhaps the problem causing this issue isn't still resolved, the strange thing is that, as said, it works on some updater packages and doesn't work on others.
If there is something more I could do, I'm free to help! :)
p.s. As said in my last post, I hope that I haven't done anything wrong writing again here on this thread, instead I hope that sharing the results of my tests could be useful.
mcuelenaere:
@quetzalcoatl:
Thanks for the notes! I'll look into it sometime this week..
--- Quote from: GuybrushThreepwood on August 23, 2008, 04:46:44 PM ---...
p.s. If the code has to be modified to be compiled under Windows, how was the version on pimpmyzen compiled? Was it cross-compiled?
--- End quote ---
No, it was compiled using VS2005.
--- Quote ---p.p.s What I meant by "manual way to extract the firmware" was asking what's the updater file structure and how to manually extract the firmware from it.
--- End quote ---
The structure of it isn't really described somewhere as it's more a binary Win32 program containing two binary scrambled & compressed binary blobs placed at a changeable spot.
But if you would like to really know it:
* the nk.bin data starts at the first DWORD in the .data section; the DWORD is the size of the compressed/scrambled blob and is preceded with some other data (you can recognize it because after the DWORD there won't be any 0x00 anymore)
* the key will need to be found in the other sections and is recognizable by the prefix 34d
* the descrambling algorithm is fixed and documented in zenutils
* the descrambled blob can be decompressed using standard Zlib
--- Quote from: GuybrushThreepwood on August 24, 2008, 09:54:44 AM ---...
If there is something more I could do, I'm free to help! :)
--- End quote ---
You could always help porting Rockbox ;)
--- Quote ---p.s. As said in my last post, I hope that I haven't done anything wrong writing again here on this thread, instead I hope that sharing the results of my tests could be useful.
--- End quote ---
No, it was just a little warning in order to not convert this thread into some kind of 'Fix my ZVM!' help thread :)
edit:
I just committed some fixes for ZenUtils, try recompiling and see what it gives..
GuybrushThreepwood:
@mcuelenaere
I've updated my copy of the SVN: tomorrow I would build again the sources and see what happens then let you know. Tomorrow I would try to set up a better Windows environment too...
I've opened the updater executable with a PE Editor and the .rdata section is only 60Kb worth while the .data section is a lot bigger (a little less than the entire package dimension): isn't the firmware (scrambled and compressed as you've said and I've expected) supposed to be in the .data section? BTW I have to go deeper into this...
mcuelenaere:
--- Quote from: GuybrushThreepwood on August 24, 2008, 06:38:07 PM ---@mcuelenaere
I've updated my copy of the SVN: tomorrow I would build again the sources and see what happens then let you know. Tomorrow I would try to set up a better Windows environment too...
I've opened the updater executable with a PE Editor and the .rdata section is only 60Kb worth while the .data section is a lot bigger (a little less than the entire package dimension): isn't the firmware (scrambled and compressed as you've said and I've expected) supposed to be in the .data section? BTW I have to go deeper into this...
--- End quote ---
Sorry, I was wrong. You're right :) It is the .data section; the info I gave you wasn't double checked.
For example: ZENVPlus_PCFW_L22_1_32_01.exe :
* the data is in .data; starting exactly at 0x5F0C4; while it's length is at 0x5F0C0 (or relatively to start of .data: 0x0C4 & 0x0C0)
* the key (34d12E9276d9bB6796efe6457749886) is also in .data
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version