[FRAGE] .dll Converter

[MrSm!th]

Originally Posted by ToxicLibrary™

Also ist der Witz an den DLLs das sie effizienter sind?

Nein.
Dlls sind einfach Dlls. Sie enthalten ausführbaren Code, der nicht eigenständig ausgeführt werden kann, sondern nur, wenn sie von einem Prozess geladen werden.
Das ermöglicht es, große Programme wie Spiele in viele kleine Teile aufzuspalten und gewisse Funktionen nur zu laden, wenn sie auch gebraucht werden.
Eine Dll ist eine Möglichkeit, Code wiederzuverwerten oder einfach ein bestehenden Code in sogenannte Module aufzuteilen.
Es ist also eine Codebibliothek (Dynamic Linked Library), eine .exe gewissermaßen auch, allerdings kann sie auch eigenständig ausgeführt werden und ihr einziger Zweck ist nicht, anderen Programmen Code bereitzustellen.


Dieser Post mit dem Keylogger da hat eigentlich nichts mit dem zutun, was ich vorher geschrieben habe.
Er hat nur etwas gesagt, was so ziemlich jeder wissen sollte:

Ob Dll oder Exe, wer infizierten Code ausführt, bekommt probleme.
Ob er nen Doppelklick auf ne Exe macht oder sich sogar die Arbeit macht, ne Dll in nen Prozess zu injizieren ist doch egal, Virus bleibt Virus und er ist in jeder Form gleichgefährlich, wenn der User nicht weiß, dass es einer ist.

Das heißt ich kann´s vergessen auf eine .dll Datei zuzugreifen weil sie total verschlüsselt sind ? Hab ich das richtig verstanden ?
Dümmstes Beispiel:

Ein hack für ein Spiel (z.b. Combat arms) .
Eine Dll datei die ich mit einem Injektor sprich PerX öffne kann ich nicht mehr umbauen ?

Du öffnest sie mit PerX nicht, du injizierst sie lediglich in einen Prozess, der sie dann ausführt.
Genau so wenig kannst du eine Exe einfach so "umbauen".
Es sind eben binäre Dateien, Dateien die Code enthalten, Code in Form von Maschinensprache.
Den kannst du nicht einfach so bearbeiten wie eine Textdatei.
Du musst entweder den Source Code haben und ihn umschreiben oder die Dll/Exe mit einem Debugger patchen, allerdings musst du dafür ASM können und es ist deutlich komplizierter, da du alles auf der untersten Softwareebene siehst und verstehen musst, um etwas zu ändern.

Sprich ja, für einen Laien wie dich ist es unmöglich, eine Dll, die du heruntergeladen hast, zu bearbeiten.

[Deda94]

Also hab ich das jetzt richtig verstanden:


DLL:

-Kann nicht eigenständig ausgeführt werden

-Man kann bestimmte Funktionen abrufen

-usw....


EXE:

-Zeigt Code an/Stellt Code bereit


Also ist sozusagen eine DLL wie mehrere EXE'n.... Besser halt.

Edit:

Originally Posted by Mamon110

Leute wie kommen vom Thema ab =)

Das heißt ich kann´s vergessen auf eine .dll Datei zuzugreifen weil sie total verschlüsselt sind ? Hab ich das richtig verstanden ?
Dümmstes Beispiel:

Ein hack für ein Spiel (z.b. Combat arms) .
Eine Dll datei die ich mit einem Injektor sprich PerX öffne kann ich nicht mehr umbauen ?

Sobald die .dll Injiziert ist kannst du sie nicht mehr "Umbauen".

Sobald die DLL Kompiliert wurde, sprich in die Computersprache "Übersetzt" wurde, müsstest du die 0&1 Sprache perfekt beherschen um da noch was zu drehn xD

...Korrigiert mich wenn ich falsch liege

[MrSm!th]

Originally Posted by ToxicLibrary™

Also hab ich das jetzt richtig verstanden:


DLL:

-Kann nicht eigenständig ausgeführt werden

-Man kann bestimmte Funktionen abrufen

-usw....


EXE:

-Zeigt Code an/Stellt Code bereit


Also ist sozusagen eine DLL wie mehrere EXE'n.... Besser halt.

Nein lol, wo hab ich das geschrieben?
Eine Dll ist nicht besser, sie ist etwas völlig anderes, was ist daran so schwer zu verstehen?

Eine Exe ist dafür gedacht, ein ausführbares Programm zu sein, während eine Dll nur als Codebibliothek für Programme gedacht ist, da es unklug ist, den gesamten Code in einer Datei zu haben.

Weder ist eine Dll besser noch eine Exe, sie haben unterschiedliche Anwendungsgebiete.
Eine Dll wird auch gerne mal für Hacks benutzt, da sie ein sehr einfacher Weg ist, seinen eigenen Code in ein anderes Programm zu bekommen, aber prinzipiell sind Dlls Bibliotheken und Exe Dateien Programme.
Beide enthalten Code und dieser kann auch ganz normal ausgeführt werden (eine Dll müsste erst von einem Programm geladen werden, aber prinzipiell ist sie auch eine Datei mit ausführbarem Code, weshalb ein Converter sogar möglich wäre), nur ist eine Dll hauptsächlich dafür da, ihren Code anderen Programmen bereitzustellen und eine Exe ist das Programm selbst, es enthält also den Code nur für sich selbst.

Nix besser.

[I]Sobald die .dll Injiziert ist kannst du sie nicht mehr "Umbauen".

Das ist schonmal ganz großer Mumpiz, Injektionen haben damit nichts zutun.
Unter einer Injektion versteht man, dass man einen Prozess zwingt, die gewollte Dll zu laden, beispielsweise um schädlichen Code auszuführen oder für Hacks, ...

Sobald die DLL Kompiliert wurde, sprich in die Computersprache "Übersetzt" wurde, müsstest du die 0&1 Sprache perfekt beherschen um da noch was zu drehn xD

Ist soweit richtig, aber das ganze nennt sich Maschinensprache und diese ist für Menschen lesbar in Form von ASM.
Du musst also nicht die 1en und 0en verstehen, sondern kannst mithilfe eines Disassemblers den Code in Form von Assembler ansehen, eine recht hardwarenahe Sprache (eben Maschinensprache), die auf die ganzen abstrakten Konstrukte aus höheren Sprachen verzichtet, weshalb sie deutlich schwerer zu verstehen und noch schwerer zu bearbeiten ist.

[Mamon110]

Humm.. Krass..
Also wie ich verstehe, ASM auf 99% können und dann könnte ich eine .dll auch "lesen".
Hab schonmal soweit verstanden.

Aber kleine nebenfrage: Wie ist einem Gelungen diese Maschinensprache in "Programmiersprache" umzuwandeln ? Ich meine 0&1en kann jah sogesehen niemand lesen außer des PC´s (oder allgemein was damit arbeitet) . Da muss man doch jemand haben der das alles auch so lesen kann oder ?

/Edit
Außerdem habe ich noch zwei Fragen.
Könnt ihr mir vllt bitte (da wir eh schon dabei sind) die drei unterschiede erklären ?
- .NET Dlls
- native Dlls
- native exe

Was bedeutet dekompilieren ?

[MrSm!th]

Das hat nichts mit Dlls zutun <.<
Sondern mit allen nativen Programmen, ob Dll, .exe, .sys, .com oder was es sonst noch für Programmendungen gibt.

Und nur weil du ASM kannst, kannst du nicht gleich ein Programm verstehen, da du dann nur die Syntax kannst. Logische Zusammenhänge erkennt man durch Erfahrung im Reverse Engineering, dass man zb. gewisse Blöcke als "if Block" in einer Hochsprache identifizieren kann usw.
Und dadurch versteht man dann den Code, den man vor sich hat. Nicht durch das simple Können der ASM Syntax.

Eine Hochsprache wird durch den Compiler in die 0en und 1en übersetzt.
Dieser macht das nach festgelegten Regeln, zb. eine Addition, die du in den meisten Hochsprachen durch ein + ausdrücken würdest würde in den ASM Befehl add übersetzt.
Dieser hat einen festen Wert, den sogenannten Opcode.
Und der wird mit Informationen über die Operanden dann in die Datei geschrieben, sodass die Addition beim Ausführen des Programms durchgeführt werden kann.
Dabei liest der Prozessor den Opcode ein, erkennt, was er dann machen muss und tut es.

So kann man es stark vereinfach sagen.


Den Unterschied zwischen nativen Dlls und nativen Exe Dateien werde ich nun nicht nochmal erklären, ganz ernsthaft, lernt lesen, ich habs nun schon mehrmals geschrieben.

Der Unterschied zwischen .NET Dlls/Exe Dateien und nativen Ausführbaren Dateien ist der, dass .NET Dateien auf einer Virtuellen Maschine, der .NET Umgebung ausgeführt werden.
Das ist eine Art virtueller PC auf dem ein spezieller Byte-Code (diese Opcodes würde der Prozessor nicht verstehen, nur der virtuelle Prozessor von .NET versteht sie, weil er sie einprogrammiert bekommen hat) ausgeführt wird und ist eine Art Laufzeitcompiler.
Das heißt, der Code, den man zb. in VB.NET geschrieben hat, wird in eine Byte-Code übersetzt, der zur Laufzeit vom .NET Prozessor interpretiert und auf dem echten ausgeführt wird.
Das verringert natürlich die Geschwindigkeit, erhöht aber die Sicherheit und kapselt die Software von der Hardware ab, sodass ein .NET Programm auf jedem PC läuft, der das .NET Framework installiert hat.
Deshalb sind .NET Sprache heutzutage relativ beliebt bei Unternehmen.

Dekompilieren ist das Rückgängigmachen des Kompiliervorgangs, also die Rückgewinnung des Quellcodes.
Das ist bei nativen Sprachen praktisch unmöglich, da sehr viele Informationen beim Kompilieren verloren gehen. Bei .NET und Java siehts anders aus, da werden noch genug Informationen in der ausführbaren Datei gespeichert, sodass man daraus den Quellcode zurückgewinnen kann.

Allerdings würde dir das auch nichts bringen, deine Fragen lassen vermuten, dass du nicht programmieren kannst, du könntest also damit eh nichts anfangen, weshalb auch ein Decompiler für native Dlls dich nicht wirklich weiterbringen würde, weshalb ich nicht verstehe, wieso du danach fragst.

[Mamon110]

Du hast jah recht was mein wissen in Programmieren angeht, aber ich bin dabei es mir selber beizubringen..
Deshalb versuche ich einfach schonmal das aufzufangen, und da fragen zu stellen wo ich möglichst immer eine Antwort bekomme. Hier halt.
Und das speichere ich mir auch alles ein, wenn ich dann mal so weit bin, damit ich nicht noch ein Thread eröffnen muss, sondern schon alles habe
Dir ein Großes Danke. Und ein Thx für jeden deiner Antworten

Kanns es jetzt eigentlich schließen außer andere User haben noch fragen.

[-AmA-]

*** ich hab noch eine...
Funktionen von gecrypteten Dlls müsste man auch aufrufen können, solange man den Namen und die Parameter kennt. Ist das richtig?

[MrSm!th]

nein, deshalb sind sie ja verschlüsselt.
du müsstest sie erst entschlüsseln.

Originally Posted by Mamon110

Du hast jah recht was mein wissen in Programmieren angeht, aber ich bin dabei es mir selber beizubringen..
Deshalb versuche ich einfach schonmal das aufzufangen, und da fragen zu stellen wo ich möglichst immer eine Antwort bekomme. Hier halt.
Und das speichere ich mir auch alles ein, wenn ich dann mal so weit bin, damit ich nicht noch ein Thread eröffnen muss, sondern schon alles habe
Dir ein Großes Danke. Und ein Thx für jeden deiner Antworten

Kanns es jetzt eigentlich schließen außer andere User haben noch fragen.

was hat das nun mit decompilen zutun? wenn jemand dir seinen source code nicht geben möchte, solltest du das akzeptieren.

[5769854332]

Originally Posted by -AmA-

*** ich hab noch eine...
Funktionen von gecrypteten Dlls müsste man auch aufrufen können, solange man den Namen und die Parameter kennt. Ist das richtig?

Wenn die Funktion im Export Table (im Header) der Dll aufgelistet ist, kann man sie aufrufen, z.B. mit GetModuleHandle + GetProcAddress.

(LordPE -> Directories -> ExportTable [...] )

Wenn die Funktion noch nicht decryptet wurde, bringt es wenig/nix, die aufzurufen.

[MrSm!th]

Wenn eine Dll verschlüsselt ist, ist meist auch die ExportTable verschlüsselt/zerstört.

[5769854332]

Originally Posted by MrSm!th

Wenn eine Dll verschlüsselt ist, ist meist auch die ExportTable verschlüsselt/zerstört.

Das geht natürlich.

Das Hackshield von Ahnlab in 4Story macht es soweit ich weiß nicht:

1) LoadLibrary (...)
2) Die DllMain startet das Hackshield, und entschlüsselt (wenn keine Hacks/Debugger detected werden) die exportierten Funktionen.
3)ret -> TClient.exe, if eax==0 jmp badboy
4) 4Story sucht im export (address?) table der dll die Adressen der Funktionen
6) als erstes wird die Funktion mit dem Namen/Ordinal "10" aufgerufen
7) Je nachdem, ob das Hackshield einen Debugger gefunden hat, läuft die Funktion einwandfrei, oder crashed, da sie noch nicht entschlüsselt wurde (siehe 2.)

Um an den Code der Funktionen ranzukommen, könnte man mit einem Program, das nicht detected wird einen Dump erstellen, sich die return values raussuchen und eine fake dll nachbauen.

[-AmA-]

Also könnte man eigentlich auch die Routinen in der Anwendung ausfindig machen und selber die dll entschlüsseln...

Noch ne frage zum Hackshield von 4Story...
Wenn schon vorher nach einem Debugger etc. gesucht wird, was befindet sich den in diesen Funktionen?
Ist mir irgendwie unlogisch das da zuerst überprüft wird und danach noch zusätzliche Sachen geladen wird....

[MrSm!th]

Originally Posted by -AmA-

Also könnte man eigentlich auch die Routinen in der Anwendung ausfindig machen und selber die dll entschlüsseln...

Noch ne frage zum Hackshield von 4Story...
Wenn schon vorher nach einem Debugger etc. gesucht wird, was befindet sich den in diesen Funktionen?
Ist mir irgendwie unlogisch das da zuerst überprüft wird und danach noch zusätzliche Sachen geladen wird....

Mit verschlüsselt meinten wir gepackt und genau, entpack mal schnell Themida, macht man ja in 5 Minuten
Und doch, Hackshields ExportTable ist zerstört oder schonmal Funktionen gesehen, die Ordinal 10 heißen?
Sie wollen nicht, dass außenstehende sehen können, welche Funktion wie heißt.

Und die Funktionen sind nicht einzelnd verschlüsselt, das ganze Ding ist gepackt.


Und nun bitte ontopic bleiben, hier gehts nicht um den HS von 4Story

[Mamon110]

Originally Posted by MrSm!th

was hat das nun mit decompilen zutun? wenn jemand dir seinen source code nicht geben möchte, solltest du das akzeptieren.

Wie gesagt ich kenn mich da nicht aus, aber das hat mich halt interessiert und darum habe ich nachgefragt =)