Rockbox Development > New Ports
Creative Zen Vision:M
jhulst:
--- Quote from: iSE on April 19, 2007, 01:23:07 PM ---If we are able to calculate what the hash algorithm is then we could use it to give a fake one back to the player so it thinks it original firmware. Another way would be find what the hash actually is so we could give that back to the player and again fool it.
--- End quote ---
We don't know how the hashing function and hash verification actually works as of yet, so this statement may not end up being completely true. Depending on where/when the hash is calculated, the only way to "fool" the player may be to put the computed hash in the correct place of the firmware.
iSE, sorry to contradict you, but I think it's good to make sure the facts are being presented as best we know them so that people don't get confused.
jhulst:
Take the following with a grain of salt as I have not had a lot of time to work through my findings:
It looks like the checksum/hash is being computed in the firmware update software. It seems that the firmware updater program is divided into two parts, the main part, and a library called by the main part.
In the library, at line 7C93CF82, there are some references to Image Checksum. From my understanding, one of the functions calls "LdrVerifyImageMatchesChecksum" which is at 7C93CFE4. This may be where the checksum is calculated.
To look at the code, I used OllyDbg and examined 1.61.01 version of the firmware. I've mirrored the firmware updater (15 MB). My way of getting to the library was to run the updater without a player plugged in. It will terminate in the library.
Again, these are some very initial thoughts. I am probably wrong about some, if not all of it, I just wanted to give a starting point that others who may want to help may begin to look at.
My next step will be to hookup a player and step through the code to try and understand what it is doing.
jwh
edit: fixed links
larryzotter:
Do u mean the verifying is done i the updater program instead of the ZVM itself?
TheBlackCat:
It may be done at both. I am pretty sure the nk.bin file contains a checksum mismatch error message ("header checksum" I think it was called), which would indicate that there might be a checksum detection on the ZVM itself as well as the installer. This would not matter if they used the same hash algorithm, but could be very annoying if they don't.
I don't know much about checksum, but it would seem to me that the hash algorithm could not include the checksum itself, right? If that was the case they would have a "chicken and egg" problem where putting in the computed checksum would change the checksum, forcing you to recompute it. The recomputed checksum would again change the checksum, etc. If it is the case that the checksum avoids one part of the file, is it possible it might avoid others as well that are not considered important?
Another question: if we know where the checksum is being calculated would it be possible to delete that from the code entirely and replace it with some sort of "if 1=1" test or something trivial like that? Or perhaps leave the algorithm in but bypass the test for whether there is actually a match or not. I know nothing about assembly or machine code editing so I don't know if that is possible. However, I would guess if people are ever able to understand the assembly or machine code well enough to determine the hash algorithm then it would be as easy if not easier to understand it well enough to bypass the test entirely in some way. It probably wouldn't be a particularly elegant solution but it might save a lot of trouble.
saratoga:
--- Quote from: TheBlackCat on April 21, 2007, 01:05:51 PM ---
Another question: if we know where the checksum is being calculated would it be possible to delete that from the code entirely and replace it with some sort of "if 1=1" test or something trivial like that? Or perhaps leave the algorithm in but bypass the test for whether there is actually a match or not. I know nothing about assembly or machine code editing so I don't know if that is possible. However, I would guess if people are ever able to understand the assembly or machine code well enough to determine the hash algorithm then it would be as easy if not easier to understand it well enough to bypass the test entirely in some way. It probably wouldn't be a particularly elegant solution but it might save a lot of trouble.
--- End quote ---
Yeah, thats the easiest way around these things. Find the "branch if not equal" instruction and change it to a NoOp. That way it doesn't notice if the checksum/hash is wrong. Ideally someone would work out the checksum, so that the software didn't need to be hacked (which would be awkward for rockbox since no one can distribute the hacked program). But either now would be really interesting and a great start since it would let us know pretty quickly if there was a second check on the player itself.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version