Rockbox Development > New Ports
Creative Zen Vision:M
mcuelenaere:
--- Quote from: davidb on July 15, 2007, 06:22:18 PM ---I agree with you - I would say it's safe to assume that the hashing algorithm and check is in the bootloader and that the bootloader doesn't change when you upgrade the firmware. That said, why would the update program need to have the hashing algorithm in it? Why wouldn't Creative just "ship" the firmware updates with the hash already appended to nk.bin? It seems to me that would be the most likely be what they do, but I may be wrong. This is a potentially vital piece of information. Does the firmware update the Creative ships have the NULL block hash value already stored in it? If not, then it is safe to assume that the updating program has the hashing algorithm in it and we should focus on disassembling it to find the hashing algorithm. If the firmware does come with the hash value already stored, then it would seem we need some way to have a look at the bootloader in order to figure out the algorithm.
Also, keep in mind the algorithm itself doesn't necessarily have to run on the entire block of code/memory. I noticed mcuelanaere mentioned running some checks on that first block of the program (everything but the NULL block). What if it just picks the first x bytes, or x bytes starting from y location, or x bytes every y bytes (point being, there's many different possibilities).
I've read this whole thread a couple times through, but it's still hard to pick up on everything that people have done. mcuelenaere, you seem to have made the most progress out of anyone. Would you (and anyone else for that matter) mind documenting what you have done so far on the wiki page so that it's easier for others to get up to speed?
I don't have a Zen yet, but I think I've convinced myself to buy the 60gb one. I'd like to help get rockbox on it because I really want ogg support. I have experience with c/c++ etc and assembler programming. Can anyone recommend what I should start looking into/tools that I should use?
--- End quote ---
Ok, you convinced me : ) I was wrong.
But you do have an interesting point I've never thought about, what if the bare firmware that is included in the .exe does not have the NULL block, but that it would have been added by the program ?
It would make sense why the app would extract it to a place on your HDD and it could be possible.
The only way to find out, is to extract the firmware from the .exe; which I'm going to investigate tomorrow unless someone is ahead of me ; )
TheBlackCat:
That would be possible, but it defeats one of the main purposes of the checksum in the first place which is to make sure the firmware is intact. If the download is corrupted then the updater will run the algorithm on the corrupt file and generate the checksum for the corrupt file (assuming the algorithm itself is undamaged).
davidb:
--- Quote from: TheBlackCat on July 15, 2007, 07:27:39 PM ---That would be possible, but it defeats one of the main purposes of the checksum in the first place which is to make sure the firmware is intact. If the download is corrupted then the updater will run the algorithm on the corrupt file and generate the checksum for the corrupt file (assuming the algorithm itself is undamaged).
--- End quote ---
Interesting idea. If this is true for the Zen, then the hashing algorithm will be in the updater program.
Transience:
Not quite on topic, but I've written up all the progress made so far into an article on my website: http://www.the2200.net/phpBB2/kb.php?mode=article&k=11
If anyone finds that I'm missing anything, or that there are errors, I'll be more than happy to correct them.
---EDIT---
I'm having no luck with directMTP myself, but perhaps someone could try modifying one of the big blocks of 00 in the nk.bin file, and uploading it to the player. There's one that starts at 8e72h. I think these mark the boundaries between the firmware blocks, so perhaps the checksum algorithm ignores these sections? It would make sense to ignore those sections in order to save time on the checksum algorithm, as they don't contain any information (as far as i know).
bgdwie:
from what i have examined and observed, the firmware on all of the creative harddisk based mp3 players from the zen touch PFS (playesforsure) onwards is installed and executed the same way, i have read on a number of other forums that a user has made way in reading the partitions upon the zen touch, which are likely to be in the same format as the ones in the vision: m, so could be helpful for reading from that.. too busy looking for the thread... i can't remember where i was going with this....
EDIT: oh yeah, now i remember, now, if it is possible (which we have pretty much said yes to) to hijack firmware onto this player, that would mean that it would also be very easily possible to do it to other creative players too, since they all (just about) use the same processor and firmware loading system.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version