Exe -> dll

C

ChiefWiggum

0
Hey,

weiß nicht ob das hier umbedingt der richtige Bereich ist aber ich versuchs einfach mal hier.
Ich habe ein Programm das enthält eine Unterfunktion, die eine Berechnung durchführt und dann fertig ist.
Nun möchte ich ein eigenes Programm haben, welches an das Resultat der Berechnung "rankommt", den Algo nachzucoden wäre viel zu aufwändig, weil er halt zu lang ist.
Nun gibt es für mich 2 Möglichkeiten:
1.) In der Berechnungs-Datei die entsprechenden Stellen so anpassen, dass ich dort meinen eigenen Code in Assembler hinzuprogrammiere (Mein Code soll eig nur die Berechnung nochmal etwas umrechnen und dann in die Registry einfügen)
ODER
2.) Ich exportiere die Funktion die ich benötige und mache aus der .exe eine .dll

Da mir der 2. Weg am besten gefällt, wollte ich mal fragen, ob es einfach so möglich ist, aus einer exe eine dll zu machen (Natürlich mit der Anpassung der entsprechenden Bits im Header) und was ich dann genau ändern müsste.
Was mir irgendwo im Kopf rumschwirrt ist, dass man einen Flag auf DLL setzen muss und eine Export-Section hinzufügen muss. Außerdem müsste ich wohl noch einen eigenen dllMain()-Code hinzufügen, der aber nichts machen muss.


MfG
 
Theoretisch kannst du die Exe auch so lassen und mit LoadLibrary laden. (Ja, das geht). Dann brauchst du nur noch den statischen Offset zu der genannten Funktion und addierst diesen auf das zurückgegebene Module-Handle. Fertig.
 
Danke für den ansatz, aber das wäre ja auch zu einfach gewesen.
Habs jetzt mal getestet, und direkt stimmen die DLL-Importe nicht.
Desweiteren sind die ganzen Offsets in der exe die geladen werden soll auf ein Imagebase von 0x00400000 gestellt, also müsste ich das ändern.

Nun ist mir jedoch eine weiter Methode eingefallen:
Was ist wenn ich die .exe mit einer einfachen LoadLibrary erweitere und damit eine .dll von mir lade, die dann entsprechend die Sprungbefehle einbaut?
Das müsste doch eigentlich auch gehen, oder?
 
Hmm. Ich habe jetzt nicht ganz verstanden, welches Problem da jetzt aufgetaucht ist.

ChiefWiggum hat gesagt.:
Habs jetzt mal getestet, und direkt stimmen die DLL-Importe nicht.
Zum Vergrößern anklicken....

Welche Dll-Importe stimmen nicht? Loadlibrary sollte alles korrekt auflösen, wie bei einer normalen Dll.
Woran machst du das fest, dass Imports nicht stimmen?

ChiefWiggum hat gesagt.:
Desweiteren sind die ganzen Offsets in der exe die geladen werden soll auf ein Imagebase von 0x00400000 gestellt, also müsste ich das ändern.
Zum Vergrößern anklicken....

Wenn du die Exe mit LoadLibrary lädst, klappt das? An welche Adresse wird die exe nun geladen?

Hat die exe reloc Informationen? Wenn nicht, dann kannst du die Imagebase nicht ändern.
Dann solltest du die Imagebase deines Hostprogrammes ändern. (Wenn dies das Problem sein sollte)

ChiefWiggum hat gesagt.:
Was ist wenn ich die .exe mit einer einfachen LoadLibrary erweitere und damit eine .dll von mir lade, die dann entsprechend die Sprungbefehle einbaut?
Das müsste doch eigentlich auch gehen, oder?
Zum Vergrößern anklicken....

Sicherlich. Allerdings wäre das eher "von hinten durch die Brust ins Auge".
 
Nein, die .exe hat keine Relocations.
Wie kann ich es denn erzwingen, dass die exe in 0x00400000 geladen wird?

(ich bin gerade an der "von hinten durch die Brust ins Auge"-Technik am werkeln^^)
 
ChiefWiggum hat gesagt.:
Nein, die .exe hat keine Relocations.
Wie kann ich es denn erzwingen, dass die exe in 0x00400000 geladen wird?
Zum Vergrößern anklicken....

Ähh. Ok ich bin verwirrt.
Du schreibst doch eine Exe, die die andere exe mit Loadlibrary lädt, richtig?
Welche Imagebase hat die? Standardmäßig ja auch 0x00400000. Ändere das mal in den Linkeroptionen, damit da "Platz" ist für die exe, die du nachlädst. Dann sollte an dieser Adresse auch der View der nachgeladenen exe angelegt werden.

ChiefWiggum hat gesagt.:
(ich bin gerade an der "von hinten durch die Brust ins Auge"-Technik am werkeln^^)
Zum Vergrößern anklicken....

Na, dann mal viel Spaß am tüfteln. :wink:
 
Achso okay^^ Versuch ich gleich mal.
Aber erst werd ich meinen jetzigen Ansatz vervollständigen.

Danke (=

EDIT:
So jetzt bin ich an dem besseren Ansatz dran.
Wie schaffe ich es, dass mein CodeBlocks Relocations hinzufügt bzw die ImageBase direkt anders setzt?
 
Zuletzt bearbeitet:
Ich bekomm das mit dem ImageBase-Verschieben nicht hin >.<
In Code::Blocks zusätzliche Linkersetting --base=20000 gemacht - Nichts passiert. Hat jemand eine Idee?

EDIT:
Habs in Linker-Options mit diesem hinbekommen:
-Wl,--image-base=0x00100000,--disable-auto-image-base

Jetzt ist die ImageBase zwar verschoben, die .exe wird jedoch nicht @ 0x00400000 geladen :(
Wie schaff ich das denn jetzt noch?
 
Zuletzt bearbeitet:
ChiefWiggum hat gesagt.:
Jetzt ist die ImageBase zwar verschoben, die .exe wird jedoch nicht @ 0x00400000 geladen :(
Wie schaff ich das denn jetzt noch?
Zum Vergrößern anklicken....

Dann sieht es tatsächlich so aus, als müsste sie das nicht.
SICHER, dass tatsächlich keine relocations vorhanden sind? (Relocations müssen nicht unbedingt eine eigene Section haben. -> In den Directories gucken)

Also. Probier es einfach mal aus. Hast du das relative (!) Offset zur Funktion?
Dann rechne dies auf die Base drauf an der die exe tatsächlich geladen wird.
 
Also, lordpe zeigt mir keine Relocations an, heißt das dass absolut keine vorhanden sind?
Und ich rufe ja @ Base + 0x1234 auf und es klappt nicht, da feste addressen gepusht werden.

Ich hab jetzt einen noch anderen ansatz genommen, nämlich das ich die PE manuell lade.
Also, loader.exe EP @ 0x00100000
Läd @ 0x00400000 die exe, fixt die Imports und ruft die Funktion auf.
Unter WinXP funktioniert das jedes mal, unter Win7 bekomme ich beim VirtualAlloc sporadisch ERROR_INVALID_PARAMETER und ERROR_INVALID_ADDRESS.
Ich versteh nur nicht wieso das quasi zufällig auftritt. Meine Parameter für VirtualAlloc sind statisch und daher kann es daran nicht wirklich liegen.

@Win7 sieht das dann teilweise etwa so aus:
Code: 
F:\EKG>earthLoader.exe
ModHandle: 0x00100000
This computer has page size 4096.
Reserving 32768[0x8000] Bytes
Loading into memory...
31129[0x7999] bytes read.
Fixing IAT...DONE!
Calling external function. GL!
Seems like were back. Check it out:
***Funktionsoutput - Funktioniert***


F:\EKG>earthLoader.exe
ModHandle: 0x00100000
This computer has page size 4096.
Reserving 32768[0x8000] Bytes
VirtualAlloc-Error: 87

F:\EKG>earthLoader.exe
ModHandle: 0x00100000
This computer has page size 4096.
Reserving 32768[0x8000] Bytes
VirtualAlloc-Error: 487

F:\EKG>
 
Zuletzt bearbeitet:
Es gibt tatsächlich keine Garantie dafür, dass du zu jedem Zeitpunkt die Memory Region reserviert bekommst. Vielleicht reserviert sich "irgendjemand" (Runtime-Lib?) die Adresse vorher. Also nicht gezielt, sondern kriegt zufällig diese Adresse zugeteilt.
Mach standardmäßig VirtualQuery auf die Adresse, schau den Status nach und RELEASE sonst vlt. mal auf gut Glück. :S Wobei das schon sehr destruktiv ist.
Bessere "Chancen" ergeben sich wohl, wenn du tatsächlich mal versuchst die Funktion als Export hinzuzufügen um diese dann statisch zu importieren. Dann wird die exe ziemlich früh vom PE Loader gemapped, bevor sich irgendetwas anderes die Adresse "schnappen" kann.
 
Hab jetzt die Datei die sonst in den Speicher geladen wird direkt als Section hinzugefügt.
Nach einem PE-Rebuild von LordPE hat windows die Datei dann auch akzeptiert und es läuft ohne Probleme... unter XP.
Win7 schmeißt mir einen Fehler raus und zwar bei __set_app_type. Der Speicherbereich an den gesprungen werden soll existiert nicht. Also muss es wohl wieder irgendwas mit ner fehlerhafen PE zu tun haben >.<
Aber wieso mag XP es und 7 nicht? (beides 32 bit)
Und wieso macht MinGW immer so einen komischen Funktions-Prolog? (http://666kb.com/i/bogu7iuxdxli1b459.png)

Ich verzweifel langsam an 7 :/
 
Hm was geändert hab ich nicht, also könnte das gut der Fall sein.
Ich verstehs nicht wieso macht Win7 da nur so einen Stress >.< Es könnte doch alles so einfach sein.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben