Rockbox Development > New Ports
Creative Zen Vision:M
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: ---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
--- End code ---
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:
--- Quote from: zook on September 13, 2007, 09:23:12 AM ---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.
--- End quote ---
Could be
--- Quote ---One odd thing that I've discovered is that the FBOOT DATA segment is the exact same size in the majority of these.
--- End quote ---
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)
--- Quote ---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.
--- End quote ---
Are you talking here about EXT0 or about LT© ?
--- Quote ---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.
--- End quote ---
Hopefully they did :)
I also took a look at the firmware and I made some little changes to the 010 Editor parsing template:
--- Code: ---//--------------------------------------
//--- 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;
//--------------------------------------------
--- End code ---
The rest stays the same.
Together with the template above I made this one for EXT0:
--- Code: ---//--------------------------------------
//--- 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;up
zook:
--- Quote from: mcuelenaere on September 13, 2007, 11:27:17 AM ---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)
--- End quote ---
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.
--- Quote from: mcuelenaere on September 13, 2007, 11:27:17 AM ---Are you talking here about EXT0 or about LT© ?
--- End quote ---
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.
--- Quote from: mcuelenaere on September 13, 2007, 11:27:17 AM ---I also took a look at the firmware and I made some little changes to the 010 Editor parsing template:
--- End quote ---
Ahh, I tried using the other template earlier, but the board software displays the code incorrectly.
mcuelenaere:
--- Quote from: zook on September 13, 2007, 01:04:24 PM ---Ahh, I tried using the other template earlier, but the board software displays the code incorrectly.
--- End quote ---
http://rafb.net/p/Y25m3N12.html
http://rafb.net/p/YoH1fj87.html
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version