Any developers interested in working on CHDK firmware for DSLRs ? - page 19 - DSLR Hack development - CHDK Forum

Any developers interested in working on CHDK firmware for DSLRs ?

  • 202 Replies
  • 102015 Views
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #180 on: 10 / January / 2009, 10:45:33 »
Advertisements
I've tried searching for your AES table values, but can't seem to find them in the 5D MKII fir.

should be there. try to search the sbox - it is byte per byte without endianess troubles:
Code: [Select]
ROM:00990FCC 52 09 6A D5+ byte_990FCC    DCB 0x52,   9,0x6A,0xD5,0x30,0x36,0xA5,0x38; 0 ; DATA XREF: ROM:off_8A459C                                    
ROM:00990FCC BF 40 A3 9E+                DCB 0xBF,0x40,0xA3,0x9E,0x81,0xF3,0xD7,0xFB; 8 ; AES::SD[256]
ROM:00990FCC 81 F3 D7 FB+                DCB 0x7C,0xE3,0x39,0x82,0x9B,0x2F,0xFF,0x87; 16
ROM:00990FCC 7C E3 39 82+                DCB 0x34,0x8E,0x43,0x44,0xC4,0xDE,0xE9,0xCB; 24
and so on - 256 byte. after this, there is AES::TE0[256]

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #181 on: 10 / January / 2009, 17:29:05 »
in 50d code looks like this:
Code: [Select]
ROM:00804EA0 05 30 A0 11                 MOVNE   R3, R5
ROM:00804EA4 4E 2F 8F 12                 ADRNE   R2, aDUpd_verifyfir             ; "%d=UPD_VerifyFirmware"
ROM:00804EA8 0C 00 00 1A                 BNE     loc_804EE0
ROM:00804EAC 48 11 9F E5                 LDR     R1, =0xB760
ROM:00804EB0 06 00 A0 E1                 MOV     R0, R6
ROM:00804EB4 54 16 00 EB                 BL      decrypt_and_check_fw_sub_80A80C           ; <<- check this! calls AES several times
ROM:00804EB8 00 50 A0 E1                 MOV     R5, R0
ROM:00804EBC 00 30 A0 E1                 MOV     R3, R0
ROM:00804EC0 86 00 A0 E3                 MOV     R0, #0x86
ROM:00804EC4 4D 2F 8F E2                 ADR     R2, aDUpd_decryptof             ; "%d=UPD_DecryptoFirmware"
ROM:00804EC8 16 10 A0 E3                 MOV     R1, #0x16
ROM:00804ECC 06 C0 00 EB                 BL      printf_sub_834EEC
ROM:00804ED0 00 00 55 E3                 CMP     R5, #0
ROM:00804ED4 4F 00 00 0A                 BEQ     loc_805018                      ; go to print checksum
ROM:00804ED8 05 30 A0 E1                 MOV     R3, R5
ROM:00804EDC 47 2F 8F E2                 ADR     R2, aDUpd_decryptof             ; "%d=UPD_DecryptoFirmware"

the code at 0x80A80C calls 2 subroutines - 1st to decrypt (which is AES decryption), 2nd to calculate the checksum/signature (which is a SHA256). Both not compromised!
I think we've got the key within one of those headers?!

the interesting subroutine is here:
Code: [Select]
ROM:0080A80C             decrypt_and_check_fw_sub_80A80C                         ; CODE XREF: sub_804D18+19Cp
ROM:0080A80C                                                                     ; sub_805034+94p
ROM:0080A80C
ROM:0080A80C             arg_28          =  0x28
ROM:0080A80C
ROM:0080A80C 70 40 2D E9                 STMFD   SP!, {R4-R6,LR}
ROM:0080A810 00 50 A0 E1                 MOV     R5, R0                          ; make R5 point to header
ROM:0080A814 00 40 A0 E1                 MOV     R4, R0                          ; make R4 point to header
ROM:0080A818 30 00 90 E5                 LDR     R0, [R0,#0x30]                  ; get 0x19DEA0 - make R0 point to data-header
ROM:0080A81C 04 20 B0 E7                 LDR     R2, [R0,R4]!                    ; get 0x0000000C
ROM:0080A820 00 00 82 E0                 ADD     R0, R2, R0                      ; make R0 point to FW?!
ROM:0080A824 28 20 94 E5                 LDR     R2, [R4,#0x28]                  ; get flasher-header lenght, 0x120 (288 byte)
ROM:0080A828 12 0E 52 E3                 CMP     R2, #0x120                      ; sure, it is
ROM:0080A82C 01 00 00 2A                 BCS     loc_80A838                      ; done
ROM:0080A830
ROM:0080A830             loc_80A830                                              ; CODE XREF: decrypt_and_check_fw_sub_80A80C+54j
ROM:0080A830 00 00 A0 E3                 MOV     R0, #0
ROM:0080A834 70 80 BD E8                 LDMFD   SP!, {R4-R6,PC}
ROM:0080A838             ; ---------------------------------------------------------------------------
ROM:0080A838
ROM:0080A838             loc_80A838                                              ; CODE XREF: decrypt_and_check_fw_sub_80A80C+20j
ROM:0080A838 2C 20 94 E5                 LDR     R2, [R4,#0x2C]                  ; R2: 0xFFFFFFFF
ROM:0080A83C 6D FF FF EB                 BL      decrypt_FW_sub_80A5F8           ; decrypt?!
ROM:0080A840 01 00 70 E3                 CMN     R0, #1
ROM:0080A844 70 80 BD 08                 LDMEQFD SP!, {R4-R6,PC}
ROM:0080A848 00 00 A0 E3                 MOV     R0, #0
ROM:0080A84C 20 00 84 E5                 STR     R0, [R4,#0x20]
ROM:0080A850 38 10 94 E5                 LDR     R1, [R4,#0x38]
ROM:0080A854 05 00 A0 E1                 MOV     R0, R5
ROM:0080A858 01 00 00 EB                 BL      checksum_FW_sub_80A864          ; calc checksum
ROM:0080A85C 20 00 84 E5                 STR     R0, [R4,#0x20]
ROM:0080A860 F2 FF FF EA                 B       loc_80A830
ROM:0080A860             ; End of function decrypt_and_check_fw_sub_80A80C

first call within the "decrypt_FW_sub_80A5F8" is some kind of "memcpy", next calls are to pre-init the arrays, create tables and preset hashes. After this, decryption is done.

we have 2 possible ways:
1. run / singlestep this stuff within a debugger
2. Try external AES-Decryption with possible key-data from the header

I think I am pretty right and we have AES/SHA256 confirmed
« Last Edit: 10 / January / 2009, 17:42:03 by Tyra Misoux »

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #182 on: 10 / January / 2009, 17:45:40 »
Yes! I think we are looking at the same thing. I just can't tell as well since I'm new to ARM assembly. If you follow your
Code: [Select]
BL      decrypt_FW_sub_80A5F8


then you should get to something like this, no?
Code: [Select]

sub_80A62C

var_130= -0x130
var_12C= -0x12C
var_128= -0x128
var_108= -0x108
var_CC= -0xCC
var_C8= -0xC8
var_A8= -0xA8
var_98= -0x98
var_78= -0x78
var_58= -0x58
var_48= -0x48
var_28= -0x28
var_24= -0x24

STMFD   SP!, {R4-R10,LR}
SUB     SP, SP, #0x110
MOV     R10, #0
MOV     R4, R0
STR     R10, [SP,#0x130+var_28]
LDR     R0, [R0,#0xC]
MOV     R7, R1
CMP     R0, #0
MOV     R5, #0x20
BNE     loc_80A660

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #183 on: 10 / January / 2009, 18:02:29 »
Yes, this is the same stuff. Here I have this at 0x80A5F8

I am also new to ARM. Always have to look up about the mnemonics - using this page, for example :-)
RealView Assembler User's Guide: LDM and STM

For experiment the "HsCipherSDK" SDK should work well... damn "Demo-Version". typical windows. takes too much time to make the tools work, first....

This HsCipherSDK is cool stuff and the VC-Demo rocks.
Unfortunately they want 400 euro and 850 euro with sourccode  :lol
to kill the limit search all a1 70 fa 03 10 83 e8 01 a3 and replace the 83 e8 01 by 90 90 90
to kill the nagscreen patch the 55 at offset 0x1520 to 0xC3
("HsCipherSDKDll.dll needs to be modified only)

oh well - you are allowed to do stuff like this in your own memory only. never give such patched files to others.

I do not know if this tool helps. But was a nice exercise tonight and it is a nice crypt SDK anyway. With my girlfriend still in prison, saturday night is good for hacking
« Last Edit: 10 / January / 2009, 21:28:51 by Tyra Misoux »


Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #184 on: 10 / January / 2009, 23:06:18 »
Yes, this is the same stuff. Here I have this at 0x80A5F8
I am also new to ARM. Always have to look up about the mnemonics - using this page, for example :-)
RealView Assembler User's Guide: LDM and STM

Same thing I'm using. I'll link the flasher and flasher header together and then maybe we'll have the same address space and can compare notes. The AES stuff is a little beyond me at the moment, but I can play catch up.

*

Offline reyalp

  • ******
  • 12148
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #185 on: 10 / January / 2009, 23:56:50 »
I am also new to ARM. Always have to look up about the mnemonics - using this page, for example :-)
RealView Assembler User's Guide: LDM and STM
You may also want to refer to the ARM reference manuals, found at http://infocenter.arm.com/help/index.jsp.  The most relevant ones are linked directly from Developer Technical Documents - CHDK Wiki
Don't forget what the H stands for.

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #186 on: 11 / January / 2009, 06:47:25 »
arwulf - the addresspace won't become the same!
My CODE is also loaded at 0x800120

YOU loaded the code to 0x800120
I loaded the header+code at 0x800000 (because the header is 0x120 byte in size, my code starts at the same address).
So I think you have a little different image.

I just found a terrible bug in this 400 Euro expensive CipherSDK... The Demo simply wont descramble files because they forgot to convert the ascii key to binary inside "DoFileEncDec" :-)

there are some torrents to an arm insiders's Guide. I will try this.
« Last Edit: 11 / January / 2009, 06:51:26 by Tyra Misoux »

*

Offline mx3

  • ****
  • 372
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #187 on: 11 / January / 2009, 06:55:42 »
I just found a terrible bug in this 400 Euro expensive CipherSDK... The Demo simply wont descramble files because they forgot to convert the ascii key to binary inside "DoFileEncDec" :-)

I'm sure you have seen following libs:
Crypto++ Library 5.5.2 - a Free C++ Class Library of Cryptographic Schemes
Algorithms Supported in Botan

my question is:
does CipherSDK suit you better than these libs?
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler


*

Offline quietschi

  • ***
  • 116
  • Ixus70 102a
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #188 on: 13 / January / 2009, 09:24:58 »
Hi
find similar 256 bytes in every flasher located

40D108 at 99BFE8
50D103 at 997744
5D2107 at 99A514

maybe this is for decrypt data?

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #189 on: 14 / January / 2009, 15:32:14 »
Same tables can be found in 40D FW so these seem to be generic for Canon  :D @ locations
0081A88C (256 bytes)
0081A98C
0081AD8C
0081B18C
0081B58C
0081B98C
0081BD8C
0081C18C
0081C58C and
0081C98C

In both the 50D the 40D code the fist block is 526 bytes large, but the start of the other 9 tabkes are spaced precicely 1024 byes appart. So could it be that other tables are 1024 bytes in size?

cheers emklap

one finds those tables inside the decrypted flasher. since it is symetric stuff it should be no problem to reverse the algorithm and reconstruct the table from encrypted code. So maybe thats the way to get them.
Or maybe one guy connects to the chip with JTAG? I am sure the CPU has JTAG capabilities but I do not want to open my new camera :-) at least not at this time! (maybe I destroy it anyway with further development - then the time is come to open :-)

well, I am not interested in how to get the tables for flasher at this point. I am more interested in decrypting the datachung as well in running my own code. I failed when try to patch the flasher and run it. fix the checksum alone is not enough.

I found lot of checksumming and signature stuff in the flasher.
At least there is a MD5 calculation as well as AES!
if you like to name the tables (50d fw 1.0.3)
the AES Tables at
0x990FCC - AES::SD[256] - 0x52, 9,0x6A,0xD5,0x30,0x36,0xA5,0x38
0x9910CC - AES_TE0[256] - 0xC66363A5,0xF87C7C84,0xEE777799
0x9914CC - AES::TE1[256] - 0xA5C66363,0x84F87C7C,0x99EE7777
0x9918CC - AES::TE2[256] - 0x63A5C663,0x7C84F87C,0x7799EE77
0x991CCC - AES::TE3[256] - 0x6363A5C6,0x7C7C84F8,0x777799EE
0x9920CC - AES::SE[256] - 0x63636363,0x7C7C7C7C,0x77777777 (unpacked)
0x9924CC - AES_TD0[256] - 0x51F4A750,0x7E416553,0x1A17A4C3
0x9928CC - AES_TD1[256] - 0x5051F4A7,0x537E4165,0xC31A17A4
0x992CCC - AES_TD2[256] - 0xA75051F4,0x65537E41,0xA4C31A17
0x9930CC - AES_TD3[256] - 0xF4A75051,0x4165537E,0x17A4C31

(the tables are well know, so it is no problem to find them in any code)
the stuff is referenced from within a table at 0x8A4594
so the code at 0x8A45A4 is supposed to do AES

first I thought it is not referenced but library stuff only
but there is a reference to this code as a table-entry at 0x8958CC. that address is pushed to stack at
895888 3C 30 9F E5                 LDR     R3, =do_AES_loc_8A45A4
89588C 00 30 8D E5                STR     R3, [SP,#0]

if there is AES - there must be another key :-) if that is in ROM we are fucked at this point.

(btw. OS is DryOS of course for 50d, too)
and YES, it DOES decrypt 50d 1.0.3
« Last Edit: 14 / January / 2009, 15:38:26 by emklap »

 

Related Topics