• Skip Navigation

Blog of eddy14

Search for:

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

HaxoGreen 2010

Vor einigen Wochen hatte ich ein paar Freunde, die ich aus dem Internet kenne, mal im Real-Life getroffen. Und wir hatten auch zusammen etwas gehackt. Es hatte wahnsinnig Spaß gemacht, die Leute zu treffen, die man sonst nur im IM antrifft. Und lustigerweise reden diese Personen genauso wie im IRC, mit all den Abkürzungen, und ab und an hört man sogar Leetspeak. Ich nenne diese Leute “die Illuminaten”, weil sie alles unter ihre Kontrolle reißen können. Ich war beeindruckt zu erfahren, hinter wie vielen Hacking-Aktionen diese Leute standen, von denen ich in den letzten Jahren gehört hatte. Und niemand weiß weder wer sie sind, noch dass sie dahinter gesteckt haben. Genug über die leetesten h4×0rs die ich bisher kennen gelernt habe. Nun etwas anderes:

Ich bin vor ein paar Stunden von einem Hacker Camp zurück gekehrt: dem HaxoGreen in Luxemburg. Dort habe ich mit den oben genannten Personen 5 Tage verbracht. Hat ziemlich viel Spaß gemacht (mal abgesehen davon dass es schwierig für mich war, dort was essbares zu finden). Ich war noch nie bei irgendeiner Veranstaltung, wo es zahlreiche Hacker gibt. Und wie nicht anders zu erwarten war, hat mich kabel mit seinen Social Engineering Skills überzeugt, einen Talk zu halten. There you go: http://events.hackerspace.lu/camp/2010/schedule/events/30.en.html. In dem Vortrag ging es um das eigentliche Thema hier auf dem Blog (neben den zahlreichen Emo-Beiträgen): Security through Obscurity. Eine kleine Einführung in Reverse Engineering. Und als Beispiel dann meine Vorgehensweise um OTRKEY zu analysieren. Es war nunmal der aufwendigste, welches nicht in 5 Minuten erklärt ist (sonst hätte ich lieber SFT erklärt).

Zu meinem Talk gibt es keine Aufnahmen die ihr euch ansehen könnt (sorry!). Man hat mir gesagt, dass mein Vortrag ganz okay war. Meine Behauptung, dass ich irgendeinen peinlichen Fehler mache, hat sich zum Glück als leere Behauptung herausgestellt

Aber was mich eigentlich am meisten freut: Ich habe nun eine eigene Top-Level-Domain!

www.41yd.de

Für alle die den Namen nicht verstehen: Es ist “eddy14″ rückwärts (reversed! Wenn ihr versteht …)

Nun denn. Ihr solltet von nun an diese Domain benutzen Ich kuschel mich jetzt in mein warmes Bettlein. Viel besser als ein Zelt *froh ist*

Löcher im Sieb

Lange ist es her, dass ich mich mit PHP Scripten beschäftigt habe. Aber gestern hatte ich Grund dazu.

Wenn ich nicht gerade dabei bin für die Prüfungen zu lernen, oder mich mit logischen Fehlschlüssen beschäftige, bin ich seit gestern zusätzlich am Reversen von Zend Optimizer. Ich will wissen, wie der Schutz (unter anderem die Verschlüsselung) funktioniert. (Anmerkung: Der Schutz von Zend Guard bewirkt, dass man die PHP Dateien nicht mehr einfach einsehen kann, da diese durch ein unbekanntes Verfahren geschützt, verschlüsselt und komprimiert sind. Der Zend Optimizer kann diese verkrüppelten Dateien ausführen). Zum Analysieren der Software brauchte ich eine Beispieldatei, welches mit Zend Guard geschützt ist. Ich nahm Schulfilter Plus. Obwohl ich eigentlich den Zend Optimizer selbst analysieren wollte, und nicht die Beispiel Datei, zog etwas merkwürdiges meine Aufmerksamkeit auf sich. Wenn ich Schulfilter Plus im Browser ausführte, erreichte mich eine Fehlermeldung:

Call to undefined function: mcrypt_get_iv_size()

Anscheinend hatte dieses Stück Software eine Anwendung für Verschlüsselung gefunden. Ist das nicht toll? Diese, eigentlich ungewollte, Entdeckung bescherte mir ein paar Stunden Spaß. Dem wäre nicht so, wenn die PHP Datei lesbaren Code beinhaltet hätte; da wäre alles sofort ersichtlich. Der Zend Guard machte es spannend!

Die Fehlermeldung tauchte nur auf, weil ich mcrypt nicht installiert hatte. (Normalerweise installiert man Schulfilter Plus mit einer .iso Datei, welches Apache, PHP, libmcrypt und alles drum und dran mitinstalliert. Die Installation ist in der VM immer abgestürzt, deswegen habe ich die PHP Dateien in eine bestehende Apache Installation kopiert. Und da hat nunmal mcrypt gefehlt! Welch ein Glück.)

Mcrypt ist einigen PHP Entwicklern bekannt: es bietet uns einfache Schnittstellen um gängige Verschlüsselungsalgorithmen (u.a. DES, AES, Blowfish,…) anzuwenden. Normalerweise hätte ich mir gedacht: Wow, da legt jemand sehr großen Wert auf Datensicherheit! Und ich hätte mich gefreut. Aber kurz zuvor hatte mir Lemming von einem sehr peinlichen Bug in der Schulfilter Plus Software erzählt, sodass ich nun bereit war alles mögliche von den Entwicklern zu erwarten. Wofür wurde hier die Verschlüsselung verwendet? Um die tatsächliche Wirkung zu entfalten, nämlich Daten sicher aufzubewahren, oder doch nur, um gewisse Daten und Vorgehensweisen zu verbergen/verschleiern?

Und da ich dieses Posting verfasse, könnt ihr euch denken, dass es letzteres war. Ich habe mir kurz nach diesen Gedanken mcrypt installiert. Für Windows ist es eine einfache DLL Datei. Diese exportiert alle benötigten Funktionen, damit der PHP Interpreter sie nutzen kann.

Nun könnte ich theoretisch folgendes machen: Da libmcrypt selbst open-source ist, könnte ich mir den Code besorgen, vor jeden Aufruf einer Funktion ein printf machen, neu compilen, und mir ausgeben lassen welche Funktion mit welchen Argumenten aufgerufen wird. Nun lass ich die Schulfilter Software laufen; so hätte ich eine nette Ausgabe, und wüsste, welcher Key verwendet wird, welcher Algorithmus etc. (das gleiche kann ich theoretisch auch mit dem PHP-Interpreter machen, um Zend Guard zu umgehen, dazu aber irgendwann in einem späteren Posting mehr).

Aber ich wollte es mir nicht so einfach machen. Ich hatte Lust auf Assembler. Also blieb ich weiterhin in meinem Debugger OllyDbg.

Ich lud mir php-cgi.exe in den Debugger, und führte es aus, bis alle wichtigen Bibliotheken geladen waren. Nun wechselte ich die Ansicht auf mcrypt, und ließ mir die angebotenen Funktionen ausgeben:

Wie man sieht, habe ich schnell ein paar Breakpoints gesetzt. Das wichtigste hier ist mcrypt_enc_get_iv_size. Dort müsste ich ja anhalten wenn ich die Software ausführe (denn aus der Fehlermeldung kann ich darauf schließen, dass diese Funktion aufgerufen wird).

Allerdings gibt es noch andere sehr schöne Funktionsnamen wie z.b. mcrypt_set_key. Diese Funktion wird sehr wahrscheinlich aufgerufen, wenn das Passwort für Ver-/Entschlüsselung gesetzt werden soll. Wenn ich nur einmal auf dieser Funktion breake, müsste ich die Möglichkeit haben die Parameter einzusehen. Dann bräuchte ich nur noch den Namen des Algorithmus um die Verschlüsselung nachzubauen.

Ich trace ein bisschen im Code rum; da ich Zend Optimizer noch nicht genug analysiert habe, ist das alles schwer nachzuvollziehen. Aber irgendwann sehe ich dann folgendes im Stack:

0012F834   01858FA0  ASCII “rijndael-128″
0012F838   00000000
0012F83C   0182A228  ASCII “ecb”

Na das sieht doch sehr nach Rijndael aus, im ECB modus. Also gehe ich zurück zu den exportierten Funktionen, und setze überall breakpoints, die was mit Rijndael zu tun haben:

Nun sollte ich immer benachrichtigt werden, wenn die Software etwas mit diesen Funktionen anstellt. Und das tut sie wirklich: “Breakpoint at libmcryp.rijndael_128_LTX__mcrypt_set_key”. Irgendwo müssen die Parameter für diese Funktion rumliegen, und ich bin optimistisch dass es der Key sein wird! Tada:

Ausgeschrieben: “fhslJefRe12jadf45HSDd54kad4fk2dA“. Das ist der Schlüssel für die Verschlüsselung. Es gilt noch herauszufinden, ob es immer der selbe ist (davon kann man sich überzeugen indem man die Daten von verschiedenen Ausführungen, und Installationen von Schulfilter Plus in den Debugger schmeisst). Um es vorweg zu nehmen: ja, es ist immer der selbe Schlüssel.

Irgendwann komme ich in die decrypt Prozedur, und sehe, wie Daten entschlüsselt werden. Live! Das ist ein sehr schöner Augenblick <3

Ich weiß also nun, dass Rijndael-128 verwendet wird, mit dem oben genannten Schlüssel. Nun muss ich gucken, für welche verschlüsselten Daten es überhaupt gebraucht wird. Ich suche in der Ordnerstruktur der Software nach irgendwelchen Dateien die verschlüsselt aussehen. Und tatsächlich: Im Unterordner “xml” befindet sich eine Datei mit dem Namen “systemusers.xml”. Der Name ist vielversprechend.

Haben die Entwickler etwa alle User-Daten in dieser Datei gespeichert? Das wäre sehr gefährlich, denn die XML Dateien sind für jedermann zugänglich! (Wieso zum Teufel programmiert irgendjemand so etwas? Ich könnte ausrasten). Nur die (wie wir noch sehen werden: unsichere) Anwendung von Verschlüsselung hält uns davon ab, die Daten einzusehen.

Ich schreibe eine kleines Python Script, welches das Verschlüsselungsverfahren anwendet, um die Daten zu entschlüsseln: Und tatsächlich, ich sehe am Ende die XML Datei. Erschreckender Fund darin:

<user xml:id=”user1″ role=”role1″ added_by=”cockpit”>
<name>tfkadmin</name>
<password>263aa25bd34cc2fbe24b70ba46e41fe0</password>
<dn/>
</user>

Es sind die Login Daten für den Administrator. Das Passwort ist einfaches MD5. Und sowas kann jeder von jedem Server runterladen, welches diese Software einsetzt? Mir ist es schleierhaft, wieso die Entwickler sowas tun. Entweder sie wissen es nicht besser, oder sie halten sich einen eigenen Zugang offen (böse Vorwürfe meinerseits!). Vieles in der Software ist auf diese Weise (mit dem gleichen festen Schlüssel) verschlüsselt. Auch die Backup-Datei (Nebenbei angemerkt: Die Backup-Datei ist eigentlich nur eine PHP Datei, mit verschlüsselten Strings. Sehr schlampig…). Die ganze Sicherheit geht zugrunde, wenn jemand diesen privaten Schlüssel der Entwickler hat (der Schlüssel wird jedem Kunden in der Software mitgeliefert!). Die gehen echt ein großes Risiko ein. Das sind echte Kerle mit Eiern in der Hose, sage ich euch!

Ich hoffe es wird so langsam jedem klar, dass eine Tarnung (wie durch den Zend Guard) nicht sehr viel bringt, wenn man vor dem Erforscher des Systems etwas verheimlichen will. Ich gehe sogar soweit zu behaupten, dass die unsichere Programmierarbeit bekannt war; ich denke, dass mit dieser Verschleierung versucht wurde, sich einen eigenen Zugang offen zu halten. Ich denke nicht, dass die Leute versucht haben ihr geistiges Eigentum zu schützen. Jeder der den Code einsehen könnte, würde es strikt ablehnen, so ein Scheunentor auf seinem Server zu installieren. Wieviele gravierende Bugs und Geheimnisse findet man erst, wenn man die Scripte einsehen könnte?

In der oben genannten systemusers.xml ist ein weiterer User aufgelistet. Der Benutzername ist “tfksupport” und das Passwort ist anscheinend nur den Entwicklern bekannt. Dieser User ist auch auf invisible gesetzt, sodass man ihn (sogar als Administrator) nicht verwalten kann. Auch wenn dieser User in dem Handbuch Erwähnung findet, und es tatsächlich für den Support zu sein scheint, macht das einen stutzig. Man will doch trotzdem die volle Kontrolle über die Maschine haben!

Der Vorteil eines PHP Codes ist es ja, dass es auf einem (entfernten) Server läuft. So lange man also den Server nicht hacked (durch eine Sicherheitslücke etc.), hätte man theoretisch keine Möglichkeit, irgendwelche Daten zu kopieren, manipulieren etc. Aber die Entwickler haben sich echt komisch angestellt; sie stellen die Daten frei zugänglich ins Netz, und versuchen den Inhalt zu verschleiern, anstatt einfach den Zugriff zu den Daten zu verweigern. (Siehe: Security through Obscurity)

(20:36:48) eddy14: das ist echt so lächerlich von denen, sowas verstecken zu wollen
(20:37:07) lemming: evtl arbeiten die mit otr zusammen ^^
(20:37:12) eddy14: haha

Wie gefährlich so eine Burka für Software ist, sieht man an dieser Äußerung: “Nachdem in Bayern bereits 1500 von 5500 Schulen mit dem Jugendschutzpaket der TIME for kids Foundation einen wirksamen Schulfilter einsetzen, soll nun Bayern zum Musterland für Kinder- und Jugendschutz im Internet werden.”. Schützt die Kinder, aber bitte richtig!

Anfangs wollte ich die Entwickler über diesen Missstand informieren, bevor ich diesen Beitrag veröffentliche. Aber ich denke, diese Leute haben sehr fahrlässig gehandelt. Sehr viele Schulen verwenden diese Software. With great power comes great responsibility.

Ich bin verliebt

Seit Tagen fühle ich mich großartig. Wenn ich morgens aufwache, und die Augen öffne, fange ich sanft an zu lächeln. Ich fühle mich toll. Oft liege ich einfach nur da, und lächle die Wand an.

Kurz darauf setze ich schöne Musik auf, die mich noch glücklicher macht. Ich stehe auf und fange an wilde Bewegungen mit meinem Armen zu machen. Ich spiele Luftgitarre; oder ein anderes Instrument das gerade auf die Musik passt. Es fühlt sich großartig an. Das Leben fühlt sich großartig an.

Ich bin verliebt.

Und auch wenn ich euch jetzt in die irre geleitet habe; es geht hier um keine Frau. Ich habe mich in die Wissenschaft verliebt. Ich liebe Darwin, ich liebe Einstein, ich liebe Newton, ich liebe Feynman, ich liebe Dawkins.

Es erfüllt mich plötzlich mit solch einer großen Freude, mir einfach nur die Welt anzuschauen und darüber nachzudenken, wie genial es ist, dass mich überall Atome umgeben. Ich schaue mir die unzähligen Tiere an und ich bin fasziniert von der Tatsache, dass sich alle entwickelt haben. Nachts schaue ich mir die Sterne an, und mir gefällt der Gedanke, dass ich mit wissenschaftlichen Methoden hier aus der Erde, aus meinem Kopf heraus, verstehen könnte, wie das alles funktioniert. Mit Stift und Papier.

Die Welt ist so wunderschön, wenn man annimmt, dass es keine Magie gibt, keine Wunder, keine göttlichen Eingriffe.

Meine Gedanken fühlen sich gerade wirklich frei an. Ich habe so ein großes Verlangen danach, das Universum zu verstehen. Die Innereien des Computers zu erforschen war anscheinend nur die Einstiegsdroge.

Ich gehe nun schlafen, es ist schon wieder fast 6 Uhr morgens.

Für alle die von diesem neuen Beitrag enttäuscht sind: ich finde aktuell leider keine Zeit für Reverse Engineering. Ah, und da ich noch nie ein Video hier auf dem Blog eingebunden habe, tu ich das mal, passend zu diesem Beitrag:

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 0×1D158EC9. 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 “0×7B7A39E8″. 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

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.

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.