Any developers interested in working on CHDK firmware for DSLRs ? - page 14 - DSLR Hack development - CHDK Forum
« previous next »
Pages: 1 ... 9 10 11 12 13 [14] 15 16 17 18 19 ... 21   Go Down

Any developers interested in working on CHDK firmware for DSLRs ?

  • 202 Replies
  • 148795 Views
*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #130 on: 03 / May / 2008, 12:18:14 »
Advertisements
Quote from: ASalina on 03 / May / 2008, 11:54:16

What do you mean by "generated on the fly"? Do you think the hash tables in the file header have yet another level of encryption, or do you mean that they are just taken from the file and each FW version has different hash tables?


Actually, I guess the tables really would need to be generated, since the data in the FW file is each only 19 bytes long and the decrypter uses two hash tables that are 512 and 513 bytes long.

I wonder if those other CRC's at 0x40 and 0xBC are actually used along with the data at 0x68 and 0x88 in a formula to make the keys?
Logged
*

Offline mx3

  • ****
  • 372
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #131 on: 03 / May / 2008, 12:54:51 »
Quote from: ASalina on 03 / May / 2008, 12:18:14
Quote from: ASalina on 03 / May / 2008, 11:54:16

What do you mean by "generated on the fly"? Do you think the hash tables in the file header have yet another level of encryption, or do you mean that they are just taken from the file and each FW version has different hash tables?


Actually, I guess the tables really would need to be generated, since the data in the FW file is each only 19 bytes long and the decrypter uses two hash tables that are 512 and 513 bytes long.

I wonder if those other CRC's at 0x40 and 0xBC are actually used along with the data at 0x68 and 0x88 in a formula to make the keys?


I think tables are generated at run time (on the fly) because decrypter for 1.0.5 do not work on 1.0.8 fw file.

I'm working on recreation of hash tables for flasher(loader) 1.0.8 .
I hope I will manage this.
As soon we have tables it would be possible to guess how file header fields are used to generate of hash table.

Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #132 on: 03 / May / 2008, 16:22:00 »
wow, u guys are pretty active on this. tell me when i have to rename the thread title to "developers working on chdk port for dslrs", or split/move some posts.
i'm sure you will be able to succeed in this matter, hats off to you guys.
Logged
*

Offline kwf

  • **
  • 72
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #133 on: 03 / May / 2008, 18:16:56 »
Quote from: Seklth on 03 / May / 2008, 08:16:03
Quote from: kwf on 02 / May / 2008, 16:38:13
Is there a s19 encoded part in other firmwares (other than 20D and 350D) as well?

It is "EEP" section.



EEP = EEPROM? How do you know?
Logged
*

Offline mx3

  • ****
  • 372
Encryption analysis
« Reply #134 on: 04 / May / 2008, 01:24:34 »
40D
Quote from: mx3 on 03 / May / 2008, 12:54:51
Quote from: ASalina on 03 / May / 2008, 12:18:14
Quote from: ASalina on 03 / May / 2008, 11:54:16
What do you mean by "generated on the fly"? Do you think the hash tables in the file header have yet another level of encryption, or do you mean that they are just taken from the file and each FW version has different hash tables?

Actually, I guess the tables really would need to be generated, since the data in the FW file is each only 19 bytes long and the decrypter uses two hash tables that are 512 and 513 bytes long.

I wonder if those other CRC's at 0x40 and 0xBC are actually used along with the data at 0x68 and 0x88 in a formula to make the keys?
I think tables are generated at run time (on the fly) because decrypter for 1.0.5 do not work on 1.0.8 fw file.

I'm working on recreation of hash tables for flasher(loader) 1.0.8 .
I hope I will manage this.
As soon we have tables it would be possible to guess how file header fields are used to generate of hash table.

I made it.
size of flasher is the same in 1.0.5 and 1.0.8 FW files.
assuming 108 flasher is identical to 105 I XOR-ed decrypted 105 flasher with 108 encrypted one.
result of xoring is cipher tream used to encrypt file
using recreate_tables tool on such stream will recreate tables

I begun encryption analysis in a hope to determine how tables depend on fw file header

you see. there is a small problem...
there are can exist 256 combinations of tables to generate the same cipher stream
recreate_tables tool can generate any of them (optional second parameter)

to ASalina, any 40D owner
I hope this information and tools will help you with further analysis


also it may be possible to patch flasher to make ROM dump to SD card.
in a such a way we could know exactly how to make decryptor instead guessing.
please check following:
- use dissect_fw3 on fir file
- use decrypt_40D10X_Flasher tool to decrypt flasher
- change some bytes in binary file (I advice you to change some strings which are displayed in flashing progresss. example: "Update Firmware?")
- encrypt flasher back using the same tool
- join files in new fir file
- use eos_fsum.exe to know new check sum
- update manualy bytes at offset 0x20-0x23 with new checksum
- try new fir file in camera

you managed to see changed text inside your camera it would be possible to make ROM dump

this test is for checking if some of fw file header fields used for additional checksuming of flasher
Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
*

Offline Seklth

  • **
  • 54
  • 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #135 on: 04 / May / 2008, 01:55:29 »
Quote from: kwf on 03 / May / 2008, 18:16:56
Quote from: Seklth on 03 / May / 2008, 08:16:03
Quote from: kwf on 02 / May / 2008, 16:38:13
Is there a s19 encoded part in other firmwares (other than 20D and 350D) as well?

It is "EEP" section.



EEP = EEPROM? How do you know?

In data section for firmware 400d 1.1.1:
Code: [Select]
pack_head       DCD 0xEA5228C2          ; cksum ; CODE XREF: FWLDR:main_head+28?
                DCD 13                  ; records_num
                DCD 0x18                ; tableOffset
                DCD 0x220               ; packOffset
                DCD 520                 ; tableLenght
                DCD 0x3863BA            ; packLenght
                DCD 8                   ; BIND_RESOURCE
                DCD 0x220               ; Offset 927EB0
                DCD 0x1B040             ; Length
aBIND_RESOURCE  DCB "BIND_RESOURCE",0,"=============="
                DCD 3                   ; MAIN_FIRMWARE
                DCD 0x1B260             ; Offset 942EF0
                DCD 0x35C9A0            ; Length
aMAIN_FIRMWARE  DCB "MAIN_FIRMWARE",0,"=============="
.................................
                DCD 0xB                 ; EEP
                DCD 0x386412            ; Offset CAE0A2
                DCD 0x1C8               ; Length
aEEP            DCB "EEP",0,"========================"

Logged
*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #136 on: 04 / May / 2008, 05:02:37 »
Quote from: mx3 on 04 / May / 2008, 01:24:34
40D


I made it.
size of flasher is the same in 1.0.5 and 1.0.8 FW files.
assuming 108 flasher is identical to 105
I XOR-ed decrypted 105 flasher with 108 encrypted one.
result of xoring is cipher stream used to encrypt file
using recreate_tables tool on such stream will recreate tables

Wow! That was a very smart idea!

Quote from: mx3
I begun encryption analysis in a hope to determine how tables depend on fw file header

you see. there is a small problem...
there are can exist 256 combinations of tables to generate the same cipher stream
recreate_tables tool can generate any of them (optional second parameter)

to ASalina, any 40D owner
I hope this information and tools will help you with further analysis

also it may be possible to patch flasher to make ROM dump to SD card.
in a such a way we could know exactly how to make decryptor instead guessing.
please check following:
......

I've D/Led the tools and will follow your instructions tomorrow when I'm rested.
I'm currently using FW 1.0.5 in the camera.
I don't know yet if the camera will allow me to flash an older (or current) version
of FW. I will test that first by trying to install the current 1.0.5 FW.

A ROM->SD card dumper would be fantastic! This is very exciting!
Logged
*

Offline owerlord

  • ***
  • 115
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #137 on: 04 / May / 2008, 14:19:09 »
I think somebody misunderstood me. I'm runing code (writen in asm now) on my 400D without problems. The problem is for me to write a code that will do something usefull :-)

I'm not an expert in disassembly - mayby it's easy to make a memory dumper? some body can tell me how to write a file to CF card?
Logged
*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #138 on: 04 / May / 2008, 16:26:06 »
Quote from: ASalina on 04 / May / 2008, 05:02:37

I've D/Led the tools and will follow your instructions tomorrow when I'm rested.


Slight trouble.

decrypt_40D10X_flasher.c do not put the first 288 bytes of the .fir file into the output file. There is a #if 0/#endif wrapped around that section of code in decrypt_40D105_flasher.c. I removed that and it works fine. I copied that source file to decrypt_40D108_flasher/decrypt_40D108_flasher.c, since they are the same anyway, and it decrypts FW108 now as well.

Below is a modified decrypter tool that checks the LSD of the version string in the .fir file and automatically uses the appropriate hash tables. This decrypter works on both FW105 and FW108.

Looking at next steps now. I'll report back with progress.

Logged
*

Offline mx3

  • ****
  • 372
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #139 on: 05 / May / 2008, 01:40:48 »
Quote from: ASalina on 04 / May / 2008, 16:26:06
decrypt_40D10X_flasher.c do not put the first 288 bytes of the .fir file into the output file. There is a #if 0/#endif wrapped around that section of code in decrypt_40D105_flasher.c. I removed that and it works fine.

what sense to aply flash decryptor to data header section and data section?
- data header section is not encrypted
- data section encrypted with different keys.

decrypt_40d108_flasher tool is just a proof of concept tool.
it's purpose is just to check recreate_tables tool

if you want to make correct decryptor you must know how to decrypt data section
for that we have to have ROM dump or decrypted data section :-)


What we(you) want really is to launch you code in camera.

I think you must choise now what next thing you are going to do:

 - try to guess how tables are generated using fw file header so you could decrypt data section
 I'm not realy sure it possible - 256 combinations of 105 fw tables vs. 256 combinations of 108 fw tables

 - make tool for dictionary attack to data section
we have alot of strings for that
and the bigger the file more chances for attack to be succesful
if you intrested in this I will explain idea

 - make patched version of .fir file to make ROM dump. then it will be possible to analize ROM in IDA to know how to make new .fir file.
it seems to me it is simplest way to get ROM dump.
I hope it will work.


I vote for flasher patch to get ROM dump.
I described steps to make it.
I can help to do it.
Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
Pages: 1 ... 9 10 11 12 13 [14] 15 16 17 18 19 ... 21   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal