best tool to reverse-engineer a WinXP PS/2 touchpad driver?

Question

I have a PS/2 touchpad which I would like to write a driver for (I'm just a web guy so this is unfamiliar territory to me). The touchpad comes with a Windows XP driver, which apparently sends messages to enable/disable tap-to-click. I'm trying to find out what message it is sending but I'm not sure how to start. Would software like "Syser Debugger" work? I want to intercept outgoing messages being sent to the PS/2 bus.

Answer 1

IDA Pro won't be much use to you if you want to find out what 'messages' are being sent. You should realise that this is a very big step up for most web developers, but you already knew that?

I would start by deciding if you really need to work at the driver-level, often this is the Kernel level. The user mode level may be where you want to look first. Use a tool like WinSpy or other Windows debug tool to find out what messages are getting passed around by your driver software, and the mouse configuration applet in control panel. You can use the Windows API function called SendMessage() to send your messages to the application from user mode.

Your first stop for device driver development should be the Windows DDK docs and OSR Online.

Answer 2

I suggest reading the synaptics touchpad specs (most of the touchpads installed on notebooks are synaptics') available here http://www.synaptics.com/decaf/utilities/ACF126.pdf I believe on page 18 you'll find the feature you are looking for. At least you'll know what to expect.

So, very likely, the touchpad driver "converts" the command coming from user mode to this PS/2 command.

I don't know the specifics of the touchpad PS/2 driver but I see two major ways for the user mode panel to communicate with the driver: - update some key in the registry (this is actually very common) - the driver provides an alternate "channel" that the user mode app opens and writes specific commands to

You may want to try using the process monitor from sysinternals to log registry activity when setting/resetting the feature. As for the options 2 you may want to try IRP tracker from OSR and see if there's any specific communication between the panel and the driver (in the form or IRPs going back and forth). In this case, kernel programming knowledge is somewhat required. The windows kernel debugger may also be useful to see if the PS/2 driver has some alternate channel.

Answer 3

Have a look at IDA Pro - The Interactive Disassembler. It is an amazing disassembler.

If you want to debug, not just reverse engineer, try PEBrowse Professional Interactive from SmidgeonSoft