Dis-assemblieren einer Interrupt-Routine. Wie geht das?

  • Hallo!


    Ich bräuchte für die Erstellung einer eigenen Interruptroutine in TurboPascal3 (für einen NCR DMV), auf die der Interruptvektor Int21 temporär umgebogen werden soll, den assembler-code eben jener original int21 interrupt routine, um sie bis auf kleine Änderungen "nachbauen" zu können.


    Ich habe nie mit dem "debug.com" Programm gearbeitet und kenne mich auch mit anderen Programmen, die Ähnliches tun, nicht aus, denke aber, daß debug ein geeignetes Werkzeug sein könnte.


    Ich stelle mir vor, mit einem geeigneten Programm an die Speicheradresse des Int21 zu gehen. Diese Adresse findet man in der Interruptvektortabelle.

    Kann man dann ab dieser Adresse das Programm veranlassen, ein Dis-assembling bis zu jenem OpCode vorzunehmen (IRET), der die Interruptroutine abschließt und dieses disassembling in eine Datei schreiben? Dann könnte ich es in Ruhe studieren und an geeigneter Stelle die für mich sinnvollen Änderungen vornehmen.


    Wenn sich hier jemand mit so einer Aufgabenstellung auskennt bitte möglichst Schritt für Schritt beschreiben, wie das zu machen ist. Ich wäre sehr dankbar!

    Ich brauche keine Hilfestellung wie man in TP eine Interruptroutine schreibt und einsetzt, es geht mir nur darum an den code des int21 zu kommen, der für die abwicklung der Unterfunktion 3fH zuständig ist.


    Hintergrund: Ich möchte in TurboPascal einen Ersatz für die blockread(params....) Prozedur schreiben, welcher eine Datei einliest, deren Bytes bevor sie noch im RAM landen aber on-the-fly verändert TPs original blockread() ruft dazu den int21 Unterfunktion 3FH auf. 3FH holt ein Byte nach dem anderen von der Datei und schreibt das Byte an eine Speicheradresse, die ihr beim Aufruf übergeben wurde. Meine Interruptroutine soll nun den int21/3fh ersetzen. Zu 99% wird das einfach eine Kopie, vor dem Befehl das Byte in den RAM zu schreiben kommt bei mir aber noch die gewünschte Änderung des Wertes und dann erst das mov es:[di],al oder stosb. Auf diesem Weg erspare ich mir das höchst zeitaufwändige nochmalige Einlesen vom RAM in die CPU, Änderung des Wertes, Zurückschreiben ins RAM.

  • Natürlich kann man dazu DEBUG nehmen. Nur: Es kann durchaus sein, dass das, was du machen willst, nicht ganz so einfach ist, wie du dir das vorstellst. DOS ist auf minimale Größe und größte "Funktionalitätsdichte" programmiert. Es ist also sehr wahrscheinlich, dass Unterfunktionen, die von 21/3f aufgerufen werden (z.B. das Lesen eines Sektors, das wäre so ungefähr die Stelle, die du abändern willst), von vielen anderen DOS-Funktionen (z.B. die für sequentielles Lesen) mitverwendet werden. Möglicherweise (bzw. sehr wahrscheinlich) ist die Stelle, die du patchen wolltest, nichtmal im DOS, sondern im BIOS (INT13H, Funktion 2) und wird vom DOS nur aufgerufen. Das liegt im ROM - keine gute Idee, das zu patchen.


    Um nun rauszufinden, ob du die entsprechenden Stallen "temporär patchen" kannst, würde dir nichts anderes übrigbleiben, als das halbe DOS zu disassemblieren.... (Wie gesagt: Ich bin mir ziemlich sicher, du wirst die Stelle im DOS gar nicht finden, sondern am "unteren Ende" werden ziemlich sicher BIOS-Funktionen im ROM aufgerufen.)


    Kurzum: Keine gute Idee.

  • Danke erstmal für die ersten Rückmeldungen!


    tofro:

    Unter Dos 2.11 auf einem NCR DMV ist mit Sicherheit immer nur 1 Programm aktiv.

    Mein geplantes Programm enthält neben der eigentlichen Aufgabe diese eine Intr-Prozedur, auf die der intr-Vektor verbogen wird. Und das nur für den Moment, wenn ich eine Datei entsprechend umgewandelt im Speicher haben möchte. Danach wird sofort der Originalvektor wieder eingesetzt. Eine Gefahr, daß andere Programme mit meiner Intr-Prouzedur nicht zurechtkommen, existiert nicht. In 3 codezeilen in TP sieht das so aus:


    setintvec (int21, addressofmeineproc);

    liesundwandlediedatei (meinedatei, rambuffer);

    restoreintvec (int21, originaladdressint21);


    Der Hinweis auf mögliche - und ich gehe davon aus, daß das mit Sicherheit zutrifft - Zugriffe auf BIOS routinen durch den int21/3fh ist gut und richtig. Aber genau deswegen, weil man sich sehr gut mit der Hardware auskennen müßte (und in BIOSfragen) um dies fehlerfrei zu programmieren, möchte ich genau den eingeschlagenen Weg gehen: eine exakte Kopie des Teils des int21 in meiner Intr-Prozedur mitaufzunehmen, der für die Abarbeitung eines 3Fh Aufrufes notwendig ist. Dieser tut ja alles korrekt. Ich habe nicht vor das Rad neu zu erfinden. Meine eigentliche Änderung besteht nur darin, daß ich vor dem Schreiben des Bytes an die Adresse des übergebenen Buffers das Byte in meinem Sinne abändere. und dann erst wird es ins RAM geschrieben. Alles andere bleibt gleich.


    Alle anderen Funktionen des int21 werden umgehend an die Originaladresse weitergeleitet. Um die kümmert sich meine intr-prozedur nicht.


    Wenn debug.com ein geeignetes Programm ist, wie muß ich es bedienen?

  • Ich stelle mir vor, mit einem geeigneten Programm an die Speicheradresse des Int21 zu gehen. Diese Adresse findet man in der Interruptvektortabelle.

    Kann man dann ab dieser Adresse das Programm veranlassen, ein Dis-assembling bis zu jenem OpCode vorzunehmen (IRET), der die Interruptroutine abschließt und dieses disassembling in eine Datei schreiben? Dann könnte ich es in Ruhe studieren und an geeigneter Stelle die für mich sinnvollen Änderungen vornehmen.

    Hallo DoPe


    ich kenne das NCR DMV nicht, aber ich kann Dir folgendes aus meinen Erfahrungen mit anderen Systemen raten:


    Ein Debugger kann üblicherweise Breakpoints setzen, bei denen die Ausführung des Programmes anhält und man die Register etc. ansehen kann. In Interruptroutinen sollte man aber keinen Breakpoint setzen, da man sonst Gefahr läuft, dass das System hängen bleibt (Absturz).


    Zum Disassemblen braucht man aber keine Breakpoints, sondern man kann vorab ab einer bestimmten Adresse den Maschinencode entschlüsseln, ohne das Programm zu starten. Dann kannst Du den Code inspizieren und sehen, wo Du Deine Änderungen einbauen willst. Im Prinzip läßt sich ja der Interruptvektor auf Deine selber geschriebenen Routinen "umbiegen". Du muss aber dafür sorgen, dass die anderen Benutzer dieser Routine auch weiterhin mit der "neuen" Routine funktionieren.


    Vermutlich wird es einiger Experimente (und Abstürze) bedürfen, bis alles klappt. Für den Anfang würde ich die Originalroutine an einen anderen Ort kopieren, den Interruptvektor dorthin umlenken und sehen, ob noch alles funktioniert. Danach mit kleinen Schritten Änderungen durchführen und Dich Deinem Ziel annähern.


    Ich wünsche jedenfalls viel Erfolg (und Geduld).


    Grüße, PAW


    P.S. hat sich mit Deinem letzten Beitrag überschnitten

    Einmal editiert, zuletzt von PAW ()

  • Bei DOS Programmen üblicherweise "kryptisch". Man gibt einen Buchstaben ein und eine Adresse - dann wird was angezeigt.


    kurz

    https://www.computerhope.com/debughlp.htm


    ausführlich siehe PageTwo

    https://thestarman.pcministry.com/asm/debug/debug.htm (!)



    Wenn Du mehr Komfort haben willst, such mal nach Borland Turbo Debugger.



    Kann man solche Routinen, wenn man die Interrupt No. eh weiß, nicht auch irgendwie in einer Art ROM / BIOS Listing nachsehen. Sollte es doch mittlerweile auch geben.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Du hast nicht verstanden, was ich geschrieben habe (hat überhaupt nix mit "mehreren Programmen" zu tun):


    Höchstwahrscheinlich ist es so: Das DOS liest überhaupt keine Daten, sondern findet nur raus, welche Sektoren zur Datei, die du lesen willst, gehören, und beauftragt dann das BIOS mit dem Lesen der passenden Sektoren in den vom DOS-Aufrufer (Turbo Pascal) angegebenen Speicherbereich. Dazu liest das DOS regelmäßig "zwischendurch" immer mal wieder im gleichen DOS-Aufruf mittels derselben BIOS-Funktionen z.B. das Directory, um z.B. den nächsten zu deiner Datei gehörenden Cluster zu finden. Könntest du jetzt die Stelle patchen, in der das BIOS den grade gelesenen Sektor, der zu deiner Datei gehört, in den Speicher der zu deinem Pascal-Programm gehört, schreiben will, und aus jedem "X" ein "U" machen (was du nicht kannst, weil das BIOS im ROM ist), würdest du unabsichtlich auch die "X" zu "U"s machen, die das DOS selber liest, um das Directory zu lesen.


    Das DOS verwendet die Routine, die du patchen willst, also auch für "eigene Zwecke" (wie das Directory zu lesen). D.h. du würdest auch das DOS selbst "nasführen".


    Erwischst du die Stelle im BIOS nicht (dort findet der eigentliche Datentransfer statt, nicht im DOS), kannst du gradesogut mit demselben Effekt und CPU-Last (und wesentlich weniger Aufwand) im Pascal-Programm aus allen gelesenen Xen Us machen.

  • Danke erstmal für die ersten Rückmeldungen!


    tofro:

    Unter Dos 2.11 auf einem NCR DMV ist mit Sicherheit immer nur 1 Programm aktiv.

    TSR-Programme gab es damals noch nicht?

    • i-Telex 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • Der INT21h-Vektor sitzt bei Addresse 0:88h und ist 4 Bytes lang (LSBF)


    er kann mit


    Code
    DEBUG
    D 0:88

    angezeigt werden.

    Wenn du wissen willst, das DOS da treibt, kannst du mit dieser Addresse (4 Bytes von hinten nach vorne abtippen, weil Intel und dem U-Befehl das DOS disassemblieren.

  • Hallo DoPe


    wenn du einen guten Debugger möchtest, dann suche im Netz unter "AFD Advanced Full Screen Debugger". Gibt es, so weit ich weiß, gratis. Der ist jedenfalls wesentlich leichter zu bedienen, als der DEBUG von DOS.


    Grüße, PAW

  • Zitat von fritzeflink

    den AFD.EXE habe ich nicht gefunden aber eine informativen Blog dazu

    Hier dürfte ein Download sein: AFD.zip

    Was ist das denn für ein schwindeliger Link?

    "This file was uploaded from Pakistan on August 22, 2008 at 4:45 AM" - WTF!


    Ich hoffe, ich habe mir jetzt nichts eingefangen. :(

    Und das File gab's da nicht.


    V O R S I C H T ! ! !

    • i-Telex 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."


  • Ich weiß nicht, was du für Programme verwendest, bei mir kommt folgender Schirm:



    Bei DOWNLOAD kommt folgendes Window:




    Also wo ist das Problem?

  • Ich verwende Firefox und sehe das hier:



    • i-Telex 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • Das kann ja sein, dass mein Werbeblocker daran schuld ist. Was mich eigentlich erschreckt hat, war das "Uploaded from Pakistan".

    • i-Telex 7822222 dege d

    • technikum29 in Kelkheim bei Frankfurt

    • Marburger Stammtisch

    Douglas Adams: "Everything, that is invented and exists at the time of your birth, is natural. Everything that is invented until you´re 35 is interesting, exciting and you can possibly make a career in it. Everything that is invented after you´re 35 is against the law of nature. Apply this list to movies, rock music, word processors and mobile phones to work out how old you are."

  • Eine AFD Pro Version 2 gab es *nie*, das war eine "Fake" Version (jeder mit Hex-Editor kann das).

    Die Version 1 der Pro Version kriegt man (das ist die einzige offizielle Version) nur aus relativ dubiosen Quellen (old-dos.ru bspw.).

    Die AFD ohne Pro von "Puttkammer" von 1987 hänge ich mal hier dran, damit sollte die Diskussion darüber beendet sein.

    Dateien

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

  • Als Disassembler kann ich sourcer empfehlen, ist speziell für x86 code entwickelt worden mit vielen hilfreichen Kommentaren.


    Falls Du im Internet nicht fündig wirst, kannst Du auch das BIOS hier posten, dann lass ich einmal sourcer darüberlaufen.


    Beiliegende batch datei speichert das ROM in eine bin-Datei.

  • Hintergrund: Ich möchte in TurboPascal einen Ersatz für die blockread(params....) Prozedur schreiben, welcher eine Datei einliest, deren Bytes bevor sie noch im RAM landen aber on-the-fly verändert TPs original blockread() ruft dazu den int21 Unterfunktion 3FH auf.

    Soweit ich weiß befördert das BIOS die Daten vom Festplatten- oder Diskettencontroller per DMA-Transfer an der CPU vorbei direkt in den RAM.

    Folglich wird es sich gar nicht vermeiden lassen, zum Ersetzen einzelner Byte-Werte noch einmal über den Block zu iterieren.


    Vorschlag von meiner Seite:

    Lass den Quatsch mit dem Disassemblieren und versuche stattdessen, die Schleife zum Ersetzen der Werte bestmöglich zu optimieren.

  • Eine AFD Pro Version 2 gab es *nie*, das war eine "Fake" Version (jeder mit Hex-Editor kann das).

    Die Version 1 der Pro Version kriegt man (das ist die einzige offizielle Version) nur aus relativ dubiosen Quellen (old-dos.ru bspw.).


    Dem kann ich mich nicht ganz anschließen!


    Natürlich könnte man die Texte mit einem Hexeditor ändern. Das erklärt aber nicht, wie aus der Version 1.01 PRO die Version 2.00 PRO wurde. Die Dateien haben unterschiedliche Längen und die Copyrighttexte inkl. der Versionsnummer sind an verschiedenen Stellen im EXE-File.


    Außerdem habe ich einen Link gefunden mit einem Bild der AFD-Diskette Vers. 1.03


    Link zu Artikel betreffend AFD 1.03


    Also gab es mehrere Version von AFD-Pro.


    Hier noch die Titelbilder der Versionen AFD-Pro 1.01 und AFD-Pro 2.00



    Was der Unterschied zwischen den Versionen ist, habe ich noch nicht eruiert. Jedenfalls dürften beide Versionen die Prozessoren bis zum 80386 inkl. unterstützen.

  • Zu 99% wird das einfach eine Kopie, vor dem Befehl das Byte in den RAM zu schreiben kommt bei mir aber noch die gewünschte Änderung des Wertes und dann erst das mov es:[di],al oder stosb. Auf diesem Weg erspare ich mir das höchst zeitaufwändige nochmalige Einlesen vom RAM in die CPU, Änderung des Wertes, Zurückschreiben ins RAM.

    Was spricht gegen ein gewöhnliches Lesen mit anschließendem Ersetzen mit z.B. folgendem Code und passender Tabelle für xlatb?

    Code
    transform:
            shr     cx,1
            jc      odd
    l1:     lodsb
            xlatb
            stosb
    odd:    lodsb
            xlatb
            stosb
            loop    l1

    Das ist nicht einmal auf einem 8088 langsam. Der Flaschenhals dürfte eher der Massenspeicher sein.

  • Man kann ausführbare Dateien auch mit einem EXEPacker komprimieren bzw. enkodieren, so dass die Dateien unterschiedlich aussehen, aber in Wirklichkeit doch das Gleiche sind. Meine Infos stammen von old-dos.ru, ich konnte aber mit einem Hilfsprogramm namens UNP (Unpack) auch die gepackte AFD Pro in eine ungepackte Version verwandeln (unter DOS natürlich, nicht unter Windows).

    Ich hänge mal das Unpack-Programm dran, hat mir auch bei diversen DOS-Spielen geholfen, an die "echte" ausführbare Datei dranzukommen.

    So eine EXE-gepackte Datei erkennt man dadurch, dass man eben genau nicht nach den Texten in der ausführbaren Datei suchen kann.

    Ich lasse Dir aber gerne Deinen Glauben an verschiedene AFD Versionen, man sagt ja "Der Glaube versetzt auch Berge".

    Dateien

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

  • Debuger:
    Also ich habe auch den AFD-PRO V1.01
    @PAW,
    wo gäbe es denn die Version V2.00, falls es sie überhaupt gibt ?


    Ich hatte vor vielen Jahren mal den S-ICE für DOS im Einsatz.
    Der braucht aber zwingend einen 386er Prozessor.
    Der konnte sich schön im Hintergrund verstecken und zuschlagen, wenn bestimmte RAM- oder IO-Adressen gelesen oder geschrieben wurden.
    Der konnte sogar einen Reboot überstehen. Damit hatte ich mal eine CP/M-86 Software debuged.
    Boot mit DOS, S-Ice resistent geladen, Ctrl-Alt DEL, CP/M-86 boot und dann konnte ich über HotKey den S-Ice benutzen.
    Lang lang ist das her, so ca. 1989.


    Wenn den S-Ice DOS jemand möchte, bitte anfragen.


    mfG. Klaus Loy

  • Zitat von klaly

    Also ich habe auch den AFD-PRO V1.01

    @PAW,

    wo gäbe es denn die Version V2.00, falls es sie überhaupt gibt ?

    Habe ich weiter oben schon reingestellt: Thread mit Link zu AFD-Pro 2.00


    Im nachfolgenden Thread #17 gibt es noch diverse Screenshots.


    Wäre natürlich interessant, ob Du Unterschiede zwischen 1.01 und 2.0 rausfinden kannst.


    Gruß, PAW

  • Man kann ausführbare Dateien auch mit einem EXEPacker komprimieren bzw. enkodieren, so dass die Dateien unterschiedlich aussehen, aber in Wirklichkeit doch das Gleiche sind. Meine Infos stammen von old-dos.ru, ich konnte aber mit einem Hilfsprogramm namens UNP (Unpack) auch die gepackte AFD Pro in eine ungepackte Version verwandeln (unter DOS natürlich, nicht unter Windows).

    Ich hänge mal das Unpack-Programm dran, hat mir auch bei diversen DOS-Spielen geholfen, an die "echte" ausführbare Datei dranzukommen.

    So eine EXE-gepackte Datei erkennt man dadurch, dass man eben genau nicht nach den Texten in der ausführbaren Datei suchen kann.

    Ich lasse Dir aber gerne Deinen Glauben an verschiedene AFD Versionen, man sagt ja "Der Glaube versetzt auch Berge".


    Ein EXEPacker sollte ja, wie der Name schon sagt, die EXE-Datei auch komprimieren, sowie "unlesbar" machen. Das ist bei der Version 2.00 nicht der Fall. Man kann die Texte mit einem Hexeditor ansehen und auch ändern.


    Außerdem sind die Hilfetexte in Version 1.01 deutsch in Version 2.00 auf englisch. Das kann wohl auch ein EXEPacker nicht wirklich leisten.


    Es gibt allerdings noch andere Unterschiede zwischen den Versionen, wobei die Version 1.01 offenbar besser abschneidet, da es beim Gx-Befehl zusätzliche Parameter gibt.


    Version 1.01 ... /D-Parameter (bei GC-Befehl beschrieben) lässt sich ausführen:


    Version 2.00 ... /D-Parameter bringt Syntax-Fehler



    Gruß, PAW

  • Fakt ist, dass ich über diesen eigenartigen Link auch nicht an den AFDPro 2.0 dran komme.
    Ähnlich wie detlef und fritzeflink bereits in #12 und #13 erwähnt hatte.

    Könntest mir das gezippte File evtl. per PM schicken, nur damit man es hat.


    mfG. Klaus Loy