7D firmware file update
Trammell Hudson
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.
--
Trammell
Trammell Hudson
> [...] I can re-encrypt the official 7D flasher and stuff it back into the
> firmware file successfully.
For the record:
./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.
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.
--
Trammell
Ba...@aol.com
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
Trammell Hudson
> 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.
--
Trammell
Trammell Hudson
> 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:
http://wiki.hacdc.org/index.php/Secure_bootloader
The worst case scenario would be that we would need to figure out
how to get in through the sio port or one of the numerous debug
ports on the camera.
--
Trammell
Trammell Hudson
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)
0x50: Always 0x24 (both)
0x54: Always 0x44 (both)
0x58: Always 0xb0 (pointer to flasher header?)
0x5c: Flasher + 0x70 ?
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)
0xc0-0xcf: MBZ
0x120: Start of encrypted flasher
Sample 7D header (1.0.9):
0000000 80000250 00000000 00000000 00000000
0000010 2e302e31 00000039 00000000 00000000
0000020 9e5642e5 000000b0 00000120 001c0970
0000030 0022e200 ffffffff 00c41b8c 00000000
0000040 b99b53de 00000004 00000000 00000020
0000050 00000024 00000044 000000b0 0022e150
0000060 0022e200 00a1398c 3d9250ec 89263417
0000070 e4684520 27a4132d 342246d5 00000000
0000080 00000000 00000000 116147a3 12b56111
0000090 3efd1d5c a748337f 56f9927a 00000000
00000a0 00000000 00000000 00000000 00000000
00000b0 001c0850 001c0850 00000000 6dcb1922
00000c0 00000000 00000000 00000000 00000000
Sample 5D header (1.1.0):
0000000 80000218 00000000 00000000 00000000
0000010 2e312e31 00000030 00000000 00000000
0000020 b7384f65 000000b0 00000120 ffffffff
0000030 001a0cd0 ffffffff 0092224c 00000000
0000040 9d6fd907 00000004 00000000 00000020
0000050 00000024 00000044 000000b0 001a0c20
0000060 001a0cd0 0078157c 12538b62 59432b66
0000070 de3ad22d cfe0931e ea8a2d92 00000000
0000080 00000000 00000000 6a7a4463 ff3a6731
0000090 0fefd218 adfe6ae7 6dce3526 00000000
00000a0 00000000 00000000 00000000 00000000
00000b0 001a0bb0 001a0ba4 00000000 348e2ce8
00000c0 00000000 00000000 00000000 00000000
Sample 5D header (1.0.7):
0000000 80000218 00000000 00000000 00000000
0000010 2e302e31 00000037 00000000 00000000
0000020 b7932bae 000000b0 00000120 ffffffff
0000030 001a0de0 ffffffff 009168cc 00000000
0000040 f4600670 00000004 00000000 00000020
0000050 00000024 00000044 000000b0 001a0d30
0000060 001a0de0 00775aec a3a82005 5969f763
0000070 ff0951b2 e1d8a2e5 ec8487c2 00000000
0000080 00000000 00000000 f733aad6 44ad45bd
0000090 86e85aca cad9aa2f b8c91f31 00000000
00000a0 00000000 00000000 00000000 00000000
00000b0 001a0cc0 001a0cb4 00000000 78021ac9
00000c0 00000000 00000000 00000000 00000000
--
Trammell
Trammell Hudson
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.
--
Trammell
Trammell Hudson
> 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?
--
Trammell