Shareable DLL

m*nuel

Hi,

ich habe eine DLL programmiert und diese soll von 2 Programmen geshared werden. Das eine Programm ist von mir und das andere Programm soll ein Spiel sein.

Das ganze soll so ablaufen:

Mein Programm (exe) bindet die lib von meiner DLL ein und die DLL selber soll sich bei dem Aufurf durch mein exe Programm wiederum an einen weiteren Prozess hängen. Jedoch klappt das nicht so ganz wie gewollt.

Der Zweck der DLL ist folgender: Die DLL soll eine API sein um Funktionen von einem bestimmten Spiel aufrufen zu können. Da nicht jeder so viel KnowHow über Memory Hacking hat, möchte ich das eben dadurch erleichtern.

Das heißt: Dritte schreiben ein Programm und binden meine API (DLL) ein und rufen dort bestimmte Funktionen auf. Die DLL selber soll aber erkennen wenn sie das erste mal aufgerufen wird und sich versuchen an den Prozess des Spiels selbst zu injecten. Die Injection funktioniert prima. Das habe ich bereits getestet indem ich einen Debug Mode in meine DLL eingebaut habe und nur die DLL an sich durch einen Injector in das Spiel injected habe. Das heißt, dass die DLL automatisch halt paar Tests und interne Funktionen ohne meine Kontrolle aufgerufen hat. Wie gesagt, das hat soweit funktioniert da die DLL an sich nicht durch ein weiteres Programm benötigt wird.

Wenn ich allerdings jetzt meine exe dazu hole und dort per #pragma once die lib einbinde und dann eine Funktion in der DLL aufrufe, dann versucht zwar die DLL sich an den Prozess zu attachen, was ihr auch gelingt ist aber total isoliert. Das heißt, das wenn ich einen Pointer auf eine bestimmte statische Adresse von dem Spiel setze und diese manipuliere, denkt meine DLL das ich nicht die Adresse vom Spiel meine sondern die von meiner exe. Die DLL (meine API) soll aber nur ein Wrapper sein.

Sprich: Ein Programm von einer Person ruft die DLL auf -> DLL attacht sich an den Prozess von einem Spiel -> DLL manipuliert den Speicher von dem Spiel

Ich denke das mein Vorhaben ohne auf ReadProcessMemory/WriteProcessMemory zurück zu greifen nicht wirklich funktioniert da die DLL nicht von zwei Prozessen gleichzeitig verwendet werden kann ohne das es zu Komplikationen kommt.

Warum ich mich weigere Read/WriteProcessMemory zu verwenden: Ich mache in der Funktion interne Function-Calls und mich nervt es wirklich immer RemoteThread's aufzumachen. Wenn ich einfach nur einen direkten Pointer auf die zu manipulierenden Adressen setze, geht das ganze viel einfacher.

Ich habe keinen Code dazu angehängt da die DLL in so vielen Dateien ausgelagert ist. Also die ganze Logik das es echt schwierig wird das hier zu beschreiben. Ich tat mich beim Beschreiben schon selbst schwer. Mir wäre es teilweise am liebsten (kann ich natürlich nicht verlangen aber sollte jemand doch Interesse haben mir auf diese Weise zu helfen wäre das nett) wenn jemand über TS 3 & TeamViewer sich das ganze von mir erklären lässt.

Wenn nicht, ist das natürlich vollkommen verständlich und ich bedenke mich im Vorraus schon für jede Hilfe!

Meine generelle Fragen zu meinem Problem wären jetzt:
- Kann mein Vorhaben so auf diese Art funktionieren?
- Muss ich irgendetwas wichtiges beachten wenn eine DLL von zwei Prozessen geshared werden soll?
- Gibt es evtl. andere effizientere Möglichkeiten?

PS: Wenn jemand noch weitere Informationen haben möchte, kann ich diese gerne liefern. Es war bloß gerade echt schwer mein Problem ohne Code zu beschreiben. Wenn wirklich der Code benötigt wird, werde ich mir überlegen wie ich am besten den Code paste.

DarkShadow44

Naja, Prozesse sind nunmal isoliert, d.h. ohne API kannst du auf Code/Daten eines anderen Prozesses zugreifen.
AFAIK ist es auch nicht möglich eine DLL zu haben die in zwei Prozessen gleichzeitig geladen ist. Das heißt, mit Tricks ist es möglich Daten zwischen zwei Prozessen zu teilen, aber wenn du dann versuchst eine Funktion auszuführen kommst du nicht über deinen Prozess hinaus.

Meiner Meinung nach hast du zwei Möglichkeiten:

Eine DLL machen die nicht an den Prozess angehängt ist, und dann mit ReadProcesMemory/WriteProcessMemory/CreateRemoteThread arbeiten
Eine DLL machen die sich an den Prozess anhängt und von einem anderen Programm geladen werden kann. Die zwei Instanzen kommunizieren dann mittels IPC (Interprocess Communications), wie z.B. Named Pipes

m*nuel

Sehr gut! Ja ich habe bevor ich diesen Post geschrieben habe überlegt ob ich Named Pipes brauche weil das jemand in einem Beispielprojekt verwendet hat ich aber nicht ganz wusste ob das das Problem ist.

Habe jetzt einen Ansatzpunkg gefunden, vielen Dank für Deine Hilfe!