Mit Delphi in den Kernel-Modus gelangen

[SirThornberry]

Zitat von Frickeldrecktuxer_TM:

Zitat von Metal_Snake2:

Gut mit Tricks und aufwand, aber dafür lernt man auch mal mit Delphi den Kernel-Mode kennen.

Ähh... und was habe ich davon?

Man hat davon genau das gleiche wie bei allem anderen was man lernt. Es wäre jetzt jedoch übertrieben hier eine Diskussion anzufangen ob es sinnvoll ist etwas zu lernen zumal es doch langsam OT wird.

[NicoDE]

Zitat von Metal_Snake2:

Bisher bin ich von der richtigkeit diesen Artikels ausgegangen Klick.

Zum Zeitpunkt des Artikels gab's, bis auf privat ausgetauschte Units und Testprojekte, (meines Wissens) keine Delphi-Quellen für Kernel-Treiber.
Alles andere trifft unverändert zu.

Zitat von Metal_Snake2:

Es scheint nicht ganz zu stimmen das man mit Delphi/Pascal keine Treiber programmieren könnte.

Das wurde auch nie behauptet. Der Artikel legt eher nahe, dass man nicht seine Zeit damit verschwenden sollte.

Zitat von Metal_Snake2:

In C++ gibts hier sogar eine Anleitung dafür.

Seit Windows Server 2003 SP1 (und in den 64-Bit Versionen) können auch Administratoren das Kernel-Objekt '\Device\PhysicalMemory' weder lesend noch schreibend öffnen. Dadurch wird der gesamte Artikel hinfällig.
(was u.a. dazu führte, dass meine BiosHelp-Unit aktualisiert werden musste...)

Zitat von Metal_Snake2:

Jetzt bin ich Total verwirt, kann man jetzt doch mit Hacks/Tricks in den Kernel-Modus gelangen[...]

Das konnte man schon immer (Treiber mit dem DDK schreiben, der seinerseits eine native Delphi-DLL lädt (auch nicht trivial)).

Zitat von Metal_Snake2:

[...]und Treiber mit Delphi schreiben?

Nicht wirklich (lies bitte die Dokumentation des DDDK).

Zitat von Metal_Snake2:

Jedenfalls schaffe ich es nicht kompischerweise mit der DDDK eine *.Sys datei zu erzeugen.

RTFM

Zitat von Metal_Snake2:

Ich finds nur schade das es zu dem Thema Delphi und Kernel relativ wenig gibt, da es ja doch möglich ist und funktioniert.
Gut mit Tricks und aufwand, aber dafür lernt man auch mal mit Delphi den Kernel-Mode kennen.

Ich halte es für sinnvoller, sich zuerst mit dem DDK zu beschäftigen. Wenn man genug Erfahrung gesammelt und die Grundprinzipien verstanden hat (erst dann), kann man gerne versuchen (wenn man zuviel Zeit hat ) einige Teile in Delphi zu schreiben und auf Umwegen in den Kernel zu bringen.

Aller guten Edits sind drei

Zitat von Ultimator:

Ich häng das Archiv mal an, ich habs mir damals runtergeladen. Wenn das nicht okay ist, dann entfern ichs wieder.

Das Archiv enthält scheinbar die DCC32.EXE von Delphi 7 Enterprise. Ich glaube nicht, dass sie eine Ausnahmegenehmigung von Borland haben...

[brechi]

Hab hier nochmal paar kleine Sachen gemacht, obs stabil läuft weiß ich nicht ;>
Deshalb benutzung auf eigenes Risiko, Quellcode ist dabei

[Olli]

Zitat von Metal_Snake2:

Colin Wilson gelangt sogar in dern Kernel ohne einen Treiber,
indem er Physikalischen- in Virtuellen- Speicher Kopiert, daher kann er auch z.B. die Filehandles erhalten.

Bezeichnungen wir "physikalischer Speicher" sind Nonsens. Laß dich nicht von "\Device\PhysicalMemory" verleiten zu solch einer falschen Annahme!

Zitat von Metal_Snake2:

In C++ gibts hier sogar eine Anleitung dafür.

Ja toll, es gibt auch mehrere Viren die das nutzen um eine Art Rootkit zu etablieren.

Zitat von Robert Marquardt:

Nicht zuletzt ist C++ oder Delphi fuer Treiber ungeeignet. Speziell die strukturierte Ausnahmebehandlung ist etwas was der Windows-Kernel nicht vertraegt.

SEH unterstützt der Kernel sogar explizit - hingegen die C++-Exceptions mag er nicht. Wichtiger ist aber, daß man bei C++ z.B. alle wichtigen Operatoren überschreiben müßte (new, ...). Das ist ein Heidenaufwand und verbraucht allemale mehr Speicher als ein "normaler" Treiber.

Zitat von Robert Marquardt:

Strukturierte Ausnahmebehandlung aka Exceptions brauchen eine Infrastruktur die im Kernel einfach nicht vorhanden ist.

Möööp. Doch, SEH ist wohl vorhanden!

Zitat von Robert Marquardt:

Es gibt zwar C++ Treiberframeworks, aber die generelle Meinung der Treiberentwickler ist, das es nicht zuverlaessig funktionierren kann.

Möööp. Ich bin Treiberprogrammierer und empfinde das KMDF als funktionierend - es ist von MS und es basiert auf C++

Zitat von Robert Marquardt:

Ich moechte auch nicht wissen was der Delphi-Memorymanager im Kernel alles anstellt.

Garnichts, denn den Memory-Manager mußt du genau wie all den anderen Schmarrn von Delphi wegwerfen und selber neu implementieren.

Zitat von Metal_Snake2:

Ich finds nur schade das es zu dem Thema Delphi und Kernel relativ wenig gibt, da es ja doch möglich ist und funktioniert.
Gut mit Tricks und aufwand, aber dafür lernt man auch mal mit Delphi den Kernel-Mode kennen.

Ich bin überzeugt, daß man mit einem Fahrrad auch ein Auto abschleppen kann, die Frage ist einfach ob es praktikabel ist. Und die nächste Frage ist, ob du dieses Produkt dann auch unterstützen kannst und willst.
Abgesehen davon, daß der DDK-Compiler ein komplett anderer ist als der in VS, was es schon zum Abenteuer macht mit dem VS-Compiler einen Treiber zu kompilieren (wovon übrigens auch abzuraten ist).

Ist ja schön, daß du soviel Bastellaune mitbringst und auch daß brechi sie auch mitbringt und uns gleich wieder "bewiesen" hat, daß es geht (hat IMO niemand bezweifelt). Die Frage ist nur, ob man das will, wenn man professionell einen Treiber schreibt und ob man auch diesen Treiber unterstützen will. Die Leute von OSR würden dich auslachen.

Und um mich nochmals auf andere Weise zu wiederholen, sicher ist ein Rootkit oder andere Malware nicht im geringsten an Systemstabilität interessiert (sieht man am besten am Sony Rootkit), jedoch sollten ernsthafte Treiber (und deren Autoren) mit etwas mehr Augenmaß handeln und vor allem folgendes beachten:
Schreibe ich ein Usermodeprogramm scheiße, kackt maximal das Programm ab - im gleichen Fall ist es beim Treiber das ganze System.

[Olli]

Hier noch ein russischer Beitrag zum Thema. Auch hier ist die Schlußfolgerung, daß es "prinzipiell möglich" ist. Klingt nicht, als würde der Autor aktiv zu einem solchen Vorgehen raten.

[Dirkmswt]

Hallo ich hab da mal ne Frage zum dddk2004.
Ich habe mit den Beispielen probiert die nochmals zu Kompilieren,aber trotz Batch kein Erfolg gehabt
Habe auch probiert die linker.exe und was so alles zum Kompilieren notwendig ist in den Ordner zu kopieren wo ich das kompilat machen wollte aber irgendwas zickt da rum.
Bekomme auch keine Fehlermeldung was das ganze nochmals erschwert.
Liegt das vielleicht am Compiler dcc32.exe?
Gruß Dirk

[Olli]

Zitat von Dirkmswt:

Hallo ich hab da mal ne Frage zum dddk2004.
Ich habe mit den Beispielen probiert die nochmals zu Kompilieren,aber trotz Batch kein Erfolg gehabt
Habe auch probiert die linker.exe und was so alles zum Kompilieren notwendig ist in den Ordner zu kopieren wo ich das kompilat machen wollte aber irgendwas zickt da rum.
Bekomme auch keine Fehlermeldung was das ganze nochmals erschwert.
Liegt das vielleicht am Compiler dcc32.exe?

Sei mir nicht böse - lies doch einfach nochmal durch den Thread und zwar in Gänze und achte auf die Einwürfe von Nico und mir.

Bestimmt entlockte es einem Newbie auch ein verzücktes Grinsen wenn jemand ein Fortran-DDK bereitstellte oder jemand auf die bescheuerte Idee käme ein DDK in Haskell zu schreiben. Allein, es stellt sich weiterhin die Sinnfrage.

Um mich selbst zu zitieren: Schreibe ich ein Usermodeprogramm scheiße, kackt maximal das Programm ab - im gleichen Fall ist es beim Treiber das ganze System.

... und ja, es ist bereits schwer genug mit C bzw. C++ einen Treiber zu schreiben der auf allen zu unterstützenden System einwandfrei funktioniert. Wer _asm benutzt weiß, daß es u.U. sogar noch schwerer werden kann (es gibt tatsächlich Stellen wo man das wirklich braucht).

Und dann verrate ich noch ein kleines Geheimnis:
Der DDK-Compiler ist nicht identisch mit dem im Visual Studio. Zwar stimmt es, daß bis zum 2000er DDK der Programmierer den Compiler von VC6 zur Verfügung stellen mußte, dies ist aber seit dem ersten XP DDK (das den Compiler und Linker enthielt) nicht mehr der Fall. Abgesehen von diversen Sachen die der Linker von z.B. VS 2005 macht, die nicht immer vorteilhaft für einen Treiber sind, gibt es einen sehr speziellen Grund, warum man den Compiler des DDK benutzen sollte: FP Opcodes.
Jupp, im Kernelmode ist es dir nicht (bis auf Ausnahmen die Prolog und Epilog haben) erlaubt Gleitkommaoperationen zu verwenden. Der Grund ist einfach: ein Treiber ist eine DLL wird im Kontext eines Threads aufgerufen. Jeder Thread hat einen Kontext, der auch den Stand der FPU-Register usw. beinhaltet. Wenn du nun damit rumwerkelst ohne diesen Kontext vorher zu sichern und nachher wiederherzustellen, kann so gut wie alles passieren ...
Übrigens ist das einer der Gründe warum man DDKBUILD immer einem Projekt vorziehen sollte, wo der VS-Compiler benutzt wird (es sei denn es handelt sich um das DDK von 2000 oder niedriger).

Mein Fazit für dich:
Klar geht es mit Delphi einen Treiber zu schreiben. Wenn du die paar Headerchen erstmal übersetzt hast, kannst du damit fortfahren die /GS-Funktionen in den Delphi-Linker einzubauen ...
Selbst Freepascal-Treiber finde ich fragwürdig, obwohl es der Linker dort noch eher hergibt, weil ich ihn notfalls ja anpassen könnte. Also laß es doch einfach und steige in die Treiberentwicklung direkt ein, wenn es dich interessiert - aber nicht mit Delphi.
Tip: stelle keine Fragen zum DDDK in Mailinglisten als NTDEV und NTFSD

[Dirkmswt]

Ich persönlich mag eher Pascal als c++
Als Programmierer Graußen mich die lustigen Fehler wie Visual c++ Runtimefehler die öfter mal auftauchen wenn man mal mehr macht als nur was berechnen
Ich hab schon die lustigsten Schleifenfehler die ich sogar vom Algorithmus her in Pascal einwandfrei getestet habe,in Vc++ aber garnix macht oder halt böse Programmabstürze etc...
Mir kann keiner weiß machen das c++ das beste dafür sein kann
Hab mich schon mit den verschiedensten c und C++ Compilern beschäftigt u.a auch unter Linux.
Vorallem im Hochsicherheitsbereich wird c++ verpöhnt und ist nicht umsonst an den meißten xp Bugs beteiligt.
Wenn das dddk mal richtig auf den neuesten Stand gebracht wird,mit unterstützung der Community wäre das doch der perfekte Meilenstein in der Treiberentwicklung.
Pascalcode ist Kontrollierbarer als der von c++.

[Luckie]

Zitat von Dirkmswt:

Ich hab schon die lustigsten Schleifenfehler die ich sogar vom Algorithmus her in Pascal einwandfrei getestet habe,in Vc++ aber garnix macht oder halt böse Programmabstürze etc...

eine Programmiersprache und eine ID (Compiler/Linker) sind auch nur Handwerkszeuge. Und wie im richtigen Leben muss man diese eben auch beherrschen können.

Zitat:

Vorallem im Hochsicherheitsbereich wird c++ verpöhnt und ist nicht umsonst an den meißten xp Bugs beteiligt.

Ich kann auch mit Delphi / Pascal Sicherheitslücken in meinem Code programmieren, wenn ich jegliche Grundsätze außeracht lasse und von nix eine Ahnung habe.

Zitat:

Wenn das dddk mal richtig auf den neuesten Stand gebracht wird,mit unterstützung der Community wäre das doch der perfekte Meilenstein in der Treiberentwicklung.

Dann aber viel Spass. Nico hat es wohl schon erwähnt, aber es werden einfach Sprachkonstrukte von C genutztm, die es so nicht in Delphi/Pascal gibt und die man teilweise nur sehr schwer nachbilden kann. Mit einem einfachen Übersetzen der Header ist es nicht getan. Btw. müssen die meisten, die das Knowhow hier hätten auch nebenbei noch etwas Geld zum Leben verdienen.

Zitat:

Pascalcode ist Kontrollierbarer als der von c++.

Das halte ich für ein Gerücht. Gehört aber hier nicht zum Thema.

[Phoenix]

Zitat von Dirkmswt:

Ich persönlich mag eher Pascal als c++

Schön für Dich. Mir ist Pascal auch lieber als C/C++. Aber das geht denke ich den meisten Usern hier so.

Zitat von Dirkmswt:

Als Programmierer Graußen mich die lustigen Fehler wie Visual c++ Runtimefehler die öfter mal auftauchen wenn man mal mehr macht als nur was berechnen

Nur weil Du ein Werkzeug nicht beherrschst muss es noch lange nicht schlecht sein.

Zitat von Dirkmswt:

Mir kann keiner weiß machen das c++ das beste dafür sein kann

Schade für Dich, denn es ist nunmal defakto so.

Zitat von Dirkmswt:

Hab mich schon mit den verschiedensten c und C++ Compilern beschäftigt u.a auch unter Linux.
Vorallem im Hochsicherheitsbereich wird c++ verpöhnt und ist nicht umsonst an den meißten xp Bugs beteiligt.

Dem mag so sein. Aber würdest Du deswegen nur weil hier meist Python eingesetzt wird einen Systemtreiber in Python schreiben wollen?

Zitat von Dirkmswt:

Wenn das dddk mal richtig auf den neuesten Stand gebracht wird,mit unterstützung der Community wäre das doch der perfekte Meilenstein in der Treiberentwicklung.

Eher der perfekte Einstieg in den Untergang. ICH will keinen Delphi-Treiber auf meinem System laufen haben. Ich steh eher auf ein stabiles System.

Zitat von Dirkmswt:

Pascalcode ist Kontrollierbarer als der von c++.

Besser / leichter / schneller lesbar: In der Regel Ja.
Besser Kontrollierbar: Nein. Die Kontrollierbarkeit ist genau identisch und hängt von der Fähigkeit des Entwicklers damit umzugehen ab.