Hi all!
i am reversing driver with IDT hook on int1 and int3. I use VMWare and WinDbg as kernel debugger via named pipe. To be able to set a breakpoint i was forced to patch driver. So now patched driver not set his own int1 and int3 handler. But here come the problem, because driver code call int instruction itself and i need trace into driver int handler. How to proceed in this situation? Can i "simulate" int event and call driver handler with correct parameters? Or let the driver change IDT and patch int handler to remove IDT hook and put int 3(so my WinDbg break) instruction here? Is it safe to manipulate with IDT inside int handler?
thank you and sorry for my bad english.

Kayaker, I think someone just called your name...

What I'd probably try is to set breakpoints on the drivers INT handlers directly, rather than patching and breaking the driver.

Break on DriverEntry (via the direct [Call] in ntoskrnl!IopLoadDriver, assuming it's loading as a "normal" driver) and single step into the driver. If the driver is setting up an IDT hook, there's a good chance it's doing that during initialization/DriverEntry. If not, and it's from a separate IOCTL call, then determine the address of and set a breakpoint on IRP_MJ_DEVICE_CONTROL and continue from there.

Assuming you have an IDA disassembly on hand you should be able to recognize and trace through the IDT hook code itself and find an absolute address for the new INT handlers. Or, if you can find the two handler offsets in IDA, calculate their addresses from the base address of the driver.

Set regular breakpoints on one or the other handler addresses and you should be able to trace their normal operation.

Of course, theory doesn't always assure success, VMWare/WinDbg might do funny things..

Kayaker

You can issue a different interrupt and then get a breakpoint in SoftIce via command - this is the way the old StarForce Driver was debugged with all its r0/r3 swaps via ints.

Dont know WinDBG, sorry, but your simplest bet is to write a simple driver that calls for the service interrput or similar of WinDBG i.e. whenever UD2 is issued - then you use UD2 as a breakpoint instead of CCh.