NtCreateProcess / ZwCreateProcess

[Zacherl]

Hey, ich habe mal eine theoretische Frage an euch:

Wie kann ich mit NtCreateProcess einen Prozess erstellen? Ich vermute mal ich muss das EXE Image selbstständig in den Speicher laden ..

Gruß Zacherl

[Dezipaitor]

Darf man fragen, was du damit machen willst?

[Zacherl]

Natürlich .. das selbe wie ich es im Usermode mit normalen CreateProcess mache .. einen Prozess starten.

[Luckie]

Und warum nimmst da dazu nicht CraeteProcess?

[Dezipaitor]

braucht man für die Funktion nicht System-Rechte ?

[Zacherl]

Ja .. ich will ein wenig in die Treiberprogrammierung unter C einsteigen, da ich C aber nicht (gut) kann, will ich mir den Aufruf erst in Delphi klarmachen.

[Luckie]

Ähm, Treiberprogarmmirung und Delphi sind zwei verschiedene Welten, die so gut wie nichtvereinbar sind. Entweder betreibst du Treiberprogrammierung, dan aber auch richtig mit der entsprechenden Entwicklungsumgebung oder du schreibst Benutzeranwendungen mit Delphi. Und nur ein bischen Treiberprogrammierung het nicht.

[Dezipaitor]

Was hast denn die Funktion mit Treiberprogrammierung zu tun? Kann man die in einem Treiber überhaupt aufrufen? Ich würde behaupten, man müsste einen Systemdienst installieren, der das macht. Der Treiber muss das an den Dienst kommunizieren. Müsste mal Olli dazu was sagen.

Irre ich mich, oder gab es nichtmal ein Versuch ein DDK für Delphi zu erstellen?
IMHO wären Treiber eh stabiler, wenn man jede andere Sprache außer C und kleiner verwenden würde *g*
Aber MS schafft es ja nichtmal den Vista Logon Bildschirm (User defines credential provider) .NET tauglich zu machen. Wir werden schon auf das Nächste Vista warten müssen, bis man .NET Treiber schreiben darf. Da brauchen wir dann auch keine Zwangssignierung mehr :D

[Olli]

Zitat:

Zitat von Zacherl

Natürlich .. das selbe wie ich es im Usermode mit normalen CreateProcess mache .. einen Prozess starten.

Gut, weil im Kernelmode kannste damit keinen starten.

Zitat:

Zitat von Dezipaitor

braucht man für die Funktion nicht System-Rechte ?

Nein, aber um in den Kernelmode zu gelangen braucht's das TCB-Recht.

Zitat:

Zitat von Zacherl

Ja .. ich will ein wenig in die Treiberprogrammierung unter C einsteigen, da ich C aber nicht (gut) kann, will ich mir den Aufruf erst in Delphi klarmachen.

Ich würde dir dann dringend empfehlen erstmal C/C++ zu lernen und dann eventuell bei Treibern einzusteigen. Dennoch ist Treiberentwicklung komplett anderes als Anwendungsentwicklung für Win32. ISt also fast wie der Umstieg auf ein anderes Betriebssystem, wenn man C oder Pascal zur GUI-Entwicklung nimmt.

Für einen Einblick in die Native API immernoch Nebbett sowie die JwaNative.pas von jedi-apilib.sf.net ...

[Zacherl]

Ich weiß, dass Treiberprogrammierung was total anderes ist als Programmierung unter Delphi. Mit dem DDK von Microsoft wollte ich mit meinen bisherigen Kenntnissen einfach einen Treiber schreiben, der zum Test einen neuen Prozess startet. Da ich CreateProcess wie ich weiß nicht verwenden kann muss NtCreateProcess her.

Ob Delphi oder C ist ja eigentlich egal .. mir gehts nur um den Ablauf .. welche APIs brauche ich alle und in welcher Reihenfolge mit welchen Argumenten muss ich sie aufrufen? Ich möchte keine Header, die habe ich :)

Ich verstehe halt nur nicht, wie die Abfolge der APIs ist. NtCreateProcess alleine reicht ja nicht aus, denn ich sehe keinen Parameter, mit dem man einen Image Pfad angeben kann.

[Olli]

Okay, ich versuche es nochmal.

Ein Treiber ist kein Programm, sondern eher mit einer DLL vergleichbar. Es gibt nur einen Pseudo-Prozeß und das ist der Kernel ("System"), der Rest sind Usermode-Prozesse - und jetzt rate mal warum.

Und ja, es geht durchaus Prozesse auch aus dem Kernelmode zu starten, aber nicht mit NtCreateProcess. Und nein, weder im Native-Mode noch im Win32-Subsystem reicht NtCreateProcess aus - hast du schon sehr gut verstanden. Gary Nebbett hat dazu ein gutes Beispiel in seinem Buch. Allerdings möchte ich dich warnen. Willst du einen Win32-Prozeß starten, mußt du diesen auch beim CSRSS anmelden - das ist komplett undokumentiert und auch nicht so einfach per Reverse Engineering rauszubekommen, zumal es sich mit jeder Betriebssystemversion unterscheidet (und zwar im Gegensatz zur Native API, wo es bis auf Ausnahmen stabil bleibt, komplett!).

Wenn man über den entsprechenden LPC-Mechanismus mal eine falsche "Nachricht" schickt, kann einem auch schonmal irgendwelche Hardware durchschmoren. Es gab hier bis vor einiger Zeit jemanden im Forum, der diese Erfahrung aktiv gemacht hat.

Vielleicht solltest du dich doch erstmal auf die Grundlagen - sowohl die von C/C++ als auch die der Systemprogrammierung - konzentrieren, bevor du dich in dieses Terrain vorwagst. Es benötigt nämlich Jahre Erfahrung und/oder mehrere Kurse von noch erfahreneren Leuten um Code zu schreiben, der den PC des Anwenders nicht bei jedem zweiten Tastenanschlag zum Stillstand (sprich BSOD) bringt.