• Skip Navigation

Blog von eddy14

Search for:

• Home
• About me
• Reverse Engineering
• Software
• Tutorials

Des Kaisers neue Kleider

Die letzten Tage war mein Blog down. Woran lag es?

Nach der Erstellung meines Beitrages über das OTRKEY Format waren einige Leute ziemlich angepisst. Und ich nehme es ihnen nicht mal Übel. Häufig ist es viel einfacher den Überbringer der schlechten Nachricht zu erhängen, anstatt das Problem an der Wurzel zu packen.

Nun, was habe ich verbrochen? Ich habe Daten befreit, die jedem Benutzer des Dateiformats auf dem Computer liegen. Sie alle benutzen diese Informationen, um OTRKEY Dateien zu entschlüsseln. Der einzige Unterschied ist: sie wissen es nicht. Um mal das Beispiel aus meinem Beitrag zu nehmen: Das ist so, als ob man jedem ein Buch schenkt, aber insgeheim hofft, dass alle Analphabeten sind. Und dann wundert man sich, wenn jemand doch das Buch aufschlägt, und darin lesen kann.

Wer macht sich die Mühe, Geschäftsgeheimnisse in der Sprache Esperanto zu verfassen und sie dann zum Download anzubieten? Man speichert es auf tausenden von Computern. Und dann ist man wütend, wenn jemand die Sprache lernt, und die Dokumente lesen kann. Wer ist hier Schuld; der Typ der sich die Mühe macht die Sprache zu lernen, oder war es eventuell doch falsch, Geschäftsgeheimnisse frei zu verteilen? Ist es überhaupt noch ein Geheimnis, wenn es sich jeder frei, legal und offiziell aus dem Internet runterladen kann?

Die Informationen auf meinem Blog sollten entfernt werden, weil es einigen nicht gepasst hat. Wenn es darum geht, jemanden zum Schweigen zu bringen, dann geht es nicht mehr um das Dateiformat. Es geht um den freien Informationsfluss.

Mein Dekoder hat keine, ich wiederhole keine keine keine bösartige Funktionalität. Es ist ein stinknormaler Dekoder. Es funktioniert genauso wie die offiziellen Dekoder. Es ist kein Crack, nicht im entferntesten. Es ist eine Reimplementation des Dekoders. Mein Vorhaben ist auch nicht, irgendjemandem zu ermöglichen, das System zu zerstören. Der Dekoder soll in OpenSource Programmen benutzt werden, welche OTRKEY-Dateien entschlüsseln können. Diese basieren jedoch alle auf den proprietären Dekoder, und sind somit nicht 100% offen und frei. Das ist gleichbedeutend mit Schmerzen im Arsch.

Es wurde 5 Jahre lang, bewusst auf ein unsicheres System gesetzt. Ein System, auf wackeligen und zerbrechlichen Füßen. Das System ist nicht erst kaputt gegangen, als ich darauf hingewiesen habe.

Während alle vorgaben, dass alles mit dem System okay ist, habe ich einfach nur die Tatsache ausgesprochen, dass es das nicht ist. Ihr könnt ja von mir aus vorgeben, dass der Kaiser schöne Kleider an hat. Aber ich bevorzuge die Wahrheit. Der Kaiser ist nackt.

Steinigt mich.

OTRKEY-Breaker

eddy14@toFoo:~/workspace/coding/OTRKEY-Breaker$ ./otrkey-breaker ../Der_Wilde_von_Montana_10.04.08_01-15_ard_80_TVOON_DE.mpg.avi.otrkey eddyX@hotmail.de xxxx
OTRKEY-Breaker by eddy14 (v0.3)
Opening OTRKEY-File … OK
Reading magic header … OK
Decrypting OTRKEY-Header … OK
Generating bigKey … OK
Building encrypted HTTP-Link … OK
Getting key from server … OK
Decrypting response … OK
Final Step: Decrypting OTRKEY-File …
100%
Finished. Enjoy your decrypted file!

Wuhuu! Ich saß nun seit einigen Wochen (in der letzten Woche ziemlich intensiv) an diesem Dateiformat. Es nennt sich OTRKEY und wird für die (bekannte) Webseite www.onlinetvrecorder.com verwendet (es handelt sich nicht um Off-the-Record Messaging). Die Programmierung des Dekoders war nicht einfach fuer mich, da ich gewoehnlich nicht in C++ programmiere. Das Dateiformat ist nicht ganz so trivial, allerdings auch nicht äußerst kompliziert. Aber es hat Spaß gemacht und mich mit Freude erfüllt.

Die obige Ausgabe ist die meines OTRKEY-Breakers. Dieser kann OTRKEY-Dateien entschlüsseln. Aber anders als der Name vermuten lässt, bricht dieser rein garnichts, sondern tut genau das selbe was die restlichen (proprietären) OTRKEY-Dekoder auch tun. Ich habe mich dazu entschlossen, den Decrypter nicht destruktiv zu programmieren. Ich würde damit wohl Piraterie unterstützen, und ich habe keine Lust auf rechtlichen Ärger. Dataillierte Erklärung darüber, wie man die Sicherheitsbarriere umgehen könnte, um alle OTRKEY-Dateien zu entschlüsseln, ohne die Berechtigung dazu zu haben, folgt weiter unten. Soweit ich weiß, wird in nächster Zeit sowieso ein offizieller open source Dekoder von onlinetvrecorder folgen. Ich weiß allerdings nicht ganz so recht, wie sie auf diese Art ihre Pseudosicherheit noch aufrecht erhalten wollen. Anscheinend gab es schon damals im Jahre 2005 inoffizielle Dekoder, und vermutlich sogar Opensource Programme von anderen, die es reversed zu haben scheinen. Ich weiß nicht inwieweit sich das System seitdem verändert hat. Ich will nochmal ausdrücklich betonen, dass ich hiermit niemandem schaden möchte. Genau deswegen beinhaltet mein Dekoder auch keine böswillige Funktionalität.

Also. Was sind eigentlich OTRKEY Dateien? Das sind verschlüsselte Video-Dateien. Der onlinetvrecorder Dienst bietet seinen Nutzern an, die im TV laufenden Programme aufnehmen zu lassen. Allerdings ist es aufgrund der Urheberrechte nicht möglich, einfach die Sendungen auf der Webseite anzubieten, sodass sie jeder runterladen könnte. Vielmehr wird ein bestimmtes Gesetz ausgenutzt. Demnach dürfen Privataufnahmen angefertigt werden, und man darf sich Sendungen von jemandem aufnehmen lassen. Das alles beruht darauf, dass der Benutzer dem Service bescheid geben muss, dass er die Sendung haben will. Demnach hat er ihn also gebeten, eine Kopie anzufertigen, was nun legal ist (mehr oder weniger; darüber wird anscheinend noch gestritten). Nun werden also die Videos verschlüsselt. Und nur authorisierte Nutzer (die, welche diese Aufnahme in Auftrag gegeben haben) können es entschlüsseln.

Nun folgt wieder eine technische Beschreibung darüber, wie ich vorgegangen bin, um die Spezifikation dieses Dateiformates offen zulegen. Wer das nicht mag, kann nach ganz unten scrollen, um meinen Open Source Klon des Dekoders herunterzuladen. Ich hoffe, nach einigen Verbesserungen können die OpenSource Tools dort draußen, die sonst die proprietären Linux Binarys des offiziellen Dekoders verwendet haben, auf meinen zurückgreiffen.

Als ich mir vorerst nur Gedanken über das Dateiformat machte, hatte ich im Kopf nur soetwas:

Aber das ist nicht wirklich hilfreich. Diese Magie musste ich also nun mit Wissen ersetzen. Also ran an die Arbeit! Ich mache mir Gedanken, wie solch ein System ablaufen könnte. Da fallen mir zwei Möglichkeiten ein. Die erste setzt auf Security-by-Obscurity. Die zweite ist tatsächlich sicher (und tut nicht nur so!).

Also, wir haben zunächst einen Server. Der gehört dem onlinetvrecorder Dienst. Dieser wird dazu verwendet, um zu schauen, ob unser Benutzeraccount authorisiert ist. Das läuft alles auf dem Server ab. Also solange wir nicht den Server hacken (was wir nicht vor haben) ist das Verfahren absolut sicher. Nun haben wir also diese verschlüsselte Datei auf unserer Festplatte. Die Datei kann man auf vielen Mirror-Seiten kostenlos (und legal) herunterladen. Denn mit dem verschlüsselten Müll kann man nichts anfangen. Erst wenn es entschlüsselt wurde.

Das Problem ist nun, dass die Videodatei bei jedem Benutzer den gleichen Inhalt hat. Ergo: Es gibt ein Passwort zum entschlüsseln für diese Datei, egal welcher Benutzer es entschlüsseln will. Und genau dieses Passwort wird uns vom Server übermittelt. Jeder Benutzer der diese Datei entschlüsseln will, bekommt also das selbe Passwort! Es müsste nun jemand das Passwort herausfinden, und könnte es frei ins Internet stellen, und jeder könnte die verschlüsselte Datei entschlüsseln, ohne authorisiert zu sein (denn dann braucht man den Server ja nicht mehr, um das Passwort abzuholen; wir haben ihn ja bereits!).

Ich würde also bis zu dem Punkt, wo wir das Passwort vom Server bekommen, exakt das gleiche machen wie der normale Dekoder. Aber nachdem ich das Passwort habe, würde ich es meinem eigenen Server zusenden, und dieser speichert es in einer Datenbank. Nun kann jeder Benutzer das Passwort von meinem Server abfragen (der natürlich keinerlei Authentifizierung durchführen würde) und wirklich jeder könnte die Videodatei entschlüsseln. Ergo: gebrochen! Und genau das ist bei OTRKEY möglich. Der einzige Nachteil wäre, dass mindestens eine Person die Berechtigung haben müsste, diese Datei zu entschlüsseln. Und alte Aufnahmen (und sehr alte OTRKEY Dateien) wird wohl niemand mehr entschlüsseln, d.h. es wird auch weiterhin nicht möglich sein.

Wie könnte man dieses Sicherheitsloch beseitigen? Indem man für jeden User die Datei individuell verschlüsselt. Im Prinzip “On-the-Run” während er die Videodatei herunterlädt. Das würde aber heißen, dass entweder jedem Mirrordienst die unentschlüsselten Videodateien zugespielt werden müssten (die es wiederum verschlüsselt dem Benutzer geben), was sicherlich ein großes Sicherheitsrisiko darstellt. Oder aber, nur die offiziellen Server werden betrieben (Nachteil: sehr großer Traffic auf dem Server; kostet nicht gerade wenig). Oder aber, man verschlüsselt erst garnicht (wieso auch?) und lässt alle Benutzer vom offiziellen Server runterladen (der auch die Authentifizierung durchführen kann). Ich glaube, letzteres wird sogar in der Form angeboten. Es ist eventuell auch möglich, den Mirrorbetreibern eine Art Authentifizierungsmöglichkeit anzubieten, womit diese den User als “zulässig” identifizieren können, um ihm dann die unentschlüsselte Datei anzubieten. Was mir so spontan einfällt, wäre die Generierung eines einzigartigen Schlüssels, für jede Aufnahme eines Users. Der Mirrorbetreiber fragt nun vor dem Download diesen Schlüssel ab, und teilt den Schlüssel dem offiziellen OTRKEY-Server mit, welcher dann sein “OKAY”-Signal zurück sendet. So weiß der Mirrordienst, dass der User die Datei runterladen darf. Oder aber, man könnte ein spezielles Userpasswort generieren, der nur für Mirroranbieter benutzt wird, welche dann mit diesen Daten den User authentifizieren können, um den Download anbieten zu können.

Die Frage wäre am Ende wieder die der Legalität. Alles was ich sagen kann ist: das jetzige System bietet keinerlei Sicherheit, außer der Verheimlichung gegenüber dem User, was auf seinem Rechner gerade passiert. Das ist im prinzip so, als würde man eine sehr sichere Tür bauen (= Verschlüsselungsalgorithmus) dann aber den Schlüssel unter die Blumenvase vor der Tür tun (= Security by Obscurity). Oder: man verschenkt an jede Person ein Buch, in der Hoffnung dass alle Analphabeten sind, beschwert sich dann aber, wenn jemand doch darin lesen, und Informationen entnehmen kann.

Nun gilt es wie immer herauszufinden, welcher Algorithmus im Dekoder verwendet wird, und wie die Datei generell gehandhabt wird (Schlüsselgenerierung etc.). Dazu benutze ich einen Debugger/Disassembler Namens OllyDbg. Ich trace also gemütlich durch die Datei, und versuche spannende Stellen in der Datei zu markieren (bereits das hat mich mehrere Tage gekostet).

Wie man sieht, ist das Bild noch vom 23. Februar. Ich war da gemütlich am tracen, um den Programmablauf zu verstehen.

Irgendwann werden die ersten 10 Bytes der Datei ausgelesen:

Es ist unübersehbar “OTRKEYFILE”. Es scheint ein Wert zu sein, um das Dateiformat zu identifizieren (das ist üblich; die meisten Betriebssysteme erkennen anhand von solchen Mustern den Typ der Datei, und nicht durch die Dateiendung).

Ich habe einen Breakpoint an den Punkt gesetzt, andem der OpenFileDialog aufkam. Denn genau danach, würde die Datei geöffnet, und der Inhalt bearbeitet werden. Und so kam es auch. Nach kurzer Zeit erblickte ich einen String, und zwar in dieser Form:

http://www.onlinetvrecorder.com/webrecording/isuser.php?email=[1]&pass=[2]

Wobei [1] meine email-Adresse war, und [2] der MD5-Hash von meinem Passwort. Und der Name der PHP-Datei “isuser.php” lässt darauf schließen, dass geprüft wird, ob wir uns mit diesen Daten korrekt einloggen können. Das interessante an diesem String ist, dass es hier einen MD5-String verwenden. Ich breake also einige CALLs vor diesem String, und versuche herauszufinden, welche der CALLs die generierung des MD5-Hashs durchführt. Gesagt getan, und schon habe ich einen schönen Breakpoint dort sitzen, und werde jedes mal benachrichtigt, wenn ein MD5-Hash generiert wird. Das ist sehr hilfreich. Denn Hashs werden sehr häufig als Schlüssel für Verschlüsselungsalgorithmen benutzt.

Und wenn man diese Webseite mit seinen eigenen Daten mal selbst aufruft, sieht man, dass es nur ein “yes” oder “no” zurückgibt. Genau das wird auch im Programm abgefragt, und jenachdem führt das Programm dann fort, oder meldet einen Fehler.

Irgendwann später fällt mir auf, dass hier der MD5 Hash von “Windows” sowie von “00:00:00:00:00:00″ generiert wird. Ich hatte schonmal in einem Post erwähnt, dass dieses Programm insgeheim die MAC-Adresse sowie das Betriebssystem (und die lokale IP) überträgt. Gott weiß warum. Hier wurde es aber durch diese beiden konstanten Hashs ersetzt. Anscheinend brauchen die diese Daten doch nicht mehr.

An einem Punkt merke ich dann, wie die nächsten 0×100 Bytes der Datei eingelesen werden. Und nach einigen CALLs, wurde es durch einen schönen String ersetzt. Hat etwa eine Entschlüsselung stattgefunden? Bin mir ziemlich sicher, dass es passiert ist! Jetzt wirds heiß. Einige Breakpoints setzen, und laaaangsam durchhangeln. Und siehe da, ich sehe etwas, was tatsächlich brauchbar aussieht:

Allein aus diesem Stück Code, konnte ich nun den Algorithmus ausfindig machen. Wie ich das gemacht habe? Ganz einfach: Ich bin dem Code bis zum ersten memcpy gefolgt. Nun habe ich mir angeschaut, was dort genau kopiert wird:

Diese Werte sehen sehr sauber aus, und nicht nach binärem Bullshit. Das könnte wieder etwas generiertes vom Programm sein (und wie ein Physiker, wollen wir natürlich das Elementare finden, das, woraus das Höhere hier entstanden ist). Allerdings machen wir es uns einfach, und schauen erstmal, ob es einen bekannten Algorithmus gibt, der diese Daten verwendet. Also nehmen wir die ersten 4 Bytes “243F6A88″ (beachtet das Little-Endian-System!) und googlen danach. Achtung: das folgende ist keine Google-Werbung! Es ist ein Bild:

Es ist hier ziemlich viel die Rede von Blowfish. Und zufälligerweise, ist das ein Verschlüsselungsalgorithmus! Unter der Annahme, dass dieser Wert von keinem anderen Algorithmus verwendet wird, behaupte ich: OTRKEY verwendet Blowfish! Anscheinend tut dieser Assembler-Code nicht viel, als diese Werte in den Arbeitsspeicher zu legen, um sie später zu verwenden. Im zweiten memcpy wird ein weiterer Wert kopiert. Diesmal mache ich das gleiche mit den ersten 4 Bytes, und finde heraus, dass es auch zu Blowfish gehört. Bei diesen beiden Werten handelt es sich um die P- sowie S-Box von Blowfish. Ich weiß nun, dass nach der Initialisierung eine Ver- oder Entschlüsselung folgen muss. Und ich finde einen weiteren CALL dessen Adresse sehr nah an dem Initialisierungs-CALL liegt (eine Möglichkeit, die Zusammengehörigkeit von CALLs zu identifizieren). Und zwar das hier:

Es ruft die Initialisierungsfunktion auf (ich weiß nicht, wieso er das noch einmal tut). Das sieht schonmal spannend aus. Unten sieht man eine Schleife, die gerade anfängt. Etwas weiter unten geht der CALL weiter:

Sehr roh und primitiv sieht das alles aus. Da kriege ich echt Herzklopfen dabei! Jedenfalls sieht das nach einer Menge Arbeit aus, und das ist total genial. Denn das zeigt uns, dass hier irgendwas mit Daten getan wird. Anscheinend werden die geXORed usw. Hier sieht man oben, dass die erste Schleife aufhört, und eine neue beginnt. Weiter unten läuft der CALL so ab:

Wichtig hierbei ist, dass hier wiederum die letzte Schleife aufhört, dann aber zwei Schleifen anfangen, die ineinander sind. So etwas wie while() { while() { } }  oder for() { for() { } } … ihr versteht schon!

Nun haben wir ein Muster, nach dem wir in Blowfish-SourceCodes suchen können. Und zwar diesen:

Schleife {

}

Schleife {

}

Schleife {

Schleife {

}

}

Auf der Webseite des Blowfish Entwicklers Bruce Schneier finden wir einige SourceCodes zu Blowfish. Ich durchforste mal eines, und ich finde folgendes:

Na, passt es nicht unserem Muster? Nun wissen wir sogar schon den Namen unseres Calls: Gen_Subkeys. Das deutet darauf hin, dass hier die Subkeys generiert werden. Eine gänzlich normale Vorgehensweise in Blowfish. Wikipedia sagt “Aus diesen Schlüsselbits werden vor Beginn der Ver- oder Entschlüsselung Teilschlüssel, so genannte Rundenschlüssel P₁ bis P₁₈, und die Einträge in den S-Boxen von aufsummiert 4168 Bit erzeugt.”. Das scheint hier zu geschehen. Nun haben wir schon die Initialisierung und die generierung der Subkeys gefunden zu haben. Aber wenn ich Wikipedia richtig verstehe, wird für Gen_Subkeys bereits der Schlüssel für die Ver-/Entschlüsselung referenziert. Also schaue ich mal in den Registern nach, und versuche zu verstehen, wann der Code den Key anspricht. Und ich werde fündig:

Das rot markierte sieht sehr schön nach einem Key aus. Der rest wiederholt sich merkwürdig, deswegen habe ich es Orange markiert, da ich mir nicht sicher bin, ob dieser noch zum Key gehört. Ich könnte nun im Stack (oder in den Registern) suchen, ob dort die Länge des Keys mitgegeben ist. So könnte ich herausfinden, welche Werte genau zum Key gehören. Der Rest könnte nur Müll sein, oder aber auch ein Initialization Vector für (beispielsweise) den CBC-Modus. Jedenfalls werden wir herausfinden, dass der Rot markierte Bereich tatsächlich unser Key ist, und der Rest unbrauchbar. Hier nochmal der Key ausgeschrieben: EF3AB29CD19F0CAC5759C7ABD12CC92BA3FE0AFEBF960D63FEBD0F45

Hey! Ich weiß nun sogar den Key. Ist das nicht toll? Ich weiß zwar nicht, woher der Key kommt, aber das stört im moment nicht. Darum kümmere ich mich später. Wir vermuten also: Blowfish ist der Verschlüsselungsalgorithmus, und wir haben den Key gefunden!

Nun, das sieht doch ganz gut aus! Viel sicherer werden wir uns etwas später, bei der Entschlüsselung von Daten. Ich weiß ja, wie bereits erwähnt, dass nach einer Initialisierung (und dann dem Gen_Subkeys) eine Ver- oder Entschlüsselung folgen wird (sonst macht die Initialisierung ja keinen Sinn). Also taste ich mich immer mehr voran. Und irgendwann bin ich tatsächlich in einer Crypt-Routine. Das vermute ich, weil es nach “rohem” Code aussieht, mit viel XORen und auslesen von Werten. Und (sehr wichtig!) der CALL befindet sich in der Nähe der Initialisierung und Gen_Subkeys Funktion.

Nun ist Achtsamkeit geboten, denn aus der Ver-/Entschlüsselungsfunktion können wir sehr viele Informationen gewinnen um den Algorithmus herauszufinden.

Wenn man sich meine rot markierten Stellen anschaut, dann sieht man, dass hier 2 mal 4 Bytes ausgelesen werden. Nun schaut euch oben nochmal das Bild mit dem “OTRKEYFILE” header an. Die darauffolgenden Bytes sind 0x1D158EC9. Das ist auch der Wert im EBX Register! Es werden also momentan die ersten 4 Bytes der OTRKEY Datei entschlüsselt. Dabei wurde noch garkeine Abfrage an den Server gesendet, um den Key zu enthalten. Hm, was passiert hier?

Wenn man sich nun durch die ganze Schleife hangelt, merkt man, dass die ersten 8 Bytes der Datei entschlüsselt wurden. Das kann ich einfach daran erkennen, dass die 8 Bytes plötzlich mit sinnvollen Daten ersetzt wurden:

Merkt ihr den kleinen aber feinen Unterschied? Es sind die ersten 8 Bytes betroffen. Der binäre Mist wurde zu “&FN=Geis”. Das sieht doch toll aus, der Anfang eines Strings!

Also, pro Schleifendurchlauf  werden jeweils 8 Bytes entschlüsselt. Das sagt uns schonmal, dass es ein Blockcipher ist (da es die Daten blockweise entschlüsselt) und zwar in der Größe von 64 Bit (= 8 Bit * 8 Bytes). Wenn man nun nach “block cipher 64 bit” googled, stoßt man auf (unter anderem) DES und Blowfish. Beide mit einer Blockgröße von 64 Bit. Hier sieht man, dass meine Vermutung DES war, da ich damals noch nicht die Gen_Subkey CALLs etc. gefunden hatte. Allerdings hat DES nur eine Key-Länge von 56 Bit. Das heißt, wenn der Schlüssel länger ist, wird unsere Vermutung wieder auf Blowfish fallen. Wenn wir uns die Gen_Subkeys Funktion von oben anschauen, hatten wir schon einmal einen Key ermittelt. Dieser war 28 Bytes lang. Das entspricht 224 Bit (8Bit * 28 Bytes). Das ist weitaus mehr, als DES und Triple-DES vertragen kann. Blowfish kann allerdings bis zu 448 Bits benutzen (448 Bit / 8 Bit = 56 Bytes). Mehr als genug! Und schon wieder ist es Blowfish! Langsam aber sicher sollten wir akzeptieren, dass es Blowfish ist.

Nun mache ich den Test, der meine Vermutung bestätigen soll. Ich wähle den gleichen Ciphertext, den gleichen Algorithmus, und den gleichen Key. Schnell ist etwas in Python geschrieben. Und das Ergebnis der Entschlüsselung: irrsinnig verfickter Scheiss, es kommt kein richtiges Ergebnis raus! Wieso? Ich habe doch alles richtig gemacht! Ich probiere es mit weiteren Keys (die Orange markierten) usw. Nichts hilft!

Meine Motivation ist fast schon auf dem Nullpunkt, nach so vielen Tagen des Reverse Engineering. Ich bin mir schon fast sicher, dass an dem Blowfish Algorithmus rumgespielt wurde, damit es nicht mehr rekonstruierbar ist. Aber nicht jeder Programmierer kann einen Verschlüsselungsalgorithmus so umschreiben, dass die Entschlüsselung noch funktioniert (und wie man später sieht, müsste man dafür auch etwas in PHP schreiben etc.). Das heißt für mich: sehr viel Arbeit. Denn ich muss die Decrypt-Routine Schritt für Schritt durchgehen, und mit meinem Decrypt vergleichen, um herauszufinden, wo etwas verändert wurde. Das erste und einfachste, was mir dazu einfällt ist, die S-Box und/oder P-Box zu verändern. Das würde das Ergebnis der Ver/Entschlüsselung verändern, aber dennoch funktionieren! Das wäre auch ziemlich schwer zu finden, denn man müsste die gesamte S-Box mit dem Original vergleichen (einige Programme tun das bei MD5 Hashs die sie für die Generierung von Seriennummern benutzen). Egal was es ist, es sollte mir auffallen, wenn ich den Code langsam durchgehe.

Also schreibe ich eine Blowfish library in C++ so um, dass es mir immer ausgibt, welche Werte gerade ausgelesen und geXORed werden etc. Irgendwann  (nach seeeeehr langem debuggen) finde ich endlich den Fehler:

Vergleicht mal Grün mit Grün, und Rot mit Rot. Es fällt auf, dass die Grünen übereinstimmen, aber die Roten nicht! Und wenn man genau hinschaut, dann ist der rote Wert einfach nur in einem anderen Byte-Order, und zwar Rückwärts! aus “0xE8397A7B” wurde “0x7B7A39E8″. Da ist also das Problem! Vermutlich gibt es einen Implementierungsfehler was die Big- und Little-Endian Systeme angeht!

Was ich nun gemacht habe ist, einfach den Wert in meiner Blowfish Library reversed, um zu schauen, ob die Entschlüsselung dann korrekt läuft. Und das tat sie! YEAH! Wegen diesem kleinen Problem, ging die komplette Entschlüsselung nicht. Und, was das lustige an dieser Tatsache ist: ich musste bei meiner Library bewusst einen Bug einbauen, damit es funktioniert!

So, nun bin ich mir sicher: es ist Blowfish! Und ich weiß von oben noch den Key für die Entschlüsselung. Das ist das Ergebnis der Entschlüsselung für eine zufällige OTRKEY Datei:

&FN=Geist_und_Gehirn_10.01.22_22-45_bralpha_15_TVOON_DE.mpg.avi&FH=8C8E880D8B10E502D8D10B50D62988040C629AA5AA588122&OH=7D81885BAB50E88922562162CFA0AA672B506D84EAA32F98&Sw=FALSE&SZ=129542018&H=42C0209272A87222907A8A60D070E240&PD=23AD2A0B0A157E3066B[cut]

Das Ende habe ich rausgeschnitten, weil es zu lang war. Nundenn. Das sieht nach brauchbaren Informationen aus. Eventuell ist eines davon ein Key, den wir dem Server übergeben müssen. So stellt er sicher, dass wir überhaupt eine Entschlüsselung führen dürfen (neben der Kontrolle der Userdaten natürlich). Denn nur ihr offizieller Dekoder scheint ja diesen OTRKEY-Header entschlüsseln zu können (und ich!).

Was ich aber immernoch nicht weiß ist, woher das Programm den Key für die Entschlüsselung her hatte. Da kein Server vorher kontaktiert wurde, ist es möglich, dass der Key entweder aus dem Dateinamen, oder einem bestimmten Bereich der Datei gehashst/generiert wird. Oder der Key ist ein fester wert für jede Datei.

Nach einiger Analyse finde ich eine komische Funktion, die eine Art selbst geschriebene dekodierung durchführt. Es entsteht dabei der Key als Resultat! Als ich nachschaue, woher der Ciphertext herkommt, finde ich mich in der exe-Datei wieder:

Dieser Wert wird aus der .exe ausgelesen, und dann dekodiert, damit unser Key entsteht! Das ist wirklich gut durchdacht. Hätten die nämlich den Key einfach im Klartext in der .exe gelassen, hätte so gut wie jeder Idiot den Schlüssel finden können (obwohl es dennoch nicht einfach ist, den Algorithmus zu finden etc.). So wird sichergestellt, dass es nur nach blödsinnigen Daten aussieht.

Es ist also ein fester Wert, der für jede Datei verwendet wird. Mit diesem konstanten Key kann man den Header von jeder Datei entschlüsseln.

Das wäre geschafft! Wir haben aber nach so viel Arbeit noch nicht einmal begonnen die eigentliche Video-Datei zu entschlüsseln!

Nach einem Stück des Codes gelangen wir zu einer weiteren HTTP-Anfrage. Ich lasse sie laufen, und lasse Wireshark mitsniffen. So sehe ich, was gesendet wird. Es ist ein Link wie folgender:

/quelle_neu1.php?code=K3LMBS+ONd/ZmbUUfrQHacUrFAaPta2PsghPJ9qIDpOEaMOu

/BFOc2rFp6YSmM+PUpdaen2HH45uQ+xTkqoejKUAqefktbOTBOlLqYGLfIdv+vn/uIyQ09eX70HdsSEPp

Ai8qU3dzUIyrj/SDgTEZlToeaBPZhPr04L0ZONliqKvNKNWwgcV4A0+Vwalgfpl/JnFF2JkIulRRMXlSoP9

piJdyWXiomVwNFu/JbaLHy7CKAdLTjJRjGdhhr[cut]&AA=blabla@lol.de&ZZ=20100122

Anscheinend ist es verschlüsselt. Und base64 kodiert. Raffiniert! Sonst könnte jeder mitlesen, und die Anfrage nachbauen. Es werden aber noch zusätzlich meine email-Adresse, sowie das Datum übermittelt (hier war es tatsächlich der Januar). Wofür die Server diese wohl braucht? Und wieso werden die im Klartext versendet? Vielleicht braucht der Server diese, um den Key zu generieren, für die Entschlüsselung des Codes.

Jetzt ist es eigentlich nicht mehr viel Arbeit, die CALLs zu finden, wo die Verschlüsselung der Daten stattfindet. Nach einer Weile weiß ich, was genau passiert. Es wird ein String generiert, der wie folgt aussieht:

&A=meine@email.de&P=meinpassword&FN=Tagesschau_10.04.08_01-05_ard_10_TVOON_DE.mpg.avi&OH=6FAC320BA6002D83EA300498262162BEA5D8D62BD8540750&M=528C8E6CD4A3C6598999A0E9DF15AD32&OS=AEA23489CE3AA9B6406EBB28E0CDA430&LN=EN&VN=0.4.1132&IR=TRUE&IK=aFzW1tL7nP9vXd8yUfB5kLoSyATQ&D=62A85C99224731[cut]

Es wird meine Email-Adresse, mein Passwort, der Dateiname vom OTRKEY-File sowie einige andere Daten gesendet.Der IK-Wert “aFzW1tL7nP9vXd8yUfB5kLoSyATQ” ist ein konstanter Wert der immer mitgesendet wird (und vermutlich zur validierung der Anfrage dient). FN ist der Dateiname. OH ist der Dateihash. M ist der Hash der MAC-Adresse. OS ist der Hash des Betriebssystems. VN ist die Version des Programmes. Alles nach D sind zufällige Daten um dem Padding gerecht zu werden.

Um aus diesem Klartext nun einen verschlüsselten Text zu erzeugen, wird ein Schlüssel generiert. Für die Generierung dieses Schlüssels benötigt man das Datum, sowie Email und Passwort! In Python würde man die Generierung so ausdrücken:

Es wird also ein Teil des Email-Hahs, ein Teil des Passwort-Hashs sowie das Datum benutzt! Genau desswegen müssen wir Email und Datum im Klartext mitsenden (obwohl sie das Datum eigentlich auch selbst auslesen könnten). Aus der Email-Adresse wird dann in der User-Datenbank das Passwort-Hash abgefragt, und damit der Key generiert.

Und dann wird der HTTP-String mit dem Blowfish-Algorithmus im CBC-Modus verschlüsselt (der IV wird zufällig generiert, aber nicht migesendet. Das resultiert in einer korrumpierten Ausgabe, wobei allerdings nur die ersten 8 Bytes betroffen sind. Diese wurden allerdings auch zufällig drangehangen, von daher, ist es ziemlich egal)! Der Server antwortet dann entweder mit einer Fehlermeldung, oder einem base64 kodierten Wert. Dieser Wert wird dann wieder mit dem gleichen Schlüssel wie bei der Verschlüsselung im CBC Modus entschlüsselt. Und somit haben wir vom Server folgenden String empfangen:

&IB=cGkQx8p3mO1wYf6zWsA9rLiTubZq&HP=B5507180E1303191585E20FF71EC4A8D7DCC54DC31F38147B8397BF2&P=meinPasswort&A=meine@email.de&SW=TRUE&IS=http://www.onlinetvrecorder.com/thanku.php?code=JkE9ZWRkeTE0MUBobmTE4[cut]&DW=FALSE&SB=TRUE&D=33FE1DDCA7863117226C7[cut]

Das ist alles so gut wie unwichtig, außer der Wert hinter “HP=”, denn das ist unser endgültiger Key, um die OTRKEY Datei zu entschlüsseln, und die Videodatei zu erschaffen! Dieser muss nur noch im ECB Modus auf die Datei angewandt werden, und wir sind fertig.

Und ich kann mich am Video erfreuen:

Hurra! Es hat tatsächlich Spaß gemacht, aber es hat mich total ausgesaugt. Ich bin ausgebrannt. Ich habe die letzten Wochen die FH geschwänzt, weil mir dieses Programm nicht aus dem Kopf ging. Ich konnte Nachts nicht ruhig schlafen, weil es da anscheinend ein Geheimnis gab, dem ich nicht nachgehen konnte. Wie dem auch sei; hier ist mein Open Source Dekoder für OTRKEY Dateien:

DOWNLOAD (lieber nicht mehr benutzen; siehe unten)

Der Code von mir ist Public Domain. Der Blowfish-Algorithmus ist unter der MPL (ich werde versuchen einen anderen Algorithmus zu finden, der eine bessere Lizenz hat).

Erwartet nicht zu viel. Es kann momentan nur primitiv OTRKEY-Dateien entschlüsseln. Aufruf ist einfach: “./otrkey-breaker dateiname.otrkey deine@email.de deinPassword”. Es gilt natürlich wie immer, dass jeder das Programm verändern kann, wie er mag.

Wie oben bereits erwähnt, habe ich bewusst keine Möglichkeiten eingebaut, um illegal die Dateien zu entschlüsseln.

Für Linux-User: Ich habe gerade keine Lust auf eine Makefile. Aber compilen könnt ihr es ganz einfach mit “g++ *.cpp -o otrkey-breaker” in dem Ordner nach dem entpacken. Oder einfach Code::Blocks benutzen.

Allerdings war mein Decrypter nur schnell zusammengeschrieben. Hier gibt es einen schnelleren, sauberen (kurz: besseren) Decrypter von pyropeter:

OTRTOOL

Nochmal das ganze kurz zusammengefasst: Es wird der Blowfish Algorithmus verwendet. Der Key wird vom Server abgeholt. Es wird jeweils ein konstanter, sowie ein generierter Key verwendet, um die Header-Entschlüsselung sowie URL-Abfragen durchzuführen. Es wird sowohl der ECB wie auch der CBC Modus verwendet, wobei bei letzterem der IV zwar zufällig generiert, aber nicht mitgesendet wird. Die Anfragen behielten früher persönliche Daten (in Form von Hashs), wie MAC-Adresse, lokale IP-Adresse, Betriebssystem und sogar (eine Art?) Seriennummer der Festplatte. Das macht der Standard-Dekoder. Allerdings sendet der Easy-Dekoder diese Daten nicht mehr.

Neue Seiten

Ich habe heute mein altes Laptop angeschmissen und habe mir die ganzen Dateien angeschaut, die sich mit der Zeit dort angesammelt hatten. Es hat sich angefühlt wie eine Zeitreise. Bilder, Scripte, Notizen, Backups usw. Da ist mir aufgefallen, dass ich in der Zeit ziemlich viele kleine (und nützliche?) Programme geschrieben habe. Ich habe mal eine extra Page hier auf dem Blog dafür erstellt. Außerdem habe ich alte Exploits von mir gefunden (SQL Injection und co). Dafür wurde auch eine Page errichtet!

Und für mein aktuelles Interesse, das Analysieren von proprietären Formaten, wurde auch eine Page kreiert Nun sollte man nicht mehr alle meine Posts lesen müssen, um zu sehen, was ich bereits analysiert habe.

Es ist nicht viel, aber vielleicht erfreut das Eine oder Andere irgendjemanden.

Darwintag

Man erkennt es nicht ganz auf dem Bild, aber das soll einen Fisch mit Beinen darstellen. Es ist heute der Darwin-Tag (na, feiert jemand?).

Und es ist wieder Freitag, da könnte ich ja mal wieder bloggen. Ich finde es zwar blöd, ohne ein interessantes Thema irgendwas zu schreiben. Aber ich werde es einfach mal versuchen:

Die Woche über war ich täglich in der Fahrschule. Es wird langsam Zeit für meinen Führerschein. Ich hatte mit 18 angefangen, habe aber lange rumgetrödelt (habe das alles vernachlässigt). Nun bin ich schon 19 und bin immernoch nicht in die Theorieprüfung reingegangen (was sich wohl übernächste Woche ändern wird ).  Wenn ich endlich ein Auto und einen (legalen) Führerschein habe, kann ich mir die 4 Stunden Fahrt täglich in die Fachhochschule und zurück sparen (dauert dann insgesamt nur etwa 50 Minuten). Außerdem habe ich dann Möglichkeiten öfter im Labor und beim Chaosdorf (zum ersten mal) vorbeizuschauen. Vielleicht treffe ich dann auch endlich mal Kabel (und h0yt3r, tmh etc.). Kurz gefasst: ich wäre freier!

Was den unteren Blogeintrag von mir angeht: Bitte nehmt nicht alles wörtlich! Es ist echt unglaublich, wieviel Resonanz das erzeugt hat. Tut wirklich gut zu wissen, dass viele Leute sich damit identifizieren können. Zögert nicht weiterhin eure Erlebnisse mir per Email mitzuteilen. Ich lese das alles sehr gerne!

Zurück zu dem heutigen Thema: Darwin. Es ist erstaunlich wie wenig ich von der Schule über Evolution mitgenommen habe, obwohl ich mich noch daran erinnern kann, jahrelang das Thema im Biologie Unterricht gehabt zu haben. Vor ein paar Monaten als mir das aufgefallen war, stellte ich mir die Frage: Warum? Warum habe ich nichts davon behalten?

Da fiel mir etwas auf: Wir hatten damals im türkisch Unterricht einen ziemlich religiösen Lehrer. Wir haben die türkische Sprache gelernt und nebenbei Religionsunterricht genossen. In der selben Zeit lernten wir etwas über die Evolutionstheorie im Biologie Unterricht. Ich kann mich noch sehr gut an einen Hinweis meines Türkischlehrers erinnern: “Evolution ist eine Lüge! Ihr solltet aber nicht so dumm sein, und den Biologieunterricht verweigern; ihr müsst da durch. Lernt das alles, aber betet vorher zu Gott und erzählt ihm, dass ihr nichts davon glaubt.”

Anders als viele jetzt meinen, war er kein schlechter Mensch. Nur ein typisch religiöser Mensch. Wir mochten diesen Mann sehr. In der damaligen Schule war das typische Szenario: die ausländische Mitschüler wurden (unbewusst) ausgegrenzt. Oder viel eher: die Ausländer haben sich (bewusst) von anderen ausgegrenzt und eigene Gruppen gebildet. Das zeigt sich schon dadurch, dass bei Grillfeiern mit der Schulklasse die Muslime ihr Fleisch selbst kaufen sollten und ähnlichem. Selbst nach so vielen Jahren gibt es zahlreiche Barrieren, die man garnicht mitbedenkt. Und dieser türkischlehrer war einer der wenigen, die uns verstanden. Einer der wenigen türkischen Lehrer die großen Einfluss auf uns hatten. Wir dachten, er versteht uns besser, da er uns näher steht, und uns deswegen besser helfen kann. Ich habe also diesem Mann mehr Vertrauen geschenkt, als jedem anderen. Was er sagte, wurde nicht hinterfragt. Und obwohl dort draußen in der Welt viel Uneinigkeit über den Koran und dessen Interpretation herrschte, schien dieser Mensch alles beantworten zu können.

Als er uns erzählte, die Evolution sei eine Lüge, und sie einfach ins lächerliche zog, waren wir uns auch alle darüber einig, dass die Theorie gänzlich falsch sein musste. “Wenn Menschen aus Affen abstammen, wieso werden dann jetzige Affen nicht zu Menschen? Das ist lächerlich!”, wir kicherten natürlich alle über die Dummheit der Evolutionisten. Es muss ziemlich einfach sein, junge Schüler zu beeinflussen.

Und nun sind mehrere Jahre verflogen und ich beschäftige mich wieder mit diesem Thema. Wieso habe ich es so einfach abgelehnt? Wieso habe ich nicht gerade die Aussagen dieses Mannes hinterfragt? Es ist ziemlich einfach, Menschen zu beeinflussen wenn sie einem vertrauen. Wenn man die einzige Vertrauensperson ist. Die Menschen brauchen wohl mindestens einen Menschen, dem sie bedingungslos alles glauben können; der in ihren Augen immer ehrlich ist.

Okay, anderes Thema: OTRKEY. Ich mache Fortschritte. Ich bin gerade dabei herauszufinden wie die Authentifizierung mit dem Server funktioniert. Es scheint viel Obfuscation verwendet zu werden. Außerdem wird der Hash der MAC-Adresse und der lokalen IP-Adresse verschlüsselt mitgesendet. Wieso? Ich könnte mir vorstellen, dass sie damit Statistiken erstellen, oder es soll eine Art DRM sein? Wie auch immer; sobald mein Decrypter fertig ist, wird niemand gezwungen seine MAC-Adresse oder IP-Adresse mitzusenden (wenn auch nur als Hash). Ich habe momentan nicht die leiseste Ahnung, was für ein Verschlüsselungsalgorithmus verwendet wird, und welcher Schlüssel. Der Code ist leider leer von String-Verweisen [häufig stehen Strings in der exe-Datei die mir Hinweise darauf geben, welcher Algorithmus verwendet wird], sodass ich seit Tagen die Zeit damit verbringe, die CALLs zu benennen. An einigen Stellen sind pfiffige Debugger-Detektoren eingebaut. Ein wirklich sehr nettes Target. Falls ihr weitere Dateiformate und Protokolle kennt, die auf Security-by-Obscurity beruhen, zögert nicht es mir mitzuteilen.

Ich hoffe ich kriege das alles noch fertig, bevor meine Klausurphase (mitte März) beginnt. Sonst wäre ich sehr unkonzentriert beim Lernen. Es sind nur noch wenige Wochen, und ich habe fast keine Ahnung von den ganzen Themen. Wird langsam Zeit, dass ich meinen Arsch bewege.

Salzwasser Sauger

Düm Di Dum Düm, trararara DIIING. Ich wollte schon immer einen eigenen Introsong haben! Wer komponiert einen für mich? *liebschau*

Mir war gestern langweilig, also nahm ich ein Programm ausseinander! Ich wusste, dass meine Motivation nicht sehr stark war, deswegen wollte ich heute nur ein einfaches Programm operieren. Ich weiß leider nicht mehr von wem der Tipp kam, aber mir fiel eine gewisse Warez Seite ein, die ihre Angebote auf FTP-Server hochluden. Dafür wird ein eigens konstruierter Leecher verwendet. Auf der Webseite (die übrigens genauso hässlich ist wie das Programm) lädt man sich eine verschlüsselte “Mirror-File” herunter, die nur ein paar KB groß ist. Mit dem Leecher kann dieser nun geöffnet werden.

Wisst ihr nun, was ich mit hässlich meinte?

Die verschlüsselten Dateien haben die Endung “.swl”, deswegen rede ich hier von SWL-Dateien. Wie jeder Reverser weiß, wird zuerst das Programm auf die übliche Art benutzt. Wir klicken unten auf “Open”, es öffnet sich ein Dialogfenster und wir wählen unsere SWL-Datei aus. Nun lädt das Programm diese Datei, und zeigt uns den Inhalt an, sodass wir mit einem Druck auf “Download” das Herunterladen starten können.

So weit, so gut. Ich knackse kurz meine Finger, feuchte meine Lippen an, hole tief Luft, schaue auf die Uhr, merke mir die Zeit, gehe kurz auf die Toilette, hol mir von der Küche eine Tüte Erdnussflips und freue mich auf den Abend.

Als aller erstes will ich schauen, ob das Programm gepackt ist. Dafür verwende ich PEiD. Den entdeckten Packer lasse ich mir durch ein Stück Software automatisch entfernen, denn mir fehlt echt die Lust auf manual unpacking (und das Einlesen in das Thema erst!).

Nun kann ich es ganz bequem in meinen Debugger OllyDbg laden und anfangen. Ich mache mir natürlich Gedanken, wie ich am besten vorgehen soll, um das Geheimnis des Dateiformates zu befreien. Ich werde hier mal die übliche Vorgehensweise von mir schildern:

1. Dateiformat in einem Hexeditor ansehen um eine ungefähre Idee davon zu kriegen, wie die Datei strukturiert sein könnte.
2. Herausfinden, an welcher Codestelle der Dateiinhalt eingelesen wird
3. Herausfinden an welchem Punkt der komplette Inhalt entschlüsselt wurde
4. Zwischen diesen beiden Stellen an interessant aussehenden Stellen Breakpoints setzen
5. Etwas im Code tracen (während der Ausführung) um ein Gefühl dafür zu bekommen, was (ungefähr) geschieht
6. Nach Mustern im Code suchen, die mir Aufschluss darüber geben, WIE entschlüsselt wird (Algorithmus, Schlüssel, etc.)
7. Wichtige CALLs dokumentieren und benennen um ein besseres Verständnis für den Codeablauf zu haben. Alles was nach einem Schlüssel aussieht, in einer Text-Datei vormerken.
8. Vermutung aufstellen, und bestätigen durch eine Scriptsprache freier Wahl. Beispielsweise Rijndael im ECB Modus auf die Datei anwenden, und schauen ob das Resultat gut aussieht.
9. Wenn das allgemeine Verständnis für die Verschlüsslung da ist, einen Decrypter schreiben.

Der erste Schritt ist sehr einfach und ziemlich interessant! In einem Fall war es mir sogar mal möglich, allein durch das Ansehen des Dateiformates im Hexeditor herauszufinden wie es verschlüsselt wurde (ein einfacher XOR mit dem ersten Byte der Datei). Aber hier siehts nicht so aus:

Fast die vollständige Datei sieht verkrüppelt aus. Sieht nach Verschlüsselung aus (wer hätte das gedacht?). Allerdings befindet sich am Ende eine Webadresse und eine lange Zahl. Die sehen ziemlich wichtig aus! Eventuell ist es der Schlüssel (oder der Schlüssel wird damit generiert, oder es wird an die Seite versendet und dieser gibt uns den Key, oder es ist ein IV, oder oder oder ….). Wir müssen unbedingt solche Vermutungen aufstellen, damit uns später in dem Flut von Assemblercode Muster auffallen. Wenn wir die Webadresse aufrufen, wird uns eingeredet, es wäre ein 404. Schade, vermutlich wird diese Zahl per POST gesendet, oder so ähnlich.

Mehr ist aus dem alleinigen Ansehen des Dateiinhalt nicht zu entnehmen. Also gehen wir zu Schritt 2 über. Wir müssen herausfinden, an welcher Codestelle die Datei geöffnet wird. So wissen wir die ungefähre Stelle von der Entschlüsselung. Nun, betrachten wir noch einmal, was passiert wenn wir auf “Open” drücken. Es erscheint ein ein Öffnen-Dialog. Wieso versuchen wir nicht genau an dieser Stelle das Programm zu stoppen? Dieser Öffnen-Dialog scheint so ziemlich einzigartig zu sein.

Viele Windowsprogrammierer kennen bereits die API GetOpenFileName. Damit erstellt man dieses schöne Öffnendialog-Fenster das vielen Windows-Usern bekannt ist. Genau dort will ich ansetzen. Also tippe ich unten in die Commandbar von OllyDbg “bp GetOpenFileNameA”. Jetzt kann ich mir sicher sein, dass ich genau dann breake, wenn das Programm die Datei auswählt. Ich lass das Programm laufen, und genau so kommt es!

Schritt 3 ist nicht unbedingt Notwendig, aber dennoch hilfreich. Nach dem Öffnen der Datei zeigt das Programm eine MessageBox. Aha! Dort können wir auch breaken. “bp MessageBoxA”. Halleluja!

In Schritt 4 sollen wir nun interessante Stellen suchen. Dafür bediene ich mich der String-Suchfunktion von Ollydbg. Ich scrolle etwas rum, und finde süße Dinge wie “TDCP_twofish”. Das sieht nach der DCPCrypt Bibliothek für Delphi aus. Und “twofish” ist der Name des Algorithmus! Und von “SHA1″ ist auch die Rede. Eine Hashfunktion, auch schön! Also breake ich an den Stellen, wo diese Strings referenziert werden.

In Schritt 5 und Schritt 6 kann man Stundenlang verweilen. Es macht Spaß zu sehen, wie der Entwickler das Programm entworfen und programmiert hat. Man versteht langsam, wieso er jenes und anderes getan hat. Wenn man verfolgt, was mit den Strings passiert die eingelesen werden, dann erlangt man ziemlich schnell Erfolge. Einer meiner Tricks, um zu verfolgen was mit dem Dateiinhalt geschieht, ist es den Anfang der Datei so zu ändern, dass daraus ein String entsteht (ansonsten wäre es ein binärer Inhalt). Beispielsweise ändere ich die ersten Bytes zu “INHALT” und füge ein 00-Byte hinzu. Nun wird mir Ollydbg immer diesen String anzeigen, wenn irgendwo der Dateiinhalt referenziert wird. Ich trace also gemütlich durch den Code und knabbere ein paar Snacks.

Nach einiger Zeit bringe ich in Erfahrung, dass anscheinend ein Hash von etwas gebildet wird. Der Hash ist 20 Bytes lang. MD5 kann es nicht sein, denn dieses hätte eine Länge von 16 Bytes. Aus Erfahrung weiß ich, dass es sich bei 20 Bytes eigentlich immer um SHA handelt. Aus den Strings entnehme ich folgende (für viele merkwürdig erscheinende) Zeile:

ASCII “abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq”

Wenn man nach dem String googlet, wird man zahlreiche Indizien dafür finden, dass diese merkwürdige Anreihung von Buchstaben etwas mit SHA zu tun hat. Da kann ich euch aufklären: Viele der kryptografischen Bibliotheken verwenden einen sogenannten “SelfTest” um sich selbst auf Funktionalität zu testen. Dabei wird der Hash von einem bekannten String erstellt, und mit der (vorgefertigten) richtigen Lösung verglichen. Sind beide gleich, funktioniert die Bibliothek. Und um SHA zu testen, wird (unter anderem) der oben genannte String verwendet. Ich setze also einen Breakpoint in den CALL wo dieser String gelinkt ist, in guter Hoffnung, dass die Library sich bei der initialisierung automatisch selbst testet.

Da ich weiß, dass hier DCPCrypt verwendet wird, bediene ich mich einer sehr guten Methode, um alle wichtigen CALLs zu benennen. Somit wären wir also im siebten Schritt. Ich suche nach Mustern im Code! Zuerst lade ich mir die aktuellste Version dieser Kryptobibliothek herunter. Ich sehe mir die Datei DCPsha1.pas an, um nach einem einfach aussehenden Muster zu suchen. Ich finde die folgende Codezeile:

class function TDCP_sha1.GetHashSize: integer;
begin
Result:= 160;
end;

Das sieht doch sehr schön aus! Eine kurze Funktion, die auch noch mit einer ungewöhnlichen Zahl arbeitet. Diese Funktion gibt die Hashgröße in Bits an, aber das braucht uns eigentlich nicht interessieren (160 Bits / 8 ergibt 20 Bytes, die Größe unseres Hashes!). Nun wollen wir uns überlegen, wie wohl diese obige Funktion in Assembler aussehen könnte. Wenn wir absolut keinen Plan davon hätten, könnten wir uns die Delphi IDE installieren und ein Beispielprogramm mit dieser Library kompilieren (mit zusätzlichen Debuginformationen) und uns dann im Debugger das Resultat anschauen.

Ich kann mir aber bereits denken, wie es in Assembler aussieht. Und zwar so:

mov eax, 0A0
ret

So ungefähr. Also suche ich einfach in Olly nach dieser ersten Zeile. Rechtsklick->Search for->command->”mov eax, 0A0″. Olly wird fündig!

Weiter unten sieht man noch einen Teil des SelfTest-Strings. Wir sind also tatsächlich im Code von SHA. Wir drücken nun die Doppelpunkt-Taste auf der Tastatur, und benennen diesen CALL mit “TDCP_sha1.GetHashSize”. Der ein oder andere wird sich nun fragen “Wieso wollen wir unbedingt diese Codestelle wissen?”. Der Grund ist einfach: Die restlichen Funktionen der SHA-Klasse müssen (eigentlich) in der gleichen Reihenfolge wie im Code hier zu finden sein! Im Sourcecode von DCPCrypt folgt nun “TDCP_sha1.SelfTest”. Und “oh Wunder!”, in OllyDBG sehen wir auch direkt nach der GetHashSize Funktion den SelfTest String. Es stimmt also!

Wir machen einen Rechtsklick auf GetHashSize. Find Refernces to->Selected Command. Von den Resultaten wählen wir das Unmarkierte. Wir finden uns an so einer Stelle wieder:

Das sieht leer und düster aus. Aber da wir bereits eine dieser Stellen auf unsere GetHashSize-Methode zurückführen können, haben wir eine Ahnung wie wir den Rest der Funktionen benennen können. Wir wählen den nächsten “dd dump.*****” in der Liste, klicken Enter und hüpfen zum nächsten CALL. Es ist der SelfTest. Also benennen wir diesen. Dann gehen wir zum nächsten dd-Eintrag und bennen ihn mit “Init”. Denn dieser wäre die nächste Methode im Source-Code gewesen. Am Ende erhalten wir eine wunderbar dokumentierte Liste:

An wichtigen Stellen setze ich hier ein Breakpoint. “Init”, “Update” und “Final”. So kann ich verfolgen, aus welchem String ein Hash erzeugt wird.

Ich lasse das Programm nun laufen, wähle meine verschlüsselte SWL-Datei und breake bei einem der Methoden. Ich kann den Registern entnehmen, welche Daten/Parameter/Argumente der Methode mitgegeben wurden. So entnehme ich ihm die Information, dass aus dem folgenden String ein SHA1-Hash gebildet wird:

0×010203 + “PWsaltwaterPW” + 0×030201

Es scheint ein konstanter Wert zu sein. Ein Passwort, dass in die EXE eingebrannt wurde. Vermutlich wird der Hash als Key für die Verschlüsselung verwendet. Der Hash der sich ergibt, ist also immer konstant folgender Wert: EB EA FB E3 B6 7F 8E 98 19 EE C8 AC 7C 7A 1C CF 3A FB 4D BA

Das ist cool! Ich muss den Schlüssel also nicht selbst berechnen! (Trotzdem irgendwie langweilig und monoton ….). Ich schreibe mir diesen Key also auf, damit es mir nicht verloren geht, und ich die ganze Suche von vorne starten muss.

Plötzlich fällt mir nach einigen Minute auf, dass ich die SWL-Datei nicht mehr öffnen kann. Das Programm teilt mir mit, dass die Zeit abgelaufen sei! Wie bitte? Die Webseite des Leechers sagt mir folgendes:

Achtung:
SWL-Dateien können nur innerhalb von 60 Minuten nach Empfang geöffnet werden. Es spielt aber keine Rolle, wie lange sie dann geöffnet bleiben.

Aha! Da wir gerade eben herausgefunden haben, dass das Programm einen konstanten Key verwendet, kann ich mir sicher sein, dass nicht der Server uns einen temporären Key liefert, zum entschlüsseln dieser Datei. Es ist also der Leecher selbst, der Clientseitig entscheidet, dass wir die Datei nicht mehr verwenden dürfen. Und genau dafür war wohl die URL und die Nummer am Ende der SWL-Datei. Ich patche also kurz die Codestelle, sodass ich alle SWL-Dateien unendlich lange verwenden kann. Das wäre schonmal aus der Welt!

Wenn wir uns an die String-Funde von gerade erinnern: Es war die Rede von Twofish! Also lassen wir unsere Vermutung von dem Krypto-ANALyzer in PEiD bestätigen. Und dieser ist genau unserer Meinung: Es wird der Twofish-Algorithmus verwendet. Wir gehen genauso vor, wie gerade. Wir suchen nach Mustern. Ich öffne ein paar SourceCodes von DCPCrypt, und suche nach schönen Zeilen, die einzigartig sind.

class function TDCP_blockcipher64.GetBlockSize: integer;
begin
Result:= 64;
end;

Also suche ich nach:

mov eax, 080
retn

und ich lande genau an der richtigen Codestelle. Nun gehe ich genauso vor, wie bei SHA1. Und am Ende habe ich so einiges dokumentiert:

Ich breake natürlich an allen interessanten Stellen (so gut wie allen oben genannten). Und ich finde heraus, dass DecryptCBC aufgerufen wird. Somit weiß ich mit sehr hoher Wahrscheinlichkeit dass der CBC-Modus benutzt wird. Nachdem ich bei “Init” und “InitStr” breake (leider auf dem Bild nicht zu sehen), sehe ich im EDX Register den Schlüssel. Und, wie hätte man es sonst erwartet, ist es der Hash den wir oben berechnet hatten!

Schritt 8 => Unsere Vermutung ist also, dass der Dateiinhalt per Twofish entschlüsselt wird. Und der Key ist der konstante Hash, den wir oben herausgefunden hatten. Nun holen wir uns irgendeine Scriptsprache, für die es eine fertige Twofish-Bibliothek gibt. Leider hat es das weder Python (jedenfalls keine funktionierende) noch Ruby. Aber PHP hat mcrypt. Also greiffe ich auf PHP! Ich hatte keine Lust auf PHP, und die Einarbeitung in MCrypt, also habe ich mir schnell von den Beispielcodes etwas zusammenkopiert. Den Decrypter braucht ja sowieso niemand.

Ich finde nur noch kurz heraus, wie die Daten im Plaintext strukturiert sind, damit man sie auslesen kann (alle Daten sind per 0×01 voneinander getrennt. Ganz easy!) und es entsteht (Schritt 9) ein Decrypter:

Schachmatt! SWL wurde geknackt!

Download

Ein Teil dieses Blogeintrages wurde auf der Toilette verfasst. Normale Menschen lesen Zeitung auf dem Klo. Geeks bloggen. Vermutlich einer der Gründe wieso ich so viel Scheisse auf dem Blog produziere (Ah, ich liebe Wortspiele!)