EBFE's universal decrypter

    Um es mal kurz zu fassen:
    - entpackt "crypted" Exen, sofern die Crypter auf RunPE basieren (oder RunPE Portierungen - aber kein .NET).
    - nicht DAU sicher ;)
    - braucht Adminrechte
    - entpackt zur Laufzeit - d.h die Zielanwendung wird ausgefürt (verdächtige Dateien also auf VM entpacken).


    Interessant wären natürlich weitere Tests (Crypter).


    passwort:
    [hide]
    ist keins gesetzt ;)
    [/hide]

    Schöne Sache! :)


    Toll was ihr Jungs alles Produziert :D


    //EDIT:
    Du Freak! :D Seh grade das ist alles in Assembler gecoded. Nice!
    //
    Ups, steht ja auch ganz oben :|

    Signatur entfernt, da ich mich für mein eigenes Board schämen muss - Syler


    [RIGHT]Antw.: Danke und die Verwarnung drückt nur deine Hilfslosigkeit über die Aktion aus. Du bistkein guter Admin. Tut mir Leid.
    [/RIGHT]

    Einmal editiert, zuletzt von interNode ()

    Kann ich nur meinem vorredner zustimmen, sieht gut aus, eine Frage von mir
    wie lange hast du dafür gebraucht? Habe noch nie mit Assembler Programmiert, daher meine Neugierigkeit.
    Werde es auch gleich mal ausprobieren.


    MFG
    morgi

    Könntest du mir sagen was du da genau machst? Hookst du WriteProcessMemory & Co. oder machst du das doch anders?


    //sogar meine VB portierte CreateProcessEx Funktion wird gedumpt :D ich muss wissen wie du das machst! ^^




    Du sagst, du spürst die Ohnmacht, denn der Feind ist ach so stark
    Und er will dich niederhalten mit Geschrei durch Bein und Mark
    Mit Verboten und Zensur kann er zwar den Kampf erschweren
    Doch niemals wird ein Richterspruch den freien Geist bekehren.


    Fürchte lieber Deutschlands Untergang als die Reden der Vasallen
    Derer, die der Lüge dienen, denn schon bald werden sie fallen.

    Einmal editiert, zuletzt von Slayer616 ()

    Zitat von morgi;14272


    wie lange hast du dafür gebraucht? Habe noch nie mit Assembler Programmiert, daher meine Neugierigkeit.


    Ca. 2 Tage. Allerdings habe ich schon einiges in diese Richtung programmiert und musste nicht alles von 0 schreiben ;). Und imho macht es bei solchen Lowlevel Geschichten keinen gro�en Unterschied, ob man nun C/C++/Delphi oder direkt MASM verwendet (au�er vielleicht für GUI).


    Slayer616:
    ich hab mir einfach das "original" RunPE angeschaut sowie einige frei verfügbare Ports in Delphi/MASM. Man kann den RunPE Vorgang zwar immer variiren, braucht aber die "KernAPIs" ResumeThread und WriteProcessMemory.
    Wenn ResumeThread aufgerufen wird, kann man davon ausgehen, dass die Anwendung nun entpackt ist. WriteProcessMemory liefert einen Hinweis auf die Basisadresse (man kann es sicherlich auch genereller, fand ich aber irgendwie am unkompliziertesten ;) ).


    PS: wie gesagt, weitere Cryptertest samt Namen und Bugmeldungen sind willkommen ;)


    Edit: Schwarze Sonne 0.3 getestet - wird entpackt :)

    Die Idee finde ich wirklich toll! Jedoch würde ich ResumeThead-CallBack blocken (damit die es nicht ausgeführt wird!) Das wäre doch eine Innovation! AV Firmen würden dich lieben!




    Du sagst, du spürst die Ohnmacht, denn der Feind ist ach so stark
    Und er will dich niederhalten mit Geschrei durch Bein und Mark
    Mit Verboten und Zensur kann er zwar den Kampf erschweren
    Doch niemals wird ein Richterspruch den freien Geist bekehren.


    Fürchte lieber Deutschlands Untergang als die Reden der Vasallen
    Derer, die der Lüge dienen, denn schon bald werden sie fallen.

    Zitat

    Jedoch würde ich ResumeThead-CallBack blocken


    AVs tun das doch schon im Kernelmode (oder sollten zumindest :| )
    Oder meinst du einen Globalhook?


    Der Breakpoint wird ja vom ResumeThread nicht entfernt und die Ausführung ist damit ja geblockt - aber es besteht immer noch die Gefahr, dass ein anderes Prinzip als RunPE benutzt wird. Dann greift der BP/ResumeThread Block gar nicht (daher auch der Hinweis mit VM).

    Bei dem hooken wählst du ja einen CallBack. Da würde ich auffällige APIs wie ResumeThread ja blocken damit die Datei nicht vollständig ausgeführt wird...




    Du sagst, du spürst die Ohnmacht, denn der Feind ist ach so stark
    Und er will dich niederhalten mit Geschrei durch Bein und Mark
    Mit Verboten und Zensur kann er zwar den Kampf erschweren
    Doch niemals wird ein Richterspruch den freien Geist bekehren.


    Fürchte lieber Deutschlands Untergang als die Reden der Vasallen
    Derer, die der Lüge dienen, denn schon bald werden sie fallen.

    Jaja da meint EBFE ja, dass es noch andere RunPE Methoden gibt. Also auch, wenn du ein Programm entpacken willst, von dem du weiÃ?t, dass es mit einem RunPE Crypter gepackt wurde, kann es sein, dass der Hook auf ResumeThread gar nicht greift, da dieser vielleicht in einen anderen Prozess injiziert wurde, etc.

    Zitat von Zacherl;14386

    Jaja da meint EBFE ja, dass es noch andere RunPE Methoden gibt. Also auch, wenn du ein Programm entpacken willst, von dem du weiÃ?t, dass es mit einem RunPE Crypter gepackt wurde, kann es sein, dass der Hook auf ResumeThread gar nicht greift, da dieser vielleicht in einen anderen Prozess injiziert wurde, etc.


    Genau. Wobei ich da eher an "normale" Crypter denke. Oder an direkte ZwResumeThread Aufrufe.
    Der "Hook" ist auch nur ein simpler EBFE :D Breakpoint und kein Callback.
    Der Anfang der Funktion wird damit gepatcht und dann abgewartet, bis das Programm bei dem BP angelangt ist.
    Ist einerseits einfach zu implementieren, erspart den �rger mit eventuellen Antidebuggingtricks und anderseits recht zuverlässig für einmalige Breakpoints. Möchte man dagegen z.B erst auf den zweiten ResumeThread Aufruf reagieren, wird es komplizierter und damit auch unzuverlässiger.

    Ich hatte zum Test einer alten Debugging-Engine etwas ähnliches gecodet, nur eben - wie schon erwähnt - attache ich als Debugger.


    Das hat jedoch den unschönen Nebeneffekt, dass man sich noch um Anti-Anti-Debugging kümmern muss (was insofern aber sogar gewollt war, da ich den Teil so oder so coden musste).


    Infinite Loop nutze ich eher ungern, da man so (je nachdem, wie viele man davon in welchem Zeitraum verwendet) doch schon etwas Zeit verliert. Eine Möglichkeit wäre, einen Loader zu schreiben, der die .dll injected, die wiederum entsprechende Funktionen hooked (jmp/call/push+retn, zur Not auch komplexer).


    Noch ein Vorschlag zur Verbesserung (falls du das vorhast): Ein Problem könnte noch Anti-Hooking sein, was in manchen Cryptern doch schon Anwendung findet - im schlimmsten Fall sogar eine Emulation der ersten paar Bytes, wie man es von diversen Protector kennt (die ja noch zusätzlich zum Einsatz kommen können).

    Zitat von f0Gx;14406

    Eine Möglichkeit wäre, einen Loader zu schreiben, der die .dll injected, die wiederum entsprechende Funktionen hooked (jmp/call/push+retn, zur Not auch komplexer).


    Jep. Den Gedanken hatte ich auch. Erspart auch das holen der SeDebugPrivilegien. Nur in diesem Fall (für 2 BPs) lohnt sich der Aufwand imho nicht und bei zuvielen Hooks wird das wieder "ungenerell". Bei einem bestimmten Protector/Packer wäre das natürlich wieder was anderes - aber bei dem RunPE Zeug gibt es irgendwie zuviele Variationen :)


    Zitat


    Noch ein Vorschlag zur Verbesserung (falls du das vorhast): Ein Problem könnte noch Anti-Hooking sein, was in manchen Cryptern doch schon Anwendung findet - im schlimmsten Fall sogar eine Emulation der ersten paar Bytes, wie man es von diversen Protector kennt (die ja noch zusätzlich zum Einsatz kommen können).

    Naja, als einzige Gegenma�nahme fallen mir da nur "tiefere" hooks ein - z.B ZwXXX Funkktionen. Oder "richtige" Disassemblerengine und dann z.B den ersten CALL/JMP hooken. Oder sich darauf verlassen, dass die Funktionen in jeder WinVersion nicht gro�artig variieren und erst die RETs hooken. Da würde ich ehrlich gesagt lieber die Mühe in einen "echten" Unpacker/Stripper stecken :).