Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Probleme mit verbogenen Interrupts

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Profi-Forum
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
REZK



Anmeldungsdatum: 28.10.2004
Beiträge: 109
Wohnort: Stuttgart

BeitragVerfasst am: 13.08.2006, 20:33    Titel: Probleme mit verbogenen Interrupts Antworten mit Zitat

Hallo,

also, ich habe folgende Probleme:

1.) Ich habe folgendes (experimentelle) Programm:
Code:
Code  Segment
Assume  cs:code
Org     100h       

start:
jmp weiter
hallo db "hallo$"

weiter:
       mov     ah,35h     
       mov     al,21h     
       int     21h         ; der int21 vektor steht in es:bx



      mov ah,9
      mov dx,offset hallo         
      call es:[bx]

      int 20h

Code        ENDS
end start     


Das Programm macht folgendes: Es ermittelt mit der 35h Funktion des Int21 die absolute Speicherstelle des int 21 und versucht diese über call aufzurufen. Leider wird keine Message "Hallo" ausgegeben, sondern das Programm macht gar nichts und beendet sich einfach nach einer kurzen Wartezeit. Woran kann das liegen?

2.) Des weiteren habe ich noch ein Progrämmchen:


Code:

Code Segment
        Assume  cs:code
        Org     100h       


        Begin:  jmp Install  ;TSR installieren
                int 20h         




Tsr     PROC     FAR
        Assume  cs:code
        jmp indosx
        indos dw 0,0
        hallo db "dsad$"
        indosx:

       
        mov ax, word ptr indos  ;lese indos byte aus
        mov es,ax
        mov bx, word ptr indos+1
        cmp byte ptr es:[bx],0
        jne ende
       
     mov ah,9h
        mov dx, offset hallo   
        cli
        int 21h
        sti

        ende:
        iret
Tsr     ENDP



Install PROC NEAR
        Assume  cs:code,ds:code

        ;adresse des indosflag kopieren
        mov ah,34h
        int 21h
        mov word ptr indos,es
        mov word ptr indos+1,bx

        mov ah,25h   ; int 13h auf die eigene Routine verbiegen
        mov al,13h   
        mov dx,offset tsr
        cli       
        int 21h
        sti
       
        mov dx,offset Install   ;speicherresident beenden
        int 27h
Install ENDP



Code        ENDS
END    Begin


Es verbiegt den Int13h auf die eigene Routine.

Soweit klappt auch alles, wie vorauszusehen war, sind keine Zugriffe auf die Festplatte mehr möglich, allerdings ist das Indos Byte immer ungleich 0, das heißt, es ist momentan schon ein Interrupt aktiv, der nicht gestört werden will.
Folgende Varianten habe ich ausprobiert:
- Ausführen des Int 10 innerhalb des TSR statt des INT21: funktioniert, da es sich um einen BIOS Interrupt handelt.
- Ausführen des Int 21 innerhalb des TSR ohne Indosbyte Überprüfung: Programmcrash.
- Ausführen des Programmes mit Indosbyte Überprüfung: Indos Byte ist immer <> 0, d.h. kein Int21 ausführbar...


Wie kann ich trotzdem "irgendwie" den Int21 innerhalb des verbogenen Interrupts aufrufen? Hat die Tatsache, dass das Indosbyte immer ungleich 0 ist, etwas damit zu tun, dass ich gerade den Int13 verbogen habe? Mit dem Int9 (Tastaturhandler) funktioniert es nämlich auch nicht besser...

Vielleicht kann mir jemand weiterhelfen und vielleicht zusätzlich noch ein deutsches Tutorial über TSRs empfehlen, wobei ich Adoks Assembler Tutorial schon durchgelesen habe und auch in diversen Assembler Büchern nachgeschaut habe (in denen übrigens nicht mal was davon drin stand, dass man cli verwenden muss)

Vielen Dank im voraus,
MfG,

rezk
_________________
Meine sämtlichen QB Projekte findet ihr hier
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
raph ael



Anmeldungsdatum: 12.04.2006
Beiträge: 472

BeitragVerfasst am: 13.08.2006, 20:57    Titel: Antworten mit Zitat

BIOS- INTerrupts verbiegen, dass kann nicht gut gehen happy .
Weil INT 09h ja soeiner ist...

Und das INDOS-Flag sollte nicht immer ON sein.

Und du wirst wahrscheinlich nicht den INT27h, sondern den INT21h aufrufen wollen...
Steht alles hier.
SHR DX,4
Daran gedacht?
DX erhöhen?
mit den Augen rollen
Und ins DX soll das LETZTE BYTE DER TSR-FUNKTION REIN!
Aber bevor SHR DX,4
_________________
Zitat:
1000 Yottabytes sind absurd. 640 Yottabytes sollten genug für jeden sein.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
REZK



Anmeldungsdatum: 28.10.2004
Beiträge: 109
Wohnort: Stuttgart

BeitragVerfasst am: 13.08.2006, 21:33    Titel: Antworten mit Zitat

Hallo raphael,

danke für die Antwort.

Zitat:
BIOS- INTerrupts verbiegen, dass kann nicht gut gehen happy .
Weil INT 09h ja soeiner ist...


Stimmt eigentlich... Funktioniert hats aber trotzdem... wenn man den Int10h aus dem TSR heraus aufruft: wenn man eine Taste drückt, wird die eigene Routine ausgeführt.

Zitat:
Und das INDOS-Flag sollte nicht immer ON sein.

Ja, das ist das Problem... Könnte es sein, dass da irgendein Interrupt immer stört? Oder ist die Routine zum testen des Indos Bytes falsch implementiert?


Zitat:
Und du wirst wahrscheinlich nicht den INT27h, sondern den INT21h aufrufen wollen...
Steht alles hier.
SHR DX,4
Daran gedacht?
DX erhöhen?
mit den Augen rollen
Und ins DX soll das LETZTE BYTE DER TSR-FUNKTION REIN!
Aber bevor SHR DX,4


Also: int 27h gibt es auch, ist eine Alternative zu int21h:31. Und das mit dem Umwandeln (shr) ist bei dem 27er sogut ich weiss nicht nötig.
Und in dx steht das Ende des TSR (oder in dem Fall der Anfang der Install Routine, ist aber ja dasselbe..)


Aber wie gesagt, das mit dem Indos Byte...
Funktioniert weder unter Freedos noch unter einer Windows ME Startdiskette...

MfG,
rezk
_________________
Meine sämtlichen QB Projekte findet ihr hier
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
A.K.



Anmeldungsdatum: 02.05.2005
Beiträge: 467
Wohnort: HH

BeitragVerfasst am: 13.08.2006, 22:40    Titel: Re: Probleme mit verbogenen Interrupts Antworten mit Zitat

REZK hat Folgendes geschrieben:

1.) Ich habe folgendes (experimentelle) Programm:
Code:
Code  Segment
Assume  cs:code
Org     100h       

start:
jmp weiter
hallo db "hallo$"

weiter:
       mov     ah,35h     
       mov     al,21h     
       int     21h         ; der int21 vektor steht in es:bx



      mov ah,9
      mov dx,offset hallo         
      call es:[bx]

      int 20h

Code        ENDS
end start     


Das Programm macht folgendes: Es ermittelt mit der 35h Funktion des Int21 die absolute Speicherstelle des int 21 und versucht diese über call aufzurufen. Leider wird keine Message "Hallo" ausgegeben, sondern das Programm macht gar nichts und beendet sich einfach nach einer kurzen Wartezeit. Woran kann das liegen?


Hi,

wieso versuchst du den INT 21h an-zu-callen?
Normalerweise werden Segment und Offset bei einem INT-Aufruf automatisch auf den STACK gePUSHt (CS:IP+Call_Len).
Du benutzt ein CALL dafür, welches im Normalfall nur IP+CALL_LEN PUSHt. Richtig wäre hier ein FAR CALL, oder wird das durch deinen Assembler bereits in ein FAR CALL umgewandelt?

Die zweite Sache wäre der CALL selber.
Du hast angegeben:
CALL es:[bx]
Dort müßte es so heißen:
CALL es:bx
da du sonst als Sprungadresse den Inhalt von [es:bx] hast. Dies wären aber schon die ersten Befehle des INT 21h.

MFG A.K.
_________________

http://forum.IconSoft.de
http://www.pnpbb.de - hol dir jetzt dein eigenes kostenloses Forum *NEU*
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen Yahoo Messenger MSN Messenger
REZK



Anmeldungsdatum: 28.10.2004
Beiträge: 109
Wohnort: Stuttgart

BeitragVerfasst am: 17.08.2006, 11:06    Titel: Antworten mit Zitat

Hallo,

vielen Dank A.K., jetzt läuft das Ganze.

Hier habe ich nochmal einen Quelltext:

Code:
.model tiny
.radix 16
.code
       
org 100

start:       
mov ah,3c   ;erzeuge Datei
lea dx, file
xor cx,cx
int 21h
push ax


mov ax,3513 ; ermittle Position des Int 13
int 21

mov ax,es   ; es=ds
mov ds,ax
mov al,byte ptr ds:[bx]

kopiere:    ;ermittle bytes im Interrupt bis iret
    cmp al, byte ptr iret_1
    je raus
    inc al
    inc word ptr zahler
jmp kopiere


raus:
mov ah,40h
pop bx
mov cx, word ptr zahler
mov dx,word ptr [int21er]
int 21

int 20h

;daten
iret_1:
iret     
file db "int.txt",0
zahler dw 0
int21er dw ?     
end start


Das Programm soll folgendes machen: Es soll eine Interrupt Routine (hier die 13er) in eine Datei schreiben, um das Ende der Routine festzustellen, wird nach einem "iret" gesucht.

Das Problem: Das Programm findet schon nach wenigen Bytes (ca. 100) ein iret bzw. Daten, die mit dem Opcode von "iret" äquivalent sind.

Da ich mir kaum vorstellen kann, dass die Interrupt Routine so kurz ist, ist wahrscheinlich ein Byte innerhalb des Interrupts, das von der Interrupt Routine als Daten (was ist der Singular von Daten ???) interpretiert wird.

Hilft es, eventuell jmp's nachzuverfolgen um diese eventuell störende Datenbereiche zu umgehen?

Ich hoffe, jemand weiss auch bei diesem problem weiter.
Danke im voraus,

MfG,
rezk
_________________
Meine sämtlichen QB Projekte findet ihr hier
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
A.K.



Anmeldungsdatum: 02.05.2005
Beiträge: 467
Wohnort: HH

BeitragVerfasst am: 17.08.2006, 11:21    Titel: Antworten mit Zitat

Hm,

das wird schwer.
Im ersten Moment ist es ja so das durch einen IRET der "Interrupt verlassen wird".
Als Äquivalent dazu kann man z.B. das END oder das RETURN aus QBasic dahernehmen.
Jetzt ist die Sache ob dieses IRET ein "echtes" oder "unechtes" ist. Also ob es einem Datenbereich angehört oder wirklich zum Programm gehört. Das hast du ja so auch schon feststellen können.
Also bleibt im Grunde genommen nichts anderes übrig als alle JMP's (auch JZ, JA....) zu verfolgen und daraus Rückschlüsse zu ziehen wo der Interrupt "zu Ende ist". CALL's gehören natürlich auch dazu.
Und dieses Auswerten ist schon eine Funktion die ein sehr kompfortabler Disassembler mitbringt aber recht aufwendig ist. Ich bin der Meinung das dies auch schon unter Reverse Engineering fällt.

Naja, im Endeffekt heißt das:
Entweder du schreibst einfach eine selbstdefinierte Anzahl von Bytes in deine Datei oder du schreibst dir ein Programm welches den Assemblercode mit den JMP's auswertet und danach die Anzahl der Bytes berechnet.

Ganz hilfreich könnte dir bei dieser Sache ein Memview-Programm sein mit dem du schon mal vor dem "Abschreiben des Interruptes" diesen durchleuchten kannst.

MFG A.K.
_________________

http://forum.IconSoft.de
http://www.pnpbb.de - hol dir jetzt dein eigenes kostenloses Forum *NEU*
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen Yahoo Messenger MSN Messenger
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Profi-Forum Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz