Ich suche Beispielcode für einen DOS Sys Treiber - wenn möglich für
Turbo/Borland C/C++ oder Watcom, ist für ein Reverse Engineering Projekt
Ich hab eine paar Links, Dr Dobbs,... und ein paar PDFs gefunden aber
fast alles ist Asemblercode - da weiss ich wie ich eine Sys Treiber
baue, nur finde ich nichts für pure C - falls das überhaupt ganz ohne
Assembler möglich ist
Hallo cppbert3,
cppbert3 schrieb:> Ich suche Beispielcode für einen DOS Sys Treiber - wenn möglich> für> Turbo/Borland C/C++ oder Watcom, ist für ein Reverse Engineering Projekt
eventuell findest Du etwas im Sourcecode von Truecrypt.
Marc schrieb:> Ich vermute, das damals viel mit Inline Assembler gearbeitet> wurde, DOS war ja ziemlich nah an der Hardware im Vergleich zu modernen> Betriebssystemen.
Wie schon geschrieben, habe ich schon Dos sys Treiber in Assembler
programmiert, mein Problem ist die Sprungtabelle usw. am Anfang der Sys
Datei, mir ist nicht klar wie ich das in C hin bekomme oder was ich für
Linkersettings brauche
Peter M. schrieb:> Hallo cppbert3,> eventuell findest Du etwas im Sourcecode von Truecrypt.
Truecrypt ist Erstrelease 2004, das ist lange lange nach der 16 Bit DOS
Zeit, ich denke das ist technologisch was völlig anderes
cppbert3 schrieb:> Ich suche Beispielcode für einen DOS Sys Treiber - wenn möglich> für> Turbo/Borland C/C++ oder Watcom,
Das dürfte passen:
Adams/Tondo - Treiberprogramme in C unter Dos
ISBN 3-446-16391-3
vielleicht muss es auch nicht unbedingt ein DOS Geräte-Treiber sein
im Grunde will ich mit C ein Binary erzeugen welches bei Offset 0 eine
far-Jump Tabelle enthält - dieser "drv" wird dann von einer alten
DOS-Applikation geladen welche dann direkt far calls auf die
Tabellen-Punkte macht um die entsprechenden Treiber-Funktionen
aufzurufen
hier ein assemblierbares Beispiel (nur mit weniger/trivial Funktionenals
in echt)
Wichtig:
-der Jump/Call-Table muss exakt an der Stelle liegen
-es müssen Far-Funktionen als Ziele sein
-alle Variablen werden per cs-Register adressiert
sonst laeuft das nicht mit der Original-Applikation
den Original-Treiber habe ich vollständig reverse engineering und möchte
den jetzt nach C portieren
vielleich auch nur ein kleiner Stub in Assembler für den Table und dann
ein C Objekt mit dem Code dazu linken, ohne C-Runtime? aber wie bekomme
ich dann die Variablen CS-Register adressiert?
Oliver S. schrieb:> Da das aber damals in Assembler alles machbar war, sollte das heute auch> noch so sein.
Möglich ist es schon, aber nicht für jeden. Und von "modernen"
Programmierern wird das grundsätzlich abgelehnt. Ist wie beim Fuchs mit
den sauren Trauben oder so ähnlich.
Wichtig ist dabei die Schnittstelle von C zu Assembler- (oder sonstwas)
Unterprogrammen, die muss in der Compiler-Linker-Dokumentation
beschrieben sein. Wenn nicht hat man gleich ganz schlechte Karten. Wie
das bei Turbo-C war kann ich mich nicht mehr erinnern.
Georg
Hallo IgNorbert3,
cppbert3 schrieb:> Peter M. schrieb:>> Hallo cppbert3,>> eventuell findest Du etwas im Sourcecode von Truecrypt.>> Truecrypt ist Erstrelease 2004, das ist lange lange nach der 16 Bit DOS> Zeit, ich denke das ist technologisch was völlig anderes
warum bist Du so ignorant?
Ich denke, also irre ich!
Was ich Dir schrieb, betrifft nicht nur Truecrypt, sondern auch das ach
so moderne Veracrypt.
Lies' hier und krieche zu Kreuze!
[...
Last point : the code of VeraCrypt BIOS boot loader runs in a restricted
environment with limited resources and legacy mode (16-bit), which make
all cryptographic computation slower. Once Windows is started, we go
back to normal more with no performance degradation.
We can do nothing about this. In the future, we plan to support UEFI
boot which enables the use of more resources for booting.
...]
https://sourceforge.net/p/veracrypt/discussion/technical/thread/77d58591/
Peter M. schrieb:> warum bist Du so ignorant?> Ich denke, also irre ich!
Warum bist du so empfindlich? Ich war nicht ignorant obwohl ich denke
das du keine Ahnung von dem hast was ich weiter oben so gepostet habe
Peter M. schrieb:> Lies' hier und krieche zu Kreuze!> [...> Last point : the code of VeraCrypt BIOS boot loader runs in a restricted> environment with limited resources and legacy mode (16-bit), which make> all cryptographic computation slower. Once Windows is started, we go> back to normal more with no performance degradation.> We can do nothing about this. In the future, we plan to support UEFI> boot which enables the use of more resources for booting.> ...]> https://sourceforge.net/p/veracrypt/discussion/technical/thread/77d58591/
Es geht mir um ein sehr konkretes Problem zu dem ich sogar
funktionierenden Assemblercode gezeigt habe, das hat mit einem 16 bit
bootloader eines krypters nicht mehr gemeinsam als das ähnliche
Schlagworte vorkommen
Werter cppbert3,
cppbert3 schrieb:> Es geht mir um ein sehr konkretes Problem zu dem ich sogar> funktionierenden Assemblercode gezeigt habe, das hat mit einem 16 bit> bootloader eines krypters nicht mehr gemeinsam als das ähnliche> Schlagworte vorkommen
Assemblercode taucht in Deinem Eingangsbeitrag nicht auf.
Ich musste mich daher mit Deinen wenigen Sätzen bescheiden.
Mein Seher ist in Urlaub, und die Kristallkugel in Reparatur.
Eine lustige Antwort von Dir, die mir unterstellt, dass ich
Informationen von Dir ignoriert hätte, die zu dem Zeitpunkt gar nicht
vorhanden waren.
Timing kann bei Assemblerproblemen durchaus eine Bedeutung haben.
Unter einem laufenden Windows-Betriebssystem zählt der entsprechende
Code wohl als "Filtertreiber".
Dir zuliebe nenne ich den Code, der die gleiche Aufgabe beim Systemstart
wahrnimmt nun "Bert-Minus-Minus-Code". Wir wollen das Kind doch nicht
bei seinem eigentlichen Namen nennen! :)
Peter M. schrieb:> Assemblercode taucht in Deinem Eingangsbeitrag nicht auf.> Ich musste mich daher mit Deinen wenigen Sätzen bescheiden.
Bei deinem Folgenpost stand der Assemblercode schon lange da
Wenn du mir helfen kannst dann mach es bitte konkret mit Fragen oder
Ideen, aber beschwer dich nicht wenn dein dann doch etwas zu allgemeiner
Tips bei mir nicht den Anklang finden den du erwartet hast und falls du
keine Ahnung von Assembler und C Linkage hast ist ist es höchst
wahrscheinlich schwer mir zu helfen, ich entschuldige mich im Vorfeld
falls du doch tiefe Assembler/C Kenntnisse hast
Peter M. schrieb:> Timing kann bei Assemblerproblemen durchaus eine Bedeutung haben.> Unter einem laufenden Windows-Betriebssystem zählt der entsprechende> Code wohl als "Filtertreiber".
Was auch immer die beiden Statements mit meinem Problem zu tun haben
- sollte dir unklar sein was der obige Assemblercode macht ist das
einfach nicht der Platz um grobes PC wissen zur Schau zu stellen
cppbert3 schrieb:> im Grunde will ich mit C ein Binary erzeugen welches bei Offset 0 eine> far-Jump Tabelle enthält
Du kannst die Ablage im Speicher per Linker koordinieren. Schau mal in
die Beschreibung von TLink.
Ich fühle mich hier erinnert an den Artikel "Assembler to C" von Walter
Bright.
https://www.digitalmars.com/articles/b43.html
Da gab es glaube ich, auch noch etwas mehr dazu, finde ich aber nicht
mehr.
Ein anderes Projekt ist der Midnight Commander von Miguel de Icaza - der
den Dos - Norton Commander (asm) in C geclont hatte.
Microsoft wollte ja auch von Dos wegkommen und hatte dafür u.a. directx
entwickelt.
Dann gibt es Dos-Programme/Rechner, die DPMI nicht abkönnen - aber so
manches Dos-Programm braucht die Erweiterung auf z.B. Unreal-Mode z.B.
oder eben ein Protected Mode Interface.
Bei einfachen 16-Bit Sachen muss der Linker das schwierige Real
Mode-Handling betreiben - ohne dem wird das nix mit far-jumps.
Die Watcom-Programme laufen auf 16 Bit - und auf 32 Bit d.h. auch auf
Windows 8. obwohl bei mir 64 Bit.
Auch dieses ist zu berücksichtigen: die Portabilität nach wohin genau?
Es gibt z.B. auch neuere Bibliotheken, so dass ältere Compiler gar nicht
mehr auf älteren Kisten laufen bzw. gar nicht mehr aufwärts-compatibel
sind.
rbx schrieb:> Ich fühle mich hier erinnert an den Artikel "Assembler to C" von> Walter> Bright.> https://www.digitalmars.com/articles/b43.html
den Artikel kenne ich
keine Ahnung was deinen anderen Sätze nur im entferntesten mit meinem
Topic zu tun haben - ausser das es irgendwie mit DOS und 16Bit zu tun
hat
ich mach nichts mit Windows oder DirectX, DPMI oder DOS/Windows
Portierung sondern will eine DOS-Code den ich disassembliert habe von
Assembler nach C portieren - das Ergebnis läuft aber weiterhin unter DOS
und der Linker hat mit der far/near/Real-Mode Segmentierungs-Sache bis
auf das zuordnen der passenden Symbole keine Bedeutung - das muss alles
der Kompiler machen
Soweit ich verstanden habe geht es ja nur darum wie man eine
Sprungtabelle in C programmiert. Dafür könntest Du dir auch den
C-Startup-Code von heutigen ARM Cortex-M3 Mikrocontroller ansehen. Bei
dem Keil uVision MDK for ARM ist entsprechender Code mit enthalten, oder
es könnte auch Beipsiele im Netz irgendwo geben.
Julius schrieb:> Soweit ich verstanden habe geht es ja nur darum wie man eine> Sprungtabelle in C programmiert.
nur die Sprung-Tabelle ist nicht soo schwer, das ich aber meine Daten in
C/C++ per CS oder Umwege DS adressiert bekomme scheint schwierig
Julius schrieb:> Dafür könntest Du dir auch den> C-Startup-Code von heutigen ARM Cortex-M3 Mikrocontroller ansehen. Bei> dem Keil uVision MDK for ARM ist entsprechender Code mit enthalten, oder> es könnte auch Beipsiele im Netz irgendwo geben.
ist das in dem Umfeld nicht alles super spezialisiert und lässt sich
kaum auf mein MS-DOS 16 Bit Umfeld mappen?
Ben B. schrieb:>> von Assembler nach C portieren> Aber sonst bist Du gesund?
alle paar Jahre packt mich die Assembler-Lust und da ich beruflich u.a.
auch im Reverse-Engineering tätig bin - dort aber selten mit alten
Systemen zu tuen haben ist es schon eine Form von krankhaftem
Masochismus der mich treibt :)
ich bin jetzt von der Idee abgekommen alles vollstaendig in C zu machen
d.h. ich schreiben den Jump-Table in Assembler und verweise auf externe
far Functionen in C/C++
Assembliert, kompiliert und linkt auch - alles ganz toll
ABER
Jetzt werden meine Variablen in C/C++ nicht richtig adressiert:
1. der Zugriff passiert per DS-Register - obwohl durch den Plugin-Caller
aber nur CS verfuegbar ist (ich koennte ds=cs+? setzen)
2. der Linker geht irgendwie davon aus das meine C/C++ Variablen in
einem freien Segment vorliegen deswegen sind
die Variablen-Offsets beim Zugriff falsch
die alte DOS-Applikation macht diese komischen Vorgaben (Daten nur per
CS erreichbar, und eben dieser Jump-Table) daran kann ich nichts
aendern
ich würde es sehr gerne vermeiden die Variablen in den Assembler-Code zu
stellen - vielleicht hat ja jemand noch eine Idee
Was ich bisher haben:
Assembler-Code (Stellt sicher das der Jump-Table den DOS Plugin-Vorgaben
entspricht)
drv_asm.asm
man sieht deutlich das die Variablen-Offsets so aufgeloest worden sind
als wenn es wirklich ein Daten-Segment geben wuerde, d.h. die Offsets
reichen in Code-Bereiche
ich habe keine Idee wie ich das lösen kann
Es kommt der gleiche Code raus wenn ich das mit einem alten Borland C++
3.1, TLINK, 16 Bit MS-Linker usw. probiere - damit hat es nichts zu tun,
der Linker hat eben keine Ahnung was er machen soll
im Anhang das jetzige Layout mit den falschen Offsets
kann ich überhaupt zum Linkzeitpunkt die falschen mov-Offsets im TEXT
Segment noch beeinflussen?
eine andere Idee wäre es das DATA-Segment zwischen den Jump-Table und
die C-Funktionen zu linken und dann irgendwie den Wert von ds per Hand
über die größe des Tables zu berechnen + Tramplin-Funktion pro
Table-Eintrag - und damit indirekt die move-Offsets zu korrigieren?
Fühlt sich alles ein wenig bastelig an - aber so ein Plugin ist eben
auch absolut keine normale Exe oder Com-Program
Kennt jemand vielleicht noch ein Forum das mehr auf solche Frage
spezialisiert ist?
fast geschafft:
beim UniLink wie auch beim Microsoft Linker gibt es eine Option um
Sections zu mergen
ich hab jetzt einfach mit "-GM:_TEXT=_DATA" als Linker Parameter
befohlen die beiden Segmente in eins rein zu machen - und schon passen
die Offsets
jetzt ist nur noch blöd das der C-Kompiler DS zur Adressierung der Daten
nutzt - sonst wäre ich schon fertig mit dem Rumpf :(
jetzt hatte ich gedacht eine schöne Lösung gefunden zu haben (sogar die
Adressierung per DS sieht so gut aus) - aber leider sind jetzt meine
Variablen-Offsets wieder falsch :(
Fertig!
so jetzt klappt es - mit dem Open Watcom V2 kann man auch CODE-Segment
Variablen machen
damit bekomme ich dieses komische Plugin-Konzept unter Kontrolle
und kann jetzt alles schoen in C/C++ nachbauen
drv_asm.asm