VerifyAndDecryptFirmware() Found! Maybe... - DSLR Hack development - CHDK Forum
« previous next »
Pages: [1] 2 3 4   Go Down

VerifyAndDecryptFirmware() Found! Maybe...

  • 36 Replies
  • 20342 Views
*

ASalina

VerifyAndDecryptFirmware() Found! Maybe...
« on: 21 / May / 2008, 16:10:32 »
Advertisements
I think I have just found the function to verify and decrypt the Firmware payload in the 40D FW108. The function is located at ROM:00804C10. I haven't had a chance to study it yet, but it sends these strings to TryPostEvent()

"[UPD] %d=UPD_VerifyFirmware"
"[UPD] %d=UPD_DecryptoFirmware"

And error strings

"[UPD] ERR %d=UPD_VerifyFirmware"
"[UPD] ERR %d=UPD_DecryptoFirmware"

After that function comes one that Posts the string

"[UPD] Verify And Decrypt Start"

I'm sure the Firmware Decrypter is in this section of code. I'll do my best to try to figure it out, but I'll need help.

HELP!  :D
Logged
*

ASalina

Re: VerifyAndDecryptFirmware() Found! Maybe...
« Reply #1 on: 21 / May / 2008, 16:40:53 »
YES! The actual EOR-ing of encrypted data is taking place at loc_80F6C0, which is in a subroutine called by VerifyAndDecryptStart() (ROM:00804FC8)

R12 is loaded with =0xFF803FE1 and the Link register (??) contains another address which is calculated and I haven't figured that out yet. The two pointers are indexed one byte at a time and XORed with each other, with the results are used to XOR the contents of R1, which was loaded with (char *)R0, and are finally stored back into (char *)R0; R0++, and the loop continues.

This is essentially the same algorithm used by decrypt40D.c.

Once the starting value in the Link Register is found we will have the start of the hash two tables used to decrypt the Firmware Payload.
 
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: VerifyAndDecryptFirmware() Found! Maybe...
« Reply #2 on: 21 / May / 2008, 17:10:23 »
Nice work! I'll have a look at it as well (I'm planning on buying a 40D somewhere in the next couple of months), maybe I can find something.

Edit: may I ask how you loaded the dump into IDA and what the md5sum is? I managed to locate (some of) the things you referenced, but not at the locations you specified. I should have the 108 firmware, since I downloaded it as 108 and decrypted it with the 108 tables....
« Last Edit: 21 / May / 2008, 17:41:41 by DataGhost »
Logged
*

ASalina

Re: VerifyAndDecryptFirmware() Found! Maybe...
« Reply #3 on: 21 / May / 2008, 18:04:47 »
Quote from: DataGhost on 21 / May / 2008, 17:10:23

Edit: may I ask how you loaded the dump into IDA and what the md5sum is? I managed to locate (some of) the things you referenced, but not at the locations you specified. I should have the 108 firmware, since I downloaded it as 108 and decrypted it with the 108 tables....

I split the Flasher code from the decrypted .fir file using mx3's "dissect_fw3" utility from 40d_v10.rar. See:

Any developers interested in working on CHDK firmware for DSLRs ?

I had to re-attach the flasher's header to the flasher code in order to get things lined up in IDA.

I then loaded the resulting file into IDA at 0x00800000

You should be able to just load the whole decrypted .fir file into IDA at 0x00800000 and get the same result, but with the extra encrypted payload.
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: VerifyAndDecryptFirmware() Found! Maybe...
« Reply #4 on: 21 / May / 2008, 18:27:56 »
Yes, I just loaded the entire decrypted file to that address, but LDR R12, =0xFF803FE1 is at (the first instruction of) loc_80F554, which is identified as CipherBuffer_0 by A-series signatures. 0x80F6C0 is not a loc in my dump, it's part of the subroutine following CipherBuffer_0 and the opcode at that address is LDR R3, =0x40E4 (no EOR anywhere near there).

By the way, the fact that it got identified by the signatures (and with a proper function name) probably suggests that this function also exists more or less in the same form in other VxWorks cameras, so that might also help a bit in finding the tables.
« Last Edit: 21 / May / 2008, 18:31:18 by DataGhost »
Logged
*

ASalina

Re: VerifyAndDecryptFirmware() Found! Maybe...
« Reply #5 on: 21 / May / 2008, 18:52:19 »
Quote from: DataGhost on 21 / May / 2008, 18:27:56
Yes, I just loaded the entire decrypted file to that address, but LDR R12, =0xFF803FE1 is at (the first instruction of) loc_80F554, which is identified as CipherBuffer_0 by A-series signatures. 0x80F6C0 is not a loc in my dump

That's a difference of 0x120 or 288 bytes.... That's the size of the first header at the beginning of the file.

Are you sure that you have the header in that file, and that the first byte of that header is at 00800000?
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: VerifyAndDecryptFirmware() Found! Maybe...
« Reply #6 on: 21 / May / 2008, 19:24:56 »
Ah, ok. That's the point of reference I needed. Indeed, I don't have the header (I skipped it and didn't reattach it to the decrypted file).
I also tried applying A-series decryption on the main body, didn't work. I backtracked the magic unknown R2 value but so far I ended up in a jump table after going about 5 functions backwards. What I did manage to discover:
The function that calls CipherBuffer_0 sets up R2 by doing
LDR R3, [R4,#0xC]
MOV R2, R3

R1 is also loaded, LDR R1, [R4]. R1 appears to be the length of the payload. In the decrypted firmware file, I see
EC 11 63 00  70 11 63 00  6C 11 63 00  00 00 00 00
right before the file start mx3's program identified. The first 3 long values appear to be *more or less* the payload length. Unfortunately, [R4,#0xC] can't be 0 or the program will return. Still, something which might be worth noting.

I'll reattach the 288-byte header now and see if I can get better results. It'll probably also fix the mid-string references and a bunch of missing refs :)

Edit: better yet... I can just rebase the entire program to 0x800120. I highly doubt the header would contain valid ARM code anyway and this will keep my comments.
« Last Edit: 21 / May / 2008, 19:29:08 by DataGhost »
Logged
*

ASalina

Re: VerifyAndDecryptFirmware() Found! Maybe...
« Reply #7 on: 21 / May / 2008, 19:39:10 »
I haven't applied any signatures to this disassembly. I did try emklap's first IDC string-finding script (see: Guide how to start analysing 40D firmware) but it didn't get them all. Other than that I have been disassembling by hand. I'd like to generate a FLIRT signature file of what I've found so far, but don't know how yet.

I'm going to change some of my made-up function names to match the ones you mention from the A-series cameras so we don't get confused.
Logged
*

Offline owerlord

  • ***
  • 115
Re: VerifyAndDecryptFirmware() Found! Maybe...
« Reply #8 on: 21 / May / 2008, 20:19:28 »
from my experience: signatures from ASeries are totaly useless and they only corupt the code (assign function starts in the middle of a real functions etc).
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: VerifyAndDecryptFirmware() Found! Maybe...
« Reply #9 on: 21 / May / 2008, 20:26:09 »
Ok, this code makes more sense. What amount of control do you have over the camera? Is there any way to make a memory dump or display memory contents on the LCD? That would be immensely useful, if the values I found are correct. This is what I found for the magic R2 value we're looking for:

R2 = [[[0x1D40]+0x58] + [[[0x1D40]+0x58]+0x2C] + [[[0x1D40]+0x58] + [[[0x1D40]+0x58]+0x2C] + 0x24] + 0xC]
or
R2 = [[[0x1D40]+0x58] + [[0x1D40]+0x58] + 0x24 + 0xC]

since the function is called from two locations with different arguments. I also made some other notes but the stuff appears to be quite hidden.

Quick addition: I found that [[0x1D40]+0x58] is assigned the value 0x12000000 somewhere (0x806B30 - 0x806B3C, seems to be structure initialization), so the new values are

R2 = [0x1200000C + [0x1200002C] + [0x12000024 + [0x1200002C]]]
R2 = [0x24000030]

which might not make sense. Can you check if 0x1200002C and 0x24000030 exist? (LDR Rx, =0x1200002C and then LDR Rx, [Rx]. Camera should shut down if memory address does not exist)

This might be completely wrong, though. It looks error-prone and I wouldn't be surprised if I made a mistake somewhere.
« Last Edit: 21 / May / 2008, 20:28:49 by DataGhost »
Logged
Pages: [1] 2 3 4   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal