Windows Process Injection - Versuch

[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 ...

[hustbaer]

@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

[wpi]

@hustbaer sagte in Windows Process Injection - Versuch:

Ich bin aber kein Moderator hier. Von mir aus kannst du machen was du willst

Klang in dem anderen Thema aber noch ganz anders ... aber ok.