DLL aus Speicher laden?

hustbaer

Martin Richter schrieb:

Also warum dann überhaupt eine DLL wenn der Code sowieso nur in dieser Exe drin ist und in dieser genutzt werden kann?

Naja, es gibt ja durchaus DLLs wo mal keine LIB-Alternative hat, und auch keinen Source, aus dem man sich die LIB selbst bauen könnte.

Wenn man also ne "Single-File-Applikation" haben will, dann ist das schon ein Grund.

Bleibt noch die Frage wann/ob-jemals es wichtig ist, dass ein Programm nur aus einer einzigen .exe besteht.

So richtig guter Grund dafür fällt mir jetzt auch keiner ein.

Wobei... "Deppensicher" ist u.U. schon ein Argument. Es gibt ja etliche DLLs die vielleicht irgendwo im Suchpfad vorhanden sein könnten.
Wenn dann jmd. nur die .exe kopiert, ohne die DLLs im selben Verzeichnis, weil er meint das reicht...
Wenn die Applikation dann noch startet, weil die DLL irgendwo anders gefunden wird, dann läuft die Applikation ggf. gegen eine ältere/neuere Version der DLL... alles nicht gut.

Ist natürlich nur ein Problem bei "portable" Applikationen. Ich mag aber portable Applikationen, finde das praktisch. Gerade bei Dingen die man nicht jeden Tag braucht, und u.U. überhaupt bloss ein einziges mal.

Ethon

http://code.google.com/p/hadesmem/

Siehe "ManualMap".

Aber auch wird der Anonyme Nutzer (komisch, dass solche Anfragen immer anonym sind), wieder die große Hackerfreiheit postulieren und sagen "er wüsste schon warum dies sinnvoll ist, dass muß er uns aber nicht sagen...".

Wegen Leuten wie dir bleibt einem ja nichts anderes übrig, als anonym zu posten

Trotzdem danke für die Ausführungen.

Und nein, ich habe nichts illegales damit vor.
Wie gesagt, der Großteil ist eigenes Interesse, wie das alles so überhaupt funktioniert. Der andere Grund ist, dass ich -- OH NEIN ICH BIN ULTRA BÖZE -- einen Cheat schreiben möchte, der bitte nicht erkannt werden soll.

Und nun: schönen Abend noch.

Ethon

Nooze schrieb:

Der andere Grund ist, dass ich -- OH NEIN ICH BIN ULTRA BÖZE -- einen Cheat schreiben möchte, der bitte nicht erkannt werden soll.

Nachmal ein fetter Grund HadesMem zu verwenden.

hustbaer

Nooze schrieb:

Der andere Grund ist, dass ich -- OH NEIN ICH BIN ULTRA BÖZE -- einen Cheat schreiben möchte, der bitte nicht erkannt werden soll.

Und inwiefern hat das mit deiner Frage zu tun?

Das hat indem was damit zu tun, dass verschiedene AntiCheat-Systeme LoadLibrary Hooken. Und wenn eine "ExtremeHookMegaAimBotSkillerDurr.dll" geladen wird, wird man gebannt, was bei ManualMapping halt nicht der Fall ist

hustbaer

Dann hast du deine Frage falsch gestellt.
Was du willst ist doch lediglich Code in einen Fremden Prozess zu bringen (und dann dort auszuführen).
Dann mach das halt.
Ich sehe aber keinen Grund für die Anforderung dass dieser Code als DLL vorliegen muss. Und selbst wenn du es über ne DLL machst, muss dein Code nicht mit beliebigen DLLs klarkommen. Was die Sache enorm vereinfacht.

Aber es ist doch viel einfacher, eine DLL in einen externen Prozess zu bringen und die Relocs und Imports aufzulösen, als all den Kram selber zu berechnen.

Oder nicht?

Zum Imports auflösen müssten diese Imports ja auch wieder im RAM vorliegen und von dort geleaden werden (ergo von Dir manuell), wenn Du Allgemein das DLL laden von der Festplatte vermeiden willst.

hustbaer

Morle schrieb:

Zum Imports auflösen müssten diese Imports ja auch wieder im RAM vorliegen und von dort geleaden werden (ergo von Dir manuell), wenn Du Allgemein das DLL laden von der Festplatte vermeiden willst.

Er kann ja die DLL die er "aus dem Speicher laden" will selbst schreiben.
D.h. er kann sich auf Funktionen beschränken, die aus DLLs stammen, die sowieso schon in den Zielprozess geladen werden.

Das Module-Handle kann er sich dann einfach mit GetModuleHandle[Ex]() holen. LoadLibrary wird dann nicht mehr gebraucht.

Bzw. selbst wenn er weitere DLLs braucht, stehen die Chancen vermutlich auch nicht ganz schlecht, dass er diese nachladen kann. WENN es sich dabei um original Windows DLLs handelt.

Alles andere kann/muss er dann halt statisch in seine DLL reinlinken.