G3 X 1.00C FW Dump - Firmware Dumping - CHDK Forum
« previous next »
Pages: [1] 2 3   Go Down

G3 X 1.00C FW Dump

  • 24 Replies
  • 21861 Views
*

Offline Nippey

  • *
  • 7
G3 X 1.00C FW Dump
« on: 15 / September / 2015, 03:38:39 »
Advertisements
Hi,

I just managed to dump the FW from my new G3 X.

https://www.dropbox.com/s/j2v2z55mtc6jzkz/G3X_1.00C.7z?dl=1
The 7z includes
* PRIMARY.BIN (32MB)
* CBDUMPER.LOG
* Version Info.txt (Output of ver.req)

Please check if the file contains everything that is needed.

BR
Nippey


PS:
I already tried to follow srsa_4c's method for disassembling DIGIC6 code.
Now I have a disassembly with a lot of "loc_*" labels, but I'm lost here :D

What to do now?
Can I already compare signatures of the SX280 with the signatures in this disassembly?
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: G3 X 1.00C FW Dump
« Reply #1 on: 15 / September / 2015, 17:22:19 »
Hi,
Quote from: Nippey on 15 / September / 2015, 03:38:39
Please check if the file contains everything that is needed.
the dump looks correct.
Quote
Now I have a disassembly with a lot of "loc_*" labels, but I'm lost here
If you'd like to start something, try finding the equivalents of the sx280 102b addresses (found in stubs_entry_2.S). You obviously need to disassemble the sx280 102b firmware for this.
I highly recommend applying the known names found in the attached csv file to the disassembly with the stubs2disv7.pl script.
Logged
*

Offline fe50

  • ******
  • 3152
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: G3 X 1.00C FW Dump
« Reply #2 on: 20 / September / 2015, 04:03:08 »
@Nippey
Hello & welcome, thanks for the dump  :)
Quote from: fe50 on 20 / September / 2015, 04:02:03
Added the
  • G3X 1.00C
full 32MB dump by Nippey from this forum post to the CHDK P&S FW dumps repository.
Logged
*

Offline Nippey

  • *
  • 7
Re: G3 X 1.00C FW Dump
« Reply #3 on: 29 / September / 2015, 17:17:19 »
Hey,

I think this isn't enough to start a separate G3 X porting thread, but I managed to find stunning 14 pointers! ;D

I'll attach them here as I'm on vacation now and won't be online the next month.
(Based on srsa's csv file.)
« Last Edit: 29 / September / 2015, 17:18:52 by Nippey »
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: G3 X 1.00C FW Dump
« Reply #4 on: 29 / September / 2015, 20:03:13 »
Quote from: Nippey on 29 / September / 2015, 17:17:19
Hey,

I think this isn't enough to start a separate G3 X porting thread, but I managed to find stunning 14 pointers! ;D

I'll attach them here as I'm on vacation now and won't be online the next month.
(Based on srsa's csv file.)
I'd vote for this giving you fair claim on starting the G3X porting thread.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Nippey

  • *
  • 7
Re: G3 X 1.00C FW Dump
« Reply #5 on: 23 / November / 2015, 08:07:47 »
Thx @waterwingz :D

Just a lifesign of myself:
In the meantime I found about 50% of the function calls, whose references I know for the SX280 firmware thx to srsa.

All by finding similarities and visual diffing between the G3X and the SX280 code. Ugh.
@srsa: How did you manage to find ALL references in an appropriate amount of time??

Currently I'm writing a script that extracts call-graphs from a known function to another known function from the SX280 firmware.
So, I can follow the same graph from a known to an unknown function on the G3X firmware.

Lets see if this works...
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: G3 X 1.00C FW Dump
« Reply #6 on: 23 / November / 2015, 12:13:21 »
Quote from: Nippey on 23 / November / 2015, 08:07:47
In the meantime I found about 50% of the function calls, whose references I know for the SX280 firmware
That's very nice. I probably have to mention here that one doesn't need to know all those addresses for a functioning port. The (currently) required ones can be found in the stubs_entry.S stubs_entry_2.S and stubs_min.S files.
However, if you know a large number of additional functions, your disassembly looks much more friendly and finding new stuff becomes easier.

Quote
All by finding similarities and visual diffing between the G3X and the SX280 code. Ugh.
@srsa: How did you manage to find ALL references in an appropriate amount of time??
I used firmware disassemblies of some new models (pre-DIGIC 6). The sigfinder does a good job on these, and many parts of the code are shared between D6 an pre-D6 models. If you locate a routine that is the same or similar in your cam and a reference D4+ cam, you can easily collect the functions that are referenced in it.
Also, there are so-called "jumptables" where a large number of functions are referenced by their address - the table entries are usually in very similar order.
I know of two such tables, see these sx280 excerpts:
Code: [Select]
fc028420: 499b      ldr r1, [pc, #620] ; 0xfc028690: (fc15a7e5) <AllocateUncacheableMemory>
fc028422: 64c1      str r1, [r0, #0x4c]
fc028424: 499b      ldr r1, [pc, #620] ; 0xfc028694: (fc15a811) <FreeUncacheableMemory>
fc028426: 6501      str r1, [r0, #0x50]
fc028428: 499b      ldr r1, [pc, #620] ; 0xfc028698: (fc29aabf) <RegisterEventProcedure_arg3_equals_zero_>
fc02842a: 6541      str r1, [r0, #0x54]
fc02842c: 499b      ldr r1, [pc, #620] ; 0xfc02869c: (fc29aa6d) <RegisterEventProcedure>
fc02842e: 6581      str r1, [r0, #0x58]
fc028430: 499b      ldr r1, [pc, #620] ; 0xfc0286a0: (fc29aac3) <UnRegisterEvntProc>
fc028432: 65c1      str r1, [r0, #0x5c]
Code: [Select]
fc3e234e: 49ff      ldr r1, [pc, #1020] ; 0xfc3e274c: (fc29aa6d) <RegisterEventProcedure>
fc3e2350: 6581      str r1, [r0, #0x58]
fc3e2352: 49ff      ldr r1, [pc, #1020] ; 0xfc3e2750: (fc29aac3) <UnRegisterEvntProc>
fc3e2354: 65c1      str r1, [r0, #0x5c]
fc3e2356: 49ff      ldr r1, [pc, #1020] ; 0xfc3e2754: (fc29abc7) <register_eventproctable>
fc3e2358: 6601      str r1, [r0, #0x60]
fc3e235a: 49ff      ldr r1, [pc, #1020] ; 0xfc3e2758: (fc29abdd) <unregister_eventproctable>
fc3e235c: 6641      str r1, [r0, #0x64]
fc3e235e: 49ff      ldr r1, [pc, #1020] ; 0xfc3e275c: (fc28fd87) <Fopen_Fut>
fc3e2360: 6681      str r1, [r0, #0x68]
fc3e2362: 49ff      ldr r1, [pc, #1020] ; 0xfc3e2760: (fc28fdaf) <Fclose_Fut>
fc3e2364: 66c1      str r1, [r0, #0x6c]The first entry of these tables is a string that looks like a version number:
Code: [Select]
fc0283d4: a199      add r1, pc, #612 ; 0xfc02863c: (30302e30) *"0.001"
fc0283d6: 6001      str r1, [r0, #0] You need to check them of course, because these tables tend to change slightly from time to time.

Additionally, there are event procedure tables. If you locate them, you can do a harvest because they reference both name and function address.
« Last Edit: 23 / November / 2015, 12:16:28 by srsa_4c »
Logged
*

Offline Nippey

  • *
  • 7
Re: G3 X 1.00C FW Dump
« Reply #7 on: 17 / December / 2015, 15:55:16 »
Hey,

thanks for the hints.
I could find 3 more functions this way.

Regarding the stubs_entry.S, I chose an arbitrary file from the trunk from another model and started to search specifically for these missing functions.

I found 91% of stubs_entry.S and 84% total.
You'll find my progress attached.

Regarding the remaining functions it gets more and more difficult to have success.
I will now start to read everything regarding compiling
 * any code
 * an led blinker
 * chdk itself

If I start to move towards chdk building, I'll create the appropriate thread.
Happy Holidays!
Logged
*

Offline Nippey

  • *
  • 7
Re: G3 X 1.00C FW Dump
« Reply #8 on: 04 / February / 2016, 01:53:50 »
Maybe I am not yet ready to think about "porting".

I first wanted to find the LED addresses and blink them.

So I identified the functions "task_LEDCon" and "LEDTable_Init".
The Base Address of the LEDs was easy to find.
After tearing apart both functions, I still have no clue about the individual offset addresses.

Both functions share a set of global variables (pointers).
  • One Semaphore
  • One MsgQueue
  • Three dynamically allocated memories

One of these memories is an array of a struct.
The array size is 7 elements and the struct has a size of 36 Words.
The uin32_t with Offset 0x8 contains the offset that is read by "task_LEDCon".

But "LEDTable_Init" sets it to zero.
So regardless of what LED Number comes out of the MsgQueue, and what array element is chosen, the uint32_t at 0x8 is always zero.
This doesn't make sense.

It seems like there must be another function called after "LEDTable_Init" to populate the offset address of the respective LED.

====>
Do you think it is possible to change the dumper script to first get the address of the allocated array and then dump the array itself?
How do I use and dereference pointers in Canon Basic?
Can I simply do the following?
(Couldn't get it to run yet..)

Code: [Select]
table_ptr = 0xBAC8       'Global Pointer to LEDTable
table_addr = *table_ptr  'Address of LEDTable
Fwrite_Fut(table_addr, 7*36*4, 1, dumpfile)   'Dump LEDTable
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: G3 X 1.00C FW Dump
« Reply #9 on: 04 / February / 2016, 12:48:02 »
Quote from: Nippey on 04 / February / 2016, 01:53:50
I first wanted to find the LED addresses and blink them.

So I identified the functions "task_LEDCon" and "LEDTable_Init".
The Base Address of the LEDs was easy to find.
After tearing apart both functions, I still have no clue about the individual offset addresses.

Both functions share a set of global variables (pointers).
  • One Semaphore
  • One MsgQueue
  • Three dynamically allocated memories

One of these memories is an array of a struct.
The array size is 7 elements and the struct has a size of 36 Words.
The uin32_t with Offset 0x8 contains the offset that is read by "task_LEDCon".

But "LEDTable_Init" sets it to zero.
So regardless of what LED Number comes out of the MsgQueue, and what array element is chosen, the uint32_t at 0x8 is always zero.
This doesn't make sense.

It seems like there must be another function called after "LEDTable_Init" to populate the offset address of the respective LED.
The function I'd call LEDtable_init is sub_fc075dc4. The suspicious values there are 0x21 and 4. "poke_gpio" is sub_fc0d79d8 - the objdump based disassembly gets derailed right before its start, but you can use reyalp's capdis tool to disassemble it correctly. The base address is 0xd20b0800 (as on all D6 cams so far), so the two LED candidates are 0xd20b0800+(0x21*4) and 0xd20b0800+(4*4). The magic numbers (for switching them on/off) are still 0x4d0002 and 0x4c0003.
I'm assuming you do follow reyalp's work on the D6 sigfinder - it's progressing pretty well.

Quote
How do I use and dereference pointers in Canon Basic?
We don't know all details of this language. I'd probably use the peek event procedures that are registered by System.Create: Peek8, Peek16, Peek32 - for addresses, you obviously need Peek32.
Logged
Pages: [1] 2 3   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal