Blog von eddy14

Tanz der Algorithmen

Ich fange mit meinen berühmt berüchtigten Worten an: Mir war mal wieder langweilig.

Um genau zu sein, hatte ich wieder Lust, geheime Systeme zu erforschen. Systeme, die ich nicht erforschen darf, und nicht soll. Wie mir mal ein weiser Türke anvertraute: Wir Türken haben einen großen Drang, genau das zu tun, was Verboten ist. Es liegt uns allen im Blut, um es mal mit den Worten des dritten Reiches zu sagen.

Ich blogge heute mal wieder etwas in Richtung Reverse Engineering von proprietären Systemen. Ich werde versuchen, etwas mehr Lehrreiches in mein Posting einzubringen. Also: Aufpassen!

Wie in meinem letzten Posting bereits angedeutet, geht es diesmal um Anti-Leech. Ich zitiere mal eine einzige Zeile, die ausreicht, um meine dunklen Augen zum Leuchten zu bringen:

With help of Anti-Leech you can protect your file links using an encrypted communication which will make it impossible for people to see where they actually download from and leave you in total control!

Ein müdes lächeln beschmückt mein Gesicht. Nicht, weil ich meinen Gegner unterschätze, sondern weil ich wirklich müde bin! Ein bisschen Recherche zeigt mir, dass bereits im Jahre 2005 ein Decrypter existierte. Der Programmierer hat anscheinend das Java Plugin von Anti-Leech decompiled, und nachgebaut. Aber ich möchte nocheinmal verlauten lassen, dass ich das alles nur just4fun mache (wen erinnern diese Worte auch, an das hier?). Und nicht, weil meine Arbeit für irgendjemanden wichtig ist.

Ich habe mir also erst einmal angeschaut, was dieses Anti-Leech denn genau ist: Es ist ein Browser-Plugin. Installiert man es, kann man spezielle Downloads, die per Anti-Leech geschützt sind, herunterladen. Der Sinn und Zweck ist, den Ort der Datei geheimzuhalten. Vermutlich ist der Grund, sich vor Abuse zu schützen. Die Dateien sind wohl illegal, und liegen auf Freehostern, die nichts davon wissen. Aber Anti-Leech kann noch mehr: detailierte Statistiken über Downloads, Passwortschutz und Traffickontrolle. Wer macht das ganze Zeug denn total irrsinnigerweise Clientseitig? Ein Server kann das alles, ohne dass der Besucher ein Plugin installieren muss, der auch noch einzig und allein auf Windows Betriebssystemen läuft. Kerckhoff würde lachen. Um mehr über Security by Obscurity zu erfahren, lese meinen alten Post über SFT.

Also habe ich mir das Plugin runtergeladen, installiert und erstmal probiert. Ich kenne nur eine Seite, die Anti-Leech noch benutzt. Mal schnell die Seite aufgerufen, einen Download gestartet, und gestaunt was passiert. Das Plugin erzeugt in meinem Firefox einen neuen Content, der mich den Downloadordner der Datei bestimmen lässt. Ein Button betätigen, und schon wird die Datei heruntergeladen. Die Datei selbst ist auch verschlüsselt, aber mit einem ganz anderen Programm. Dem FLP Loader. Laut meiner damaligen Twitter Nachricht, hatte ich das FLP Format bereits am 12ten Juli diesen Jahres dokumentiert. Die halbe Arbeit war also schon erledigt.

Der nächste Schritt wäre nun, zu prüfen ob das Plugin die einfachste aller Möglichkeiten verhindert: Mit einem Sniffer nachschauen, woher die Datei runtergeladen wird. Es kommt unerwartet: der Sniffer wird nicht erkannt. So einfach wäre die Sicherheit bereits gebrochen. Oder einfach, indem ich dem System ein Proxy schalte, oder einen Sniffer auf einem anderen Rechner im LAN (eventuell sogar auf dem Router?) installiere. Vermutlich auch, wenn ich die HTTP Aufrufe des Programmes einfach redirecte.

Wie auch immer, ich wollte was ganz anderes: Assembler! Eine Tatsache bestätigt meinen Ruf als Freak: Wenn ich Hunger bekomme, dann steigt meine Lust auf das Programmieren sowie das Hacken immens. Ich werde Hungrig nach beidem.

Und ich war hungrig. Man, war ich hungrig, ich hätte ein ganzes Sojapferd verdrücken können. Ich war ein Drogensüchtiger, der die Volumenregelung seines Musikplayers genauso dosiert wie das Volumen seiner Heroinspritze. Gangstas Paradise verführt mich in eine phantastische Welt voller sprechender Schlangen, wovon eines, eine Frau zu dem Genuss einer Frucht verleitet, woraufhin ein bärtiger Magier mich zum Leben auf der Erde verdammt, auf das meine ganze Rasse leide.

Phantasie hilft Zusammenhänge zu verstehen, in einer Welt voller Befehle und Zahlen. Also starte ich den Mainstreamdebugger schlechthin: Ollydbg. Wie Einstein schon einst feststellte, braucht man nur Stift, Papier und seinen Verstand um die Welt zu erforschen. Deswegen stelle ich mir eine schöne Welt vor, in der ich genau das tun kann:

Reverse Engineering im Real-Life

Also fange ich an zu debuggen. Das blöde an diesem Programm ist: es ist ein Plugin. Eine DLL. Ich kann sie zwar in meinen Olly laden, aber ausführen kann ich sie nicht. Also debugge ich meinen Firefox Browser, switche per Kontextmenü zu der DLL und schaue mir vorerst ein paar Strings an.

RSA_private_decrypt returned error

Aha. Sieht ja sehr interessant aus. Vielleicht ein Asymmetrisches Verschlüsselungsverfahren? Das wäre nice, bisher hatte ich damit nichts zu tun! Um einen Blick für RSA Code zu bekommen, habe ich mich in diverse Spezifikationen eingelesen, und mir C Code dazu angeschaut. Mit dem Gedanken, dass ich Codeteile eventuell später beim Debuggen entdecke, und somit meine Vermutung bestätigen kann, dass es sich hier um RSA handelt.

Leider kam heraus, dass dies nicht der Fall ist. Ein paar Breakpoints, und einigen Analysen später, fand ich folgendes heraus: Der Client sendet eine ganz normale GET Anfrage an den Anti-Leech Server (der “normale” Link zur Download Datei, den jeder zu Gesicht bekommt). Allerdings mit einer speziellen Regelung. Es wird ein neuer Eintrag in den Header der HTTP Abfrage eingefügt:

X-AL-User-Agent: ALNN/1.0

AL steht sehr wahrscheinlich für “Anti-Leech”. Erst dann reagiert der Server mit der entsprechenden Antwort, die folgende Zeile im Header enthält:

X-AL-Location: scramble:[Verschlüsselter Inhalt]

Der Inhalt ist nur eine Zeile lang. meistens genau 60 Zeichen lang. Ich habe also als nächstes in den Strings nach dem besagten “scramble”, sowie “X-AL-Location” gesucht, und überall einen Breakpoint gesetzt, wo es nett aussieht. Um noch die Bereiche davor zu analysieren, habe ich einen Breakpoint auf CreateFile erstellt. So sollte es mir möglich sein, genau dann zu breaken, wenn die Datei fertig runtergeladen wurde.

Nun hatte ich eine ungefähre Vorstellung davon, wo genau sich die “geheime” Stelle im Code befindet.

Die Untersuchung der Descramble Funktion führte auf das folgende Ergebnis: Im verschlüsselten String befinden sich einige Stellen, die so aussehen wie: “%35″. Jeder Bereich, der mit einem Prozentzeichen begann, und zwei darauffolgende Zahlen beinhaltete, wurde von der Descramble Funktion seziert. Es ist eigentlich ganz simple. Solche Werte werden einfach (in diesem Fall) durch den ASCII Wert von “35″ ersetzt. So ergibt sich am Ende der normale Ciphertext. Nun gilt es herauszufinden, welcher Verschlüsselungsalgorithmus verwendet wurde, und welcher Schlüssel.

Und genau das ist es, was mir so viele Schmerzen im Arsch bereitet hat (um es mal schlecht übersetzt zu sagen). Die Verzweiflung bringt einen dazu, verrückte Sachen zu tun. Neben mir lag ein Stift, dessen Abdruck man einfach Wegwischen kann. Und vor mir war mein Kleiderschrank. Es kam wie es kommen musste:

Mein Kleiderschrank als Notepad

Die Werbung für die Piratenpartei ist unbeabsichtigt!

Nun sah ich nur flüchtig über die Verschlüsselungsmethoden hinüber, und hatte ein paar Vermutungen:

Es ist:

-DES

-Triple-DES

-Blowfish

-RSA

-Lupus

Da es niemals Lupus ist, konnte ich das schon rausstreichen.

Nachdem ich das Verschlüsselungsverfahren genauestens erforscht und dokumentiert hatte, war ich mir über eines sicher: Es konnte nicht RSA sein. Denn der Schlüssel berechnet sich auf eine Weise, die sehr untypisch (wenn nicht sogar unmöglich) für RSA ist. Mit MD5 aus einem konstanten Wert, dem IV sowie dem Datum, den wir per HTTP selbst mitsenden. Letzteres vermutlich auf Grund der Obfuscation. In Python könnte man es so beschreiben:

1. const_iv = “\x14\x3f\x71\xfb”
2. m = hashlib.md5()
3. m.update(“/dlm_download.php/[FILENAME]&id=[ID]&dyn=[NUMBER]&changename=&netpumperquery=1&mirror=0″)
4. m.update(“Sat, 31 Oct 2009 22:43:28 GMT”)
5. a = hashlib.md5()
6. a.update(m.digest())
7. a.update(“\x4A\x29\xD1\x8B\xAD\x5B\x58\x79\x35\x8E\x21\x68\x84\xA6\x7C\xB4\x38\xDE\x5B\xF0\x96\x53\x98\xBF\xA3\x07\x91\xF6\x76\x59\x9F\x6D”)
8. a.update(const_iv)

Wie man im Code sieht, existiert ein IV. Das heißt also, es ist kein ECB Modus.

So blieb nur noch DES, Triple-DES und Blowfish übrig. Der Grund für diese starke Eingrenzung liegt daran, dass ich bemerkt habe, dass es ein block cipher ist. Und zwar einer, mit der Blocklänge von 64 Bit. Eigentlich war ich mir bereits sicher, dass es kein Blowfish ist. Der Krypto ANALyzer von PEiD zeigte mir, dass in der Datei irgendwo die S-Box von DES existiert. Und genau diese wurde von dem Verschlüsselungsalgorithmus referenziert. Vermutung also: Es ist DES, oder Triple-DES. Ich kam mir mittlerweile wie Dr. House vor, der versucht, eine Krankheit zu identifizieren. Ironischerweise verspürte ich Schmerzen an meinem Bein. Das war ein Zeichen Gottes! (Oder es lag daran, dass mein Fahrrad kaputt war, und ich deswegen 3 Stunden zu Fuß laufen musste … Hm, nein sicher nicht, es war garantiert ein Zeichen!)

Um nun den Rest herauszufinden musste ich nur schauen, wie lang der Key ist. Wenn es nur 8 Bytes sind, dann ist es DES (sehr wahrscheinlich). Ansonsten (falls 16 oder 24 Bytes) ist es wohl Triple-DES. Nun, der Key ist aber 32 Bytes lang. Das passt weder zu DES, noch zu Triple-DES. Einige Strings gaben mir aber Hoffnung: Es wurde wohl die Crypto API von OpenSSL verwendet. Nun konnte ich dort nachschauen, ob eine nicht-standartisierte Funktion programmiert wurde, um längere Keys zu verwenden.

Die einzige Möglichkeit die sich erübrigt ist: DES_xcbc_decrypt. Dieser verwendet wohl einen Key, variabler Länge. Da aber dieser Modus von keiner Python Library implementiert wurde, sank meine Motivation auf 0, um einen Decrypter zu schreiben. Nach so vielen Wochen der Arbeit, sollte igendwann Schluss sein. Ich kann also nicht verifizieren, ob meine Vermutung stimmt. Das wäre der letzte Punkt gewesen, um die Doku von Anti-Leech komplett zu machen.

Somit beende ich meine Arbeit an diesem Verschlüsselungssystem, mit dem Gewissen, dieses Target (wenigstens größtenteils) auch besiegt zu haben Falls ich den Decrypter irgendwann fertigschreibe, nenne ich es “Leech-Toaster” (der obligatorische Dank an dieser Stelle an n4pster-3D*).

Grüße gehen natürlich auch an kugelfisch (wann kommen mal wieder neue Posts von dir?) dem ich unter anderem verdanke, dass ich mich überhaupt für proprietäre Formate und Protokolle interessiere

This entry was posted on Saturday, November 7th, 2009 at 19:22 and is filed under IT Security, Reverse Engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.