Creative Zen Vision:M

[davidb]

so perhaps the bootloader is only checksumming certain blocks of the firmware, and skipping others?

My post on page 20 says the same thing.

Anyway, I was thinking last night: there are several F* (FBOOT, FRESC) blocks and several H* (Hjukebox.grs, Hjukebox2.jrs, ...) blocks; if the F refers to flash and the H to HDD, it would mean everytime an upgrade is performed the boot code is flashed.

To prove my theory: if you look at the rescue menu, you'll see a version number. If you upgrade your firmware, this number changes. But if your HDD becomes corrupt or your ZVM won't boot anymore (you come automatically in Rescue mode), this number is the same (so it doesn't depend on a file on HDD).

So in short, a HDD dump wouldn't give us any real useful information, because (boot) code is stored in ROM/flash.

Also, there are 2 other strange blocks in nk.bin (EXT0 and an encrypted one), maybe one of them could contain DSP code and/or are written to a specific place (as none of them has an H or F in front of their name); but this has nothing to do with the above.

I believe your right about the F* and H* theory and therefore about the HDD dump not providing anything about the hashing algorithm. I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.

[mitch04]

hi ok this is something different but i was looking around and i foun this site Creative ZEN Vision M Firmware Mod  talks about all this
Article Name: Creative ZEN Vision M Firmware Mod
Author: Transience
Description: All the information currently known about the ZVM's firmware.

Category: Modification
Type: Programming

the site is http://the2200.net/phpBB2/viewtopic.php?t=34
i asked his what this is but havnt wrote back yet

[iSE]

Yeah thats a summary of everything thats been posted here n on epizenter

[mcuelenaere]

I believe your right about the F* and H* theory and therefore about the HDD dump not providing anything about the hashing algorithm. I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.

Indeed, I agree with you.
But to find out, we should extract the firmware from the .exe where it is ZLIB compressed.
I already tried decompressing it, but without any result (see some posts back).
Could someone else try this?

[iSE]

could it be that its encrypted aswell?

[mcuelenaere]

could it be that its encrypted aswell?

It could be, but I don't think so.
There maybe is some MD5 verification, but it would be kinda strange of Creative to do so
(cause then you would have an MD5 "hacker-free" ZLIB compressed binary, which will get an SHA-1 sort-of hash added and get sent to the device).

[MagistrateD]

I believe your right about the F* and H* theory and therefore about the HDD dump not providing anything about the hashing algorithm. I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.

Indeed, I agree with you.
But to find out, we should extract the firmware from the .exe where it is ZLIB compressed.
I already tried decompressing it, but without any result (see some posts back).
Could someone else try this?

im no expert with .exe files but by looking at the latest patch.exe fro the zvm it looks like the fun stuff starts at 0x001000 and ends at 0xF1D140 and is followed by a series of warning strings.  i tried running the all round unidecrypt and all i could learn was that it is coded in C++ 6.0. if anyone has anymore guesses about what format it could be compressed in lemme know please.

EDIT: not sure if someone has pointed this out before but creative has a recovery tool for all mps players (http://www.creative.com/products/mp3/MP3PlayerRecoveryTool/welcome.asp?region=2)
not too sure if its worth taking a look at to manipulate and im too tired to check but this also means that if any little tests brick a zen it can be reverted.

[mcuelenaere]

Some (useful) links were posted at epiZENter.net:

http://flickr.com/photos/chlazza/946305589/
http://flickr.com/photos/chlazza/946305207/
http://flickr.com/photos/chlazza/946305167/

[mcuelenaere]

OK so the last few days I focused myself on trying to extract the compressed nk.bin out of the installer, which I unfortunately didn't succeed in.
But if someone could locate the program called deezee or one which has the same functionality, that could be very helpful.
edit: I already got the program now, but it didn't work; so the data must be available in an altered way and not in the normal ZLIB format.

On the other hand, I analyzed some of the files in nk.bin and I'm pretty sure EXT0 is written for the C54x DSP chip and FBOOT is the boot loader (which could load the encrypted/compressed/obfuscated/... block present in the nk.bin file).

I also checked the SHA-1 variants iSE sent me, but apparently these are just 'other ways' for generating the same SHA-1 checksum; so maybe Creative is using a slightly modified version or they are computing the checksum in a way we don't (yet) know, for example the whole file except for the first 10 bytes.

[mcuelenaere]

So I extracted some raw data out of the exe, but I think it is 1)XORed with a key and 2)ZLIB compressed.

The size of the file is present at 0x5D0C0 and is a Little Endian UInt. Directly after this number is the raw data present ending in one '0000' block. These numbers are based on ZENVisionM_30GB_PCFW_L21_1_61_01.exe.

The file could be XORed with this key: '34d12D23f6c894B96ff4735153836'

download link: http://www.verzend.be/v/7079781/perfect.bin.html

[zook]

I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.

I'm a bit limited by not owning the player but I've unpacked the firmware image stored in ZENVisionM_30GB_PCFW_L21_1_62_02e.exe.
There is a checksum within the NULL block: 45E2 DCDD 4C07 2B99 5DDB B21A B15A D1EF 55CC 6A3A
But I can't say if it differs from the one sent to the device.

The file could be XORed with this key: '34d12D23f6c894B96ff4735153836'

Close. The key is slightly mutated first.
Decrement each character by one, and OR 0x80 to the result.
Then it's just standard zlib inflate from there on.
The process is the same for the Jboxcrl.crl and unicow.dll.


Has it been established if all segments within the firmware image effect the checksumming? Is the segment headers included in the sum? If the scope was more limited, it would be more feassible to perform crypt analysis on the different versions of the checksums.
I'm mostly inclined to believe that the checksum is a standard algorithm, who's result get's mutated to obscure where it's from. Based on the mutation used in the updater, I'm guessing that it's simple enough to be discovered through basic crypt analysis.

[mcuelenaere]

I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.

I'm a bit limited by not owning the player but I've unpacked the firmware image stored in ZENVisionM_30GB_PCFW_L21_1_62_02e.exe.
There is a checksum within the NULL block: 45E2 DCDD 4C07 2B99 5DDB B21A B15A D1EF 55CC 6A3A
But I can't say if it differs from the one sent to the device.

The file could be XORed with this key: '34d12D23f6c894B96ff4735153836'

Close. The key is slightly mutated first.
Decrement each character by one, and OR 0x80 to the result.
Then it's just standard zlib inflate from there on.
The process is the same for the Jboxcrl.crl and unicow.dll.

Wow, that's some pretty nice accomplishment you've got there
Could you provide me with some more information about dexoring the contents (so each character of the key is decremented by one and then you just OR 0x80 every character of the raw contents incrementing the position in your key-string?) or did you make a little program which does the extracting?

And as you're saying the extracted nk.bin file already got an NULL block, this means that we are back to square 1..

Has it been established if all segments within the firmware image effect the checksumming? Is the segment headers included in the sum? If the scope was more limited, it would be more feassible to perform crypt analysis on the different versions of the checksums.
I'm mostly inclined to believe that the checksum is a standard algorithm, who's result get's mutated to obscure where it's from. Based on the mutation used in the updater, I'm guessing that it's simple enough to be discovered through basic crypt analysis.

I'll try to do an SHA-1 checksum on only the data (so without the segment headers), but it may be easier deassembling FBOOT or FRESC to check if there is some checksum code present there...

edit:
The checksum value gave me 11E2AE6CC89B212F8FA860730B15327336439E7E while the NULL block contains 77 A0 03 39 3E 4A 09 B9 E1 BD 2F 14 09 7A 8A 8C 17 8F 38 AA

[zook]

Here's my hacked together code: http://rafb.net/p/vTdhN853.html

The relevant bit is:

Code: [Select]

   // Mutate the xorkey.
 Â   for (int i = 0; i < keylen; i++)
 Â   {
 Â       key[i] = key[i] - 1;
 Â   }

 Â   // Decipher the chunk.
 Â   for (int i = 0, j = 0; i < dwChunkSize; i++, j = i % keylen)
 Â   {
 Â       lpChunk[i] ^= (key[j] | 0x80);
 Â   }

I'll be working on providing an easy way to produce checksums of the different segments.
EDIT: Once that's done it would be nice with some other versions of the firmware for comparison.

[mcuelenaere]

Here's my hacked together code: http://rafb.net/p/vTdhN853.html

I'm trying to get this thing compiled but atm I only got 1 problem left and this is:

Code: [Select]

Error 4: fatal error LNK1104: cannot open file 'MSVCMRTD.lib' (I'm using VC++ 2005 and I'm getting it both in Release & Debug mode)

Could this mean I should reinstall VC++?

[zook]

Here's my hacked together code: http://rafb.net/p/vTdhN853.html

I'm trying to get this thing compiled but atm I only got 1 problem left and this is:

Code: [Select]

Error 4: fatal error LNK1104: cannot open file 'MSVCMRTD.lib' (I'm using VC++ 2005 and I'm getting it both in Release & Debug mode)

Could this mean I should reinstall VC++?

How are you linking to zlib?
With my project I just added a console project to the zlib solution and added a reference.