Creative Zen Vision:M

[mcuelenaere]

I downloaded an precompiled ZLIB dll which included an zlib.h file; and it didn't complain about anything related to ZLIB, so I didn't think it could be that. But I'll try your way.

[zook]

When the linker complains about missing libraries or multiple definitions. It's often because you're linking with a library which implicitly links to other libraries, which may be incompatible with your setup.
The library could also come from a pragma statment in one of the headers you're using.

[mcuelenaere]

Ok, I got it going by defining ZLIB_WINAPI, including the zlibwapi.lib and including zlib.h
Only problem now is: it is eating my memory
Currently it is using 1,2GB of RAM, which is definitely due to Zlib; because I got the same problem a while ago.
But now I can't end the process (?? maybe some WinXP bug) and so 1,8GB of 512MB RAM is in use...

[zook]

Hmm. I'm also on XP (32-bits), so that shouldn't be it.
Does the two examples that comes with zlib work?
Maybe I should just add command line options and upload the exe...

[mcuelenaere]

Hmm. I'm also on XP (32-bits), so that shouldn't be it.
Does the two examples that comes with zlib work?
Maybe I should just add command line options and upload the exe...

I think that would be the best, since I had to restart my pc in order to solve the problem

[zook]

Okey, here it is: http://www.fileshost.com/en/file/5227/ZvmFirm-rar.html
The cli is as follows:
ZvmFirm [-d updater offset outputfile key] | [-i firmware]
  -d decompresses
  -i displays segment information

  updater - is the executable.
  offset - is the offset of the compressed size in C/C++ hexadecimal notation.
  outputfile - is the file you want it stored in. this file will be overwritten if it already exists.
  key - is the non-mutated ascii key.
  firmware - is the firmware filename.

[zook]

I think I know what your problem was. You forgot to update the 'offset' and/or 'xorkey'.
I've been collecting different versions of the firmware and ran into the same problem, when either of those were not correct.
I'll list the offset and key values that I've found and tested here:

Code: [Select]

ZENVisionM_30GB_PCFW_L20_1_51_01.exe    0x5C0D0   34d12CC55497667G239f734499796
ZENVisionM_30GB_PCFW_L21_1_60_01.exe    0x5C0D0   34d12FD8Be716793Fd7df4611544519
ZENVisionM_30GB_PCFW_L21_1_61_01.exe    0x5D0C0   34d12D23f6c894B96ff4735153836
ZENVisionM_30GB_PCFW_L21_1_62_02e.exe   0x5E0C0   34d124E7B849397127d97992522927
ZENVisionM_60GB_PCFW_L20_1_11_04.exe    0x5B0D0   34d1252E3f9874F2B945e447139419
ZENVisionM_60GB_PCFW_L21_1_21_02e.exe   0x5E0C0   34d12DGC76efe694999527119669896
ZENVisionM_PCFW_LF_1_41_01.exe          0x5C0D0   34d125FBBb7c9BEGGf7ce999942972
ZENVisionM_PCFW_LF_1_41_01e.exe         0x5C0D0   34d12BF95f65825D491996213143192

One odd thing that I've discovered is that the FBOOT DATA segment is the exact same size in the majority of these. And the ones I've compared are also mostly identical, except for a block at the end. This block starts with a 32-bit size and then there's a chunk of encrypted/compressed data, which is radically different amongst the different versions. The block size is also the same in the different versions.
Given that the size is the same in each version, I'm guessing that there hasn't been any changes to the content of the block, but rather it's been encrypted with different keys.
I obviously have no clue about this data but it could reveal some important aspects of the crypto used, and anything worth hiding probably has some significance. Supposing that the data is encrypted with a xor key, then we could possibly discover the key used through character frequency analysis. Now, what good is the key? Well, if the key changes between each firmware, then the key should be in the firmware somewhere. Also, it would be somewhat wasteful to have multiple encryption algorithms for different puporposes. For space efficiency they would probably use the same algo and possibly key.

[mcuelenaere]

I think I know what your problem was. You forgot to update the 'offset' and/or 'xorkey'.
I've been collecting different versions of the firmware and ran into the same problem, when either of those were not correct.

Could be

One odd thing that I've discovered is that the FBOOT DATA segment is the exact same size in the majority of these.

This could mean that FBOOT is just a boot loader loading the code from HDD or it could mean nothing really is changed to the main code (which I doubt if you look at the changes in different firmwares)

And the ones I've compared are also mostly identical, except for a block at the end. This block starts with a 32-bit size and then there's a chunk of encrypted/compressed data, which is radically different amongst the different versions. The block size is also the same in the different versions.
Given that the size is the same in each version, I'm guessing that there hasn't been any changes to the content of the block, but rather it's been encrypted with different keys.

Are you talking here about EXT0 or about LT© ?

I obviously have no clue about this data but it could reveal some important aspects of the crypto used, and anything worth hiding probably has some significance. Supposing that the data is encrypted with a xor key, then we could possibly discover the key used through character frequency analysis. Now, what good is the key? Well, if the key changes between each firmware, then the key should be in the firmware somewhere. Also, it would be somewhat wasteful to have multiple encryption algorithms for different puporposes. For space efficiency they would probably use the same algo and possibly key.

Hopefully they did

I also took a look at the firmware and I made some little changes to the 010 Editor parsing template:

Code: [Select]

//--------------------------------------
//--- 010 Editor v2.0 Binary Template
//
// File: Creative firmware (nk.bin)-Parser
// Author: l_e
// Edited by: mcuelenaere
// Revision: 0.1
//--------------------------------------

typedef struct {
CHAR BlockID[4];
DWORD Size;
if (BlockID == "FNIC"){
UCHAR Desc[96];
} else if (BlockID == "0TXE"){
UCHAR Desc[24];
UCHAR Data[ Size - sizeof(Desc) ];
} else if (BlockID == "LLUN" || BlockID == "FFIC" || BlockID == " LT©"){
UCHAR Data[ Size ];
} else {
UCHAR Desc[32];
UCHAR Data[ Size - sizeof(Desc) ];
}
} BLOCK;
//--------------------------------------------The rest stays the same.
Together with the template above I made this one for EXT0:

Code: [Select]

//--------------------------------------
//--- 010 Editor v2.0 Binary Template
//
// File: Creative firmware (EXT0)-Parser
// Author: mcuelenaere
// Revision: 0.1
//--------------------------------------

typedef struct {
CHAR BlockID[4];
DWORD Size;
UCHAR Data[Size+2];
} BLOCK;
//--------------------------------------------
CHAR[] StrRev( CHAR s[] )
{
local int sz;
local int up;
local CHAR strng[sizeof(s)];

for (sz =sizeof(s)-1,up=0;upstrng[up] = s[sz];
}
return strng;
}


string ReadBLOCK( BLOCK &block )
{
return StrRev( block.BlockID );
}
//--------------------------------------------

local ulong id;
local ulong tmp;
local ulong ofs;

BigEndian();
id = ReadUInt( FTell() );

while ( !FEof() ){
FSeek( ofs );
BLOCK block;
FSeek( ofs+sizeof(block) );
ofs = FTell();
}

//--------------------------------------

[zook]

This could mean that FBOOT is just a boot loader loading the code from HDD or it could mean nothing really is changed to the main code (which I doubt if you look at the changes in different firmwares)

Yeah, I think FBOOT is the complete boot loader. Based on the segment sizes, my guess would be that ®TL contains the player code and EXT0 is either filesystem or flash data.

Are you talking here about EXT0 or about LT© ?

I was still talking about FBOOT. If you look at offset 0xB000 of that segment, you'll see 80 1C 00 00, which is the size (7296) of the following chunk. It's the exact same location and size in all but two of the ones I've looked at, yet the contents is entirely different. The only explanation that I can think of, is that each version is encrypted with a different key.

I also took a look at the firmware and I made some little changes to the 010 Editor parsing template:

Ahh, I tried using the other template earlier, but the board software displays the code incorrectly.

[mcuelenaere]

Ahh, I tried using the other template earlier, but the board software displays the code incorrectly.

http://rafb.net/p/Y25m3N12.html

http://rafb.net/p/YoH1fj87.html

[zook]

I've been checking out various leads.
First I got my code setup to handle different algorithms and combinations of segments. I've used the following algorithms: MD4, MD5, RIPEMD-128, RIPEMD-160, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 & TIGER. And the following combinations of segments:
Full w/ header -- The entire CIFF segment, including it's header.
Full w/o header -- The entire CIFF segment, excluding it's header.
Segmented w/o headers -- All segments within CIFF, excluding their headers.
Segmented w/o headers(!DATA) -- All non-DATA segments within CIFF, excluding their headers.
Segmented w/o headers(DATA) -- All DATA segments within CIFF, excluding their headers.
Segmented w/o headers(DATA.F) -- All F* DATA segments within CIFF, excluding their headers.
Segmented w/o headers(DATA.H) -- All H* DATA segments within CIFF, excluding their headers.
In this setup I've computed the hashes and xored them with the NULL block value. The idea was to test the assumption that the NULL block was obsfuscated by a constant xor key. However, that's not the case for this set of combinations and algorithms. Here's a log of the output: http://rafb.net/p/YQ0Kfr77.html

Second, I've been looking for repeating patterns in the ending block of the FBOOT segment. The idea behind this was again, to determine if a xor cipher was used. For example, with a xor cipher, blocks of zero will leave parts of the key exposed as a repeated pattern. However, I haven't been able to find any such patterns in the block. One explanation could be that the block is encrypted and compressed. Or they could be using a real cipher.

Third, I've looked at the firmware updater itself. There was some crypto algorithms mentioned earlier and I've been looking into their role. The ECC(Elliptic Curve Crypto), DES, RC4 and SHA-1 together form an implementation of MS-DRM v2, or similar, as described here: http://www.spinnaker.com/crypt/drm/freeme/Technical
Most, if not all, of the crypto code comes from MS SDK libraries.
The scheme is used to authenticate the firmware updater application with either the Windows Media Device Manger or Media Transfer Protocol API's. Apparently using some parts of these API's require that you have a certificate issued by MS.

So, in summary, a lot of work but little progress. I'm starting to think that looking at the firmware is the only viable approach. However, I'm not in the least bit familiar with anything besides x86 assembly. I've tried disassembling the FBOOT segment using various different processor modules but none of them yield any intelligible code, that I can tell anyway. If anyone has anything to contribute in the ways of getting a disassembly, then I'd be happy to familiarize myself with the instruction set and architecture.

[Transience]

Seeing as it's fairly easy to access/modify the firmware data on the HDD, couldn't we use the creative bootloader to launch rockbox? or is this more trouble than it's worth? The bootloader doesn't check the firmware on the HDD since I was able to modify a GUI image and have the player still boot. Is this a feasable idea?

[GodEater]

I would say so - if you can do it. It's the same method currently used on the Gigabeat F/X for example - there's some Toshiba bootstrap code which starts the device, and then jumps into the rockbox bootloader.

[zook]

Having looked at elder zen models, it's obvious that the NULL signature is the least of our worries.
Every entry of code within the firmware archive is encrypted and without an understanding of the algorithms used, we can't put any meaningful code on the player.
I've found several elder zen models which employ a lesser protected scheme and in later firmware versions introduce the fully protected one.
This open's up the possibility of understanding the protocol used to get fully protected firmware onto a player.
As such I'm currently looking at the Dell DJ and other zen players using the same scheme.

[fejfighter]

I tried for a search through this thread (i have read all of it, but some of it was quite a while ago)

has anyone tried disasembling the actual firmware installer (regardless of what firmware is inside) in order to try and follow how the firmare makes its way to zen vision? it may reveal when and where the checksum is done,

apologies if it has already been tried


keep up th good work too