Creative Zen Vision:M

[Hitman2k7]

Well I also got an nk.bin on my players hd by changing the Formatcode to undefined. But the player doesn't do anything with it unless changing the formatcode to firmware but that's as far as i know not possible.

GetObjectInfo: received ObjectInfo:
  Format code       = MTP_FORMATCODE_UNDEFINED
  Protection status = MTP_PROTECTIONSTATUS_NONE
  Compressed size   = 21767736
  Thumbnail format  = MTP_FORMATCODE_NOTUSED
  Thumbnail size    = 0
  Thumbnail width   = 0
  Thumbnail height  = 0
  Image width       = 0
  Image height      = 0
  Image bit depth   = 0
  Parent obj handle = 0x0
  Association type  = MTP_ASSOCIATIONTYPE_UNDEFINED
  Association desc  = 0
  Sequence number   = 0
  File name         = nk.bin
  Capture date      =
  Modification date =
  Keywords          =

The red thing has to be 0xb802 (UNDEFINEDFIRMWARE) for the player recognizing it.

[iSE]

A small comment I noticed, my ZVM gave that responsecode pretty fast; so it must be computing the checksum while it is receiving the firmware, cause computing the SHA-1 checksum even on a 1,0Ghz comp takes 10 to 15sec ...

Just to check, are you sure that the player actually calculates the checksum, or just compares it with a static one? try altering the nk.bin but leaving the checksum the same. Does that fail? I know theres a 99.9% chance it will but it mite be worth eliminating as a step to discovering when the checksum is calculated by the player. (start, middle, during, end etc)

[Hitman2k7]

try altering the nk.bin but leaving the checksum the same.

That's impossible. The checksum completely changes even if you change only 1 byte of the file.


But how does the player know if the file is an official one? I mean they all have different checksums and creative has no influence on them...

[aegis]

try altering the nk.bin but leaving the checksum the same.

That's impossible. The checksum completely changes even if you change only 1 byte of the file.

I think iSE knows it.
What he says is: are you sure the player actually calculates the checksum? Maybe it's only comparing some strings here and there? And if it calculates the checksum - on which stage is it done? Is it calculated for the whole code? etc. etc.

But how does the player know if the file is an official one? I mean they all have different checksums and creative has no influence on them...

Again: are you sure with your assumptions?
Certainly, the Creative must have the influence upon them - unless they stuff their code with a large pile of rubbish by design just to fit some arbitrary checksum - however I wouldn't bet it would really work.
So, if altering the code and putting the right checksum (again, are you sure? ) in the end does not work, it means for me there must be some duplicate of the checksum in the code. Maybe it's split on two or more strings, maybe it's *very simply* encrypted (like add 1 to a char, or so on), maybe it's something more sophisticated, some version code or whatever - I don't know - but there must be some way for the program to validate the update and say "sorry, it's not ours".

[iSE]

Agreed. There are a lot of assumptions flying around and a lot of progress has been made, however, specifics are needed and facts should be seperated from supposition.

What if we just run through what is known, what is assumed to be true, n what there is a vague suspicion of? This could then help to recap where everyone is up to and we can finally update the wiki lol.

mcuelenaere, im trying to make sense of this template for the 010 editor that I_e made on the epizenter forum. However, using the latest firmware: ZENVisionM_60GB_PCFW_L21_1_21_02e, I do not seem to be able to get the same results or locate the checksum in nk.bin. Does it only work with the 30GB version?

What I am hoping to try is to remove the NULL part containing the checksum and then calculate various hashes from the rest of it to determine which checksum the NULL block matches. Since I am assuming the checksum would not be calculated from the checksum itself. What if we get together a list of the different checksums, that mite help to calculate the algorithm?

[mcuelenaere]

mcuelenaere, im trying to make sense of this template for the 010 editor that I_e made on the epizenter forum. However, using the latest firmware: ZENVisionM_60GB_PCFW_L21_1_21_02e, I do not seem to be able to get the same results or locate the checksum in nk.bin. Does it only work with the 30GB version?

What I am hoping to try is to remove the NULL part containing the checksum and then calculate various hashes from the rest of it to determine which checksum the NULL block matches. Since I am assuming the checksum would not be calculated from the checksum itself. What if we get together a list of the different checksums, that mite help to calculate the algorithm?

Maybe you could upload your nk.bin and I'll then see what I can do Normally, the structure applies to all currently known ZVM firmwares. And if you want to remove the NULL part, you can just remove the last 28 bytes('NULL'+size of the block+block itself).
I tried myself calculating the SHA-1 hash & RIPEMD160 of various parts of the firmware, but couldn't find a corresponding hash. Either Creative uses an altered version of SHA-1 or they use a self-made hash (doubt it) or I haven't found the right spot to calculate the hash

But what's a fact is that in the firmware update program, there is a SHA-1 (based) hash calculation routine. Maybe if someone who is familiar with X86/Win32 hacking could disassemble the functions? Or if some people who know ARM could disassemble the firmware itself? (although I think this is harder and less people exist who know ARM than people knowing X86 (especially Win32)..)

[iSE]

It may well be the case that Im just using 010 Editor incorrectly, I've never used it before but I do have some experience with checksums and assembly (which isnt ALL too dissimilar from ARM) so if I can first understand what you've discovered so far, hopefully i may be able to help.

You mention the update program uses a SHA-1 (based) hash calculation routine? What do you know about this? Wouldnt it be reasonable to test the same routine on the firmware itself?

Ideally, what we are after is the calculation algorithm correct? Hopefully we could try and create a keygen and we'd be sorted! lol

Here is my nk.bin: http://www.verzend.be/v/2461049/nk.bin.html

[mcuelenaere]

If you look at the structure of the firmware, you have something like this:
struct BLOCK FFIC,CIFF,0h,21767708
struct BLOCK block[0],CINF,8h,104
struct BLOCK block[1],DATA,70h,52396
struct BLOCK block[2],DATA,CD1Ch,553456
struct BLOCK block[3],©TL ,93F0Ch,2530680
struct BLOCK block[4],DATA,2FDC84h,518298
struct BLOCK block[5],DATA,37C51Eh,1533734
struct BLOCK block[6],DATA,4F2C44h,8234664
struct BLOCK block[7],DATA,CCD2ECh,8131192
struct BLOCK block[8],DATA,148E564h,141792
struct BLOCK block[9],DATA,14B0F44h,52446
struct BLOCK block[10],DATA,14BDC22h,11602
struct BLOCK block[11],DATA,14C0974h,390
struct BLOCK block[12],EXT0,14C0AFAh,6946
struct BLOCK block[13],NULL,14C261Ch,28

The first block (the CIFF block) is EXACTLY the size of the full firmware EXCEPT the NULL block (containing the checksum).
This can't be a coincidence, can it? I mean, this has to got to mean that the NULL block contains the checksum of the whole CIFF block.
The only problem is that nor the SHA-1 hash nor the RIPEMD160 hash is the same...

[mcuelenaere]

Here is my nk.bin: http://www.verzend.be/v/2461049/nk.bin.html

This one works perfectly with the template Are you using this one?

Code: [Select]

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

typedef struct {
CHAR BlockID[4];
DWORD Size;
if (BlockID == "FNIC"){
UCHAR Desc[96];
} else if (BlockID == "LLUN" || BlockID == "FFIC"){
UCHAR Data[ Size ];
} else {
UCHAR Desc[32];
UCHAR Data[ Size - sizeof(Desc) ];
}
} 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;

LittleEndian();
id = ReadUInt( FTell() );

if (id == 0x43494646){ // "CIFF"
BLOCK FFIC;
FSeek( 8 ); //Move back to first "real block", since CIFF-block includes most of the stuff
ofs = 8;
while ( !FEof() ){
FSeek( ofs );
BLOCK block;
FSeek( ofs+sizeof(block) );
ofs = FTell();
}
} else {
Warning ("Not valid CIFF-header. Exiting");
return -1;
}

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

[iSE]

I was using a different version of this i think. In my template results window, i got 21 blocks which are all:

struct MSG1 MSG1Block[X]

X being in increments of 0-20.

trying the template you suggest gives me a syntax error on line 30...

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

It is possible that not all of the NULL block is the checksum. I've seen in the past that buffers are included at the start or finish to fill out the checksum making the original unknown. If I can get access to the information you do, I'll try other checksums.

Would collecting all the different checksums from various people not help to narrow down the possible algorithm?

[mcuelenaere]

I was using a different version of this i think. In my template results window, i got 21 blocks which are all:

struct MSG1 MSG1Block[X]

X being in increments of 0-20.

This one is for Hjukebox2.jrs, which is a block in nk.bin ; )

trying the template you suggest gives me a syntax error on line 30...

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

Normally, this one should work; which version of 010 Editor are you using? Maybe try a fresh start and restart the app or so : )

It is possible that not all of the NULL block is the checksum. I've seen in the past that buffers are included at the start or finish to fill out the checksum making the original unknown. If I can get access to the information you do, I'll try other checksums.

Could be, I don't have a lot experience with hacking DAP's. But this way looks very believable to me, the structure looks perfect and so; but I could be wrong : )

Would collecting all the different checksums from various people not help to narrow down the possible algorithm?

I don't know if that could help, but maybe it can. Do you mean collecting all the checksums from the different versions of the firmware?
But I think hacking the firmware update program is going to be more productive ; )

[TheBlackCat]

I was wondering, is the MTP requirement built into the hardware or can it be changed if the firmware is replaced?

[mcuelenaere]

I was wondering, is the MTP requirement built into the hardware or can it be changed if the firmware is replaced?

It is pure software; if the Rockbox USB stack is going to get into SVN & the ZVM target will get ported I don't think MTP will get supported anymore

[LambdaCalculus]

I was curious about something. If the MTP stack is in software on the ZVM, would this also apply to other Creative NOMAD/ZEN players? I have been trying to gather up info on the Dell Digital Jukebox to help start a port (the thread's at http://forums.rockbox.org/index.php?topic=11368.0).

At the risk of going a bit off topic to the ZVM, would any research done on this platform apply to nearly any NOMAD/ZEN platform? The Dell DJ is OEM'ed from Creative, uses MTP to transfer media, and is TMS320-based. So can this info be spread across the entire line?

[saratoga]

I was curious about something. If the MTP stack is in software on the ZVM, would this also apply to other Creative NOMAD/ZEN players? I have been trying to gather up info on the Dell Digital Jukebox to help start a port (the thread's at http://forums.rockbox.org/index.php?topic=11368.0).

I don't think hardware MTP devices exist.  Its just a protocol run on top of USB, theres no sense in making one.