It's been some time since I've done any work on the 7D -- the National Film Challenge and other work has occupied 150% of my time the past few weeks.
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 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 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...
And in additional 7D firmware news, I hear that Canon may be releasing yet another firmware update for the camera. So we'll have something else to compare against if we ever get our program running inplace of the flasher.
On Fri, Oct 30, 2009 at 07:42:32PM -0400, Trammell Hudson wrote: > [...] I can re-encrypt the official 7D flasher and stuff it back into the > firmware file successfully.
The 0x6dcb1922 is the IV used by the symetric XOR encryption algorithm. There must be another signature somewhere in the header that is being used to validate the flasher code image.
As a hack to avoid flashing bogus payloads, touch a second foo.fir file on the CF card. This will force the flasher to bring up a file requester before flashing.
It's been some time since I've done any work on the 7D -- the
National Film Challenge and other work has occupied 150% of my time
the past few weeks.
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 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 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...
And in additional 7D firmware news, I hear that Canon may be releasing
yet another firmware update for the camera. So we'll have something
else to compare against if we ever get our program running inplace of
the flasher.
On Fri, Oct 30, 2009 at 07:47:28PM -0400, Trammell Hudson wrote: > The 0x6dcb1922 is the IV used by the symetric XOR encryption algorithm. > There must be another signature somewhere in the header that is being > used to validate the flasher code image.
Continuing my investigation, the signature (?) at 0x88 - 0x9B in the header does not appear to be the flasher's (it is likely the signature of the payload). I can write random values into it, regenerate the checksum and everything is fine.
The 160 bit signature at 0x68 does appear to be that of the flasher binary image. SHA-1 is 160 bits and I see references in the 5D Mark II firmware to CRP_HashSwSha1Wrap_Init(). Additionally, the function at 0xffb65d68 clearly is a SHA1 implementation: the constants 0x5a827999, 0x6ed9eba1 and 0x8f1bbcdc are straight from the SHA1 book. The constant 0x359d3e2a, however, is not (should be 0xca62c1d6 for rounds 60-79, although there is an SUB R6, LR, R6 after the load, but I'm not sure what is in LR at that point).
Running sha1sum against both the flasher binary and the encrypted form doesn't produce a correct sum, so there may be a HMAC in use. That would be problematic (and is the way that I have implemented secure boot loaders in the past). I'm looking in the 5D firmware to see if I can find any sort of HMAC type calls.
On Fri, Oct 30, 2009 at 07:50:22PM -0400, Ba...@aol.com wrote: > Is it possible that on the next firmware upgrade for the 5D that Canon will > be blocking ML access on that camera too ?
Who knows what they will do... I'm hoping that we can figure it out on the 7D and have a working solution. The SHA1 code certainly looks very promising.
On the other hand, as part of another project I have designed a SHA1 / AES128 HMAC based boot loader that is approved for export controlled applications. It is possible to build these sorts of things in such a way that it is very, very difficult to get in:
The verification routine does not care if the payload is present. Truncating the firmware file to end after the encrypted flasher program does not cause the orange box error. That is interesting (and a good way to brick a camera!).
The signature covers the entirety of the flasher binary. I changed a byte near the end and it still caused the orange box error.
Summary so far of header (I'll add this to the wiki tomorrow):
0x00: Device ID 0x04: MBZ 0x08: MBZ 0x0c: MBZ
0x10-0x1f: Version of firmware (ASCII string)
0x20: File checksum (literally the sum of all the bytes) 0x24: Points to header at 0xb0. Flasher header? 0x28: Points to start of encrypted flasher binary at 0x120 0x2c: Some sort of length? 5D has 0xffffffff, 7D has 0x001c0970 Setting this to 0xFFFFFFF or any other value causes orange box on 7D. Length does not correspond to any known sizes.
0x30: Points to start of payload header (sizeof flasher + 0x120) 0x34: Length of payload (0xFFFFFFFF == until end of file?) 0x38: Length of file in bytes 0x3c: MBZ
0x40: Checksum of some sort? Changing it causes orange box. 0x44: Always 0x04 (both) 0x48: MBZ 0x4c: Always 0x20 (both)
0x60: Flasher + 0x120. Start of payload? 0x64: Payload length - 0x18? 0x18 == size of file header? 0x68-0x7b: SHA1 sum of flasher + HMAC (?) 0x7c: MBZ
0x80: MBZ 0x84: MBZ 0x88-0x9b: SHA1 sum of payload + HMAC (?) (no orange box) 0x9c: MBZ
0xa0-0xaf: MBZ
0xb0: Length of flasher program in bytes (orange box) 0xb4: Length of flasher program - 8 (orange box) 0xb8: MBZ 0xbc: IV for XOR decryptor (orange box)
I've found in the 7D flasher where it checks its own decrypted checksum. The function at 0x849224 (called by UPD_DecipherUpdater() at 0x0a514) does the double XOR decryption using the tables loaded into the rwdata segment around 0x2a8b.
I am still looking for the code to decode the actual firmware file. There isn't an obvious set of strings that point to an AES table for decryption, but it looks like the checksum on the payload is sha1 as we had assumed. I am hoping that the flasher uses the same algorithm so that we can compute a valid signature for it.
On Sat, Oct 31, 2009 at 04:49:49PM -0400, Trammell Hudson wrote: > I've found in the 7D flasher where it checks its own decrypted > checksum. The function at 0x849224 (called by UPD_DecipherUpdater() > at 0x0a514) does the double XOR decryption using the tables loaded > into the rwdata segment around 0x2a8b.
How many signature schemes does Canon need? In this one function (0x80a3b0) I have found function calls that use tables for their homebrew XOR, sha1, md5 and sha256. WTF?
