Creative Zen Vision:M

[Bagder]

Why do you all assume that the algorithm is in the firmware? I won't be, the checksum, as in the hash key will be stored in the firmware file and we think its the last 20 bytes of the nk.bin file.

Indeed. But the update program might have the checksum algorithm to verify the image before trying to upgrade to it (just to be able to "warn early").

its so hard to make a secure algorithm I also doubt they would ever change it.

People don't just invent their own algorithm (if they are clever), they use one of the already established and proven very reliable algorithms. And out of all players rockbox runs on, very few have the ability to change the algorithm.

[iSE]

Indeed. But the update program might have the checksum algorithm to verify the image before trying to upgrade to it (just to be able to "warn early").

I agree, and I indeed said that its possible the calculating algorithm is in the updater program just not in the actual firmware file itself (the nk.bin) which is what is transferred to the player.

People don't just invent their own algorithm (if they are clever), they use one of the already established and proven very reliable algorithms. And out of all players rockbox runs on, very few have the ability to change the algorithm.

Again I agree, but if you modify the algorithm slightly it can create huge security holes which is why modifying the algorithm would be out of the question. And if we assume the 40digits at the end of the nk.bin are the checksum, there aren't that many 160bit encryption algorithms out there so they will probably not use a different one each time. My guess is, they always use the same algorithm, obv not SHA-1 or SHA-0 because mcuelenaere checked. Did you check for the variations on the SHA-1 algorithm? There are 3 alternatives to calculating one of the values which are just as secure. So they may have used one of those as then none of the calculators would give a match as they'll use the main psuedocode.

[phcoder]

I changed 67->77 in the first SHA-1 constant. The updater no longer recognizes the player and asks me to connect it even if it's connected. I will do further debugging with softice

[bgdwie]

ok, so, this may have already been said, but, why doesn't someone get a usb data logger run it whilst doing a firmware update, it will record all packets sent and received via usb, it should give us an idea of what is going on, it might help, it should turn out some pretty interesting info...

[phcoder]

BTW. Has somebody thought about padding? To day or tomorrow I'll reverse engeneer SHA-1 related part of updater (I already have some experience with this kind of things)

[aaronwi]

ok, so, this may have already been said, but, why doesn't someone get a usb data logger run it whilst doing a firmware update, it will record all packets sent and received via usb, it should give us an idea of what is going on, it might help, it should turn out some pretty interesting info...

This has been done by a couple people, including me, I had a full log of it, couple hundred megabytes worth, posted a while back

[mcuelenaere]

Indeed. But the update program might have the checksum algorithm to verify the image before trying to upgrade to it (just to be able to "warn early").

I agree, and I indeed said that its possible the calculating algorithm is in the updater program just not in the actual firmware file itself (the nk.bin) which is what is transferred to the player.

But if the calculation algorithm is not present in the nk.bin file (so neither on HDD nor in flash) how come the ZVM rejects an altered firmware that's uploaded using just MTP commands (so not using the firmware updater program) and accepts an 'official' firmware uploaded using the same method (only MTP commands)?

I conclude that the algorithm must be present either in flash or on HDD (or even on hardware although there's little chance that's the case).

[Bagder]

Because the .bin file is simply the update file and the update code and algorithm is in flash.

(that's at least the theory and host most players work)

[mcuelenaere]

Because the .bin file is simply the update file and the update code and algorithm is in flash.

(that's at least the theory and host most players work)

Doesn't the .bin file also update flash? (FRESC)

[davidb]

I conclude that the algorithm must be present either in flash or on HDD (or even on hardware although there's little chance that's the case).

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?

[mcuelenaere]

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?

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]

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).

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.