Heutzutage ist der einzig weiterhin effektive Obfuscator Confuser. Er bietet die Verschlüsselung von Methoden an, das schon öfter angesprochene Proxy-System und vieles weitere, kurzerhand alles um einem Cracker das Leben zur Hölle zu machen. Nennt man die Methoden um, funktioniert das Proxy-System nichtmehr. Schreibt man die Assembly neu, so sind die Ressourcen unbrauchbar. Confuser zu entpacken heißt alles oder nichts, denn alles ist miteinander verknüft. Wenn man nicht alles entschlüsselt, bekommt man kein lauffähiges Programm.

Doch es gibt eine Lösung: Debugger! Bereits vor einigen Monaten habe ich ein String-Decrypter System vorgestellt, dass auf Basis des mDbg Debuggers dynamisch Strings entschlüsselt. Die Vorteile von Debuggern liegen klar auf der Hand: Wenn man einmal die Anti-Debug-Funktionen entfernt hat, kann man das Programm analysieren und auch zur Laufzeit verändern. Kein neues erstellen der Exe ist von Nöten, die Methoden und Strings sind entschlüsselt im Speicher und da das Programm immernoch vom .NET Framework gelesen werden muss, macht uns die Metadata-Zerstörung auch nichts aus.

Mich haben in letzter Zeit gefühlte tausend Emails und Nachrichten erreicht, mit der Frage ob man den FUT Autobuyer cracken kann. Meine Antwort bestand stehts aus Links zu Threads die erklären, wie man Confuser zumindest halbwegs entpackt. Alles andere ist dann kein großes Problem mehr, so war es zumindest in der Vorgängerversionen.

Weiterlesen

9 people like this post.

Like

Unlike

Der Confuser ist nach wie vor ein aktuelles Thema. Und dabei ist die String-Decryption soweit ich weiß nicht geknackt! Confuser stellt für fast alle Strings eine eigene Decrypterfunktion mit eigener Ressource sowie eigenen Verschlüsselungsparametern bereit. Der reine Horror für jeden, der einen statischen Unpacker schreiben will.

Dieses mal ging es um einen anderen, dynamischen Ansatz: Warum nicht die Strings auslesen, nachdem sie sich entschlüsselt im Speicher befinden? Und da ich bei dem Proxy System von Confuser Erfolg mit WinDbg hatte, ist auch hier zum Debugger gegriffen worden. Microsoft stellt uns eine .NET Debugging API bereit, auch wenn sich kaum etwas darüber im Internet finden lässt. Und genau mit dieser API in Kombination mit ein wenig Confuserwissen, Speicherlayout und .NET ist es möglich, einen Debugger und Unpacker für die Strings zu schreiben. Dabei laufen folgende Schritte ab:

1. Debugger Instanz erstellen + die Executable laden
2. Nach dem Laden vom “mscorlib.dll”-Modul ein Breakpoint auf System.Reflection.Module.ResolveMethod setzen (wird von .cctor gecalled, siehe Proxy-System)
3. Sobald dieser Breakpoint erreicht ist, werden Breakpoints auf alle String-Decrypter Funktionen gesetzt. Der ResolveMethod BP wird entfernt.
4. Wenn ein Decrypt-BP erreicht ist, so wird aus der Funktion raus gesprungen und der Wert in EAX ausgelesen. Dabei wird der Parameter (Token) von dem Decrypt-Call zusammen mit dem entschlüsselten String abgespeichert.
5. Alle Decrypt-Funkionen, die ein Token (+ entschlüsselten String) haben, werden mit dem echten String ersetzt.

Kingt nach viel Arbeit und Source? Nicht wirklich. Fangen wir bei Punkt 1 an:

Engine = new MDbgEngine();
Proc = Engine.CreateProcess(@"C:\Users\AL\Downloads\li0nsar3c00l enhanceviews.net bot_patched.exe", "", DebugModeFlag.Debug, null);
 
Proc.PostDebugEvent += Proc_PostDebugEvent; // Jedes Event wird hierhin weitergereicht
Engine.Processes.Active.CorProcess.OnBreakpoint += CorProcess_OnBreakpoint; // ein BP wird als Event gecalled
Proc.Go().WaitOne(); // Wir lassen laufen, bis ein BP erreicht ist.
 
Console.ReadLine();

Weiterlesen

2 people like this post.

Like

Unlike

Über CoderZ erhielt ich die Anfrage zum Cracken dieses Bots für das Spiel WarRock. Dabei gibt es sowohl einen “Free”-Mode, als auch den sog. “Premium”-Mode. Für letzteres bedarf es eines Codes, den man zuvor gegen Geld erworben hat.

Leider hat sich die Person, welche mich ursprünglich um den Crack bat, nicht mehr gemeldet, seid ich ihr eine gecrackte Version zum testen zugeschickt habe. Es ist also nicht garantiert, dass die hier gepostete Version funktioniert, ich freue mich allerdings über jedes Feedback

Des weiteren hat sich der Coder des Bots zurückgezogen und wird dementsprechend auch keine Updates mehr herrausbringen. So ist durch diesen Crack auch kein Schaden entstanden

Zurück zum Bot: Nach dem unpacken des Crypto-Obfuscators mit de4dot 2.0.3 gab 2 Features gab es zu patchen. Das erste Feature ist ein Anti-VM Mechanismus, welcher es nicht erlaubt dass der Bot unter einer virtuellen Maschine gestartet wird. Der Check dazu befindet sich gleich im Anfang nahe des EPs:

if (Class3.smethod_4())
{
MessageBox.Show("WarBot is running on a virtual computer. Please run WarBot on a real PC.", "WarBot - Error", MessageBoxButtons.OK, MessageBoxIcon.Exclamation);
return;
}

Weiterlesen

3 people like this post.

Like

Unlike

Aufgrund einer Bitte folgt hier ein Video, was ein bisschen den Unpackvorgang des Confusers beleuchtet. Es ist auf Englisch geschrieben und ziemlich schnell zusammengeklickt, daher vergebt mir Schreibfehler wie “on” statt “one” oder “weather” statt “whether”.

Durch das Klicken auf die eingeblendeten Texte setzt das Video fort

Viel Spass beim lernen und anschauen!

Zum Video hier hart klicken!

Easy

5 people like this post.

Like

Unlike

Nach einem Monat der mehr oder weniger intensivsten Arbeit erscheint hier der nächste große Artikel zum Confuser. Es wird (wiedermal) um das Auflösen des Proxy-Systems gehen. Wem das Proxy-System nicht geläufig ist, kann im vorherigen Artikel sein Wissen nochmal auffrischen.

Doch zunächst ein wenig Vorgeschichte: Ein deutschsprachiger Reverser “li0nsar3c00l” war so nett mir eine Binary zu builden, welche es zu cracken galt. Dieses “CrackMe” wurde mit Confuser 1.9 Aggressive erstellt. Aggressive enthält das Proxy-System (Methoden und Konstuktoren), String-Encryption, Code-Flow-Obfuscation, Anti-Debug und natürlich Type-Renaming. Man muss im Hinterkopf behalten dass es nicht möglich ist eine lauffähige Binary zu erstellen, wenn nicht alle dieser Systeme umgangen sind. Denn jedes System benutzt entweder Signaturen von Methoden, welche sich ändern sobald die Binary neu erstellt wird, oder aber Verrechnungen mit dem MethodToken aus dem Callstack. Das hört sich alles kompliziert an, bedeutet aber einfach dass wir keine neue Binary erstellen können ohne zuvor alles aufgelöst zu haben.

Bevor wir intensiv ans Reversing gehen können, gilt es das Anti-Debug-Modul auszuhebeln. Dazu noppen wir einfach die ganze Methode, unschön aber effektiv. Den Call zu noppen hätte auch gereicht, allerdings wusste ich nicht ob die Anti-Debug Funktion nochmal (dynamisch?) aufgerufen wird. Sicher ist sicher.

Weiterlesen

9 people like this post.

Like

Unlike