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.

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:

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 “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.

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.

Saltwater - Leecher

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:

HxD zeigt uns den Inhalt der Datei

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!

Die aller erste Zeile zeigt meinen Fund (die Funktion "GetHashSize")

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:

Eine Auflistung aller Methoden, die diese Klasse bietet

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:

Methoden, die nun nicht mehr anonym sind! Sie wurden alle mit den richtigen Namen beschmückt.

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:

Die Methoden der Verschlüsselung wurden revealed!

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:

Entschlüsselt, und sortiert ausgegebener Inhalt der SWL-Datei

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!)

Als ich gerade damit beschäftigt war die Software von der Firma, bei der ich zurzeit Praktikum mache, etwas sicherer vor Crackern zu machen, fiel mir auf, dass ich nicht so viel Ahnung davon habe. Hm,  Software sicherer machen … hm das kann ich nicht so gut … aber die Sicherheit zu brechen, das macht Spaß!

Software sichern … hm … Ich mein, “sichern” im typischen Sinne kann man es ja nicht einmal. Es liegt in der Natur der Sache, dass ein ausführbares Programm analysierbar bleibt. Nur wie kann man es so erschweren, dass jeder Reverser die Lust verliert?

Auf der Suche nach der Antwort lud ich mir ein paar CrackMe’s runter, um unter dem Vorwand von “Anti Debugging Technik erlernen” etwas bei der Arbeit cracken zu können

Acht Stunden und unzählige fertige CrackMe’s später fuhr ich nach Hause … ich war immernoch hungrig nach mehr … mehr hardcore Assembler … mehr Geheimnisse entlüften … mehr Glückgsgefühle … mehr davon. Ich kramte auf meinem USB-Stick rum, und fand eine alte version des SFT-Loaders (“SFT Loader 2006″). Nach meinem letzten Beitrag über DLC, und über RSDF, dachte ich mir, es wäre doch praktisch meine Kenntnisse im Gebiet der Analyse von unbekannten Formaten auszuweiten. Diese SFT Dateien bieten einige Warez-Seiten an. Kennt das überhaupt noch jemand? Einige wenige Seiten scheinen das noch anzubieten. Wie auch immer, meinen Spaß hatte ich jedenfalls damit

In der SFT Datei sind (verschlüsselt) Host, Username, Passwort, Dateinamen und einige Optionen hinterlegt. Sodass dieses Programm es entschlüsseln, und dann von den FTP-Servern die Dateien herunterladen kann. Das wollte ich unbedingt mal analysieren, sollte doch sicher spaßig werden?

SFT Loader 2006

Gesagt getan. In einer Woche (á 8 Stunden) und noch etwas mehr, war ich fertig. Man, hat das lange gedauert. Ich habe mit einem Aufwand von 1-2 Tagen gerechnet, aber eine Codestelle im Programm hat meinen Kopf gefickt (ja, ich benutze sonst nie diesen Ausdruck, aber dieses Dateiformat hats echt verdient!). Beim reversen wurde mir immer wieder mal schwindelig und ich hielt meinen Kopf fest, damit sich meine Umgebung nicht mehr so merkwürdig bewegt! (und das ist kein Witz!)

Nun, das SFT Format ist viel cooler als DLC … nein, nicht sicherer. Sondern etwas komplexer … also spaßiger zu reversen

Wer nichts über die Struktur des Formats lernen möchte, der möge das hier überspringen und an das Ende des Artikels springen … dort findet ihr einen SFT Decrypter (Ja, ihr könnt mich hassen, dass ich das tue …)

Als aller erstes sollte klar werden, es ist wieder Security-by-Obscurity. Es gibt keinen Weg daran vorbei, wenn man versucht, auf dem Rechner des Users Daten zu verarbeiten, von dem der Nutzer aber nichts wissen soll. Der SFT-Loader MUSS zwangsweise irgendwann die Daten entschlüsseln. Was ich nun mache ist es, zu analysieren wie dieses Programm es genau macht. Wie generiert es sich seinen Schlüssel? Welche Algorithmen werden verwendet? In welcher Stelle der Datei befinden sich die Daten? Dazu bedient man sich des Reverse Engineering.

Kerckhoffs Prinzip besagt, dass die Sicherheit eines Verschlüsselungsverfahrens auf die Geheimhaltung des Schlüssels beruhen muss, nicht auf die des Algorithmus. In unserem Fall muss jedoch das Programm das Passwort ja wissen, um den Inhalt zu entschlüsseln. Irgendwoher muss es das Passwort ja kriegen. Sei es, indem es sich das selbst generiert (siehe weiter unten) oder ob es einen hardcoded key verwendet. Die Sicherheit ist die selbe, solange ich alles rekonstruieren kann.

Nun, zurück zum Dateiformat: jede SFT Datei hat einen Header. Die ist immer 0×40 (=> 64) Bytes lang. Sie fängt (immer?) mit “A” an, gefolgt von einem 0xFF Byte, und dann “2SFT04″. Es sollte klar sein, wofür “SFT” steht. Die “2″ ist mir noch nicht ganz klar. Die “04″ allerdings steht für die Dateiversion. Soweit ich weiß, ist dies die aktuellste Version des Formats. (Jedenfalls war es das 2006)

SFT Header

Danach folgen weitere 0xFFs bis die 0×40 Bytes voll sind. Nun ist der Header fertig, und der eigentliche Content folgt. Dieser ist mit zlib komprimiert. Einfach dekomprimieren (am einfachsten mit einem Python script) und schon hat man den dekomprimierten Inhalt. Dieser ist allerdings noch verschlüsselt. Der Algorithmus für die Verschlüsselung ist RC4. Wobei wie immer die Sicherheit des Algorithmus ziemlich egal ist, solange der Schlüssel irgendwo abgespeichert ist.
Der Schlüssel für RC4 ergibt sich aus dem SHA1 Wert des Headers. Dafür schneidet man den ersten Byte (also das “A”) des Headers heraus, fügt ans Ende zwei 0xFF hinzu und hasht es dann mit SHA1. Das Resultat ist unser Key. Gewöhnlicher Weise ist es immer die selbe:

7CBEB0CF896EC8DE4F54A2850E6C73B38E95EA06

Mit diesem Key entschlüsseln wir den Dateiinhalt. Und es erscheint uns der serialisierte (aber entschlüsselte) Inhalt der Datei.

Entschlüsselter Inhalt

Von hier an ist es nicht mehr viel. Man kann einfach den Inhalt splitten, und die einzelnen Werte auslesen. Die einzelnen Base64-Strings die dort zu finden sind, sind entweder mit dem SHA512 Hash von “SFT Loader Reloaded” oder “callstackapi”, (mit dem RC4 Algorithmus) zu entschlüsseln. Hierbei hatte ich ein paar Probleme, da meine python library einen Fehler drin hatte (man, ich musste den verdammten RC4 Algorithmus fast nachbauen um den Fehler zu finden … der Programmierer hat vergessen beim crypten i und j wieder auf 0 zu setzen, siehe The Pseudo-Random Generation Algorithm)

Nach einigem rumprobieren und surfen fand ich heraus, dass der Programmierer eine nicht-standardisierte Verschlüsselung verwendet, die nirgendwo dokumentiert ist. Das wäre natürlich der total Krampf im Arsch (ja, ich weiß dass es falsch übersetzt ist) den ganzen Algorithmus auch noch zu reversen. Aber glücklicherweise fand ich diese Komponente, welches wohl dieses Verfahren überhaupt erfunden hat. Sie nennt sich RCx und ist ein selbstprogrammierter Algorithmus, angelehnt an RC5. Also entweder wollte ich ein Delphi Programm schreiben (und diese Komponente verwenden), Strings entschlüsseln und an mein Programm pipen lassen, oder den ganzen Algorithmus selbst implementieren. Ersteres fiel weg, da ich keinem User aufzwingen möchte, Wine zu installieren. Also baute ich den Algorithmus nach. Nach rund 92 Zeilen Code, und 2 Tage debugging (Python hat wohl kein “Byte” als Dateityp, das war wie ein Tritt in die Weichteile) war meine kleine RCx Klasse fertig. Damit kann man wahrlich die einzelnen Werte endgültig entschlüsseln.

Vorerst knöpft man sich das “Header” Element vor (siehe Bild oben). Aus diesem ergibt sich ein String wie folgt:

SFT0#2#D7D05C8DEED489B6C6981D9A6E8D79315C8F2D41A7AC229B385C2A2B73A7959C65F07C7D7CE4F1D6CA7A79E0C2A4847E5587079ACF

SFT am Anfang zeigt uns wieder, dass es korrekt entschlüsselt wurde (mit dem erwähnten RCx Algorithmus). Die “0″ direkt danach gibt an, ob ein Passwort notwendig ist (in diesem Fall also nicht). Ich weiß nicht genau wofür die nachfolgende “2″ ist (Maximale Threads oder so ?) aber alles nach dem letzten “#” ist der Wert, den es zu entschlüsseln gilt. Dafür wurde ein (selbstentwickeltes?) XOR und Salt-System genutzt. Der Salt-Wert ist “callstackapi”. Hierdran wird einfach das eingegebene Passwort angehangen, oder ggf. nichts angehangen. Den XOR-Algorithmus kann man wie folgt beschreiben:

def YurryXOR(key):
raw_key = hashlib.sha512(key).digest()
raw_key = raw_key[:(len(raw_key)/2)]
result = []
key = key*10
for i in range(0, len(raw_key)):
result.append(chr(ord(raw_key[i]) ^ ord(key[i])))
return ”.join(result)

Kleine Erklärung: Der key ist das erwähnte callstackapi+password. Daraus wird ein SHA512 Wert generiert. Die letzte Hälfte wird rausgelöscht. Nun wird der nicht-gehashte Key mit dem gehashten geXORed. Und das Ergebnis ist unser Key.

de5a015215664d925bf3e9f97477caee4ef7a44f6a3d0ee08bf70f1f326e41c7

Sowas in der Art (btw, ich benutze für diese Demonstration diese Testdatei).

Das ist unser Yurry-Key (die habe ich nach meinem Schatz benannt. Haiiii schatziii <3 ). Mit dieser kann man ganz schmutzige Sachen machen (nein, nicht mit meinem Schatz du Perverser! Ich meine den Key!). Haben wir diesen erstmal, stehen uns alle Wege offen. Diesen Key können wir an unser Header-Element anwenden, und somit erhalten wir einen Wert, der exakt so aussieht wie das hier:

{1F945Z9B-3ZA9-4Q13-A5DB-KDKDKFLDSHGVFBV}

(Anfangs sind noch 20 zufällige Bytes, die angehanden wurden. Das ist wohl so eine Eigenschaft vom Algorithmus. Die kann man gefahrlos rauslöschen).

Das sieht aus wie eine Seriennummer, ist es aber nicht. Dieser Wert wird nur verwendet, um zu schauen ob der User das richtige Passwort eingegeben hat.

Mit dem gleichen Algorithmus und dem gleichen Key, ist es nun möglich alle anderen Elemente zu entschlüsseln (Host, Username, Passwort etc.)

sft-decrypter

Das wars auch schon. Man kann noch durch alle Dateinamen gehen, wenn man möchte. Ich denke, das werde ich bei Gelegenheit mal machen, und dem PyLoad Projekt ein SFT-Plugin schenken (auch wenn dies kein Dateiformat für One-Click-Hoster ist).

Nachdem letztens schon wieder ein Hacker Selbstmord begangen hat, ist mir der Fall Tron (ein Hacker der Verschlüsselungen geknackt hatte) wieder eingefallen. Um exakter zu sein, dass was er den Polizisten bei einer Hausdurchsuchung mal sagte: “Man kann das Anwenden
von mathematischen Formeln doch nicht unter Strafe stellen?!” (aus dem Buch “Tron – Tod eines Hackers”).

Ich schreibe später eventuell ein Reverse Engineering Paper hierdrüber, da dieses Target ziemlich lehrreich war!

Ein letztes noch: Es ging hier natürlich wiedermal nicht um das Endresultat, sondern um den Weg. Denn an Username&Passwort der SFT Datei, käme man auch durch Sniffer, Proxies oder ein paar Spielereien mit der Hosts-Datei. Wie J. J. Abrams bereits einmal sagte, es geht nicht um das Ende (die Auflösung des Ganzen). Sondern die Zeit, die man damit verbringt (Gemeint war die Serie Lost, aber passt auch hierzu!).

Verschließt eure Augen nicht vor der Wahrheit! Speichert eure sensiblen Daten nicht in einem undurchsichtigen proprietären Dateiformat. Das ist wie mit WEP. Indem nun jeder Witzbold in ein WEP-Netzwerk einbrechen kann, hat man den Leuten die Augen geöffnet: Verwendet nicht WEP! Und viele (wenn auch bei weitem nicht jeder) haben die Gefahr erkannt. Indem man aber nun einfach sturr und blind bleibt, und meint, weil WEP gebrochen wurde, wäre die ganze Sicherheit um WEP kaputt, irrt sich. Es war schon immer unsicher, nur wurde diesmal einfach nur bewiesen, dass es so ist. Und wer meint ich hätte mit diesen frei zugänglichen Informationen irgendetwas kaputt gemacht, ist naiv. Ich habe nur Informationen veröffentlicht, die jeder SFT User auf dem Rechner hat. Nur hat es wohl keiner vorher einer Analyse unterzogen. Wie dem auch sei:

DOWNLOAD: SFT-DECRYPTER

oder: SFT-DECRYPTER + GUI (benötigt Java) von Seji

//edit 17.07.09 >>> kleines Update. Bugfixxes und ein paar Feature-Requests (Ordner und Dateiname anzeigen) wurden realisiert. Es werden nicht alle Dateinamen und Ordner angezeigt, sondern nur die ersten, habe gerade keine Lust das noch einzubauen. Dennoch viel Spaß

Nundenn, da ich generell interessiert bin, an allem was mit Sicherheit und Einbruch zu tun hat (hey, ich bin Ausländer, das liegt mir im Blut ) dachte ich mir, ich könnte in den Pausen ja mal bisschen gucken, wie die Firma strukturiert ist. Netzwerktechnisch und auch sonst.

Am ersten Tag bekam ich eine Karte, die nötig ist um die Türen öffnen können. Die Firma hat tausende von Mitarbeitern, da ist natürlich klar, dass professionelle Sicherheitssysteme eingesetzt werden. *edit* Die Kommentare hatten mal wieder Recht. Es war nur eine stinklangweilige RFID Karte Habe gerade den Shop gefunden, wo die exakt die selben Karten anbieten.

Nundenn. Ich war amüsiert davon. Meine 8-Stunden Schicht war zuende, also mache ich mich in Richtung Bahnhof (der an einem Flughafen liegt). Da ich noch ein paar Minuten warten kann, gehe ich in ein Wartezimmer.

(Das Foto wurde btw mit meiner DSi aufgenommen. Ich liebe das Teil <3 Habe es immer mit um Pi zu hören … jaja meckert nur … pi for president!)

Jedenfalls denke ich mir, total gelangweilt, “Hm, was könnte man hier so schönes machen”. Ok, ich bin an einem Flughafen, ich bin Ausländer, und habe einen Koffer dabei

Spaß beiseite … das einzig coole waren die Bewegungssensoren, die die Türen automatisch öffnen … langweilig *gähn* Dann gibts da noch diese Fernseher. Alles öde. Ich wollte mich gelangweilt an einen Platz hinsetzen und sehe das:

Also frage ich mich wie von der Stille und der Langweile betäubt, woher der Fernseher die aktuellen Daten bekommt (wann der Flug ist etc.). Oben sind die Wände “offen”, sodass man alle Kabeln sieht. Bei näherer Betrachtung des Fernsehers sehe ich folgendes:

Oh cool. Da sehe ich Kabeln. Mal näher daran gehen, oder? Dürfte cool sein zu sehen, wohin es führt.

Moment … ist das etwa … ist das? Nee oder ? Schauen wir uns das mal etwas näher an:

Das sieht doch echt aus wie ein LAN Kabel oO Was macht ein LAN Kabel am Fernseher? Und wieso ist es so “offen” und frei verlegt? Mal näher schauen

LAN Nah

LAN

(btw, sorry für die schlechte Qualität … DSi halt )

OK, erfreuliche Nachrichten. Es ist sehr wahrscheinlich ein Ethernet Anschluss. Und noch besser: Eins ist noch frei Hallo Internet am Flughafen, ich komme…

Wenn ich mich da dranstöpsel, kann ich sehr wahrscheinlich auf das interne Netzwerk zugreiffen. Oder schlimmstenfalls nur die Ausgabe des Fernsehers manipulieren. ODER einfach so einen transportablen WLAN Router dort anstöpseln, merkt sicher sowieso keiner. So könnte ich von aussen aus, in das interne Netzwerk zugreiffen

Ich dachte mir, wäre cool zu wissen wo genau das Kabel angeschlossen ist. Man siehts nicht richtig, aber ich habe mir den Arsch aufgerissen um das Bild hier zu machen:

Hinten

Während ich versuche auf dem Sitzplatz zu stehen und die Fotos zu machen, höre ich den Aufzug neben mir aufgehen, und ein Typ aus der Flughafen Security steigt aus. Ich setze mich reflexartig hin. Er schaut mich stechend an, während er raus an die Luft geht, kein Wort sagt, und seine Zigarette anzündet. Dabei schaut er öfter mal rüber. So verdächtigend. Ich bin extra noch sicher gegangen, dass mich keine Kameras beobachten. Aber ich bin gestern schon aufgefallen, als ich total auffällig Fotos von der Sicherheitskamera gemacht habe … keine 2 Minuten, und ein Securitytyp stand sehr kritisch neben mir

Danach gings ab nach Hause. Und wie es sich für einen Mann gehört, hat meine Pussy auf mich im Bett gewartet:

(das war eindeutig zweideutig )

Kill the underground, you won't kill the Hacker culture.

Die neue Phrack ist raus

http://phrack.org/issues.html?issue=66

Viel Spaß beim Lesen