• Crypter Theorie •

[Mofo]

Und um den Link nochmals zu bringen: eine Schritt für Schritt Anleitung hier ..
Mit der kannst du ganz unabhängig von der Sprache deinen Crypter umsetzten..

[nom]

Das Problem ist eher folgendes:
1. Die meisten Detections bei cryptern kommen vom Anhängen des gecrypteten Files und des wieder auslesens (TR/Dropper.Gen bei EOF z.B.) da musst du dann den PE Header Re-Alignen (^^) wobei auch schon die auslese Funktion detected sein kann.
2. Andere Detections können vom "RunPE" kommen, und somit musst du entweder ne Ahnung haben wie du es FUD bekommst bzw dir ein eigenes schreibst und damit zu
3. Der PE-Header ist nicht so simpel, dass man mal schnell drüber liest und sagt ja okay is klar, sonst würde es ja FUD Crypter hageln ohne Ende. Das nächste Problem daran ist, das RunPE für alle Windowsversionen (2000, XP, Vista, 7), was relativ einfach ist, aber auch für 32 sowie 64 bit an zu passen, was sich schon etwas schwieriger gestaltet

Und genau aus diesen 3 Gründen wirst du kein Tutorial finden, dass dir von Level 0 an erklärt wie du nen "FUD Crypt9r" bastelst, da es einfach zu Zeitaufwändig wäre.

Und zu SUNZ wegen dem wie man ne stub wieder FUD bekommt:
Wenn du einigermaßen Ahnung vom Coden hast (kp wie gut du Coden kannst daher kein Urteil über dich) dann sollte es in C/C++ nicht all zu schwer sein eine stub wieder FUD zu bekommen. In Sprachen wie VB6 wird jeder Dreck als irgendwas detected, daher hab ich das aufgegeben. In .NET Sprachen lässt sich Malware recht einfach und effektiv Coden, jedoch wird .NET immer runtergemacht, da es eben gewisse Einschränkungen hat, jedoch lässt sich damit auch einiges anstellen.

Mein Tipp:
Einfach und schnell zu lernen: C#/VB.NET
Keine Einschränkungen aber wesentlich komplexer: C/C++/Delphi

[EBFE]

Sry aber bei dem 700-Zeilen Source den du eben gepostet hast ist der Lern-Effekt auch nicht wirklich hoch. Wie erwähnt: "So irgendwie wirds schon funktionieren"..

Wo ist dein Problem, den Artikel zu lesen?
SIG^2 G-TEC - Dynamic Forking of Win32 EXE

1. Use the CreateProcess API with the CREATE_SUSPENDED parameter to create a suspended process from any EXE file. (Call this the first EXE).
2. Call GetThreadContext API to obtain the register values (thread context) of the suspended process. The EBX register of the suspended process points to the process's PEB. The EAX register contains the entry point of the process (first EXE).

Die meisten Sourcen sind nur deshalb so groß (besonders VB/c#) weil noch PE-Strukturen mit definiert werden.
Und zum PE-Format sollte man getrennt etwas lesen. Hier mal eine Linksammlung: http://free-hack.com/421932-post19.html

Ebenso zu Verschlusselungen.

Ansonsten ist das RunPE-Verfahren nichts Kompliziertes. Gerade andersherum - es ist quasi "BugUsing" in der Funktionalität des WinPE-Loadrers.

Wenn du mit PE-Format vertraut bist - also weißt, welche Werte beim Starten der Exe vom WinPE Loader ausgelesen/initialisiert werden, kannst du a) den RunPE Ansatz verstehen
b) den anderen Ansatz umsetzen (starten der Anwendung durch eigenen Stub-Code, der die Funktionalität des WinPE Loaders nachbildet, was eigentlich nur recht umständlich ist)

Also "All in one high Quality Tut" wirst du nicht finden. Weil alleine ein gutes PE-Format Tutorial ziemlich viel Arbeit macht (~20 Seiten ohne die eigentliche Referenz, wenn man die Details erklären möchte) bzw seitens des Lernenden auch mit RE/ASM-Vorwissen einige Tage Lese und Einarbeitungszeit im Debugger/PE-Editor erfordert (von Leuten, die nie was davon gehört haben, ganz zu schweigen).
Wozu soll man sich also die Arbeit machen und speziell noch eine Einführung ins PE-Format schreiben, wenn es schon anständige Tutorials dazu gibt? Und wenn man PE-Formant kennt, erledigen sich viele Fragen eher automatisch .

Was die details der Umsetzung angeht (die ewigen "FUD" Fragen) - das hängt auch größtenteils mit dem PE-Format zusammen und damit, wie die "Stub" und die Exe "zusammengebracht" werden. Da hilft es nichts, eine Anleitung zu schreiben "tu dies und jenes, dann ist es FUUUD". Entweder erkennt man den Fehler, weil man WEIß was man tut oder man wiederholt stumpf die Anleitung (sofern es eine gibt) und wartet anderenfalls immer auf Helfer.