Reverse Engineering an Apple Kext - Reconstructing the Class

Greetings!

I am currently attempting to extend the functionality of the Magic Mouse. To do this, I am hoping to write a kext that intercepts events from the multitouch driver, AppleMultitouchDriver.kext, interprets them, and either dispatches new events or forwards the actual event. This approach is similar to the approach used by DoubleCommand.

I have already created a small test kext that intercepts the mouse events (click, motion, etc) as that will be needed also.

The problem I am having now is that I am unable to intercept the events from the AppleMultitouchDevice and/or AppleMultitouchHIDEventDriver objects because there is no class definition for them. I need to be able to reassign the pointer to the callback function as I do in the mouse interceptor and as is done in DoubleCommand. As far as I know, this means I need to reconstruct the AppleMultitouchDevice class. I already am able to get a reference to the instance of the AppleMultitouchDevice object, so I just need to be able to cast it and use it.

Now that you have the background, here are my direct questions:

What methods do I need to use in order to reverse engineer the kext or reconstruct the classes in question?
What programs are available that will assist me in this effort?
Are there any tutorials or e-books that focus on this particular topic that you know of?
Is it possible for me to reassign the callback pointer without actually reconstructing the entire class?
Anything else I may have missed as I am so very new to this.

Thanks in advance for any advice or assistance!!

Unfortunately not. I have seen this before. It is using the same approach as my post here: http://stackoverflow.com/questions/1669909/extending-functionality-of-magic-mouse-do-i-need-a-kextIt is using the MultiTouchSupport.framework which is in user space. I want to write this in kernel space to get the best control possible.

Sastira 2009-12-16 20:28:21

Care to share with others?

jackrabbit 2010-01-05 19:37:26

I found a program called IDA Pro. It is great for reverse engineering pretty much any binary out there. I am hoping to use that program, in combination with GDB/remote kernel debugging to locate the method in which the callback pointer is assigned. Once I find the offset of the callback pointer, I /should/ be able to reassign it by addressing that memory directly, either through ASM or C.So the hardest part will be tracing through all the method calls and reading all the assembly to find that pointer offset.

Sastira 2010-01-05 19:43:46

What happens when an OS update moves the address of the callback pointer? I wanted to be able to hack the system keyboard driver to treat numpad '/', '*' and '-' as volume up/down/off. I found that while it may be possible to grab the callback it could change with every system update.

Adam Eberbach 2010-02-06 03:49:08

Here's a good link discussing overwriting the system drivers: http://www.obdev.at/developers/articles/00001.html

Adam Eberbach 2010-02-06 03:56:02

Hacking the keyboard driver isn't a problem at all, actually, because that is all given to you in IOHIKeyboard. I work on the (DoubleCommand)[http://github.com/mbaltaks/doublecommand] project and it has worked fine through many releases. The problem you are expecting IS a big deal when you don't have headers, though. If I do find the callback, I'd have to re-find it each time the drivers change.And thanks for the link!!

Sastira 2010-02-10 19:32:20

ansaurus

tags:

views:

answers:

Reverse Engineering an Apple Kext - Reconstructing the Class

related questions