Any developers interested in working on CHDK firmware for DSLRs ?

  • 202 Replies
  • 94150 Views
*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #40 on: 07 / February / 2008, 10:45:29 »
Advertisements
-I don't have information about structure of decrypted file.
-it seems firmware files for DSLR does not contain block structure (ie headers and bodies) so only way to dissect it properly ( and make it back ) is to analize firmware udpate code.
-no additional tolls were used to guess dissection process.
-All analysis was done with IDA ( several count of spliting file and loading it into IDA. of course it is not required to split it but I like to have independent sections to analyse. remember you mentioned unreferenced parts :-) )
Now that I've seen your 350D file there's an easier way, works for both 350d and 400d, search for the string "Copyright", it happens 3 times, the first at the beginning of the file, the third is 8 bytes after the beginning of the 0xff810000 block.


we have to make such FW file wich will be accepted by camera. so we need to know algorithm of FW update procedure (we have it)
I guess it's in the pakwif tool in svn? i'll look into it. Is it a checksum or something like that what prevents me from updating with a modified firmware?

Another thing, how do I find functions, events, and so on?
IMO signature file is the best way.
That's the problem, many functions are not where the signature file says :( I'm searching for them.

I still have a "missing link" in my mind, for example when you want to shoot from your program, what do you do? is it just calling some function in the original firmware? what do you do for getting and setting properties?

*

Offline mx3

  • ****
  • 372
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #41 on: 07 / February / 2008, 14:23:35 »
my thinking (not verified in IDA)

1) code from flash area ff810000( running OS ) loads .bin file at 800000
2) shutdowns  OS (same behavior as in P&S)
3) transfers execution to 800000

.bin file contain flasher(flash update code ) , header block ( length+checksum), data block (firmware itself)


this would explain why fw file is unstructured and containg two sections of code....
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #42 on: 07 / February / 2008, 15:12:07 »
I've managed to find the RegisterEventProcedure adress. Now I'm getting by hand the addresses of all the registered procedures, there are a lot. With this I think I'll be able to grasp many of the inner workings of the firmware. I'll look at the loader code afterwards.

*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #43 on: 07 / February / 2008, 15:33:32 »
naplam
Did you try applying signatures from A-series camera and running the inial parsing script? Maybe it could work.
CHDK Developer.


*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #44 on: 07 / February / 2008, 15:40:06 »
naplam
Did you try applying signatures from A-series camera and running the inial parsing script? Maybe it could work.
Yeah, it "didn't" work. Most addresses were in weird places. At first I thought some may be correct, but now i doubt there's a single one in the correct place. After seeing the huge amount of functions, i'm starting to think I should make a script or something to automatically find them. I've also seen there are a couple of functions that call RegisterEventProc in turn, with some parameters they get and modify, so I'll have to make more passes to the whole firmware in order to find the functions registered by those functions. We're really lucky we have the function registration thing, this is like having debug symbols... priceless.

*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #45 on: 07 / February / 2008, 15:48:52 »
Ok. I asked because the idc-script for initial parsing has the procedure for automatically naming of procedures used in the "RegisterEventProcedure" calls. See "scan-events.idc".
CHDK Developer.

*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #46 on: 07 / February / 2008, 16:56:13 »
Ok. I asked because the idc-script for initial parsing has the procedure for automatically naming of procedures used in the "RegisterEventProcedure" calls. See "scan-events.idc".
Ah great, I'm using it right now, it has detected all the registered functions automatically. I modified it to use my register function (gave it a different name). I think the other function I found, the one that called RegisterEventProcedure, is RegisterEventProcedureTable (looks like it registers procedures sequentially), I've also modified the script to use it.
So, from CHDK all you do, you do it calling these registered functions? or it does more things in other ways?

*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #47 on: 07 / February / 2008, 21:23:46 »
I have tried to upload a modified firmware to the camera, first I uploaded a firmware with the fw updater patched to bypass the checksum (and also with checksum fixed so the camera would accept it), it went ok, but when I try to upload another firmware after that it seems i haven't bypassed the check properly in the previous firmware loader code... so I think I'll just forget about this -risky- option and go for calculating the checksum properly... but i've had a look at pakwif and it seems the packed .fir for the powershots and so on is quite different from the eos .fir, so I don't know how to calculate the checksum, where to store it and what block to calculate it from. Well, the calculation is probably the same or similar because I just needed to decrease one word for every word I increased in the firmware i patched (i just patched 1 byte, a conditional branch), but I still don't know where to store it or what block to calculate it from.
Have any of you tried to modify the 400d or similar firmware already? any ideas on where to look for the checksum? (i've tried the first four bytes of the decrypted .fir, which i've seen changed from one version to another of the same firmware, but the algorithm from pakwif apparently does not generate that number).


*

Offline mx3

  • ****
  • 372
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #48 on: 08 / February / 2008, 02:25:23 »
I'm sure there are no checksum control for whole file.
I think checksum is inside file and this checksum is for second code section

I would suggest you to change some strings in first code block which are displayed on LCD: some phrase like "Are you sure?"....
if you see this changed string on LCD then it will confirm idea that update actually performed by .bin file code from RAM
then we actually don't need to patch firmware and all people will be happy about it (and camera owners and devs)

don't miss attached file :-)
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #49 on: 08 / February / 2008, 05:56:36 »
I'm sure there are no checksum control for whole file.
I think checksum is inside file and this checksum is for second code section
I just checked I can change anything in the first section and the firmware is accepted but maybe that's because of the patch i made. But unfortunately the first section you upload to the cam is not used to update the camera's firmware -i changed the strings as you suggested- so it seems we can't load any code in the camera without writing the firmware flash.

I'm still not sure about the patch I made yesterday... I think it's working because it has now accepted a file with modifications on the second section. I think the reason it didn't work yesterday is that maybe i screwed up the file when i modified an image within. I'll be looking into it.

 

Related Topics