Schon relativ lange hatte ich eine solche Serie geplant… Und hiermit ist der erste Artikel online! =)

In dieser Serie wird es, oh Wunder, um .NET Reversing gehen. Es sollte dadurch Einsteigern möglich gemacht werden, den Einstieg in dieses Themengebiet zu finden. Ich kann nicht behaupten dass es immer einfach sein wird und ich werde euch auch nicht alles vorkauen, aber das erwartet ja auch hoffentlich Niemand

Aber genug geredet! Teil 1 beschäftigt sich mit den grundlegenden .NET Reversing Tools und deren Benutzung. Mit ihnen wird ein kleines AnalyseMe analysiert und ausgewertet, dabei werden die Vor- und Nachteile des jeweiligen Programmes aufgezeigt. Natürlich gibt es auch hier kein Patentrezept, viele Wege führen nach Rom.

Das wohl bekannteste und grundlegendste Tool dürfte wohl der Redgate .NET Reflector sein. Mit ihm ist es möglich .NET Binaries zu öffnen und den Code in MSIL, aber auch in C#, VB.NET und anderen Sprachen anzuschauen. Die geladenen Projekte lassen sich sogar komplett exportieren, ein fertiges Projekt kann “zurückerstellt” werden. Die Vorteile liegen auf der Hand: Der Reflector ist benutzerfreundlich und selbsterklärend. Durch Plugins ist es möglich den Reflector zu erweitern, aber dazu zu einem späteren Zeitpunkt mehr. Des weiteren bringt der .NET Reflector ein VisualStudio AddIn mit sich, mit welchem es möglich ist durch Visual Studio das Programm zu debuggen. Eine ausgiebige Analyse-Funktion von Klassenmembern und Methoden kann dazu verwendet werden, um Methoden zu “tracen” um sich z.B. die Zuweisungen an Variable X anzuschauen. Nachteile sind, dass es leicht den Dienst verweigert sobald etwas nicht 100% regelkonform ist sowie dass es unter einer Shareware steht. Dennoch ein sehr gutes Tool um ungeschützte Programme zu öffnen und sich einen groben Überblick zu verschaffen. Z.B. die Analyse des aktuellen InterCafe-Projekts lief bisher nur über dieses Programm…

Eine Alternative zum .NET Reflector bietet die Freeware und OpenSource-Variante ILSpy. Im Grunde funktioniert sie wie der .NET Reflector, zumindest das Interface ähnelt doch sehr. Im Kern sind sie allerdings verschieden! Während der .NET Reflector den System.Reflection-Namespace nutzt, um Methodentokens aufzulösen und den Code anzuzeigen, verwendet ILSpy die Mono.Cecil-Variante. Wir werden später sicher noch auf Mono.Cecil zurückkommen, aber dieses sollte im Hinterkopf behalten werden. ILSpy kommt mit vielem klar, bei dem der .NET Reflector den Dienst verweigert. Ein integrierter Debugger ist das “Sahnehäupchen” von ILSpy. Wir werden ILSpy nachher verwenden, da es uns erlaubt Code in der C#-Ansicht zu debuggen.

Schlussendlich kommen wir zum geliebten und verhassten DILE. Der Dotnet IL Editor erlaubt uns das Debuggen von jeder Anwendung die ein .NET Modul läd, also auch jene die einen nativen Loader verwenden. Natürlich ist es leider auch das komplizierteste Tool, daher wird es in diesem Artikel nur angeschnitten. In den folgenden werden wir sicher noch genauer auf DILE eingehen, aber das würde hier den Rahmen sprengen, vorallem da die IL-Sprache bisher wohl noch keinen Sinn ergibt. Die Vorteile sind das IL-Debugging sowie die Übersicht. In mehreren Fenstern bekommen wir die Argumente und lokalen Variablen der aktuellen Funktion anzeigt und können und diese auch im genialen Object Viewer anschauen. Nach einer kleinen Einarbeitungszeit wird man dieses Tool lieben, vorallem wenn man sich nicht nur auf oberflächliche Analysen beschränken will.

Nach dieser kleinen Einführung geht es direkt an das heutige AnalyseMe 01. Natürlich wird man nur mit den Tools vertraut wenn man sie auch Anwendet, mit einem Tutorial ist hier nichts getan. Aber wer diesen Schritt noch nicht verstanden hat sollte sich generell überlegen, was er überhaupt mit Reversing will

Wenn wir AnalyseMe 01.exe wahlweise im .NET Reflector oder in ILSpy öffnen, so werden wir folgenden Code für die Main-Funktion bekommen:

private static void Main(string[] args)
{
    byte[] Bla = Blob(UltraSecret);
    for (int i = 0; i < Bla.Length; i++)
    {
        Bla[i] = (byte) (Bla[i] - i);
    }
    Assembly.Load(Bla).EntryPoint.Invoke(null, new object[] { new string[0] });
}

Relativ unverständlich, nicht? Aber würde es AnalyseMe heißen wenn der Code Sinn ergibt?

Anscheinend wird in der ersten Zeile eine Variable namens UltraSecret einer Funktion übergeben, welche ein Byte-Array zurückliefert. Wenn wir einen Blick auf die Blob-Funktion werfen, werden wir feststellen dass hier ein Base64-String in ein Byte-Array decodiert und anschließend von der Funktion zurückgegeben wird. Bla ist nun gefüllt mit Bytes aus dem decodierten Base64-String UltraSecret. Nun wird in einer Schleife jedes Byte durchgegangen und die Anzahl des aktuellen Durchlaufs von dem aktuellen Wert abgezogen. Schlussendlich wird wohl eine .NET Assembly geladen und der EntryPoint (Einstiegspunkt) aufgerufen. Da die Main()-Funktion dieser Assembly wohl einen String-Array erwartet, wurde hier ein String übergeben.

Doch schauen wir uns das ganze Schritt für Schritt im ILSpy-Debugger an. Ein Breakpoint wird wie in Visual Studio über das Klicken auf den linken Rand gesetzt, danach einfach Rechtsklick->Debug Application. Sobald mal mit der Maus über eine Variable fährt wird einem diese angezeigt:

Die Variable UltraSecret kann aber nicht angezeigt werden… Dafür könnten wir jetzt entweder DILE verwenden um die lokale Variable abzugreifen, oder wie schauen nach wann diese Variable initialisiert wird. Oder wir setzen einfach ein Breakpoint auf die Blob-Funktion und greifen so den Parameter ab. Wie dem auch sei, damit ist das “Rätsel” schon geknackt. Es wird ein hardcoded, base64-codierter String eingelesen und in ein Byte-Array decodiert. Diese Bytes werden durch einen Schleifendurchlauf wieder in den Orginalzustand versetzt und anschließend wird eine Assembly aus diesen Bytes geladen und gestartet. Das könnte vereinfacht das Verhalten eines Crypters sein

Fragen und Kritik können natürlich in den Kommentaren hinterlassen werden.

Download:
AnalyseMe 01 (127)

Greez Easy

4 people like this post.

Like

Unlike

Andere Artikel zu dieser Serie

1. .NET RE Tutorialserie - Obfuscatoren und Gegenmaßnahmen (Dezember 8, 2011)
2. .NET RE Tutorialserie - Video-Lösung zu PatchMe #02 (Dezember 3, 2011)
3. .NET RE Tutorialserie – PatchMe 01 & 02 (November 23, 2024)
4. .NET RE Tutorialserie - AnalyseMe 01 (This post) (November 10, 2024)