C/C++ Speicherinhalt direkt ausführen

Hallo Byteblaster,

sicher ist da ein Prozess, aber der ist gewissermassen ja statisch (s. vorangegangene Diskussion). Einen Thread zu erzeugen macht doch nur Sinn, wenn nebenher der gewünschte (dynamische) Hauptprozess läuft (z.B. eine Progressbar als Thread beim Ftp-Upload). Da die exe im Speicher so nicht startet, kann ich auch keinen Thread erzeugen, denke ich jedenfalls...

Wenn du eine Idee hast, lass mal hören.

Wie gesagt, (LPCVOID) lpViewBuffer ist der Rückgabewert der Funktion
und ein Zeiger auf den Beginn des Mappings:

lpViewBuffer = MapViewOfFile(hMapFile,
dwDesiredAccess,
dwFileOffsetHigh,
dwFileOffsetLow,
dwNumberOfBytesToMap);

Gruss
Jürgen
 
Hm, ein zweiter Thread wäre sicher sinnvoll, wenn man noch was nebenbei mit dem Programm machen will, bringt aber primär nix, weil er den selben Speicherbereich nutzt wie der Hauptthread.
Also was das Assemblerzeug angeht, brauchst du keinen Extraassembler, da reicht der Inline Assembler von C (1985?! da war ich 1 Jahr alt! :)):

Code: 
__asm
{
   mov eax, blah blah blah
    ....
}

Bei deinem eigentlichen Problem kann ich dir aber auch nicht weiterhelfen, weil meine Assemblerkünste relativ eingeschränkt sind und ich ganz davon abgesehen keine Ahnung über die innere Architektur einer exe habe (also jedenfalls nicht mehr als die absoluten Basics). Wenn du das wirklich durchziehen willst, dann ließ dir mal zuerst auf http://www.myfileformats.com durch, wie eine exe genau funktioniert und wie du den Schlamassel mit den Adressen beheben kannst. Der C-Block zum reinspringen wäre dann

Code: 
__asm
{
   mov eax, eintrittexe
   call eax
}

(zumindest so ähnlich)

eintrittexe wäre dann die Adresse des ersten Befehls in der exe.
Was das FileMapping angeht, naja ist prinzipiell egal ob du das so machst, oder ob du die exe einfach per Standardvorgehen in den Speicher einliest, wenn das FileMapping sowieso keine Funktionen für deine Absichten bereitstellt.
Mal ganz davon abgesehen ist es definitiv möglich! Man brauch sich nur diverse Disassembler anzuschauen, die es einem ermöglichen Quellcode zu ändern und auszuführen oder überhaupt Windows als Betriebssystem, dass den Programmen ja erstmal den ganzen Speicherkram vorgaukelt.

Was die andere Hardware angeht, also Router, Handys, ... da beißt sich die Katze in den Schwanz. Der Computer führt schließlich auch Programme aus, warum sollen die Dinger das nicht auch machen, halt alle auf ihre Weise. Nur Speicher ist das sicher nicht, ne Art Prozessor wird da schon werkeln und der interpretiert dann den Speicherinhalt vor sich hin.
 
Vielen Dank für eure Hilfe, aber ich krieg es einfach nicht hin.
Bekomme, egal was ich drehe, beim asm Aufruf einen Runtimeerror:
(...verweist auf Speicher in...)

Vielleicht liegt es an der Struktur der flash.exe, keine Ahnung.
Mache für heute erstmal Pause damit, drehe mich nur im Kreis.
Sollte ich es noch rausfinden, schreibe ich es hier rein.


Gruss Jürgen
 
Hi
auch auf die Gefahr als total verblödet zu gelten hier noch eine Frage: Wenn du die Funktion über einen Funktionspointer aufrufen würdest läuft sie ja auch in deinem "statischen" Prozess. Wenn du jetzt einen Thread erzeugst läuft er eben auch im gleichen Prozess, dein bisheriger Thread macht dann halt nix weiter als auf das Ende von Thread 2 zu warten und dann den Prozess zu terminieren Welcher Thread die Hauptarbeit leistet ist doch egal (Oder ist das in Windows anders?). Hier vielleicht noch eine andere Idee: Nicht die Exedatei laden, würde wahrscheinlich eh zu kompliziert aufgrund der Stuktur der Exedatei und den Sprungtabellen, sondern ein Image der Im Speicher befindlichen Exe erzeugen und dieses Image laden und aufrufen (ähnlich den *.com Dateien unter DOS). Bisher habe ich halt nur kleine Funktionen aufgerufen die ich vorher im Speicher (mangels Assembler :( für das embeddet System) binär erzeugt habe, aber keine Exefiles.

Gruß Byteblaster
 
Hallo Byteblaster,

ich habe diverse Varianten ausprobiert, und es kommt nicht dabei heraus.
Entweder passiert gar nichts, oder es kommt ein Runtimeerror.

Mit dem asm call ist man schon am dichtesten dran, aber das Problem scheint anders gelagert zu sein.

Probier es doch einfach mal aus:
Lese eine kleine exe in einen String ein (iostream::binary), und versuche das in einen Speicherbereich zu bringen, in dem du dies ausführen kannst.

Oder über CreateFile(), CreateFileMapping(), ViewMapOfFile() direkt in den Speicher (dies ist so eine Art Image von der Datei).

Problem ist doch, das es nichts bringt, einfach den Zeicher auf die Startadresse des Blocks zu setzen, denn woher soll der Prozessor wissen, was ich mit dem Code machen will?
Zunächst mal verweist nur der Zeiger dorthin, und die o.g. Methoden verwendet man ja allgemein, um dann n Bytes zu lesen, kopieren, schreiben, usw, aber nicht zum ausführen.

Ausführen heisst ja, assemblieren, und so "kennzeichnen", das es sich um ausführbaren Maschinencode handelt, der jetzt gestartet werden soll, und zwar bei der ersten ausführbahren Anweisung.

Isnn't it ?

Gruss
Jürgen
 
Das mit dem Ausführen ist nicht so einfach. Die EXE ist ja nicht nur Code, sondern auch Header und Sprungtabellen (siehe PE-Aufbau). Irgendwo ist da drin glaube ich auch eine Einsprungadresse. Evtl. müssen auch eine ganze Menge Zeiger angepasst werden, da der Code ja auch nicht immer an die selbe Adresse gelegt wird.
 
Ich meinte ja auch nicht ein Image von der Datei, da der Code durch die Spruntabellen, wie auch schon andere ausgeführt haben angepasst werden muss, sondern ein Speicherimage der Exedatei, wenn sie, wenn sie geladen und die entsprechenden Sprünge angepasst wurden im Speicher liegt. Also so wie sie ausführbar nach dem Laden durch das Betriebssystem im Speicher liegt, wenn im Prozessor der EIP auf den ersten ausführbaren Befehl der Exe gesetzt wird. Und dann könnte es ja auch funktionieren wenn man den EIP auf den ersten ausführbaren Befehl setzt. (Natürlich muss dieses Image erstmal erstellt und in eine Datei gespeichert werden und ist dann keine Exedatei mehr und ich hoffe dafür gibt es auch Tools.) Ich denke mal die Exedatei selber anzupassen, wird ein etwas größerer Akt, ist aber nicht unmöglich, das Betriebsystem bzw. die API-Funktionen des Betriebssystems tuen es ja auch. Vielleicht kann die ja jemand sagen wie das bei Windows genau funktioniert bzw, wie die Exedateien genau aufgebaut sind.

Gruß Byteblaster
 
Ja, die Frage müsste dann also heissen:

Wie finde ich mit Mitteln der Programmiersprache C/C++ oder inline asm die Startadresse der ersten ausführbahren Anweisung einer (unbekannten) exe Datei?

Und zweitens: Reicht das aus, läuft das Programm dann weiter?

Also muss die exe voher analysiert werden. Das ganze muss auch ziemlich schnell gehen, da der Anwender nicht merken soll, was im Hintergrund abläuft.

Gruss
Jürgen
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück