Thank You for your continued support and contributions!
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.
its so hard to make a secure algorithm I also doubt they would ever change it.
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").
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.
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...
Quote from: Bagder on July 15, 2007, 04:56:40 AMIndeed. 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.
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)
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?
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).
Page created in 0.099 seconds with 21 queries.