Windows Process Injection - Versuch

wpi

Hi, das Thema ist ziemlich neu für mich.

Meine Wunschvorstellung ist folgende, ich kann eine .exe erstellen (nennen wir sie injector.exe...) und wenn man diese startet, wird automatisch ein laufender notepad++.exe-Prozess mit bestimmten Code injiziert.

Der Code soll folgendes tun: Wenn z. B. "a" eingegeben wird, dann soll im Notepad-Fenster "d" erscheinen. Wenn "b" eingegeben wird, dann "e". Wenn "c" eingegeben wird, dann "f". Usw., usf. Also soll sich jeder eingegebene Buchstabe automatisch um 3 Stellen verschieben.

Dazu hab ich mir https://github.com/Lexsek/ProcessInjectionTool/tree/master durchgelesen.

Meine Frage wäre, wie ich damit anfangen kann, also wie man am einfachsten auf die WinAPI zugreifen kann, an einen Process-Handle kommt usw. Braucht man dafür zwingend das Visual Studio installieren?

hustbaer

Meine Frage wäre, wie ich damit anfangen kann, also wie man am einfachsten auf die WinAPI zugreifen kann, an einen Process-Handle kommt usw.

Das ist doch in dem von dir verlinkten Github Repo eh alles beschreiben.

Braucht man dafür zwingend das Visual Studio installieren?

Nein, du brauchst nicht zwingend Visual Studio. Aber es ist vermutlich der Weg des geringsten Widerstandes. VS Community Edition ist ja gratis - und sollte alles mitbringen was du brauchst.

wpi

Ich stehe vor dem Problem, dass ich nicht weiß, wie ich anfangen soll. Ich habe ein 1000-Teile-Puzzle vor mir und finde die ersten 5 Puzzleteile einer Ecke/Basis nicht ... Kannst du helfen?

DocShoe

Welche Vorkenntnisse hast du denn? Beherrschst du (zumindest die Grundlagen) von C oder C++?

wpi

@DocShoe sagte in Windows Process Injection - Versuch:

Beherrschst du (zumindest die Grundlagen) von C oder C++?

ja

DocShoe

Dann setz' als erstes ein leeres Win32 Projekt auf, spielt keine Rolle ob Konsolen-App oder Windows-Desktopanwendung. Konsolen-App ist vermutlich einfacher, weil du da keine Fenster brauchst.
Sobald du das hast steht doch auf der von dir verlinkten Seite alles, was man tun muss.

Th69

Hierfür braucht man keine direkte "Process Injection", sondern es reicht ein "Windows Hook": Verwenden von Hooks, d.h. mittels WH_KEYBOARD fängt man die Nachricht ab und ändert sie (bzw. verwirft sie und sendet die passende WM_CHAR Nachricht).

Edit: Hooking Keyboard Input To Play Snake In Notepad.exe

hustbaer

@wpi
Oops. Ich hab mir den Code in dem GitHub repo jetzt mal angesehen. Da ist ja nicht viel da. Der injected bloss ein paar NOPs in den Prozess. Das wird natürlich nicht viel bringen.

Davon abgesehen: wenn du lernen willst wie man das programmiert, würde ich mal damit anfangen den Prozess zu suchen damit du an die PID kommst, mit der du dann OpenProcess aufrufen kannst. Dabei kannst du dich an der CrawlProcess Funktion aus deinem Link orientieren. Nur dass du nicht auf die PID prüfen solltest (die willst du ja rausfinden), sondern auf den Prozess-Namen.

Dazu installierst du Visual Studio und erstellst wie @DocShoe geschrieben hat ein C++ Konsolen-App Projekt. Dann kannst du beginnen die CrawlProcess Funktion zu integrieren und abzuwandeln. Dann als nächstes OpenProcess aufrufen damit du ein Process Handle bekommst.

Und dann wird's interessant. Im Prinzip musst du eine Funktion in den Ziel-Prozess kopieren, die LoadLibrary aufruft. Ohne Assembler-Kenntnisse wird das schwierig. Aber wenn du lange genug googelst, findest du sicher eine Seite mit einer ausreichenden Erklärung bzw. sogar einem Beispiel.

wpi

Wo kann ich denn etwas mehr über das Prozess-Modell bzw. -Management von Windows lernen? Oder ist das alles in einen proprietären Nebel gehüllt?

@hustbaer sagte in Windows Process Injection - Versuch:

Und dann wird's interessant. Im Prinzip musst du eine Funktion in den Ziel-Prozess kopieren, die LoadLibrary aufruft. Ohne Assembler-Kenntnisse wird das schwierig. Aber wenn du lange genug googelst, findest du sicher eine Seite mit einer ausreichenden Erklärung bzw. sogar einem Beispiel.

Ich muss doch prinzipiell "nur" zwei Dinge machen: (a) Die Stelle (im Disassembly) finden und modifizieren, die auf die Tastatureingaben horcht/reagiert, sowie (b) danach dies in den laufenden Prozess injizieren. Oder habe ich den Ablauf falsch verstanden?

@Th69 sagte in Windows Process Injection - Versuch:

Hierfür braucht man keine direkte "Process Injection", sondern es reicht ein "Windows Hook": Verwenden von Hooks, d.h. mittels WH_KEYBOARD fängt man die Nachricht ab und ändert sie (bzw. verwirft sie und sendet die passende WM_CHAR Nachricht).

Edit: Hooking Keyboard Input To Play Snake In Notepad.exe

Ich möchte eigentlich nicht etwas global ins System injizieren. (Wahrscheinlich läuft Windows dann auch Amok ...) Es sollte gezielt ein zu befallender Prozess ausgewählt werden.

DocShoe

@hustbaer
Du kannst doch den Speicher im Remote Prozess allokieren und befüllen. Damit kannst du den Parameter für LoadLibrary bestimmen und den Rest in der DllMain erledigen. Hier findet man ein Beispiel dafür.

@wpi
Natürlich ist alles in proprietären Nebel gehüllt, gibt es einen betriebssystemübergreifenden Standard zur Prozessverwaltung? Allerdings ist der Nebel sehr hell, ich würde hier eher von Wölkchen reden, da die Windows Interna öffentlich beschrieben werden und es eine API dazu gibt. Hier findest du die Doku zu der Windows Process API. Die API arbeitet fast nur mit Handles, du musst also rausfinden, wie du von Prozessnamen/ProzessID an das entsprechende Prozesshandle kommst. Ist alles trivial, mit ein wenig Recherche solltest du das fix hinbekommen. Ein anderes Thema sind Zugriffsrechte, man darf nicht einfach so in den Speicher fremder Prozesse schreiben, wenn ich mich da richtig erinnere. Auch dazu gibt es einen Haufen Funktionen, wo man selbst mit Administratorrechten bestimmt Privilegien aktivieren muss, bevor Windows das Schreiben in den Speicher fremder Prozesse erlaubt. Wenn du die Rückgabewerte der Funktionen auswertest bekommst per GetLastError() schnell raus, woran's hakt.

Th69

@wpi sagte in Windows Process Injection - Versuch:

Ich möchte eigentlich nicht etwas global ins System injizieren. (Wahrscheinlich läuft Windows dann auch Amok ...) Es sollte gezielt ein zu befallender Prozess ausgewählt werden.

Tja, hättest du mal den Artikel gelesen (bzw. vorher übersetzen lassen, wenn du kein/kaum englisch kannst) sowie den Code dazu angeschaut (Stichwort: ThreadId).

Außerdem was nützt eine "Process Injection", wenn man nicht die Windows-Nachrichten abfangen kann (darum geht es dir doch, oder?)?

wpi

@Th69 sagte in Windows Process Injection - Versuch:

Außerdem was nützt eine "Process Injection", wenn man nicht die Windows-Nachrichten abfangen kann (darum geht es dir doch, oder?)?

Die Frage kann ich leider nicht beantworten, weil ich sie inhaltlich nicht verstehe.

@DocShoe Danke für das geteilte Wissen.

Ich bin noch nicht dazu gekommen, das Visual Studio zu installieren.

wpi

@DocShoe sagte in Windows Process Injection - Versuch:

, gibt es einen betriebssystemübergreifenden Standard zur Prozessverwaltung?

Es gibt gewissen Prozess-Scheduling-Algorithmen, ja. Round Robin zum Beispiel. Aber wie es letztlich im OS umgesetzt wurde... das weiß ich nicht.

hustbaer

@wpi sagte in Windows Process Injection - Versuch:

Wo kann ich denn etwas mehr über das Prozess-Modell bzw. -Management von Windows lernen? Oder ist das alles in einen proprietären Nebel gehüllt?

An 100 Stellen im Internet, in diversen Büchern usw. Konkrete Empfehlung kann ich keine geben. Wenn ich was brauche google ich einfach mal drauf los. Wobei es natürlich für jemanden der noch sehr wenig über das Thema weiss schwieriger ist zu beurteilen ob die Informationen die man findet zuverlässig sind.

@hustbaer sagte in Windows Process Injection - Versuch:

Und dann wird's interessant. Im Prinzip musst du eine Funktion in den Ziel-Prozess kopieren, die LoadLibrary aufruft. Ohne Assembler-Kenntnisse wird das schwierig. Aber wenn du lange genug googelst, findest du sicher eine Seite mit einer ausreichenden Erklärung bzw. sogar einem Beispiel.

Ich muss doch prinzipiell "nur" zwei Dinge machen: (a) Die Stelle (im Disassembly) finden und modifizieren, die auf die Tastatureingaben horcht/reagiert, sowie (b) danach dies in den laufenden Prozess injizieren. Oder habe ich den Ablauf falsch verstanden?

Du kannst natürlich versuchen den Code des Programms direkt zu patchen. Das ist aber fummelig. Und wenn du nicht willst dass jede kleine Änderung am Zielprogramm dazu führt dass dein Patch nicht mehr korrekt funktioniert, wird es gleich ziemlich aufwendig.

Ich würde an deiner Stelle viel lieber versuchen einen Weg zu finden wie ich das hinbekomme ohne direkt Code des Programms ändern zu müssen. U.u. gibt es einen offiziellen Mechanismus wie du die Tastatur-Inputs abfangen/ändern kannst. Und wenn nicht, dann würde ich lieber versuchen mit einer Hooking Library ala Deviare die eine oder anderen WinAPI Funktion zu hooken.

Oder du versuchst es gleich ganz ohne Code-Injection hinzubekommen. z.B. mit dem von @Th69 erwähnten WH_KEYBOARD. Keine Ahnung ob das damit wirklich noch funktioniert, aber einen Versuch wäre es wert.

hustbaer

@DocShoe sagte in Windows Process Injection - Versuch:

@hustbaer
Du kannst doch den Speicher im Remote Prozess allokieren und befüllen. Damit kannst du den Parameter für LoadLibrary bestimmen und den Rest in der DllMain erledigen. Hier findet man ein Beispiel dafür.

Er. Ja Man kann auch direkt LoadLibraryA/LoadLibraryW als Thread-Function angeben. Funktioniert, weil LoadLibrary von der Signature her "ausreichend kompatibel" mit LPTHREAD_START_ROUTINE ist. Ich hatte da was falsch in Erinnerung.

Wobei das nur so einfach geht, wenn beide Prozesse die selbe Bitness haben. Wenn sie unterschiedliche Bitness haben kommt man nicht mehr so einfach an die Adresse von LoadLibrary im Zielprozess.

hustbaer

@wpi sagte in Windows Process Injection - Versuch:

@DocShoe sagte in Windows Process Injection - Versuch:

, gibt es einen betriebssystemübergreifenden Standard zur Prozessverwaltung?

Es gibt gewissen Prozess-Scheduling-Algorithmen, ja. Round Robin zum Beispiel. Aber wie es letztlich im OS umgesetzt wurde... das weiß ich nicht.

Das ist doch zur Umsetzung deines Vorhaben völlig wörscht wie das Scheduling genau funktioniert.

wpi

@hustbaer sagte in Windows Process Injection - Versuch:

dann würde ich lieber versuchen mit einer Hooking Library ala Deviare die eine oder anderen WinAPI Funktion zu hooken

Meinst du die hier: https://github.com/nektra/Deviare2 ?

Das Wiki/der Quickstart ist gerade down: http://wiki.nektra.com/Quickstart_v.2.0

Ich bin immer Fan davon, wenn man etwas Konkretes meint, es dann auch konkret zu benennen ...

Tatsächlich habe ich auch nach Hooking Libraries/Tools gesucht. Aber leider bekomme ich von Google dazu noch keine verwertbaren Ergebnisse.

@hustbaer sagte in Windows Process Injection - Versuch:

Das ist doch zur Umsetzung deines Vorhaben völlig wörscht wie das Scheduling genau funktioniert.

Du hast die Frage/Antwort/den Beitrag von @DocShoe aber schon genau gelesen, oder?

Es gibt gewisse OS-Algorithmen. Die sind "open source" und nicht geschützt, also für alle zugänglich. Es gibt aber auch die Implementierung/Technizität der Algorithmen im OS. Die sind proprietär, geschützt, nicht frei zugänglich, ggf. patentiert.

Die Frage war, ob man aus der Theorie (dem Abstrakten, den Algorithmen) ableiten hätte können, wie Microsoft bestimmte Dinge umgesetzt/implementiert hatte. Wenn man so will: "High level" reverse engineering ... vermutlich aber nicht.

hustbaer

@wpi sagte in Windows Process Injection - Versuch:

@hustbaer sagte in Windows Process Injection - Versuch:

dann würde ich lieber versuchen mit einer Hooking Library ala Deviare die eine oder anderen WinAPI Funktion zu hooken

Meinst du die hier: https://github.com/nektra/Deviare2 ?

Das Wiki/der Quickstart ist gerade down: http://wiki.nektra.com/Quickstart_v.2.0

Ja, ich meinte Deviare2. Samples findest du im "Samples" Verzeichnis. Damit sollte man auch was anfangen können wenn das Quickstart-Guide gerade offline ist.

Ansonsten kannst du es auch mit Wayback Machine o.Ä. probieren. z.B. https://web.archive.org/web/20221126163355/http://whiteboard.nektra.com/deviare-v-2-0/quickstart_v-2-0

Oder du klonst dir das Repo, und guckst dann da nach: https://github.com/nektra/Deviare2/tree/master/Documentation/out/html

Ist jetzt echt alles keine Hexerei.

Ich bin immer Fan davon, wenn man etwas Konkretes meint, es dann auch konkret zu benennen ...

Was war dir daran jetzt nicht konkret genug? Weil ich Deviare statt Deviare2 geschrieben habe? Naja.

Tatsächlich habe ich auch nach Hooking Libraries/Tools gesucht. Aber leider bekomme ich von Google dazu noch keine verwertbaren Ergebnisse.

Dann googlest du nicht richtig. Hier, erster Hit für "Windows hooking libraries": https://www.apriorit.com/dev-blog/win-comparison-of-api-hooking-libraries

Da werden u.A. Deviare und Detours erwähnt, was nach meinem Wissensstand die beiden grössten sind. Aktuelle Links für Download, Doku bzw. Beispiele zu beiden sind wirklich nicht schwer zu finden. (Gut, bei Deviare2 musste ich etwas kreativ werden - aber das gehört halt auch dazu.)

@hustbaer sagte in Windows Process Injection - Versuch:

Das ist doch zur Umsetzung deines Vorhaben völlig wörscht wie das Scheduling genau funktioniert.

Du hast die Frage/Antwort/den Beitrag von @DocShoe aber schon genau gelesen, oder?

Oops, erwischt. Mein Fehler.

Es gibt gewisse OS-Algorithmen. Die sind "open source" und nicht geschützt, also für alle zugänglich. Es gibt aber auch die Implementierung/Technizität der Algorithmen im OS. Die sind proprietär, geschützt, nicht frei zugänglich, ggf. patentiert.

Die Frage war, ob man aus der Theorie (dem Abstrakten, den Algorithmen) ableiten hätte können, wie Microsoft bestimmte Dinge umgesetzt/implementiert hatte. Wenn man so will: "High level" reverse engineering ... vermutlich aber nicht.

Wie die konkrete Umsetzung genau aussieht vermutlich nicht - vor allem da da in letzter Zeit einiges optimiert und angepasst wurde, z.B. für hybrid/big.little CPUs.

wpi

@hustbaer Ich verschiebe das auf meiner To-Do erst einmal ganz nach hinten ... das ist ja nun erst mal nix Überlebenswichtiges. Zudem glaube ich ... dass man diese Thematik leicht in ihrem Umfang/Ausmaß unterschätzt.

Es wäre aber schön, wenn ich in 1/2 Jahren dieses Thema noch mal aufgreifen dürfte.

hustbaer

@wpi sagte in Windows Process Injection - Versuch:

Es wäre aber schön, wenn ich in 1/2 Jahren dieses Thema noch mal aufgreifen dürfte.

Sicherlich. Wobei du dann idealerweise einen neuen Thread machen solltest. Du kannst im neuen Thread ja dann diesen hier "for context" verlinken.

wpi

@hustbaer
Wieso neuer Thread? Darf ein TO den eigenen Thread nicht wiederbeleben? Das wäre mir neu ...