Some work/rest that i am doing involves sending the IRQ01 to my Ring3 or Ring0 handler. Basically i change the IDT to point to my routine, and of course i set it back to the correct address when my program exits.

If i call the INT 51h by software after i do this IDT (re)setup.... all works ok, my routine is called (hehe with ring0 priviledges) and beeps 2 times.

But if i press any key and a hardware INT01 is generated... :( arghh ...the system goes down like in no keyboard /mouse/hdd (aka no more ints) anymore...

i have been fighting with this from some day now... any suggestions will be appreciated... esp from VECNA :)

some code examples:

old_int01 dd 0
old_int02 dd 0

my_irq equ 51h


mov esi,dword ptr [IDT_Reg+2] ;get IDT base addr

mov eax,dword ptr [esi+(8*my_irq)+0] ; save IDT entry
mov [old_int01],eax

mov eax,dword ptr [esi+(8*my_irq)+4] ; for intxxh
mov [old_int02],eax

push offset Ring0_Irq01

pop word ptr [esi+(8*my_irq)+0] ;set int addr part1

mov word ptr [esi+(8*my_irq)+2],0028h ;set code selector
mov word ptr [esi+(8*my_irq)+4],0EE00h ;set int DPL3

pop word ptr [esi+(8*my_irq)+6] ;set intxxh addr part2



int 51h



mov esi,dword ptr [IDT_Reg+2] ;get IDT base addr


mov eax,[old_int01]
mov dword ptr [esi+(8*my_irq)+0],eax ; save IDT entry

mov eax,[old_int02]
mov dword ptr [esi+(8*my_irq)+4],eax ; for int20h



align 4

Ring0_Irq01 PROC FAR

xor eax,eax
call My_Beep

in al,060h

; send EOI to PIC
mov al,020h
out 020h,al
out 0A0h,al

call My_Beep


Ring0_Irq01 ENDP
Posted on 2002-03-15 12:40:45 by BogdanOntanu

probably your problem isnt there, but seens to me that you forgot a PUSH in your Method5_set proc

mov esi,dword ptr [IDT_Reg+2] ;get IDT base addr
mov eax,dword ptr [esi+(8*my_irq)+0] ; save IDT entry
mov [old_int01],eax

mov eax,dword ptr [esi+(8*my_irq)+4] ; for intxxh
mov [old_int02],eax

push offset Ring0_Irq01
push offset Ring0_Irq01 ;***push once again, to match the number of POPs

pop word ptr [esi+(8*my_irq)+0] ;set int addr part1

mov word ptr [esi+(8*my_irq)+2],0028h ;set code selector
mov word ptr [esi+(8*my_irq)+4],0EE00h ;set int DPL3

pop word ptr [esi+(8*my_irq)+6] ;set intxxh addr part2 (***unmatched POP in original code)



ps: for what you need this? coz you know that this can be used for evil things... :tongue:
Posted on 2002-03-15 12:59:42 by ancev
i know this can be used for evil things, but IMHO there are other easyer methods (that you know better i guess) than hooking on hardware IRQ's. I need this for legitimate work i am doing (a kind of custom keyboard handler cant say more because of NDA)

So basically i want IRQ01 to go thru my proggy and since IRQ01 is mapped to INT51h in windows... (job is only for Win9x/Me not for Win2k/Xp)

i need to be able to efectively "cut off" the keyboard during some proggram phases and to re-enable it again

the first PUSH is a DWORD and the 2 POP's are for a word each one of them.... :) so i guess that is not the problem or am i wrong?

thx anyway

Posted on 2002-03-15 13:29:12 by BogdanOntanu

you right... i see word ptr so rarely that i mistake they by dword ptr :)

mov al,020h
out 020h,al
out 0A0h,al

i dont understand what that code does... you write 0100000b to PIC1 and PIC2. isnt that what disable mouse/hdd/keyboard et all except IRQ5 and IRQ13?

Posted on 2002-03-15 14:33:22 by ancev
that code is for sending the EOI command (ie 20h command code) to both PIC1 and PIC2 (works ok in my OS) however i have commented out everything besides the My_Beep in that IRQ01 handler routine and still nothing not even a Beep... a Beep and then a system crash whould be so nice :)

i guess the addres is wrong in the context of a hardware generated INT .... but its Ok in the context of a software generates INT...

because if i choose and execute the Method05_generate routine .... all works ok (using mouse of course)

but if i press a key...buff system hangs with no beep ...

i checked and OS placed IRQ handlers are at C0001110h, C0001120h etc... but my handler is lower somewhere in the 401000h range... somehow i "feel" that my routine's addres is not ok for a hardware generated INT... but i wonder why?
Posted on 2002-03-15 16:08:18 by BogdanOntanu
Are you using a ring3->ring0 hack? If so, I wonder if your "hacked
ring0" code is always present... like, if a IRQ1 is generated in the
context of another app. You really ought to use a VXD for this. And
if you're doing keyboard disabling as part of a protection scheme,
forget it... it's futile.
Posted on 2002-03-15 19:54:33 by f0dder

Indeed I have used a VXD i another one of my methods, and YES it works just fine.

However my current job is to browse all methods of doing the same thing ... and even if they look close to hacking i asure you they are not!

Telling me to forget it will not help me at all, and what i need is help :)

I know protection schemes are futile in front of a determined hacker, but i have the decency to let my clients (they are paying after all) decide that.

Besides its an interesting thing to do, sending IRQs to my own handler routine ;) and its done theoretically before VXDs even get to know it (at a lower level)

So if you can help me understand why my routine is no even called on a hardware IRQ but very nicely called on a software INT 51h please let me know

i guess it could be that my IRQ handler that is located inside my ring3 application is eventually paged out, but i have no other applications running and even so it sould fail me sometimes not every time... isnt it?

Unless windows is paging out every application every time a IRQ is generated ... and that is a scarry ideea for OS performance IMHO...
Posted on 2002-03-17 07:55:15 by BogdanOntanu
Im not sure, but

mov word ptr [esi+(8*my_irq)+4],0EE00h ;set int DPL3

may be a problem for hw ints. Have you already tried it with DPL0 (8E00h)?
Posted on 2002-03-17 08:25:40 by japheth
I have tried both ways DPL3 and DPL0, both fail on hardware IRQ and DPL3 works ok on software INT
Posted on 2002-03-17 14:25:55 by BogdanOntanu
Instead of beeping (which is a "complex" function :-) I would prefer to manipulate the screen in the irq routine, possibly in text mode with

inc byte ptr ds:[0b8000h+79*2] ;right char in first line in text mode

just to see if your routine is called at all at irqs

Posted on 2002-03-18 04:44:47 by japheth
Sorry if it's me who's dull, but I try again:
is your IRQ handling code in a vxd, or in a "normal" PE file that is
using a hack to gain ring0?
Posted on 2002-03-18 08:32:09 by f0dder
Yes, my IRQ handler is inside a normal PE that uses a "hack" to manipulate the IDT table and make vector 51h point to my code inside the PE... is this the problem? placeing code inside a VXD will help?

I guess beeping is a complex routine and indeed takes some time (but i just use the speaker not the sound Blaster :) ) my guess is that my code is never reached on a hardware IRQ... o wish i have a better way of testing if my IRQ handler is reached...

but IMHO changing the screen mode to VGA text (forcefully) is even more complex... this is NOT inside my OS :) its insides windows and i do not like/want to change its video mode from gfx to text....

anyway if you know a fast and sure way of doing that for any video board ... send me the code/example :)
Posted on 2002-03-18 10:01:57 by BogdanOntanu
Bogdan, I have one thing to say: DUH. You know about paging,
right? And that on wi32, each process has a separate address
space? Hardware IRQs can be generated any time... in the context
of any application. It is very likely a hardware IRQ will be
generated when not in the context of your process...

Perhaps this can be worked around by marking the pages as
shareable, but I dunno. Hooking the IDT like this is dirty.
Posted on 2002-03-18 10:08:54 by f0dder
Excuse me if I sound ignorant ( I know practically nill about systems level stuff), but why not take a cue from the virrii guys and "infect" the MBR with your own code? You could then hook the irq before windows even gets a shot at the machine to screw everthing up :) It's still dirty (IMHO) but it seems more logical to me. If you write the boot code correctly it won't even set off antivirus's and should then work on any OS. Without a driver.

I have a couple of MBR examples of you want them.
Posted on 2002-03-18 10:39:53 by emonk
emonk, that wouldn't work at all. If we look away from some of the
very obvious problems (not very much space in MBR, av tools possibly
limiting access to MBR, etc) there's still more problems... like, windows
sets up its own IRQ handlers, effectively overriding whatever wank
you have installed while in realmode.
Posted on 2002-03-18 10:48:02 by f0dder
Oh :) I was under the impression that if you hooked it first anything that came after would just be hooking your hook? If it's not this way then how do all of those virii work under windows by hooking int 13h to trap MBR read/write? Here is a non-virus example of hooking int 13h before windows screws with you.
Posted on 2002-03-18 10:53:16 by emonk
This program is intended to run under DOS, where it is easy to hook an interrupt. Under Windows 9x the only way is to jump into Ring0. There is many way to do this from Ring3. If someone interested, I can find some viral technique how to achieve this.
Posted on 2002-03-18 11:04:47 by masquer
All MBR code is dos code... After the code is executed it then calls a back up of the old MBR and continues booting windows or whatever.


For more info on how this example works see
Posted on 2002-03-18 11:46:51 by emonk
I know that. What I want to say is to write at MBR under windows you need to go to Ring0. That program run under DOS.
And MBR code is not DOS code, DOS is not loaded yet :)
Posted on 2002-03-18 12:35:41 by masquer
Misunderstanding. I dont mean to install the MBR code from within windows. Install that from dos. I just mean using a fake MBR to hook the interrupt before windows loads. As a way to avoid fighting windows for ring 0 in the first place. It is then just a matter of writing plain ol' realmode crap :) Unless F0dder is right. Which I would believe if he would tell me why :)
Posted on 2002-03-18 12:45:24 by emonk