Programm im Speicher erzeugen und ausführen



  • Meine Anwendung empfängt Daten über eine Serielle Schnittstelle. Bei den Daten handelt es sich um ein ausführbares Programm (EXE).

    Dieses soll nun ohne auf die Festplatte geschrieben werden ausgeführt werden. Welcher Aufruf/Befehl ermöglicht dies?



  • Das geht nicht! Du must die Exe auf die Festplatte schreiben und dann ausführen.



  • Das Programme aus dem Speicher heraus aufgerufen werden können muss gehen!

    Beispiel: Auf der Arbeit hab ich so nen netten Fall, da ist die Exe verschlüsslet auf der Platte, ein Dongel entschlüsselt sie und das Ladeprogramm führt es aus. Speziell in diesem Fall währe es sehr sehr unschön wenn die entschlüsslte exe auf der Festplatte rumliegt...

    Aber wie geht das?



  • ^^geht bestimmt, aber ist wohl nicht einfach. vielleicht hilft das: http://windows-internal.net/MS.Press-Microsoft.Windows.Int/0735619174/ch06lev1sec2.html
    🙂



  • AntonWert schrieb:

    Das Programme aus dem Speicher heraus aufgerufen werden können muss gehen!

    Beispiel: Auf der Arbeit hab ich so nen netten Fall, da ist die Exe verschlüsslet auf der Platte, ein Dongel entschlüsselt sie und das Ladeprogramm führt es aus. Speziell in diesem Fall währe es sehr sehr unschön wenn die entschlüsslte exe auf der Festplatte rumliegt...

    Aber wie geht das?

    Ich meine, es gäbe da einen fiesen Hack, mit dem sowas geht. Aber der ist total abgefuckt und irgendwie nicht gut.

    Außerdem: Was bringt mir das? Wer meine entschlüsselte Executable im Tempfile-Chaos von Windows findet, kann auch einen Memory Dump davon machen. Also Unsinn.



  • Aber wie geht das?

    EXE's können nur von Laufwerken (welcher Art auch immer) gestartet werden - ich nehme an das es mittels eines virtuellen Laufwerkes bewerkstelligt wird(RAM drive).



  • hier macht das einer mit ner dll.
    vieleicht hilft dir das ja ein stück weiter.
    http://www.joachim-bauch.de/tutorials/load_dll_memory.html/en#windows-executables-the-pe-format



  • man könnte eine Art template-exe zum erstellen des Prozesses benutzen, und anschließend die exe(im Speicher) von Hand einbetten: Dlls laden, PEB fixen, PE-Header anpassen... 😉



  • man könnte ja auch ein paar dateifunktionen ala CreateFile irgentwie
    über inlinehooking oder sowas umbauen, so dass sie nicht auf die platte
    sondern den ram zugreifen. habe ich mal versucht, aber aufgegeben, weil
    ich die olle "kernel32.dll" nicht unprotecten konnte 😞

    könnte aber klappen (theroetisch)



  • Weiß nicht ob das so ohne Weiteres funktioniert, du könntest aber mal VirtualAlloc mit PAGE_EXECUTE_READWRITE als memory-protection versuchen.
    Also deine Daten, die du empfängst in den mit VirtualAlloc angeforderten Speicherbereich schreiben und dann ausführen. Funktioniert so natürlich nicht, da EXE-Dateien ja nicht nur ausführbaren Code enthalten. Vielleicht kannst du deine empfangenen Daten ja noch so abändern, dass du in den Speicherbereich gleich ausführbaren Code reinschreibst.

    Na gut, das ist wohl nicht die beste (oder kürzeste) Lösung, war auch nur so ein Gedanke...



  • AntonWert schrieb:

    Das Programme aus dem Speicher heraus aufgerufen werden können muss gehen!

    Blaaaaaaaaaaah

    Beispiel: Auf der Arbeit hab ich so nen netten Fall, da ist die Exe verschlüsslet auf der Platte, ein Dongel entschlüsselt sie und das Ladeprogramm führt es aus. Speziell in diesem Fall währe es sehr sehr unschön wenn die entschlüsslte exe auf der Festplatte rumliegt...

    Aber wie geht das?

    Das ist was anderes. In dem Fall ist ein Teil des Programms immernoch unverschlüsselt, nämlich die PE-Header, einige PE Datenstrukturen, sowie ein kleiner Programmschnippsel, der den Verschlüsselten Teil mit Hilfe des Dongles entschlüsselt etc.
    DAS geht. Ist aber a) was gänzlich anderes und b) ziemlich kompliziert.



  • Bier schrieb:

    Vielleicht kannst du deine empfangenen Daten ja noch so abändern, dass du in den Speicherbereich gleich ausführbaren Code reinschreibst.

    Das kann gehen. Allerdings muss dazu der Code Position-Independant sein. Bei x64 kein Problem, bei x86 eher schon. Oder man kann natürlich eigene Relocation-Tables mitschicken. Auf jeden Fall auch nicht ganz trivial.

    p.S.: und irgendeine Art wie der versendete Code an DLL-Importe rankommt muss man sich auch einfallen lassen. Also z.B. einen eigenen Import-Table mitschicken (und auflösen bevor man den Code ausführt). Oder die Adressen der Funktionen LoadLibrary + GetProcAddress mitgeben, und den Code alles dynamisch laden lassen (umständlich, aber möglich).



  • am besten wäre es ja einfach den windows-loader umzubauen. (wurde glaubich schon
    erwäht). scheint aber nicht zu klappen, als normaluser ohne debugrechte, etc.
    darf ich nicht im addressraum von kernel32 rumschreiben, VirtualProtect meldet
    immer access_deinded. (code: 998). eben getestet.

    bekommt jeder prozess eine kopie von kernel32 oder wird die dll einfach nur
    in den prozess eingeblendet?

    kann man nicht einfach die ganze funktion irgentwie auslesen und woanders
    ausführen? (nach relocation).

    da muss es doch was geben, wäre die eleganteste lösung



  • ^^man könnte 'createprocess' nachbauen bzw. abändern. für die exe wird ja ein 'section objekt' (auch als filemapping bekannt) angelegt. da könnte man vielleicht ansetzen und eine dateilose section (CreateFileMapping() ohne gültiges file-handle aufrufen) erzeugen, die man dann mit den daten der exe füttert. hört sich nach viel bastelei an, wär aber sicherlich interessant, sich 'ne CreateMemoryProcess()-funktion zu bauen.
    🙂



  • @AntonWert: Das geht ungefähr in drei-vier Schritten, Speicher allokieren (1), Deine Daten, die ja ausführbaren Code darstellen, rüberkopieren (2), den Speicherbereich als ausführbar "einstellen" und Funktionspointer darauf (3) setzen:

    {
        void (*my_func)(void) = NULL;
        void *pMem = NULL;
        void *pDeineDaten = NULL;
        DWORD ManyBytes = 4096;
        DWORD OldProtect = 0;
    
        ... /* pDeineDaten mit Daten füllen */
    
        pMem = VirtualAlloc(NULL, ManyBytes, MEM_COMMIT, PAGE_READWRITE);
        memcpy(pMem, pDeineDaten, ManyBytes);
        VirtualProtect(pMem, ManyBytes, PAGE_EXECUTE, &OldProtect);
        my_func = (void (*)(void))pMem;
        my_func();
    }
    

    Viel Glück beim Debuggen! 🙂



  • abc.w schrieb:

    @AntonWert: Das geht ungefähr in drei-vier Schritten, Speicher allokieren (1), Deine Daten, die ja ausführbaren Code darstellen, rüberkopieren (2), den Speicherbereich als ausführbar "einstellen" und Funktionspointer darauf (3) setzen:

    {
        void (*my_func)(void) = NULL;
        void *pMem = NULL;
        void *pDeineDaten = NULL;
        DWORD ManyBytes = 4096;
        DWORD OldProtect = 0;
    
        ... /* pDeineDaten mit Daten füllen */
    
        pMem = VirtualAlloc(NULL, ManyBytes, MEM_COMMIT, PAGE_READWRITE);
        memcpy(pMem, pDeineDaten, ManyBytes);
        VirtualProtect(pMem, ManyBytes, PAGE_EXECUTE, &OldProtect);
        my_func = (void (*)(void))pMem;
        my_func();
    }
    

    Viel Glück beim Debuggen! 🙂

    ^^ so kannste aber keine 'richtige exe' ausführen.
    🙂



  • das klappt so nicht. zum einen, weil die relocaton fehlt und zum anderen weil die
    echse einen header hat, den du mitausführen willst. 😉



  • Ach so, eine richtige exe soll es sein, habe ich überlesen. Dann... keine Ahnung... 🙂



  • vielleicht schaust mal im ReactOS source code wie CreateProcess() funktioniert, da die exe ja sowieso zuerst in den speicher geladen wird damit sie überhaupt ausführbar ist. alles andere sollte sich dann ergeben, oder FreeDOS wie die exe laden... etc..



  • mittlerweile habe ich es geschafft, kernel32 funktionen erfolgreich
    umzubiegen. allerdings scheint weder CreateProcess noch LoadLibrary
    auf dateifunktionen wie CreateFile zurückzugreifen. 😞

    wie machen die das? ich versuche grade die ntdll funktionen zu hooken.
    vielleicht klappt das ja.


Log in to reply