Unpacker: ExeStealth 2.7x, Yoda's Crypter 1.2/1.3, ExeShield 1.x

[CDW]

heute im Sonderangebot: 3 Unpacker zum Preis von einem

Y0da's Cryptor 1.2/1.3
ExeStealth 2.76/2.75/2.74;
ExeShield 1.3RC (ExeShield von "tom commander" und nicht von ExeShield Team (die sind aktuell bei 3.8 oder 3.9))
ExeShield 1.4 (Ultra Edition) sollte auch kein Problem sein, wenn das eigentliche Programm genutzt wurde (es sind noch Morphine/PE Crypter oder ähnliche UPX Scrambler beigelegt).

Es sollte eigentlich ein Unpacker für ExeStealth 2.76 werden. Da aber der "böse" y0da sich scheinbar sowohl bei ExeStealth wie ExeShield bedient und es natürlich nirgendwo erwähnt hat , wird auch sein Packer gleich mitentpackt


Und es existieren keinerlei Checks, ob es sich tatsächlich um eine mit den oben erwähnten "Cryptoren" gepackte Executable handelt - alles was nach einer gültigen Win32 Exe ausschaut, wird entpackt (dafür werden auch Executables entpackt, die nach dem Packen mit YC/ES nicht mehr laufen bzw wo einige Optionen genutzt wurden, die unter XP SP1/SP2 nicht mehr funktionieren ), also am besten schon vorher selber gucken worum es sich handelt - ob mit RDG oder PEID.

Getestet mit allen gängigen Compilern:VB,Delphi5/7,C++,Borland C++, MASM, MSVC++ 6/7

OS: getestet auf XP SP1

Quelltext (MASM) liegt bei. Programm wird noch ein paar kleine optische Überarbeitungen erfahren und natürlich Bugfixing, deshalb verlinke ich es vorerst.

Was schön wäre: Tests mit größeren VB Applikationen (da für VB ein recht hässlicher Hack integriert ist, der mit meinen Testprogrammen gut klappt - mit größeren Projekten konnte ich es aber nicht testen) und unter Win2000 oder anderen Versionen. Unter ME/9.x wird es nicht laufen.
www.cdw.de.vu/UnExeStealth.zip

 

[+++ATH0]

Witzig, dass ich für meinen ersten Versuch einen Packer zu schreiben Y0das Crypter als Vorbild genommen hab *hust* kopiert hab *hust*.
So setzt sich das wohl fort. *g*

Was ich mich frage ist, ob es eine Gefahr birgt Schädlinge damit zu entpacken, weil der Unpacker ja die Executable mit CreateProcess startet (und zwar, wenn ich das richtig verstanden habe, um LoadLibrary calls abzufangen um IAT zu rebuilden).

Die Frage ist also, wieviel von der Executable wird ausgeführt. Und kann da schon Schadcode enthalten sein?

Ich denke die Frage lässt sich hiermit beantworten:

invoke GetProcAddress,eax,addr LoadLib
		    mov ebx,eax
		    xor eax,eax
		   start_loop: 
		   invoke VirtualProtectEx,prozinfo.hProcess,ebx,100h,PAGE_EXECUTE_READWRITE,addr out_
		   .if eax==0
		   	  invoke ResumeThread,prozinfo.hThread
	          invoke SuspendThread,prozinfo.hThread
	          jmp start_loop
		   .endif

]

Er resumed und stoppt solange kurz den Process bis er es schafft die Page, wo sich LoadLibraryA befindet, als ausführbar, beschreib-und lesbar markieren kann. Dann sollte der interne "Unpacker" die IAT geschrieben haben und du kannst die grabben.

Nur verstehe ich das nur ansatzweise und die zusammenhänge sind für mich noch nicht ganz klar. Wäre nett, wenn du mir den Teil nochmal erklären würdest.

Dann ist sicherlich auch verständlich ob der Prozess vielleicht noch kurz nach dem internen IAT rebuild solange resumed sein könnte, dass er Schaden anrichten kann.

Ach ja: Keep up the good work.

 

[CDW]

Original von +++ATH0
Was ich mich frage ist, ob es eine Gefahr birgt Schädlinge damit zu entpacken, weil der Unpacker ja die Executable mit CreateProcess startet (und zwar, wenn ich das richtig verstanden habe, um LoadLibrary calls abzufangen um IAT zu rebuilden).

Die Frage ist also, wieviel von der Executable wird ausgeführt. Und kann da schon Schadcode enthalten sein?

Das Problem ist eher: es gibt keinerlei Checks ob es sich um einen der Packer handelt.
D.h wenn PEID/RDG sich irren und die Exe ist entweder nicht gepackt oder mit irgendetwas, was LoadLibraryA nicht nutzt (es gibt ja alternative APIs oder Wege), wird alles ausgeführt.

Ich denke die Frage lässt sich hiermit beantworten:
...
Er resumed und stoppt solange kurz den Process bis er es schafft die Page, wo sich LoadLibraryA befindet, als ausführbar, beschreib-und lesbar markieren kann. Dann sollte der interne "Unpacker" die IAT geschrieben haben und du kannst die grabben.

Jep, dass ist ein hässlicher Hack. Nach dem Suspend-Start ist nämlich die Kernel32.DLL nocht gar nicht geladen - da muss aber unbedingt ein BP rein. So wird einfach schön gepollt und gewartet. Allerdings ist zum "Platzierzeitpunkt" noch nichts mit IAT los.
Wenn die "markierung" gelungen ist, heißt es, dass erst jetzt BPs platziert werden können.
Eleganter und sicherer wäre es zuerst einen BP am EP zu platzieren. Dann müsste ich allerdings noch schauen, was es mit den TLS Callbacks auf sich hat (anfangs wurde auch die letze Section immer entfernt, nur ging das bei Borlandcompilaten nicht gut, da TLS Zeug in die letze Section verlagert wurde und nach dem Entfernen nicht mehr vorhanden war).

Dann ist sicherlich auch verständlich ob der Prozess vielleicht noch kurz nach dem internen IAT rebuild solange resumed sein könnte, dass er Schaden anrichten kann.

An sich nicht. Nach dem zweiten Stopp in LoadLibraryA wird nur noch gelesen/geschrieben und nichts mehr ausgeführt.Deshalb können auch Programme entpackt werden, die wegen IAT-Redirection oder sonstigen Optionen nicht (mehr) laufen.

Nur verstehe ich das nur ansatzweise und die zusammenhänge sind für mich noch nicht ganz klar

Im Prinzip passiert folgendes:
Exe wird gestartet. Es wird "gepollt" mit Resume/Suspend und VirtualProtectEx, bis Kernel32.DLL im Zielprogramm verfügbar ist.

Dann wird am Anfang der LoadLibraryA ein BP platziert und abgewartet ("infinite_loop") , bis die Ausführung da ankommt. Zu diesem Zeitpunkt ist der Packer dabei, für sich selbt benötigte API Adressen zu sammeln. Der zweite BP wird am RETN der LoadLibraryA platziert - das Ganze nur, um die Funktion auszuführen und nochmal am Anfang der LoadLibraryA einen BP zu plaztieren. Denn wenn diese Funktion zum zweiten Mal aufgerufen wird, beginnt der Packer damit, die IAT zu füllen. In ESI findet man dann gleich einen Pointer auf eine "interne Import Struktur" (RVA zum DLL Namen, RVA zum FirstThunk usw) und kann sie einfach abklappern: abgesehen vom ersten DLL Namen ist noch alles "verschlüsselt" (ROL al,4). Das ist dann auch bei allen 3 gleich
Ansonsten wird der Code noch leicht überarbeitet (sind noch zuviele unbenötigte Reste vom PECompact Unpacker drin) .

 

[+++ATH0]

Danke für die Erläuterungen. Jetzt wird einiges klar.
Gefahr besteht also noch, wenn der Schädling gar nicht damit gepackt ist und LoadLibraryA nicht benutzt.
Sollte ich also Viren oder Würmer zum studieren entpacken wollen, sollte ich das doch lieber in VMWare machen.
Man sollte ja prinzipiell Schädlinge nur sandboxed untersuchen.