Archive for Nov. 2012
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!
Easy
Zunächst einmal muss ich etwas loswerden: COM-Objekte und ihre GUID/CLSID/IDDs sind BLÖD! Seid Stunden sitze ich an einem kleinen Problem, welches sich HRESULT REGDB_E_CLASSNOTREG bzw E_NOINTERFACE nennt. Laut Google müssen CLSID und IID identisch sein, aber hier…:
CLSID_CLRRuntimeHost = 90F1A06E-7712-4762-86B5-7A5EBA6BDB02
IID_CLRRuntimeHost = 90F1A06C-7712-4762-86B5-7A5EBA6BDB02
Suche und finde den Fehler. Jap, ein Zeichen unterschied der GUIDs und alles für den A…..
So, nach diesem kleinen Ausraster direkt zur Einleitung. Es geht um CLRHosting durch Managed FASM, wie bereits in einem Post vor ziemlich genau einem Jahr erklärt. Dabei ist es möglich von .NET ASM-Code in eine native Assembly zu injecten, welche wiederrum eine CLR-Runtime läd um dort .NET Assemblys zu laden und auszuführen. Wozu braucht man das? Zum Beispiel um auf native Bootstrap DLLs verzichten zu können oder böse Malware in nativen Programmen zu verstecken.
In dem erwähnten Post wurde die CLRRuntime 2.X über die Funktion CorBindToRuntimeEx geladen, dies ist allerdings nicht zu höheren Versionen des .NET Frameworks kompatibel. Nun wurde eine andere Lösung gesucht, da viele Libraries inzwischen auf .NET 4 portiert sind.
Die hier vorgestellte Methode ist etwas komplizierter, dafür funktioniert sie für .NET v4.0.30319 und ist abwärtskompatibel. Bei dem früheren CLRHosting reichte es, eine statische Funktion aufzurufen um ein Interface-Handle zu bekommen. Von diesem Interface-Handle reichte es, wiederum eine Funktion aufzurufen, um die CLRRuntime zu starten.
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.
