chdk in the DIGIC6 world

reyalp

14033

Re: chdk in the DIGIC6 world

« Reply #50 on: 05 / October / 2015, 22:22:11 »

Advertisements

Quote from: srsa_4c on 05 / October / 2015, 17:07:15

Remembering that ARM firmwares use a single function to compute division and modulo, just tried the latter (=return 0%0), only to find that it crashes the camera as well. Will it be possible to find the rest of unsafe operations (if there's more) and fix them?

Modulo can probably replaced in the same manner. I wouldn't expect integer operations that don't involve division to trigger an exception.

Logged

Don't forget what the H stands for.

reyalp

14033

Re: chdk in the DIGIC6 world

« Reply #51 on: 08 / November / 2015, 19:01:51 »

In trunk r4285, I checked in the Lua div change, along with a corresponding change for mod.

As far as I can tell, the pre-digic 6 CPUs return 0 for anything%0.

Logged

Don't forget what the H stands for.

reyalp

14033

Re: chdk in the DIGIC6 world

« Reply #52 on: 13 / December / 2015, 02:54:20 »

I started playing around http://www.capstone-engine.org/

Handles thumb2. The windows library didn't work with my mingw setup, but source compiled easily enough. It seems like bolting this into code_gen shouldn't be too terrible.

There are also some potentially useful tools built on it http://www.capstone-engine.org/showcase.html

Logged

Don't forget what the H stands for.

waterwingz

12138

« Reply #53 on: 13 / December / 2015, 07:45:57 »

Quote from: reyalp on 13 / December / 2015, 02:54:20

It seems like bolting this into code_gen shouldn't be too terrible.

Nice find!!
It would be great to finally move away from the current hodge-podge of obsolete IDA scripts, roll-your-own dissassemblers, and partially functional gcc tools.

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14033

Re: chdk in the DIGIC6 world

« Reply #54 on: 14 / December / 2015, 01:49:00 »

http://www.hopperapp.com/ is an interactive disassembler based on capstone, for Mac and Linux. It's no IDA, but it's much more affordable and from a few minutes playing with the demo seems pretty usable on a digic 6 dump.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #55 on: 21 / May / 2016, 09:56:40 »

In addition to the previously mentioned CPU cores, there may be even more (inside or outside the DIGIC, I don't know).
Just realized that audio and video compression related strings (or at least, most of them) are not referenced in the main firmware. They are concentrated in an area in RAM that starts at 0xe00000 (sx280). The main firmware has lots of interface code and tasks (some examples: "TricEncVTask", "TricEncMsgTask"; also error-like messages like "ER DecVTSkCrat", "ER IniEventCrat", "ER DelTsk", ...).
If this thing runs independent of the main core, that would probably explain why movie related things crash the camera after booting with the firmware update method.

The audio/video stuff is followed by networking (wifi) related code, with big chunks of recognizable ARM instructions (did not check for thumb).

Logged

reyalp

14033

Re: chdk in the DIGIC6 world

« Reply #56 on: 21 / May / 2016, 14:19:04 »

Quote from: srsa_4c on 21 / May / 2016, 09:56:40

In addition to the previously mentioned CPU cores, there may be even more (inside or outside the DIGIC, I don't know).
Just realized that audio and video compression related strings (or at least, most of them) are not referenced in the main firmware. They are concentrated in an area in RAM that starts at 0xe00000 (sx280). The main firmware has lots of interface code and tasks (some examples: "TricEncVTask", "TricEncMsgTask"; also error-like messages like "ER DecVTSkCrat", "ER IniEventCrat", "ER DelTsk", ...).
If this thing runs independent of the main core, that would probably explain why movie related things crash the camera after booting with the firmware update method.

The audio/video stuff is followed by networking (wifi) related code, with big chunks of recognizable ARM instructions (did not check for thumb).

Interesting.

FWIW, I noticed this a while back (g7x ROM):
fcc3c448 exception 0:Illegal Instruction
fcc3c46c exception 1:System Call
fcc3c488 exception 2:Instruction Fetch Error

These aren't ARM exception numbers. Googling the strings lead me to
https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/extra_include/xtensa/corebits.h
https://github.com/espressif/ESP8266_RTOS_SDK
https://en.wikipedia.org/wiki/ESP8266

From other strings, I'm pretty sure this identification is correct. This is not an ARM core. OTOH, it appears to be somewhat well documented.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: chdk in the DIGIC6 world

« Reply #57 on: 21 / May / 2016, 20:55:34 »

Quote from: reyalp on 21 / May / 2016, 14:19:04

FWIW, I noticed this a while back (g7x ROM):
fcc3c448 exception 0:Illegal Instruction
fcc3c46c exception 1:System Call
fcc3c488 exception 2:Instruction Fetch Error

These aren't ARM exception numbers. Googling the strings lead me to
https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/extra_include/xtensa/corebits.h
https://github.com/espressif/ESP8266_RTOS_SDK
https://en.wikipedia.org/wiki/ESP8266

From other strings, I'm pretty sure this identification is correct. This is not an ARM core. OTOH, it appears to be somewhat well documented.

That's a useful find. That means at least one of the (integrated?) cores is an Xtensa variant. The strings are located in the area I mentioned in my previous post (near the audio/video compression related strings).
Unfortunately, the code that sets up this core seems quite obscure (I have tried following a path starting in task_MovieInit, but it only seems to do some indirect steps - such as specifying the RAM area. The ROM -> RAM copy seems to be done elsewhere. )...

Logged

reyalp

14033

Re: chdk in the DIGIC6 world

« Reply #58 on: 21 / May / 2016, 21:50:13 »

Another observation on the DryOS firmware that appears near the TAKUMI GPU and FPU related strings:

Code: [Select]

fcb3f3b1 -- INTC Illegal inter 0x%x(%d) --
fcb3f3d4  R%2d  : %08x
fcb3f3e4  PS   : %08x
fcb3f3f4  PC   : %08x
fcb3f404 < Error Exception >
fcb3f41c  EXCCAUSE : %d
fcb3f42c  ISR      : %s
fcb3f43c TRUE
fcb3f444 FALSE
fcb3f44c  TASK ID   : %08x
fcb3f460  TASK Name : %s
fcb3f474 DRYOS PANIC: Module Code = %d, Panic Code = %d

The register and error strings don't look like what canon users for ARM firmware (PS rather than CPSR for example).

Aside: Other strings in this firmware refer to "Mzrm", e.g. "MzrmRcvTskMain Start"). In the main firmware, a function called from GUISrv_StartGUISystem refers to "MzrmGraphic"

The main exception related strings are:

Code: [Select]

fc088914  R%2d  : %08x
fc088924  R13  : %08x
fc088934  R14  : %08x
fc088944  PC   : %08x
fc088954  CPSR : %08x
fc088964  CTRL : %08x
fc0889dc < Error Exception >
fc0889f4 abort
fc0889fc undefined
fc088a0c prefetch
fc088a18  TYPE : %s
fc088a24 TRUE
fc088a2c FALSE
fc088a34  ISR  : %s
fc088a40  TASK ID   : %08x
fc088a54  TASK Name : %s
fc088a70 DRYOS PANIC: Module Code = %d, Panic Code = %d

The other mystery DryOS ROM looks a lot like the main firmware:

Code: [Select]

fc5bdfa4  R%2d  : %08x
fc5bdfb4  R13  : %08x
fc5bdfc4  R14  : %08x
fc5bdfd4  PC   : %08x
fc5bdfe4  CPSR : %08x
fc5bdff4  CTRL : %08x
fc5be06c < Error Exception >
fc5be084 abort
fc5be08c undefined
fc5be09c prefetch
fc5be0a8  TYPE : %s
fc5be0b4 TRUE
fc5be0bc FALSE
fc5be0c4  ISR  : %s
fc5be0d0  TASK ID   : %08x
fc5be0e4  TASK Name : %s
fc5be100 DRYOS PANIC: Module Code = %d, Panic Code = %d

I wish I had names for these different ROMs...

Logged

Don't forget what the H stands for.

reyalp

14033

Re: chdk in the DIGIC6 world

« Reply #59 on: 22 / May / 2016, 00:50:04 »

I think I've found some of the ROM->RAM copies

On G7x

GUISrv_StartGUISystem ->fc1ee768->fc380706

fc380706 references "MzrmGraphic", and calls fc4e2134

fc4e2134 references "ZicoKick Start\n"
writes 1 to MMIO 0xd20f0120
then makes several calls like
memcpy(*p, p+8, *(p+4))
followed by a call to fc133dae (looks cache / mpu related?) and writing 2 to the MMIO.

The copied chunks (as src, dest, count) look like
0xfcb212e4 0xbff20000 0x000077b8
0xfcb28aa4 0xbff00000 0x00004ad0
0xfcc33684 0x00c00000 0x00000000 (?! unused?)
0xfcb2d57c 0x80a00000 0x00106100 (?)

On sx280hs 102b, the "ZicoKick Start" function is fc3d8e74

There are also some references to GrphLog and ZicoLog which might worth looking into.

edit:
I dumped both the source and destination of the ranges above.
Only 0xfcb28aa4 / 0xbff00000 appears to have changed.
0xfcb2d57c / 0x80a00000 contains DryOS kernel, Mzrm* and OpenGL related strings.

I switched to rec and took a shot before dumping the RAM.

« Last Edit: 22 / May / 2016, 01:34:51 by reyalp »

Logged

Don't forget what the H stands for.