7D firmware failure - Firmware Dumping - CHDK Forum
« previous next »
Pages: [1]   Go Down

7D firmware failure

  • 1 Replies
  • 3483 Views
*

Offline hudson

  • *
  • 43
7D firmware failure
« on: 04 / October / 2009, 20:22:41 »
Advertisements
As I mentioned in 7D initial steps, I've determined the device ID of the 7D to be 0x80000250 and have tried to build a test.fir file that should put the camera into an infinite loop.  When the device ID is set to 0x80000218, the image works perfectly on the 5D Mark II, but on the 7D it displays an orange error box after several seconds of displaying the "loading firmware" screen.  Is there any documentation the format of the .fir file?  Perhaps the 7D is checking some fields that the 5Dm2 does not?


Logged
*

Offline hudson

  • *
  • 43
Re: 7D firmware failure
« Reply #1 on: 30 / October / 2009, 20:08:16 »
It is still not working, but there is some minor progress: I can re-encrypt the official 7D flasher and stuff it back into the firmware file successfully.  This isn't very useful since I can't change it, but at least it indicates that my versions of the symetric encryption routines are working (in decrypt-block) and that I better understand the way the block header works in the firmware file.  One thing that I don't understand is why the 5D Mark II allows us to run a non-encrypted firmware file.  That doesn't make sense.

The other news is that I have found that only the flasher is protected by what ever signature is being used.  The payload is not, other than the whole file checksum stored in the file header at offset 0x20.  I was able to modify some bytes in the payload, update the checksum and the flasher will still load.  I'm not bold enough to try actually flashing a modified firmware image since we haven't finished decrypting it...

For future reference:
Code: [Select]
        ./decrypt-block \
                0x6dcb1922 \
                < 7d-flasher.bin \
        | dd \
                of=/Volumes/EOS_DIGITAL/7d.fir \
                bs=1 \
                seek=0x120 \
                conv=notrunc \

The 0x6dcb1922 is the IV used by the symetric XOR encryption algorithm and is stored at offset 0xbc in the header. There must be another signature somewhere in the header that is being used to validate the flasher code image since swapping bytes in it to preserve the file-wide CRC still produces the orange box error.

Logged
Pages: [1]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal