Creative Zen Vision:M

[Bagder]

The Neuros guys have said that you do have to use the DSP since the DSP side is what accesses the DAC so there's no sound otherwise. I guess the ArchOpen guys/source code can either dismiss or confirm this.

So actually, this is some very good news. And I understood that the DSP also is used for the MPEG4/Xvid/DivX playback ? And that it also supports other audio codecs than MP3/WMA? Are these implemented in the API of Neuros ? I'll take a look at the source code myself, but as I did this before and didn't came up with anything relevant, I thought it would be better if I asked it here.

The DSP is used for everything DAC-related so that would include videos, yes. And the chip wouldn't have a chance to display full frame-rate video on a TV without using the DSP pretty good.

Lots of the codecs Neuros use are in the DSP parts and they're not provided in source at all.

[toffe]

you are right, they have a zen pmc, and the zen m seems to be a creative software, not pmc
my mistake

[saratoga]

Its definately based on Windows CE (hence the nk.bin and MS dev tools for everything).

PMC is also based on Windows CE, so it may be basically the same thing.

Edit:

Also, heres the nk.bin if anyone else wants a look:

http://www.duke.edu/~mgg6/rockbox/nk.bin

Also, the nk.bin is compressed inside the updater, so don't expect to see ARM in there.  Even zipped its still about 10-12MB, maybe more, so almost the entire updater is just the compressed file with a bit of x86 to decompress it and handle the USB stuff I think.

[mcuelenaere]

Its definately based on Windows CE (hence the nk.bin and MS dev tools for everything).

PMC is also based on Windows CE, so it may be basically the same thing.

Edit:

Also, heres the nk.bin if anyone else wants a look:

http://www.duke.edu/~mgg6/rockbox/nk.bin

Also, the nk.bin is compressed inside the updater, so don't expect to see ARM in there.  Even zipped its still about 10-12MB, maybe more, so almost the entire updater is just the compressed file with a bit of x86 to decompress it and handle the USB stuff I think.

I sincerely doubt it that ZVM is running WinCE. You are right concerning the updater program, but I'm not sure if you read through the epizenter.net thread, cause there has been already some "disassembling" on the nk.bin: it's splitted up in several blocks and those can be extracted.

According to http://libnjb.cvs.sourceforge.net/libnjb/libnjb/HACKING?revision=HEAD(search for 'CIFF'), these files are also (partly) on older Zen's, which means the OS of the ZVM is based on their OS, and (stated in that same file) the OS of a Jukebox is OaSis; I don't know if this is the same on the Zen Xtra or newer Zen's...

Anyway, if you haven't read the epizenter.net thread, plz do it sometime; if you have, srry for bringing this up.

[larryzotter]

Anyone tried taking out the ZVM's hdd and plugging it using an adapter to a computer?

[iSE]

yeah, I think jhulst is awaiting an adapter for the test player he has

[Febs]

Folks, a reminder:  please DO NOT post in this thread merely to ask about updates.  Post in this thread ONLY if you are participating in discussion directly related to development of Rockbox for this platform.

[mcuelenaere]

Hi,

as some of you may know, there's a lot of discussion about the ZVM and firmware hacking on epiZENter.net

In short, I'll make up a list of what we've found out and/or think which is correct:

• The firmware(nk.bin) has it's own structure: it starts with a CIFF block, and then it's divided into several other blocks (ending in a NULL block)
• One of the blocks seems to be obfuscated/encrypted(the third one, if I recall correctly)
• The last block (the NULL block) is 20 chars long, and contains a hash/checksum. It's no common used one, cause MD4, MD5, SHA1 don't match it. (20 chars should mean 160-bit)
• A list of names is: FBOOT, FRESC, HCreative_S.TTF, HCreative_T.TTF, HDeviceInfo.xml, Hdevicon.ico, Hdevlogo.png, Hjukebox2.jrs, Hjukebox.grs, Hsplash.jbm.
• All files/blocks starting with a "H" should get written directly to the ZVM's HDD partition.
• The partition type could be minifs or CFS(Creative File System)
• The ZVM's OS could be OaSis
• I've made a program which 'hacks' the upgrading process of the jukebox updater being able to upload custom firmwares, but because the checksum isn't cracked, it's useless.
• The *.jrs, *.jbm (and maybe *.grs) files are also divided into blocks, but as it is a newer version than reported on Nomadness, for the moment they aren't readable.
• The jukebox.grs structure may been deciphered, can't confirm it at the moment. (see http://epizenter.net/e107_plugins/forum/forum_viewtopic.php?69697.75)
• The *.jrs structure is deciphered: http://epizenter.net/e107_plugins/forum/forum_viewtopic.php?69697.135
• Some xtra links: http://libnjb.cvs.sourceforge.net/libnjb/libnjb/HACKING?revision=HEAD
• A C program from libnjb, being able to extract nk.bin from the updater program. (I haven't compiled it though) fwupgrade.c
• Maybe some other stuff I missed out... Check the epizenter.net thread for more...
• Just an idea: if the checksum checking is done on the PC side, it could be interesting of monitoring the USB data transfer (and commands) of a successful upgrade, and then fake another one with your hacked firmware.

Oh, and one more thing: I strongly believe that messing around with MTP leads to nothing: the firmware will never allow you to view it's partition data. (The only possible thing you could achieve, is uploading a new firmware)

[kkffiirr]

i like the idea about monitoring the usb activity, but it sounds so easy, why no one ever tested it?
i am thinking about monitoring it myself and posting the data here....

[mcuelenaere]

i like the idea about monitoring the usb activity, but it sounds so easy, why no one ever tested it?
i am thinking about monitoring it myself and posting the data here....

Actually, I did it myself before. I came up with a 90MB(or bigger) file and because my PC hasn't got much RAM and I didn't found any decent program to read it, I didn't do anything with it.
I think it's just some commands, then the raw nk.bin file, then again some commands and it's done.

[aliask]

Hi,

• The last block (the NULL block) is 20 chars long, and contains a hash/checksum. It's no common used one, cause MD4, MD5, SHA1 don't match it. (20 chars should mean 160-bit)

SHA1 is 160 bit.

[mcuelenaere]

SHA1 is 160 bit.

Indeed, but they don't match:

SHA-1 OF 'FFIC' BLOCK: 9A 4F 20 B0 2B F3 91 99 D7 A6 6A FD C7 A6 1C 68 10 AF 82 4A

DATA OF 'NULL' BLOCK: 41 A3 63 2B 2E C2 C6 F7 DF 31 99 D8 61 2E 76 99 77 07 CB 19

BTW, this is the 010 Editor Template I use for parsing the blocks, it works perfectly.

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'm no expert on cryptography, but supposed we were to literally try to brute force that encryption, how long would that take? If its a reasonable time frame, say a few months I have an incredibly fast computer not doing anything at the moment.

[larryzotter]

But how would u 'verify' that the bruteforced checksum is correct? Try and update the firmware with the checksum to the ZVM and see if it accepts it? That would take a looooooong time...

[Bagder]

I'm no expert on cryptography, but supposed we were to literally try to brute force that encryption,

160 bits SHA1 is simply not possible to brute-force within our lifetimes, even if we'd use a hundred thousand modern PCs. Compare with the 72bit RC5 cracking contest.

Edit: contest is not contents ;-)