[S] Crypter Source C++

[Mirr0w]

hi leute.
ich wollte mal fragen, ob es einen public source code von einem crypter in c++ gibt ?!

mfg

[Zer0Flag]

Gibt es... z.B. den von Cryptic

Das nächste mal bitte erst Google oder die SuFu fragen...

~Zer0Flag

[Megagamer]

ich glaube bei opensc.ws dürftest du fündig werden

[Mirr0w]

jo vielen dank ich werde dort ma suchen ^^

[ocz]

Es gibt in der Tat Massen an public sources zu mehr oder weniger guten Cryptern. Interessanter dürfte es werden, wenn du hier nach einzelnen Snippets (z.b. zur encryption oder PE-sachen) fragst, da das dein Verständnis der Materie sicherlich besser prägen würde. Aus solchen Snippets lässt sich dann durchaus ein Crypter basteln, den du dann in den Einzelheiten selber weiter verfeinern kannst.

[EBFE]

SIG^2 G-TEC - Dynamic Forking of Win32 EXE (http://www.security.org.sg/code/loadexe.html)

[ocz]

SIG^2 G-TEC - Dynamic Forking of Win32 EXE (http://www.security.org.sg/code/loadexe.html)

Das sieht ja nach der standard memory execution aus, wie sie auch in cryptic zum einsatz kommt(wenn ich mich recht entsinne). Dürfte aber unter dem "FUD"-Aspekt eher eine weniger gute Lösung sein.

[EBFE]

wie sie auch in cryptic zum einsatz kommt(Das ist der Urvater aller heutigen "RunPE Based" Module (siehe Veröffentlichungsjahr) ;)
Das Prinzip wird erklärt sowie die Funktionsweise - was will man mehr?

PS:
98% der verfügbaren Malware-Crypter basieren afaik auf Mem-Exec Methode (wobei 95% der Programmierer diese einfach stur kopiert. Z.B wird die "PE-Realign"/Fix Optionen zuzüglich der ganzen Antis inzwischen sehr gerne in die "eigegen" Crypter eingebaut (damit korrigiert man dann die SizeOfImage nach dem Anhängen der "gecrypteten" Datei an die Stub.exe, so dass sie mit der tatsächlichen Größe übereinstimmt). Aber die angehängte Exe wird immer noch schön brav über CreateFile/ReadFile auf eigenes Modul ausgelesen - obwohl diese dank dem PE-Fix schon beim Start der Exe in den Speicher mitgeladen wurde :rolleyes: ). Alles andere ist ohne PE Kenntnisse kaum machbar ;)

[ocz]

98% der verfügbaren Malware-Crypter basieren afaik auf Mem-Exec Methode (wobei 95% der Programmierer diese einfach stur kopiert. Z.B wird die "PE-Realign"/Fix Optionen zuzüglich der ganzen Antis inzwischen sehr gerne in die "eigegen" Crypter eingebaut (damit korrigiert man dann die SizeOfImage nach dem Anhängen der "gecrypteten" Datei an die Stub.exe, so dass sie mit der tatsächlichen Größe übereinstimmt). Aber die angehängte Exe wird immer noch schön brav über CreateFile/ReadFile auf eigenes Modul ausgelesen - obwohl diese dank dem PE-Fix schon beim Start der Exe in den Speicher mitgeladen wurde :rolleyes: )

Danke, das bestätigt meine Vermutungen. Unter diesen Gesuchtspunkten wäre die Verschlüsselung aller Sections (evtl muss man da noch auf die IAT achten?) und die Platzierung der Entschlüsselungsroutine innerhalb einer Codecave (inkl junkcode beim jump dorthin) empfehlenswert. Meiner Meinung nach ist soetwas manuell in vereinfachter Art und Weise (MUPing richtig?) im olly ja schnell gemacht, wodurch die Funktionsweise beim durchsteppen auch sehr gut nachzuvollziehen ist.

gruß

[EBFE]

Danke, das bestätigt meine Vermutungen. Unter diesen Gesuchtspunkten wäre die Verschlüsselung aller Sections (evtl muss man da noch auf die IAT achten?) und die Platzierung der Entschlüsselungsroutine innerhalb einer Codecave (inkl junkcode beim jump dorthin) empfehlenswert.

Rein "ökonomisch" gesehen lohnt es sich wohl nicht - das macht afaik auch nicht mehr "fud". Habe damit noch vor ca. 1.5 Jahren rumgespielt (auch als Programm umgesetzt). Zum einen gibt es einige große Linker, die gerne die IAT in der Codesection platzieren (VB) - so dass man die Codesection dann nicht verschlüsseln kann, zum anderen wird die "Codecave-ierung" des OEP bzw. Enschlüsselungsroutine auch gerne von Heuristiken erkannt (ok, per Hand lässt sich das natürlich um einiges besser machen als per Programm, allerdings ist die Codecavegröße sowie Position meistens sehr beschränkt).
Nicht zuletzt reicht i.R die IAT schon zur Erkennung aus.

Das Problem mit den "richtigen" Cryptern, die die IAT mitverschlüsseln sind imho die ganzen Ausnahmen bei den Linkern und Imports. Zum einen gibt es noch BoundImports, TLS, JmpTables und ähnliche Spässe die mir jetzt nicht in den Sinn kommen (da es schon länger her ist ;) ). Vor allem kleinere Details, wenn man seinen PE-Crypter Win2k, WinXP, Vista, Win7 kompatibel machen möchte.

Von rein technischer Seite gesehen ist es natürlich interessant und auch empfehlenswert damit rumzuspielen - auch wenn man imho gerade in Olly "manuell" viel komplexere Sachen machen kann, als über programmatikale Umsetzung. Ganz zu schweigen davon, was man dabei so alles lernen kann. Nur dass die meisten Leute an der technischen Seite nicht interessiert sind ;)



Meiner Meinung nach ist soetwas manuell in vereinfachter Art und Weise (MUPing richtig?) also MUPing ist für mich "manual unpacking" - also das Entfernen von Protectoren (richtigen, also ASPro, Themida, Armadillo usw) per Hand, ohne Strpper/Unpacker Tools ;)

[ocz]

also MUPing ist für mich "manual unpacking" - also das Entfernen von Protectoren (richtigen, also ASPro, Themida, Armadillo usw) per Hand, ohne Strpper/Unpacker Tools ;)
Ah, da hat die lange Abstinenz wohl doch ihren Tribut gefordert. Logisch, MUPing stand für Manual Unpacking. Das hatte ich jetzt mit Manual Packing verwechselt.

Damit das an meinem ersten Tag nicht schon völlig OT wird, und ich verwarnt werde hier mal ein Link, der dir sicherlich weiterhelfen wird, wenn du die Memory Execution implementiert (kopiert?) hast.
A C++ Implementation of the Blowfish Encryption/Decryption method - CodeProject (http://www.codeproject.com/KB/security/blowfish.aspx)
Der Blowfish Algorithmus übersteigt natürlich in Komplexität natürlich schon eine verXORung, hat dafür aber natürlich auch bessere (schlechtere?) Erkennungsraten zur Folge.

Ich habe die Erfahrung gemacht, dass AVs mittlerweile sogar so weit gehen, den XOR-Key (sollte er 1 Byte sein und sich über den Verlauf nicht verändern) zu bruteforcen (nicht sonderlich schwer, wenn man weiß, dass die ersten zwei Zeichen MZ sein müssen). Wenn man also XOR benutzt, sollte der Schlüssel meiner Meinung nach in einer adequaten Länge gewählt werden.