Rockbox Development > New Ports
Creative Zen Vision:M
zook:
--- Quote from: davidb on July 30, 2007, 01:30:29 AM ---I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.
--- End quote ---
I'm a bit limited by not owning the player but I've unpacked the firmware image stored in ZENVisionM_30GB_PCFW_L21_1_62_02e.exe.
There is a checksum within the NULL block: 45E2 DCDD 4C07 2B99 5DDB B21A B15A D1EF 55CC 6A3A
But I can't say if it differs from the one sent to the device.
--- Quote from: mcuelenaere on August 28, 2007, 09:37:54 AM ---The file could be XORed with this key: '34d12D23f6c894B96ff4735153836'
--- End quote ---
Close. The key is slightly mutated first.
Decrement each character by one, and OR 0x80 to the result.
Then it's just standard zlib inflate from there on.
The process is the same for the Jboxcrl.crl and unicow.dll.
Has it been established if all segments within the firmware image effect the checksumming? Is the segment headers included in the sum? If the scope was more limited, it would be more feassible to perform crypt analysis on the different versions of the checksums.
I'm mostly inclined to believe that the checksum is a standard algorithm, who's result get's mutated to obscure where it's from. Based on the mutation used in the updater, I'm guessing that it's simple enough to be discovered through basic crypt analysis.
mcuelenaere:
--- Quote from: zook on September 12, 2007, 01:21:19 PM ---
--- Quote from: davidb on July 30, 2007, 01:30:29 AM ---I really think what we need to be concentrating on is answering the question I posed earlier - does the firmware come with the checksum value already in the null block, or does the updater put it there.
--- End quote ---
I'm a bit limited by not owning the player but I've unpacked the firmware image stored in ZENVisionM_30GB_PCFW_L21_1_62_02e.exe.
There is a checksum within the NULL block: 45E2 DCDD 4C07 2B99 5DDB B21A B15A D1EF 55CC 6A3A
But I can't say if it differs from the one sent to the device.
--- Quote from: mcuelenaere on August 28, 2007, 09:37:54 AM ---The file could be XORed with this key: '34d12D23f6c894B96ff4735153836'
--- End quote ---
Close. The key is slightly mutated first.
Decrement each character by one, and OR 0x80 to the result.
Then it's just standard zlib inflate from there on.
The process is the same for the Jboxcrl.crl and unicow.dll.
--- End quote ---
Wow, that's some pretty nice accomplishment you've got there :)
Could you provide me with some more information about dexoring the contents (so each character of the key is decremented by one and then you just OR 0x80 every character of the raw contents incrementing the position in your key-string?) or did you make a little program which does the extracting?
And as you're saying the extracted nk.bin file already got an NULL block, this means that we are back to square 1..
--- Quote ---Has it been established if all segments within the firmware image effect the checksumming? Is the segment headers included in the sum? If the scope was more limited, it would be more feassible to perform crypt analysis on the different versions of the checksums.
I'm mostly inclined to believe that the checksum is a standard algorithm, who's result get's mutated to obscure where it's from. Based on the mutation used in the updater, I'm guessing that it's simple enough to be discovered through basic crypt analysis.
--- End quote ---
I'll try to do an SHA-1 checksum on only the data (so without the segment headers), but it may be easier deassembling FBOOT or FRESC to check if there is some checksum code present there...
edit:
The checksum value gave me 11E2AE6CC89B212F8FA860730B15327336439E7E while the NULL block contains 77 A0 03 39 3E 4A 09 B9 E1 BD 2F 14 09 7A 8A 8C 17 8F 38 AA
zook:
Here's my hacked together code: http://rafb.net/p/vTdhN853.html
The relevant bit is:
--- Code: --- Â Â // Mutate the xorkey.
  for (int i = 0; i < keylen; i++)
  {
    key[i] = key[i] - 1;
  }
  // Decipher the chunk.
  for (int i = 0, j = 0; i < dwChunkSize; i++, j = i % keylen)
  {
    lpChunk[i] ^= (key[j] | 0x80);
  }
--- End code ---
I'll be working on providing an easy way to produce checksums of the different segments.
EDIT: Once that's done it would be nice with some other versions of the firmware for comparison.
mcuelenaere:
--- Quote from: zook on September 12, 2007, 02:24:27 PM ---Here's my hacked together code: http://rafb.net/p/vTdhN853.html
--- End quote ---
I'm trying to get this thing compiled ;) but atm I only got 1 problem left and this is:
--- Code: ---Error 4: fatal error LNK1104: cannot open file 'MSVCMRTD.lib'
--- End code ---
(I'm using VC++ 2005 and I'm getting it both in Release & Debug mode)
Could this mean I should reinstall VC++?
zook:
--- Quote from: mcuelenaere on September 12, 2007, 02:53:34 PM ---
--- Quote from: zook on September 12, 2007, 02:24:27 PM ---Here's my hacked together code: http://rafb.net/p/vTdhN853.html
--- End quote ---
I'm trying to get this thing compiled ;) but atm I only got 1 problem left and this is:
--- Code: ---Error 4: fatal error LNK1104: cannot open file 'MSVCMRTD.lib'
--- End code ---
(I'm using VC++ 2005 and I'm getting it both in Release & Debug mode)
Could this mean I should reinstall VC++?
--- End quote ---
How are you linking to zlib?
With my project I just added a console project to the zlib solution and added a reference.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version