Nikon Hacker

Hi all,

For anyone interested, I think I found the parameters used to compute the CRC on the full bundle (the one stored after the two files) : It's the same x/zmodem algorithm as for the files, with 0x1021 for mask but 0xcd18 as init value, computed on the full bundle up to the byte before the CRC.
More formally, the CRC is "16,0x1021,0xcd18,false,false,0" in Rocksoft (tm) Model CRC Algorithm notation.
It has been checked successfully with D7000 1.03, D5100 1.01 and D3100 1.01.

I started this as a personal challenge because I know the hacked firmware has been accepted by the camera without changing the bundle's CRC and our conclusion was that it was unused. But unless it has been tested with a random value (roos, Simeon ?), I'd be tempted to think it's not the case and we were just lucky the change made in the file was cancelled by the file-based CRC.

Let me explain this theory : the bundle CRC is computed (simplified) as :
header + file1 + file1crc + file2 + file2crc = bundlecrc
As the mask is the same for the file crcs and the bundle crc, the part (file1 + file1crc) is neutral to the bundle CRC computation. Same for (file2 + file2crc) of course.
In other words, if you change a few bytes in file1, then recompute file1crc, the changes compensate each other and bundlecrc will not be affected.

So my bet is that as long as we keep the header unchanged, we'll be able to completely change file1 and file2, recompute their CRCs, leave the bundlecrc as is and go unnoticed.
But as soon as we'll change the header (mandatory once the size of the bundled files will change), then we run the risk of having the bundle rejected by the camera.

Does it make sense to people more used to CRC computation ?

Kind regards,

Oh, by the way, I tried hard to understand the 0x20 first bytes (that Simeon called "fluff" ) of the decrypted file and didn't find any logic in them at all... before realizing that all encrypted files begin with 32 blank chars (char 0x20). So obviously, once hashed, those characters don't have any meaning and can safely be treated as a fixed header in the decrypted file. Once encrypted back, this header will render back as 32 blanks.
It was probably obvious to Simeon because he started from the encrypted files, but for most of us who started after Vitaliy's ntools, I thought it would be intersting to know.
Best regards,

Good job Vicne!

I don't have the knowledge to offer much constructive feedback, except for encouragement. But it is great to know that if you are correct and the bundle CRC comes into play once the headers change, we have a way to compute them.

Trying to read up on this stuff, but it's tough. I think I'm gone need a firmware hacking for dummies example to get me started with this thing.

-Kyle

Nice work Vicne!

Hi Vicne,

I agree in theory that the bundle CRC may be checked. But your scheme does not hold true for my hacked firmware, which does work on camera.
Also the CRC for my hacked firmware is different than the CRC for my non-hacked firmware.

Simeon