Blog von eddy14

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:

Vor der Entschlüsselung

Nach der Entschlüsselung

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.

This entry was posted on Sunday, April 18th, 2010 at 02:18 and is filed under IT Security. 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.