Hooking Functions - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: [1] 2   Go Down

Hooking Functions

  • 17 Replies
  • 5503 Views
*

Offline barberofcivil

  • ****
  • 268
    • deviantART Gallery
Hooking Functions
« on: 31 / October / 2009, 10:27:03 »
Advertisements
I'm looking for assistance on trying to hook into some functions.  Is it only possible to hook into 'registered, named' tasks?  Using the SX10 103A as my example, when looking at the currently hooked tasks (CaptSeqTask, ExpDrvTask, etc), they appear to get 'registered' at the subroutine at address FF827D10.  Indeed, every call to this function can be traced back to carrying the R0 and R3 registers which hold the task name and task start address respectively, and I have been able to find and list off all functions registered in this manner.  I have tried and been able to hook into any of these tasks (DvlpSeqTask, IrisEvent, etc) successfully.

However, my problem is that there are some functions that I would like to explore that I can't get to directly or indirectly through any of these named tasks.  They trace back to dead ends:  they reach a point where they are not called directly.  For exaple, one function in particular gets traced back to an entry point at FF852B60 which isn't branched to or called directly, it's only reference is:
ff852d9c:    sub   r0, pc, #580   ; ff852b60: (e92d4010)

As far as can tracer back, I can't get directly into one of the named tasks that I know I can hook.  Is there a way that I can hook other functions such as this? Or am I limited to the realm of named tasks and wherever they can lead me?

Logged
*

Offline RaduP

  • *****
  • 926
Re: Hooking Functions
« Reply #1 on: 31 / October / 2009, 14:27:43 »
Probably not, but what you can try to do is search the RAM for the address of that function, and if you find it, you might be able to replace it with your modified code.
Logged
*

Offline reyalp

  • ******
  • 14079
Re: Hooking Functions
« Reply #2 on: 31 / October / 2009, 16:56:20 »
Quote from: barberofcivil on 31 / October / 2009, 10:27:03
I'm looking for assistance on trying to hook into some functions.  Is it only possible to hook into 'registered, named' tasks?  Using the SX10 103A as my example, when looking at the currently hooked tasks (CaptSeqTask, ExpDrvTask, etc), they appear to get 'registered' at the subroutine at address FF827D10.
These are tasks, which are somewhere similar to a thread or process in a traditional OS. If you hook the beginning of the task, you modify it's entire behavior, but you might end up having to duplicate lots of the original code. Multiple tasks frequently use the same functions, so it's quite possible to replace the functionality in one task, yet have the old function used in other tasks.

Quote
As far as can tracer back, I can't get directly into one of the named tasks that I know I can hook.  Is there a way that I can hook other functions such as this? Or am I limited to the realm of named tasks and wherever they can lead me?
Not entirely, but this is how CHDK currently accesses almost everything.

Other options:
Some functions are accessed from pointers, e.g. a filesystem driver will have the read and write functions stuffed into a structure, and access them by that structure later. Many of the function pointers are in the canon initialized data segment, which is copied from ROM to RAM in the very first loop of the firmware code. You should be able to find/replace these quite easily. Others are set up by code elsewhere. Of course, a function might be called both via a pointer and via directly by it's ROM address.

Some functions are accessed as event procedures: see http://chdk.setepontos.com/index.php/topic,4417.0.html
The event procedure API allows you to have a hook run before every eventproc call. Part of ExecuteEventProcedure looks something like this (taking a610 sig_ref_vxworks_1 as an example, dryos does the same thing but is slightly less clear because the eventproc hook comes from a struct):
Code: [Select]
loc_FFC06864
                 LDR     R3, =0x102BC   ; parameter for event hook
                 LDR     R1, [SP,#0x10]  ; event proc name
                 LDR     R0, [R3]
                 LDR     R2, =0x1E1C     ; event proc hook variable
                 MOV     LR, PC
                 LDR     PC, [R2]        ; call hook
                 LDR     R3, [SP]
                 MOV     R0, R5
                 LDR     R1, [R3]
                 MOV     LR, PC
                 LDR     PC, [R3,#4]     ; call eventproc
...
There exists functions to set and remove this hooks, and at least one example which logs the event names.

Note that this doesn't allow you to modify the behavior of the event procs, but it should allow you to see which ones are called.

If you want to modify the behavior, you should be able to unregister an existing eventproc and register your own. Be warned however that just because a function is available as an eventproc doesn't mean it is always called as one. Many are normally called directly by address, and only called as eventprocs in the debug code.

One other idea I've had is abusing the ARM MPU. There are a couple of memory regions that are not used in the default configuration, so you could install your own exception handler, and protect the region of interest against reading. When the stock firmware tries to jump there, your exception handler gets invoked, and you set it up to return to your own modified code instead. Unfortunately, the minimum size you trap this way is 4k. So you'd probably have to copy/relocate the entire 4k block, and you'd only get 1 or 2 at the most (unless you move them around.)
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Hooking Functions
« Reply #3 on: 31 / October / 2009, 17:56:28 »
Would it be possible to set up a hardware breakpoint on execution, in the ROM memory?
Logged
*

Offline reyalp

  • ******
  • 14079
Re: Hooking Functions
« Reply #4 on: 31 / October / 2009, 19:11:25 »
My understanding (based on a limited reading of DDI0201D ARM946E-S Technical Reference Manual: Chapter 9 Debug Support) is that the hardware debug interface requires external hardware, which is at least inaccessible and possibly not present on production cameras.
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Hooking Functions
« Reply #5 on: 31 / October / 2009, 19:19:25 »
I was reading that too and it is confusing.
I am not sure if you are familiar with the 386 CPUs, but on them you can set hardware breakpoints in the protected mode, and when a memory location is read, modified or executed it will pass the control to your code. I wonder if the ARMs have something similar..
Logged
*

Offline reyalp

  • ******
  • 14079
Re: Hooking Functions
« Reply #6 on: 31 / October / 2009, 20:00:40 »
Quote from: RaduP on 31 / October / 2009, 19:19:25
I wonder if the ARMs have something similar..
I'm confident that 946E-S does not. It would be reference manual if it was there. This makes sense for embedded systems, the developers will have access to the hardware interface, and won't run their debugger on the target.

Possibly if you open up your camera, you can access the JTAG interface ;)
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Hooking Functions
« Reply #7 on: 31 / October / 2009, 21:55:54 »
I guess you are right about it, I tried to find ways to enable the debugging without jtag and it doesn't seem to work.
Although your MPU idea made me rethink again of my moving the ROM to RAM idea. This way, the non relative jumps do not have to be converted, and if the program jumps into the ROM, or tries to read data from there, the MPU exception handle could correct this behavior by pointing to the new location in RAM (simple math). But this could be slow at times..
Logged
*

Offline barberofcivil

  • ****
  • 268
    • deviantART Gallery
Re: Hooking Functions
« Reply #8 on: 01 / November / 2009, 12:11:45 »
Thanks guys.  Looks like this is likely beyond my current capabilities.  I've learned how to hook the tasks by emulating what has already been done, so Iguess I'll just have to stick to exploring the hookable tasks at the moment.

What I'm currently looking for is how the controlling of the highspeed photo capture works (the ISO3200 function).  The CHDK overrides work for changing the ISO (and shutter/aperture), so that this mode can be used with standard ISOs.  However, the image size overrides have no effect, they remain at the 1200x1600 size.  I would like to see if it is possible or not to override this and use larger image sizes or if it's inherent to the whole mode itself.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Hooking Functions
« Reply #9 on: 01 / November / 2009, 12:53:53 »
On many cameras, ISO 1600 is not different in what the sensor gets than ISO 800. The only difference is that the camera is brightening it in software. So don't waste your time with ISO 3200, just shoot raw an adjust the exposure in your raw processing program.
Logged
Pages: [1] 2   Go Up
« previous next »
 

Related Topics