Welcome to the Rockbox Technical Forums!
so perhaps the bootloader is only checksumming certain blocks of the firmware, and skipping others?
Anyway, I was thinking last night: there are several F* (FBOOT, FRESC) blocks and several H* (Hjukebox.grs, Hjukebox2.jrs, ...) blocks; if the F refers to flash and the H to HDD, it would mean everytime an upgrade is performed the boot code is flashed.To prove my theory: if you look at the rescue menu, you'll see a version number. If you upgrade your firmware, this number changes. But if your HDD becomes corrupt or your ZVM won't boot anymore (you come automatically in Rescue mode), this number is the same (so it doesn't depend on a file on HDD).So in short, a HDD dump wouldn't give us any real useful information, because (boot) code is stored in ROM/flash.Also, there are 2 other strange blocks in nk.bin (EXT0 and an encrypted one), maybe one of them could contain DSP code and/or are written to a specific place (as none of them has an H or F in front of their name); but this has nothing to do with the above.
I believe your right about the F* and H* theory and therefore about the HDD dump not providing anything about the hashing algorithm. 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.
could it be that its encrypted aswell?
Quote from: davidb on July 30, 2007, 01:30:29 AMI believe your right about the F* and H* theory and therefore about the HDD dump not providing anything about the hashing algorithm. 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.Indeed, I agree with you.But to find out, we should extract the firmware from the .exe where it is ZLIB compressed.I already tried decompressing it, but without any result (see some posts back).Could someone else try this?
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.
The file could be XORed with this key: '34d12D23f6c894B96ff4735153836'
Quote from: davidb on July 30, 2007, 01:30:29 AMI 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.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 6A3ABut I can't say if it differs from the one sent to the device.Quote from: mcuelenaere on August 28, 2007, 09:37:54 AMThe file could be XORed with this key: '34d12D23f6c894B96ff4735153836'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.
  // 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);   }
Here's my hacked together code: http://rafb.net/p/vTdhN853.html
Error 4: fatal error LNK1104: cannot open file 'MSVCMRTD.lib'
Quote from: zook on September 12, 2007, 02:24:27 PMHere's my hacked together code: http://rafb.net/p/vTdhN853.htmlI'm trying to get this thing compiled but atm I only got 1 problem left and this is: Code: [Select]Error 4: fatal error LNK1104: cannot open file 'MSVCMRTD.lib' (I'm using VC++ 2005 and I'm getting it both in Release & Debug mode)Could this mean I should reinstall VC++?
Page created in 0.127 seconds with 19 queries.