Magic Lantern Firmware Wiki
Magic Lantern Firmware Wiki
Advertisement

Intro[]

Complex programs (like the Canon firmware) have many data structures which group variables belonging to the same module.

Some examples: 2.0.4_HotPlug_Structs, 2.0.4_MovieRecorder_structs, 2.0.4_MovieWriter_structs, 2.0.4_small_LiveView_struct_at_0x44FC, mvr_config from mvr.h...

In C, you would declare a struct like this:

struct foo
{
    int bar;
    int baz;
    ...
};

In Assembler, a member of a structure is referenced like this:

FF0EAC88:	e51f8e78	ldr	r8, [pc, #-3704]	; 0xff0e9e18: pointer to 0x4B4C (aAJ_0x44FC_LiveView_struct_0x00_to_0xC8)	⬁
FF0EAC8C:	e1a04000	mov	r4, r0		⬁
FF0EAC90:	e5980028	ldr	r0, [r8, #40]	; 0x28	⬁
FF0EAC94:	e1a06001	mov	r6, r1		⬁
FF0EAC98:	e1a05002	mov	r5, r2		⬁
FF0EAC9C:	eb03b683	bl	AJ_if_StateObject_then_Get.State__R0.StateObj	

decompiled:

AJ_if_StateObject_then_Get.State__R0.StateObj(*(0x4b74))


Mem-spy (Memory Addresses) and ARM-console decompiler (module "deco") will only show addresses like 0x4b74. These are found after some computation (you can't find them in the dump easily).

Step-by-step example[]

Let's say we have found an interesting address on 550D/1.0.8 or 1.0.9 (these two versions are identical, unlike 60D):

#define FOCUS_CONFIRMATION (*(int*)0x41d0)

To find other related references, you need to find the structure which our address belongs to. We are looking for a number which satisfies these conditions:

  • it's smaller than our interesting address (0x41d0), but not with too much
  • the firmware has some references to it

Load arm-console, define this function:

def guess_struct(d, x, refmin=2, maxsize=1000):
    candidates = {}
    for a,v in d.ROM.iteritems():
        if v <= x and v >= x-maxsize:
            nrefs = len(find_refs(d, v))
            if nrefs > refmin:
                candidates[v] = nrefs
    for c,n in sorted(candidates.iteritems(), key=lambda x: -x[1]):
        print hex(c),"refs=%d" % n, "dif=%d" % (x-c)

... and try it (it will find some candidates and sort them according to the number of references to them).

In [119]: guess_struct(d,0x41d0,2,500)
4000 refs=236 dif=464
4100 refs=54 dif=208
41B4 refs=31 dif=28
41CC refs=20 dif=4
4154 refs=17 dif=124
3FFF refs=17 dif=465
41A0 refs=16 dif=48
4001 refs=13 dif=463
4002 refs=12 dif=462
4009 refs=10 dif=455
4008 refs=9 dif=456
4014 refs=9 dif=444
[...]

Now we have to use some intuition. Obviously, the first results are not the good ones (as you have noticed from the NumPy'ing tutorial, "round" numbers have a lot of references to them, and the reason can be found easily by studying some human psychology :)

So, from these candidates, we notice that "41CC refs=20 dif=4" is very close to our address and the firmware has many references to it, so let's see what other functions are referencing it.

In [120]: d.refs(0x41CC)

olc_info_changed+4:
ff0a8d30:	e59f12ec 	ldr	r1, [pc, #748]	; 0xff0a9024: pointer to 0x41cc
0x41cc

focusinfo+4:
ff0a90f8:	e51f40dc 	ldr	r4, [pc, #-220]	; 0xff0a9024: pointer to 0x41cc
0x41cc

rmt_olc_com_gr8_focusStatus+16:
ff0a8f9c:	e59f5080 	ldr	r5, [pc, #128]	; 0xff0a9024: pointer to 0x41cc
0x41cc

[... and a bunch of others ... ]

Indeed, it seems to be something related to focus and GUI display.

Let's try to see one of those functions:

In [121]: g focusinfo
// Start of function: focusinfo
NSTUB(focusinfo, ff0a90f4):
ff0a90f4:	e92d403e 	push	{r1, r2, r3, r4, r5, lr}
ff0a90f8:	e51f40dc 	ldr	r4, [pc, #-220]	; 0xff0a9024: pointer to 0x41cc
ff0a90fc:	e3a01000 	mov	r1, #0
ff0a9100:	e58d1008 	str	r1, [sp, #8]
ff0a9104:	e5941008 	ldr	r1, [r4, #8]
ff0a9108:	e3510000 	cmp	r1, #0
ff0a910c:	0a00000e 	beq	0xff0a914c: pointer to 0xe5dd2009	
ff0a9110:	e5941004 	ldr	r1, [r4, #4]
ff0a9114:	e3510001 	cmp	r1, #1
ff0a9118:	1a000007 	bne	0xff0a913c: pointer to 0xe3a02004	
In [122]: dec focusinfo
*(-4 + sp0) = lr0
*(-8 + sp0) = unk_R5
*(-12 + sp0) = unk_R4
*(-16 + sp0) = arg3
*(-20 + sp0) = arg2
*(-24 + sp0) = arg1
*(-16 + sp0) = 0
if *(0x41D4) == 0:
    *(-24 + sp0) = BYTE(MEM(-15 + sp0))
    DebugMsg(159, 1, msg='    focusinfo %x,%x,%lx', BYTE(0), BYTE(MEM(-15 + sp0)), arg2, 0x0, unk_R4, ...)
    return ret_DebugMsg_FF0A9168
if *(0x41D0) != 1:
    PD_NotifyOlcInfoChanged(0x0, -16 + sp0, 0x4, arg3) => ret_PD_NotifyOlcInfoChanged_FF0A9148
    *(-24 + sp0) = BYTE(MEM(-15 + sp0))
    DebugMsg(159, 1, msg='    focusinfo %x,%x,%lx', BYTE(0), BYTE(MEM(-15 + sp0)), arg2, 0x0, unk_R4, ...)
    return ret_DebugMsg_FF0A9168
*(-16 + sp0) = BYTE(MEM(1 + arg0))
*(-15 + sp0) = BYTE(MEM(arg0))
*(-14 + sp0) = BYTE(MEM(2 + arg0))
*(-13 + sp0) = BYTE(MEM(3 + arg0))
PD_NotifyOlcInfoChanged(0x0, -16 + sp0, 0x4, arg3) => ret_PD_NotifyOlcInfoChanged_FF0A9148
*(-24 + sp0) = BYTE(MEM(arg0))
DebugMsg(159, 1, msg='    focusinfo %x,%x,%lx', BYTE(MEM(1 + arg0)), BYTE(MEM(arg0)), arg2, BYTE(MEM(1 + arg0)), unk_R4, ...)
return ret_DebugMsg_FF0A9168
!end

Bingo! Now we have a way to find this address inside a function... we just have to look for "focusinfo" to find this on a new camera.

Applying the new findings on other cameras[]

Let's validate our new finding on 60D and 600D. By decompiling the function referencing "focusinfo %x,%x,%lx", we find:

60D.109 : if *(0x4680) != 1: ... (value identical to the one found with mem-spy -> confirmed)
600D.101: if *(0x479C) != 1: ...

For 50D, I'm too lazy to load the dump and decompile it, so let's just look in assembler:

FF8AF378:	e59f4070	ldr	r4, [pc, #112]	; 0xff8af3f0: pointer to 0x3cdc	
FF8AF37C:	e5941008	ldr	r1, [r4, #8]    ; this will be: r1 = *(int*)0x3ce4;		
FF8AF380:	e3510000	cmp	r1, #0	        ; <--- this is the first decompiled "if"
FF8AF384:	0a000010	beq	FF8AF3CC		
FF8AF388:	e5941004	ldr	r1, [r4, #4]    ; this will be: r1 = *(int*)0x3ce0;
FF8AF38C:	e3510001	cmp	r1, #1	        ; <--- this is the second decompiled "if"
...
FF8AF3E0:	e28f208c	add	r2, pc, #140	; *' focusinfo %x,%x,%lx'

So, the focus confirmation address on 600D is 0x479C, and on 50D is 0x3ce0.

Now, all we have to do is to put the new values in platform/MODEL.FWVERSION/consts.c, in the definition of FOCUS_CONFIRMATION, and try :)

Homework[]

Fix the decompiler so it can show structures and offsets instead of magic numbers.

Discussion[]

http://groups.google.com/group/ml-devel/browse_thread/thread/b50e139a4cf43d40/a01ea49683ad9129?show_docid=a01ea49683ad9129

Advertisement