DLL aus Speicher laden?
-
Alles nur hergeleitetes Geschwafel.
-
Manuell ein ziemliches Gefrickel, darf man annehmen.
Vielleicht hilft dir das: http://www.enigmaprotector.com/en/aboutvb.html
-
Wenn man Google benutzt wird man sofort fündig... ich verstehe diese Diskussion um dieses Thema nicht.
Die Idee von DLLs wird damit verbogen und vernichtet.
Es gibt nicht einen "guten" Sinn hinter solcher Aktion...Just my 2 cents und für mich EOD.
-
Martin Richter schrieb:
Es gibt nicht einen "guten" Sinn hinter solcher Aktion...
DOCH GIBT ES .... omfg
-
Und der wäre z.B.?
-
Hi schrieb:
Martin Richter schrieb:
Es gibt nicht einen "guten" Sinn hinter solcher Aktion...
DOCH GIBT ES .... omfg
Na dann raus mit der Sprache. Ich bin gespannt...
-
Schutz vor Crackern. Obfuscation. Nichts externes, was man dann einfacher reversen kann.
Deppensicherer. Einfachere Updates. Klar, für kleine Programme.
Oder man kann so auch einfach ein Programm um eigenen Code erweitern, dessen source man nicht hat.
Viele Fälle gibts nicht, das stimmt wohl. Aber manchmal ist es genau das, was man braucht. Nur eine Datei.
-
Hi schrieb:
Schutz vor Crackern. Obfuscation. Nichts externes, was man dann einfacher reversen kann.
Du glaubst doch nicht im ernst dass die deine dll nicht finden!? Das würd wohl sogar ich schaffen, obwohl ich absolut 0 Erfahrung mit solchen Dingen hab...
Hi schrieb:
Deppensicherer.
Wenns deppensicher sein soll, dann macht man einen anständigen Installer.
Hi schrieb:
Einfachere Updates.
wtf?
Hi schrieb:
Oder man kann so auch einfach ein Programm um eigenen Code erweitern, dessen source man nicht hat.
Inwiefern?
Hi schrieb:
Aber manchmal ist es genau das, was man braucht. Nur eine Datei.
In diesen Fällen würd ich eher versuchen das Problem, nämlich die Tatsache dass ich zwei Dateien hab wo ich nur eine will, zu lösen anstatt zu derart starken Psychopharmaka zu greifen...
-
Ich hatte zwar schon EOD angekündigt aber es reitzt mich auf diesen Unsinn zu antworten:
Abgesehen von allen Argumenten die folgen.
Die Idee einer DLL, Speicher zu sparen, Pflege einfach zu machen, Code wiederzuverwenden. wird durch solch ein Verfahren konterkariert.
Dann benötige ich keine DLL sondern nur ein Stück statische Lib.
BTW: Als Hook Codebasis wäre solch eine eingebette DLL auch nich geeignet!
Also warum dann überhaupt eine DLL wenn der Code sowieso nur in dieser Exe drin ist und in dieser genutzt werden kann?Hi schrieb:
Schutz vor Crackern. Obfuscation. Nichts externes, was man dann einfacher reversen kann.
Quatsch. Irgendwann ist das Ding im Speicherund für jeden Debugger sichtbar!
Schutzmeachinsmen erschließen sich meistens dem "Reverse Engineer" erst beim aktiven Debuggen. Eine DLL alleine oder der sichtbare Code nützt selten.Hi schrieb:
Deppensicherer. Einfachere Updates. Klar, für kleine Programme.
Quatsch. Da man mittlerweile sowieso Admin Rechte benötigt um in die Programmverzeichnisse zu installieren kommt man um den Installer nicht drum herum.
Und selbst wenn. COPY und PASTE einer Dateigruppe geht auch.Hi schrieb:
Oder man kann so auch einfach ein Programm um eigenen Code erweitern, dessen source man nicht hat.
Wie das? Wie kann man damit was verändern?
Hi schrieb:
Viele Fälle gibts nicht, das stimmt wohl. Aber manchmal ist es genau das, was man braucht. Nur eine Datei.
Keiner der hier genannten Gründe ist ein Grund! Alles nur leere Argmente.
Bleiben also nur "Bösartigkeit" um "Minderwissende" reinzulegen. Oder Bösartigekeit zu verschleiern.
Oder es bleibt die Illegalität, DLLs zu benutzen an der man keine Rechte hat, dies aber verschleiern möchte...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...".
-
Hab grad nicht viel Zeit, schreibe vllt später noch mehr:
Es erhöht den Aufwand des crackens, und das zählt! 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.
Man kann ein Programm, dessen source man nicht hat, eine .exe zB, um eigenen Code erweitern. DLL schreiben, Hooks einsetzen oder sonstwas, und diese DLL in die .exe einbinden. Beim start der .exe wird der eigene Code dann mitgeladen und ausgeführt.
So schwer zu verstehen?
-
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
-
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.
-
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.
-
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.
-
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
-
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.