I'm working on the same kind of thing Bogdan was working on last year(hooking the keyboard interrupt handler). Only for me it is on W2K\XP. No difference at all, because I wrote a Kernel Driver that allows me to work in Ring 0. Note that in W2K, IRQ01 corresponfs to int31h.
Here is my code :
pushad
sidt fword ptr IDT_Limit
mov eax, IDT_BaseAddress
mov ebx, 031h
shl ebx, 3
add eax, ebx
mov IDT31_off, eax
mov dx, word ptr
mov Save2, dx
mov dx, word ptr
mov Save1, dx
cli
lea ebx, My_Int31
mov word ptr , bx
shr ebx, 16
mov word ptr , bx
sti
int 31h
cli
mov dx, Save1
mov word ptr , dx
mov dx, Save2
mov word ptr , dx
sti
popad
My_Int31h is my keybooard ISR. My problem : the IDT is effectively changed and then back, but my_Int31 is never called. Can someone help me?
Thanks in advance.
Nico.
Here is my code :
pushad
sidt fword ptr IDT_Limit
mov eax, IDT_BaseAddress
mov ebx, 031h
shl ebx, 3
add eax, ebx
mov IDT31_off, eax
mov dx, word ptr
mov Save2, dx
mov dx, word ptr
mov Save1, dx
cli
lea ebx, My_Int31
mov word ptr , bx
shr ebx, 16
mov word ptr , bx
sti
int 31h
cli
mov dx, Save1
mov word ptr , dx
mov dx, Save2
mov word ptr , dx
sti
popad
My_Int31h is my keybooard ISR. My problem : the IDT is effectively changed and then back, but my_Int31 is never called. Can someone help me?
Thanks in advance.
Nico.
Different processes may have different IDTs. If you want to hook the keyboard ISR, you should use appropriate system APIs. If you want to install a handler callable in your process from user mode, you must set the DPL equal to 3.
I'm using a kernel-mode driver, so I am already in Ring0. This is thus not an issue. Sorry for the lack of precision.
Nico.
Nico.
the only reasons I can imagine why my_int31 isn't called are
- wrong definition of IDT_BaseAddress
- selector in gate is not zero-based (pretty unlikely)
- wrong definition of IDT_BaseAddress
- selector in gate is not zero-based (pretty unlikely)
I'm sure there is no problem with IDTBaseAddress. Indead I found a tool that gives me the exact composition of the IDT.
All the selectors of all Interrupts are 0008 (base = 1, TI = 0, RPL = 0) Should I put base=0 for my routine? I tried it, it doesn't change a thing.
Is the 31st entry of the IDT the keyboard ISR (corresponding to int9 in real mode)? Or is it another?
I'm kinda puzzled here..
Thanks for your help guys.
Nico.
All the selectors of all Interrupts are 0008 (base = 1, TI = 0, RPL = 0) Should I put base=0 for my routine? I tried it, it doesn't change a thing.
Is the 31st entry of the IDT the keyboard ISR (corresponding to int9 in real mode)? Or is it another?
I'm kinda puzzled here..
Thanks for your help guys.
Nico.
I doubt that GDT selector 8 has a base of 1???
BTW, how do you know your routine isn't executed?
BTW, how do you know your routine isn't executed?
Hi,
Maybe this thread help you:
http://www.asmcommunity.net/board/viewtopic.php?t=18859&highlight=
It creates a new IDT entry number 0xed
Regards,
Opcode
Maybe this thread help you:
http://www.asmcommunity.net/board/viewtopic.php?t=18859&highlight=
It creates a new IDT entry number 0xed
Regards,
Opcode
No there is no problem with changing the IDT.
After several documentation readings, it seems that the 9th entry of the IDT corresponds to some exception, AND to IRQ1.
So I change the IDT to point at my handler. My handler is really simple : it waits for an output at port 64h (keyboard), once there is one it disables the keyboard, sends an End Of Interrupt to the PIC. After my handler has been executed once (one keystroke UP), my main program changes the IDT back. The only thing visible after I launche my driver should be the loss of the first charcter typed on the keyboard. But it's not.
Instead, everything stays normal.
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr............
Thanks for your help guys.
Nico.
After several documentation readings, it seems that the 9th entry of the IDT corresponds to some exception, AND to IRQ1.
So I change the IDT to point at my handler. My handler is really simple : it waits for an output at port 64h (keyboard), once there is one it disables the keyboard, sends an End Of Interrupt to the PIC. After my handler has been executed once (one keystroke UP), my main program changes the IDT back. The only thing visible after I launche my driver should be the loss of the first charcter typed on the keyboard. But it's not.
Instead, everything stays normal.
rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr............
Thanks for your help guys.
Nico.
DUH, it's pretty trivial actuelly. If no HW interrupt occurs during the execution of my driver, nothing is going to happen. Sorry for the stupidity.
On the contrary, if I let the IDT point to my handler, and do'nt change it back, every thing stays the same, nothing happens, and my keyboards works. It's as though Windows was letting me beleive that I had changed the IDT, but was one step ahead of me.
Again rrrrrrr....
Nico.
On the contrary, if I let the IDT point to my handler, and do'nt change it back, every thing stays the same, nothing happens, and my keyboards works. It's as though Windows was letting me beleive that I had changed the IDT, but was one step ahead of me.
Again rrrrrrr....
Nico.
I don't know much about driver , can u post the right code again ?
Can anyone tell me how to use that code in Delphi Or VC ?
Thanx a lot .
Can anyone tell me how to use that code in Delphi Or VC ?
Thanx a lot .