flat assembler
Message board for the users of flat assembler.

Index > DOS > interrupt override

Author
Thread Post new topic Reply to topic
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 07 Jan 2011, 20:25
as i write some examples, i'd like to share this one that is very simple for education purpose.

i hope it will help.

Code:
; this example shows how to override a real mode interrupt
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
        org 100h                ;
main:                           ;
        call irq1.new           ; install new irq1 handler
@@:                             ;
        cmp byte[irq1.code],1   ; compare scancode with value of escape key
        jne @b                  ; reloop if not equal
        call irq1.old           ; restore old irq1 handler
        ret                     ; exit program
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
irq1:                           ; new keyboard handler
        push ax es word 0b800h  ; save registers and push a value
        pop es                  ;      that is poped in es
        int 0ffh                ; call the old handler, vector 0FFh in ivt
        in al,60h               ; read the current scancode
        mov [es:0],al           ; display it's value
        mov [cs:.code],al       ; save its value
        pop es ax               ; restore registers
        iret                    ; retour d'interruption
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.code:                          ; scancode data
        db ?                    ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.vector equ gs:9*4              ; .vector is the irq1 handler adress
.save   equ gs:255*4            ; .save is the original handler save place
.new:                           ; install new irq1 handler
        cli                     ; disable interrupts
        push ax                 ; save ax
        push bx                 ; save bx
        push gs                 ; save gs
        push word 0             ; push value 0 for gs
        pop gs                  ; pop it in gs
        mov ax,[.vector]        ; load current irq1 handler
        mov bx,[.vector+2]      ;
        mov [.save],ax          ; save it in the vector 0ffh of the ivt
        mov [.save+2],bx        ;
        mov ax,cs               ; load new irq1 handler
        mov bx,irq1             ;
        mov [.vector],bx        ; save it in the irq1 vector of the ivt
        mov [.vector+2],ax      ;
        pop gs                  ; restore registers
        pop bx                  ;
        pop ax                  ;
        sti                     ; enable interrupts
        ret                     ; return to main
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.old:                           ; restore old irq1 handler
        cli                     ; disable interrupts
        push ax                 ; save registers
        push bx                 ;
        push gs                 ;
        push word 0             ; push 0 value for gs
        pop gs                  ; pop it in gs
        mov ax,[.save]          ; load old irq1 handler vector
        mov bx,[.save+2]        ;
        mov [.save],ax          ; restore it in irq1 vector
        mov [.save+2],bx        ;
        pop gs                  ; restore registers
        pop bx                  ;
        pop ax                  ;
        sti                     ; enable interrupts
        ret                     ; return to main
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    


it will just display current scan code as an ascii char in the up/left corner of text mode screen memory each time a scan code is emitted.


Last edited by edfed on 07 Jan 2011, 23:04; edited 1 time in total
Post 07 Jan 2011, 20:25
View user's profile Send private message Visit poster's website Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932 07 Jan 2011, 22:34
wouldnt be easier to emulate int instead of putting handler to 0xff?
Post 07 Jan 2011, 22:34
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 07 Jan 2011, 23:02
it is possible if:

jmp far[eax] at the end of the interrupt, but as i first want to use the original int9 management pior to read a scancode from 60h, it is the only way.
Post 07 Jan 2011, 23:02
View user's profile Send private message Visit poster's website Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932 08 Jan 2011, 00:23
int = pushf + far call.

just install this hook by overwriting ivt, and new handler save arguments then far calls handler after pushf'ing flags, then you deal with arguments.
Post 08 Jan 2011, 00:23
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 08 Jan 2011, 00:44
yeah, why not, then, i will be forced to use a dword for irq1.saveold.

since i plan on the use of BDA for the irq1.code byte, the irq1.inc handler will be just code, no data at all.
it will be easyer then to translate in protected mode.

every technical choice have bad and good points.

here, the bad point of my choice is the use of int 0FFh, but i nevr heard about the presence of any int 0FFh in any software, then, it is not a problem for me.
Post 08 Jan 2011, 00:44
View user's profile Send private message Visit poster's website Reply with quote
Ninho



Joined: 07 May 2010
Posts: 16
Ninho 22 Jan 2011, 18:46
edfed wrote:
yeah, why not, then, i will be forced to use a dword for irq1.saveold.

here, the bad point of my choice is the use of int 0FFh, but i nevr heard about the presence of any int 0FFh in any software, then, it is not a problem for me.


Int FF is avoided for a good reason : the AT compatible BIOS uses the last bytes of the IVT for its stack while doing a "shutdown" return from protected mode, and will happily trash your interrupt vector in the process ! In case you're too young to remember that, have a look at Ralph Brown's good ol' interrupt list. And should you think this is old stuff, it is old indeed - should you assume it can be ignored, you're wrong. Even Intel's MP specification takes care to mention the "legacy" 80286-type shutdowns among the things that platform BIOSes must respect.
Post 22 Jan 2011, 18:46
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 23 Jan 2011, 01:05
then, use int 0F9h.

and frankly, only one thing is important, do something that woirks, not always refer to big brother indications.

asm for me is freedom, everything possible, then, no need to become crasy for some limitations, just jump over them.

PS:
ninho, i don't know you enough to accept your aggresive criticism.. even in a pure technical domain, some personal respect should be the master word.
Post 23 Jan 2011, 01:05
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20620
Location: In your JS exploiting you and your system
revolution 23 Jan 2011, 01:40
edfed wrote:
and frankly, only one thing is important, do something that woirks, not always refer to big brother indications.
Ninho is correct here. Just because something might work for you on your system does not mean it will work everywhere on other systems. You have to take note of things that the OEM has done in order to avoid unexplained problems.

"Big brother"s do their thing, we might not agree with what they do but we still have to be aware of it so as to make sure our code will work. Being anarchistic is all well and good but not to the point of hurting ourselves with code that fails.
Post 23 Jan 2011, 01:40
View user's profile Send private message Visit poster's website Reply with quote
Ninho



Joined: 07 May 2010
Posts: 16
Ninho 23 Jan 2011, 11:38
[quote="edfed"]
edfed wrote:
ninho, i don't know you enough to accept your aggresive criticism.. even in a pure technical domain, some personal respect should be the master word.


Edfed I agree entirely about (mutual) respect as a necessity. I'm uncertain what in my warning made you read disrespect, even less agressivity towards you. Such attitudes simply aren't mine, usually; maybe because English is not my native language, I like to keep "it" strictly technical, did the message /taste/ not too sweet ? I'm verily sorry. Also did you fail to grasp the "warning" was meant to inform not just your person, but every other reader who comes to this thread now or in the future and might not be aware of the possible consequences of the advice given by you ?

Quote:
and frankly, only one thing is important, do something that woirks, not always refer to big brother indications.


As far as I'm concerned, I'm a grand father more than a big brother now ;=)
As for the technical point above, methinks you should welcome the warning rather than take offence. Of course while experimenting for yourself, you are welcome to try things that will provably work on your own machines - it is /my/ right and possibly my duty also to warn you (in case you didn't know before) and others who never heard of shutdown returns and all that mess, about the known risks of your approach. /You/ are the one who mentionned, quote, education purposes, unquote :=)

Like you said, use another vector - F9 might be safer. Not to be aggressive, but frank altogether, your approach is not one I would pick for interrupt hooking under DOS.

Happy new year (if it's not too late for wishes)
Post 23 Jan 2011, 11:38
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 23 Jan 2011, 15:11
under dos, i remember, self modifiable code is possible.

very possible, then something like this

Code:
int9:
cli
call .pre ;call prefunction
pushf ;simulate int
.jmpfar@:
call far dword0:0  ;simulate int
call .post ;call postfunction
sti
iret  

.new:
mov eax,[0:9*4]
mov [.jmpfar@+1],eax
mov ax,cs
ror eax,16
mov ax,int9
mov [0:9*4],eax
sti
ret

.old:
cli
mov eax,[.jmpfar@+1]
mov [0:9*4],eax
sti
ret

.pre:
ret

.post:

ret
    


thank you for advice, if 0FFh vector use can lead to a crash, it's sure it is not cool...


Last edited by edfed on 14 Feb 2011, 21:42; edited 2 times in total
Post 23 Jan 2011, 15:11
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA
bitshifter 23 Jan 2011, 18:42
You have two common choices when hacking irq1
Either jmp far into the old handler or shut up the PICs IR1 (out 20h,20h) and iret.
Jumping into the old handler is more preferred since the BIOS stays informed.
Post 23 Jan 2011, 18:42
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 23 Jan 2011, 18:47
that's why i made it, because my own irq1 handler does not it, leading to some problems since i test it under real dos, with dpmi installed.
Post 23 Jan 2011, 18:47
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 14 Feb 2011, 21:56
something like a generic way to overide interrupt would be possible, in order to have only 2 functions.
the far pointer to old interrupt to be saved in the dword just before new handler entrypoint.

Code:
dd ?         ;FAR POINTER HERE
int9:
cli
call .pre ;call prefunction
pushf ;simulate int
call far dword[int9-4]  ;simulate int
...
    


then, before to call the overider, pass interrupt vector offset with bx register, and new handler with si register
Code:
mov si,int9
mov bx,9*4
call newint
...
mov si,int9
mov bx,9*4
call oldint
...
newint:
mov eax,[0:bx]
mov [si-4],eax
mov ax,cs
ror eax,16
mov ax,si
mov [0:bx],eax
sti
ret


oldint:
cli
mov eax,[si-4]
mov [0:bx],eax
sti
ret
    


this would be interresting and i will probably use it in my code now. Very Happy
and for sure, it can be made fool compatible. Laughing
Post 14 Feb 2011, 21:56
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.