Windows Process Injection - Versuch
-
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?
-
Welche Vorkenntnisse hast du denn? Beherrschst du (zumindest die Grundlagen) von C oder C++?
-
@DocShoe sagte in Windows Process Injection - Versuch:
Beherrschst du (zumindest die Grundlagen) von C oder C++?
ja
-
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.
-
Hierfür braucht man keine direkte "Process Injection", sondern es reicht ein "Windows Hook": Verwenden von Hooks, d.h. mittels
WH_KEYBOARDfängt man die Nachricht ab und ändert sie (bzw. verwirft sie und sendet die passendeWM_CHARNachricht).
-
@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
OpenProcessaufrufen kannst. Dabei kannst du dich an derCrawlProcessFunktion 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
CrawlProcessFunktion zu integrieren und abzuwandeln. Dann als nächstesOpenProcessaufrufen damit du ein Process Handle bekommst.Und dann wird's interessant. Im Prinzip musst du eine Funktion in den Ziel-Prozess kopieren, die
LoadLibraryaufruft. 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.
-
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_KEYBOARDfängt man die Nachricht ab und ändert sie (bzw. verwirft sie und sendet die passendeWM_CHARNachricht).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.
-
@hustbaer
Du kannst doch den Speicher im Remote Prozess allokieren und befüllen. Damit kannst du den Parameter fürLoadLibrarybestimmen und den Rest in derDllMainerledigen. 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 perGetLastError()schnell raus, woran's hakt.
-
@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?)?
-
@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.
-
@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.
-
@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.
-
@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ürLoadLibrarybestimmen und den Rest in derDllMainerledigen. Hier findet man ein Beispiel dafür.Er. Ja
Man kann auch direkt LoadLibraryA/LoadLibraryWals Thread-Function angeben. Funktioniert, weilLoadLibraryvon der Signature her "ausreichend kompatibel" mitLPTHREAD_START_ROUTINEist. 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
LoadLibraryim Zielprozess.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@hustbaer
Wieso neuer Thread? Darf ein TO den eigenen Thread nicht wiederbeleben? Das wäre mir neu ...
-
@wpi
Es ist verwirrend und daher i.A. nicht gern gesehen.
Ich bin aber kein Moderator hier. Von mir aus kannst du machen was du willst
