Creative Zen Vision:M

[Sonic]

Hey, people! I just bought a ZVM, but the one drawback was that it didn't support Rockbox. So I'd be willing to help, if someone could tell me how. I don't know how to program, but I could learn if somebody pointed me to a good tutorial, or something. 

[CloudAge]

I would like to help in anyway possible aswell is there any status to some extent on this project as of yet?

[iSE]

Unfortunately reverse engineering the firmware to a player is extremely difficult. It is not a simple case of follow this howto and here you go. We are all still trying to figure out how to get our own version of the firmware onto the player without it being rejected.

The reason it is rejected is because the hash check the player performs on the firmware fails, as in, it knows its not the original and so will not load it because it may be corrupt and/or tampered with. If anyone has any experience cracking cryptographic hashes, I suggest you read through the posts that have come before this and help in anyway you can. If you want to learn, it is through this where you will be able to help.

[Sonic]

So, if it's so hard to decode the hash, why not use the original hash, from the original firmware? Maybe the other parts of the firmware could be identified, and then we could just figure out which part was the hash. Unless that just sounds really stupid. 

[iSE]

Well the idea behind a hash is that it calculates it from the contents of the firmware, so if the contents change then when it tries to calculate the hash it will be wrong and so will fail. 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.

[jhulst]

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.

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]

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.

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.

[larryzotter]

What would be a good software to "see" whats in the nk.bin fle? I've tried a hex editor with not much luck.

[jhulst]

What would be a good software to "see" whats in the nk.bin fle? I've tried a hex editor with not much luck.

Check out reply #157 for how mcuelenaere does it.

[koston]

So watch this:

http://www.bilder-speicher.de/07042521261533.vollbild.html

Seems to be a lot of Cryptoshit inside

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.

This is inside the ntdll.dll. There cant be a checksum calculation, because this is a Windows library. The checksum calculation must be inside the code of ZENVisionM_30GB_PCFW_L21_1_61_01.exe. The Windows DLLs you mostly use for creating Messageboxes (user32.MessageBoxW for example) or something like that.

[mcuelenaere]

So watch this:

http://www.bilder-speicher.de/07042521261533.vollbild.html

Seems to be a lot of Cryptoshit inside

I got this:

Code: [Select]

ADLER32 :: 0001609C :: 0041609C
The reference is above.
Adler32 checksum (unsigned 32-bit integer, BASE value); used by ZLIB compression library
ADLER32 :: 00016171 :: 00416171
The reference is above.
Adler32 checksum (unsigned 32-bit integer, BASE value); used by ZLIB compression library
CRC32 :: 0004F700 :: 0044F700
Referenced at 004162CF
Referenced at 0041631E
Referenced at 00416364
Referenced at 004163A6
Referenced at 004163E6
Referenced at 00416425
Referenced at 0041646A
Referenced at 004164AF
Referenced at 004164EF
Referenced at 00416544
Referenced at 00416570
CRC32 precomputed table for byte transform
DES [long] :: 00051D90 :: 00451D90
The reference is above.
DES: transformation nibbles
ECC: DRM (Microsoft), prime modulus :: 00051AB4 :: 00451AB4
Referenced at 0041972B
Microsoft elliptic curve, prime modulus of DRM curve
MD4 :: 00027663 :: 00427663
The reference is above.
MD4 transform & init constants (also used in SHA, RIPEMD, partly in CAST)
MD5 :: 0002586D :: 0042586D
The reference is above.
MD5 transform (\"compress\") constants
SHA1 [Compress] :: 0002326A :: 0042326A
The reference is above.
SHA1 additive constants (also used in SHA, SEAL, partly in RIPEMD)
SHA1 [Compress] :: 00023DBF :: 00423DBF
The reference is above.
SHA1 additive constants (also used in SHA, SEAL, partly in RIPEMD)
ZLIB deflate [word] :: 0004F600 :: 0044F600
Referenced at 00415D0C
ZLIB deflate compression algorithm - literal code lengths, used to build the trees


[mcuelenaere]

Some functions I've found in the .exe (named them myself):

FirmwareChk at 00413E10 (big function, has a lot of checks of nk.bin in it)
FORMAT_FIRMWARE at 00417A30 (I suppose here ZVM's firmware is erased)
FIRMWARE_DOWNLOAD at 00417CE0 (and here it is uploaded?)
CheckFormatSupport() at 00417FB0 (name was found in the strings)
ChkSumInit at 004229B0 (has something to do with the CheckSum; I strongly believe it is SHA1 or RIPEMD160) --> this one uses a lot of SHA1 constants, so I believe the SHA1 hash is generated here

(SetRegSeed at 00424275)
(CreateRegRNGKey at 004242B8)
-> these are from minor importance