Rockbox Development > New Ports
Creative Zen Vision:M
mcuelenaere:
--- Quote from: iSE on July 08, 2007, 06:22:39 AM ---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?
--- End quote ---
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:
--- Quote from: iSE on July 08, 2007, 07:24:25 AM ---Here is my nk.bin: http://www.verzend.be/v/2461049/nk.bin.html
--- End quote ---
This one works perfectly with the template :) Are you using this one?
--- Code: ---//--------------------------------------
//--- 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;up
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version