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

Any developers interested in working on CHDK firmware for DSLRs ?

  • 202 Replies
  • 99291 Views
*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #60 on: 08 / February / 2008, 11:17:04 »
Advertisements
be careful.
I would suggest you to use CHDK approach ( don't touch flash)
I know, i know, It's quite risky. Anyway I still don't know how to make a chdk-like program. After I get the control at the loader, how do I install a keyboard hook and go back to the camera user interface instead of proceeding with the firmware update? well coming back is more or less easy, just cancel the upgrade, but everythng else..
By the way, if you want the checksum program, funcion addresses or anything i'm finding out to test it, just ask me.
« Last Edit: 08 / February / 2008, 11:18:55 by naplam »

*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #61 on: 11 / February / 2008, 07:00:04 »
I have been going through the disassembly, naming functions and so on. I've also modified the loader to read memory locations and display them on the screen. The only problem is (i think) that the memory is cleared before the firmware loader is executed :( so it's no use... I've seen many locations at 0x1XXXX (just 5 digits), what is usually there in other cameras? what is usually at 0xC0xxxxxx? I'd like to know what's there. I've also found several function names & addresses towards the end of the firmware (getOwnerName, GetICUVersion, etc.). And I've found things about properties, there are many strings (like cf_lens_button, batt_type, avail_shot, gui_mode...), how are these "properties" read and written to? where are they stored? those strings are not referenced anywhere, but they are between properties functions (there are .c file names around).

*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #62 on: 11 / February / 2008, 10:50:33 »
One more thing, this is the code at the very beginning of the updater:
Code: [Select]
ROM:00800088                 LDR     R1, =0x4D3
ROM:0080008C                 STR     R1, [R0]
ROM:00800090                 LDR     R0, =0xC0400000
ROM:00800094                 LDR     R1, =0x410005
ROM:00800098                 STR     R1, [R0,#8]
ROM:0080009C                 MOV     R0, #0xC0000000
ROM:008000A0                 LDR     R1, =0xD9C50000
ROM:008000A4                 STR     R1, [R0,#0x10]
ROM:008000A8                 LDR     SP, =0x1900
ROM:008000AC                 MOV     R11, #0
ROM:008000B0                 LDR     PC, =0xFF8100A0 [color=red](modified, would be =0x008000D0)[/color]
Those instructions are both in the firmware and in the updater code. The code above is from the updater, I modified it to jump to the firmware and continue... it should be like a "reset", just start the camera firmware again instead of going on with the updater, but it hangs the camera and I have to remove the battery. Any ideas why this happens? The code is identical in the firmware and the updater, I just made the updater jump to the firmware to continue  ???


*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #63 on: 11 / February / 2008, 20:24:45 »
Ah I've made some progress now with my analysis. Now I've relocated the data section in IDA and i'm seeing references to initialized data, not bad. I guess making a memory dumper should be easier than loading chdk or the firmware, maybe I should make one which will also let me load more interesting data and bss sections in ida. Any recommended reading/source code for this?


*

Offline mx3

  • ****
  • 372
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #64 on: 12 / February / 2008, 08:01:55 »
By the way, if you want the checksum program
please publish it.
I think the best way is to attach it to forum

I'm not sure why have you selected FF8100A0 (I have not analyzed FW)
I suggest you to jump to ff810000 or ffff0000

I suspect you have already using your own loader instead of patching original firmware file.
could you publish this project also so we could help you?
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 #65 on: 12 / February / 2008, 08:21:47 »
By the way, if you want the checksum program
please publish it.
I think the best way is to attach it to forum

I'm not sure why have you selected FF8100A0 (I have not analyzed FW)
I suggest you to jump to ff810000 or ffff0000

I suspect you have already using your own loader instead of patching original firmware file.
could you publish this project also so we could help you?
The checksum program is a tacky proggy i made on a pinch. I attach it to this message- by the way i think it only works well with v1.1.1 firmware, the checksum it generates for version 1.1.0 is very close to the correct one on the 1.1.0 file but not the same. That doesn't matter anyway you can just calculate the difference and adjust.

About the address, the base is ff810000, at the entry point there are a few instructions (the same ones for the loader -entry point 800084- and the firmware -entry point FF810054-), in the firmware those few instructions then jump to 0xFF8100A0, which is the starting function that calls usrInit. The true RegisterEventProcedure is at FFB06658, the flirt signature for a series cams is misidentifying many functions. I'm using version 1.1.1 of the firmware if you want to download it and disassemble it.

ff810000 corresponds to file offset 142ef0. Data segment is at 4931e0 in the file, relocated to address 0x1900. These offsets are INCLUDING the non-encrypted 32-byte header. The base for the loader code is easier, 0x800000 corresponds to the beggining of the file, data is relocated in that case from 923AE0 to 0x1900.

About loading something, I have nothing yet, the first thing I tried was to make the loader jump to the firmware so it would load the firmware, which is much simpler than loading chdk or creating an additional task or somthing, but it didn't work so I'm still wondering why. If calling the firmware as-is won't work, more complicated things won't work either! any ideas why it's not working? what i did is just making the loader jump to start the firmware instead of jumping to start the loader. --well, I can modify the firmware section and load it, but any error and my camera turns into a brick, so i'm playing it safe and going for the loader chdk-style
« Last Edit: 12 / February / 2008, 08:37:46 by naplam »

*

Offline RayeR

  • *
  • 18
    • RayeR's homepage
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #66 on: 12 / February / 2008, 20:40:04 »
Hi doods,
I see there are a lot of news since I was last here!
I also made a few of simple mod experiments on my 350D but nothing new, napalm was faster and I can only confirm his discovers on 350D.

1) I tried to modify updater section string - failed (message about corrupted file and request for shutdown)
2) Well, the 1st thing I always do to try outwit the checksum is to modify few bytest a little to keep modulo 256 unchanged and it works. Like napalm I tried "Updbse Firmware?" at 0x98068 and it works. When I flash it I replaced FIR file on the CF by original FIR and try update again - the message reverted to normal. This mean that firmware update code is executed from FIR file like on PowerShots.
3) I do the same for OS part, I changed "Sdosor cleaning" string in English language block and it works fine too, chage is permanent.

I didn't seek for chksum place but napalm made something - but maybe I miss it, what offset in file exactly do you use to place checksum for 1st and 2nd section? I can see some 8 bytes of garbage at the beginning of decrypted FIR: 02 00 A0 E3 12 00 EA followed by Copyright - is it right place here?
And on what offset is the 1st instruction?

A note for using FIR update for starting user code - it seems when you choose FW update and pres first OK it loads FIR file from CF, decrypts it and check checksums. If checksum don't match or you cancel update at last warning it will not let you back to OS, probably its cleared or CPU is in state of no return.
I have no idea if it can or cannot be simply restarted by jumping at entrypoint. Maybe smoother way would be to modify OS- if there are any text init scripts - to look for specific file on spec. CF location to run it and then do normal exit back to OS.

BTW this would be possible to dump memory from updated code, we would need  to find some location to replace current code by dumper code. But there may be 2 issues:
1) when I run dumper code, camera is in some special state which doesn't reflect normal operatio of OS.
2) can be still use OS FS services fo write dumpfile on CF? If not, how to transfer dumped data out?
3) What all areas to dump? As ARM is 32bit it has huge address space AFAIK top addresses are used for memory mapped peripherals on ST ARM but I don't know what is used here. Any idea of memory map where is flash and ram? And is it all internal ram/flash or is there combination of onchip and external memory? E.g. I know PowerShots has external 16MB flash but mayalso have some small onchip.
Canon EOS 350D, PowerShot A95

*

Offline naplam

  • *
  • 25
  • EOS 400D
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #67 on: 12 / February / 2008, 21:05:24 »

I didn't seek for chksum place but napalm made something - but maybe I miss it, what offset in file exactly do you use to place checksum for 1st and 2nd section? I can see some 8 bytes of garbage at the beginning of decrypted FIR: 02 00 A0 E3 12 00 EA followed by Copyright - is it right place here?
And on what offset is the 1st instruction?
Checksum for whole file is bytes 32-34, inner checksum for sections I don't know, I just "cracked" the loader checks so it wouldn't complain. But i'm not using that anyway, I want to use the loader if possible for testing.

Quote
A note for using FIR update for starting user code - it seems when you choose FW update and pres first OK it loads FIR file from CF, decrypts it and check checksums. If checksum don't match or you cancel update at last warning it will not let you back to OS, probably its cleared or CPU is in state of no return.
Yep, the memory locations are screwed, I tried reading several addresses which should have info in them and apparently they've been wiped. About the checks, i think the first one (whole file checksum) may be performed by the runnning firmware, while other checks -this i'm sure- are later performed by the newly loaded loader from the fir file.

Quote
I have no idea if it can or cannot be simply restarted by jumping at entrypoint. Maybe smoother way would be to modify OS- if there are any text init scripts - to look for specific file on spec. CF location to run it and then do normal exit back to OS.
I tried jumping from the loader entry point to the firmware entry point and the processor hangs somewhere, I have to remove the battery to restart.

Quote
1) when I run dumper code, camera is in some special state which doesn't reflect normal operatio of OS.
2) can be still use OS FS services fo write dumpfile on CF? If not, how to transfer dumped data out?
3) What all areas to dump?
1) yeah apparently it wipes everything and doesn't initialize again.
2) probably, but would have to find the functions
3) beggining of memory, data sections, bss section, C0.... part, ff81.. part.


*

Offline RayeR

  • *
  • 18
    • RayeR's homepage
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #68 on: 12 / February / 2008, 21:16:32 »
Aha, there's some difference in 350D and 400D FW - As I can see original FIR is 4907626B but decrypted is 4907594 - 32B missing!
Then 400D have 16B more of garbage at the beginning thand 350D

400D:
00000000: 59 C0 55 E3 30 00 00 00 90 7C 12 00 00 00 00 00
00000010: 02 00 A0 E3 12 00 00 EA 43 6F 70 79 72 69 67 68

350D:
00000000: 02 00 A0 E3 12 00 00 EA 43 6F 70 79 72 69 67 68

The 1st 8 bytes at 0 seems to be some common header for all DigicII DSLRs
In your suma.cpp you use offset 35 or 32-34? But do you count those 32B which decripter ommited? little bit confusing... GN :)
Canon EOS 350D, PowerShot A95

*

Offline RayeR

  • *
  • 18
    • RayeR's homepage
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #69 on: 12 / February / 2008, 21:22:45 »
Checksum for whole file is bytes 32-34, inner checksum for sections I don't know, I just "cracked" the loader checks so it wouldn't complain. But i'm not using that anyway, I want to use the loader if possible for testing.

Are you sure about 3 chksums? I though there are 2 for both sections.
Canon EOS 350D, PowerShot A95

 

Related Topics