DLL aus Speicher laden?

dot

Hi schrieb:

Loader und Binary können verschlüsselt in der .exe abgelegt werden, nur benötigte codeteile entschlüsselt und ausgeführt werden usw... aber davon habt ihr scheinbar keinen Plan.

Das ist uns klar und hat absolut nichts mit dlls zu tun!?

Hi schrieb:

Man kann ein Programm, dessen source man nicht hat, eine .exe zB, um eigenen Code erweitern. DLL schreiben, Hooks einsetzen oder sonstwas, [...]

Ja, das wissen wir natürlich ebenfalls, was hat das mit der Fragestellung hier zu tun?

Hi schrieb:

[...] und diese DLL in die .exe einbinden. Beim start der .exe wird der eigene Code dann mitgeladen und ausgeführt.

Erklär einem interessierten Laien doch mal, wie genau du die dll in die exe packst, wie genau die dll dann "mitgeladen" wird und wie genau der Code aus dieser dll dann zur Ausführung kommt. Da bin ich jetzt mal echt gespannt

Hi schrieb:

So schwer zu verstehen?

Ja, der Zusammenhang zum Thema ist mir leider immer noch nicht klar, vermutlich bin ich einfach zu dumm und unwissend

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.