• Skip Navigation

Blog von eddy14

Search for:

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

Archive for the ‘IT Security’ Category

NLP

Ich möchte in diesem Beitrag auf die Neurolinguistische Programmierung (NLP) eingehen. Anders als der Name vermuten lässt, geht es hierbei nicht um Computer. Aber dennoch hat es etwas mit meinem Blog zu tun: es wird häufig in IT-Security Foren erwähnt, wenn es um Social Engineering geht (sagt “Hallo” zur neuen Kategorie “Social Engineering” auf dem Blog!).

Für Leute, denen der Begriff absolut nichts sagt:

Neurolinguistische Programmierung (kurz NLP) bezeichnet die Idee, dass der Mensch anhand von Reiz-Reaktions-Ketten funktioniert und diese neu gestaltet werden könnten. Geändert werden soll das eigene Verhalten durch Analyse des alten Verhaltens und „Programmieren“ von neuen Reaktionen. Der Schwerpunkt des NLP liegt bei Kommunikationstechniken und Mustern zur Analyse der Wahrnehmung. Das Ziel ist eine erfolgsorientierte Kommunikation.

Auf dem ersten Blick hört sich das absolut super an. Als ich vor einigen Jahren darauf stieß (und soweit ich mich erinnern kann, war es damals in den ITS Foren kaum bekannt) war ich ganz heiß darauf, alles darüber in Erfahrung zu bringen. Den Ansporn dazu gab mir vor allen Dingen der Zauberkünstler Derren Brown, welcher in einigen seiner Auftritte behauptet, per NLP Menschen manipulieren zu können. Nach so einer genialen Show, wer hat da nicht Interesse an NLP?

Nun, Derren Brown ist allerdings auch ein Skeptiker. Er erklärt in einem Interview mit Prof. Dawkins, was für Tricks Leute verwenden, die von sich behaupten, übernatürliche Fähigkeiten zu besitzen. Er zeigt ganz gut, dass man mit einer angeblichen Begründung, die Leute schnell hinter’s Licht führen kann. Vielleicht trifft das ja auch auf seine eigene Aussage zu, dass er NLP verwendet? Deswegen will ich mich hier mit NLP kritisch auseinandersetzen:

Wenn man nach NLP googled, dann findet man zahlreiche Webseiten, die Werbung für NLP Seminare machen. NLP hat sich bisher nach einer ernsten Wissenschaft angehört; aber die Resultate erwecken den Anschein, dass:

• a) die Leute das Wissen um NLP kommerziell vermarkten wollen
• oder b) das NLP nur Blödsinn ist.

Weiterhin heißt es auf Wikipedia:

NLP ist in Abgrenzung von der wissenschaftlichen Psychologie im Zuge von New Age und des Human-Potential-Movements entstanden.

Dass es daraus entstanden ist, hat vielleicht nicht viel zu sagen. Aber dass es in Verbindung mit “New Age” gebracht wird, ist ein Schlag ins Gesicht, was der Wissenschaftlichkeit des NLP angeht. Es heißt zwar an einigen Stellen, dass NLP nicht den Anspruch erhebt, wissenschaftlich begründet zu sein; dafür machen die NLPler aber Behauptungen, die wissenschaftlich geprüft werden können.

Da NLP Anfang der 70er Jahre entwickelt wurde, gab es bereits so einige skeptische Wissenschaftler, die sich mit diesem Thema auseinandergesetzt haben. Um uns die Kritik anzuschauen, sollten wir erstmal wissen, was für Behauptungen NLP aufstellt. Einer der Kernthesen des NLP nennt sich “preferred representational system” (PRS) und behauptet, dass Personen sich (intern) im Kopf eine Landkarte konstruieren. Dies geschieht durch die Verarbeitung von externen Informationen, die durch fünf “Sinnessysteme” wahrgenommen werden: durch die visuelle Wahnehmung, die auditive Warnehmung, das Kinästhetische (im Rahmen des NLP sind hierbei alle Gefühle gemeint), das Riechvermögen sowie dem Geschmackssinn. Es wird weiterhin behauptet, dass das Bewusstsein einer Person eines der erwähnten “Sinnessysteme” überwiegend benutzt (zu einer gegeben Zeit). Außerdem soll sich das Bevorzugen dieses Systems auf die Sprechweise auswirken. Beispiel: Wenn sich eine Person gerade überwiegend im visuellen Zustand befindet, benutzt sie Satzanfänge wie “Ich sehe nicht, wieso…” oder “Es sieht so aus, als ob…”.

Die Gründer Bandler und Grinder behaupteten im Jahre 1979 außerdem, dass man diesen Zustand aus den Augenbewegungen ablesen kann. Beispielsweise sei der kinästhetische Zustand daran zu erkennen, dass die Person nach rechts unten schaut.

Aus der Annahme, dass jede Person eine eigene Vorstellung von der Welt hat, folgt dass Personen eine andere Vorstellung von der Welt haben. Deswegen soll man sich dem verbalen sowie dem non-verbalen Verhalten des Gegenüber anpassen, um die effektivste Kommunikation zu ermöglichen.

Das zu den Kernthesen von NLP. Welche Kritik gibt es dazu? Allgemein gilt: Wenn man eine Behauptung aufstellt, muss man diese begründen und stützen können. Die Beweislast liegt also bei demjenigen, der die Behauptung aufstellt. Was sind also die Beweise für die Kernaussagen von NLP?

Falls die Behauptungen von Bandler und Grinder begründet wären, dann wäre es richtig zu sagen, dass sie einen Grundstein des menschlichen Bewusstseins entdeckt hätten. Sie machen Aussagen die einfach empirisch überprüft werden können. Und in den 30 Jahren seitdem die Behauptungen aufgestellt wurden, sollte es genug Beweise für die Thesen geben, damit diese im Psychologie Fachbereich an Universitäten rund um den Globus gelehrt werden können. Drei Jahrzehnte später ist jedoch festzustellen, dass NLP in fast kompletter Isolation vor veröffentlichten Beweisen existiert. Die Kernaussagen von NLP aus den 70ern wurden größtenteils bereits in den 80ern angezweifelt. Sharpley (1984) hat sich die Forschung um NLPs Aussagen über PRS angesehen, und kommt zu dem Schluss, dass es nur wenig Beweise gibt, und vieles dagegen spricht.[1]

Vernichtende Worte gibt es auch hier zu hören:

Objektive empirische Studien und Berichte haben konsequent gezeigt, dass NLP anständigen Überprüfungen nicht Stand hält. Berichte und Meta-Analysen haben NLP einen eindeutige negative Bewertung gegeben und bestätigen wiederholt die Aussage, dass keine neurowissenschaftlichen Grundlagen (oder jegliche anderen wissenschaftlichen Grundlagen) für die Behauptungen von NLP existieren.[2]

Es gibt also keinen Grund anzunehmen, dass NLP funktioniert.

Schauen wir uns nun die genaueren Behauptungen der NLPler an, und schauen uns die Beweislage dafür an. In einer der üblichen PDFs von einer Seite die für NLP wirbt, heißt es über das “Ankern”:

Die Technik des Ankerns geht zurück auf die Arbeit über den bedingten Reflex von Ivan Pawlow und das Konzept der Konditionierung aus dem Behaviorismus.
Unser Gehirn, bzw. Nervensystem speichert in allen Situationen, in denen wir intensive Gefühle (positive wie negative) haben, alle Umgebungswahrnehmungen mit ab. Wird dann später eine dieser Umgebungswahrnehmungen wiedererkannt, löst das Unbewusste wieder die Emotion aus.
Die Umgebungsreize, die zum Zeitpunkt der Emotion aufgetreten sind, werden quasi als Auslöser für die Emotion in der Neurologie verankert. Dieser Prozess läuft immer ab. Alles Lernen beruht auf dem Konzept des Ankerns. [4]

Um es anders auszudrücken: Man will z.B. ein bestimmtes Gefühl jederzeit abfrufen. Dafür versucht man das Gefühl so intensiv wie möglich zu erleben, und dann ein Schlüsselreiz zu setzen (wie z.B. die Berührung eines Körperteils). Nun kann man mit dem Schlüsselreiz angeblich das Gefühl jederzeit wieder auslösen (gut demonstriert in dem Video von Derren Brown, das oben verlinkt ist). Der Psychologe Christoph Bördlein sagt dazu:

Das klingt zwar nach Pawlow und klassischem Konditionieren, jedoch nur auf den ersten Blick. – Tatsächlich gibt es keinen Lernmechanismus, der so funktionieren könnte. Allenfalls hat ein solches Vorgehen symbolischen Wert.[3]

Eine weitere (und oben bereits erwähnte) berühmte Behauptung ist folgende:

Augenzugangshinweise
Eine weitere Möglichkeit, herauszufinden, in welchem Sinnessystem mein Kommunikationspartner denkt, ist das Konzept der Augenzugangshinweise. Wir haben im NLP herausgefunden, dass etwa 70% der rechtshändigen Mitteleuropäer ihre Augen in unten angeführte Richtungen bewegen, wenn sie nach innen gehen, um Informationen in einem bestimmten Sinnessystem abzurufen. Die restlichen 30% haben auch ein konsistentes Muster, das aber individuell kalibriert (=bestimmt) werden muss. [4]

Dr. Bördlein ist auch skeptisch gegenüber dem:

Auch spätere Grundlagenforschung zu NLP wirft ein bezeichnendes Licht auf die magere theoretische Basis. Z.B. kann die “Augenbewegungshypothese” des NLP als widerlegt gelten (vgl. Bliemeister, 1988). Nach Auffassung des NLP lassen sich aus der Richtung, in die eine Person beim Denken blickt, Rückschlüsse auf ihren Denkstil (oder das von ihr benutzte “Repräsentationssystem”) ziehen Jedoch ließ sich kein wie auch immer gearteter Zusammenhang im Sinne der NLP-Hypothesen nachweisen. Trotzdem arbeiten NLP-Therapeuten weiterhin in der Illusion, sie können aus der Richtung, in die ein Klient blicke, quasi ablesen, wie dieser gerade denke.[4]

Ich hatte bereits das “mirroring” (auch genannt “pacing”) erwähnt. Man kopiert die Handlung des Gegenüber. Nun, auch keine guten Neuigkeiten darüber:

[...] Forschung in der Richtung des mirroring deutet darauf, dass wenn die mirroring-Hypothese einer Person während einer Session/Therapie erklärt wird, dass diese Person den Erklärenden für überzeugender hält. Jedoch; wenn die Hypothese nicht erwähnt wird, kann die Person, welche die Technik anwendet, unüberzeugend rüberkommen. Mirroring wurde sogar als ablenkend, irritierend und unklug für Kommunikationszwecke bezeichnet. [2]

Ich möchte nicht noch weiter ins Detail gehen. Aber ich denke, man sieht sehr gut, dass an NLP nicht viel dran zu sein scheint. Die Methoden die NLPler anwenden um dafür zu werben, sind mehr als zweifelhaft. Sie werden außerdem beschuldigt, sich als wissenschaftliche verkaufen zu wollen, obwohl sie es nachweislich nicht sind.

Alles was übrig bleibt, sind die Behauptungen der NLPler, dass man einfach selbst probieren solle und man werde sehen, dass es funktioniert. Das erinnert eher an Homöopathie und Astrologie, als an Wissenschaft. Der obige Text über das Mirroring sollte sogar die Erklärung nahe legen, dass es eine Art Placebo-Effekt ist. Um noch ein letztes mal Dr. Bördlein zu zitieren:

Dennoch berichten NLP-Adepten oft davon, wie hilfreich NLP für sie sei und wie sie es selbst tagtäglich als wirksam erlebten. Neben dem bekannten “confirmation bias” – der (allzu-)menschlichen Tendenz, einmal getroffene Annahmen fortlaufend zu bestätigen (Bördlein, 2000) – und einem nicht zu vernachlässigenden Selektionsfehler (enttäuschte NLP-Kunden werden keine Werber für das Verfahren) basiert diese wahrgenommene “Wirkung” von NLP-Trainings vermutlich auf einer Art Placebo-Effekt. [3]

Resultat: “Neurolinguistische Programmierung” scheint nur Pseudowissenschaft zu sein und sollte auch so behandelt werden. Social Engineerer sollten sich nicht darauf stützen.

-
Quellenverzeichnis:
[1] Übersetzung aus http://jarhe.research.glam.ac.uk/media/files/documents/2009-07-17/JARHE_V1.2_Jul09_Web_pp57-63.pdf Volume 1, Number 2, S.59 (04.06.2011 03:35)
[2] Übersetzung aus http://knol.google.com/k/neurolinguistic-programming (04.06.2011 03:46)
[3] http://www.boerdlein.gmxhome.de/nlpmemo.html (04.06.2011 03:54)
[4] http://www.nlp-direkt.at/Downloads/NLP-E.pdf (04.06.2011 02:42)

Arduino + ferngesteuerte Lampe

Ich bin ein blutiger Kacknoob was Elektrotechnik angeht. Dennoch habe ich seit Jahren vor, etwas in der Richtung zu tun (wer will denn auch Systeme erforschen, ohne verstehen zu wollen, wie die darunter liegende Hardware funktioniert?). Also habe ich mich mit meinen bisherigen Kenntnissen (die mir schon fast peinlich sind) daran gewagt, ein Stückchen Hardware einem Reverse Engineering zu unterziehen

(Wer die vielen Andeutungen nicht verstanden hat: ich entschuldige mich dafür, keine genaue Ahnung davon zu haben, was ich hier in dem Post von mir gebe )

Ich wollte mit einem simplen Target anfangen. Bei Reverse Engineering von Software ist sowas einfach, da man ja unzählige 30-Tage-Shareware Programme findet, die man einfach kostenfrei runterladen kann, um an ihnen rumzuexperimentieren. Bei Geräten sieht die Sache wieder ganz anders aus. Ich fand zufällig diesen Artikel. Leider habe ich das dort vorgestellte Gerät nicht Zuhause (obwohl ich sowas schon im Baumarkt gesehen habe). Daraufhin fiel mir sofort ein, dass meine liebe Mami eine Wohnzimmerlampe gekauft hatte die (zu ihrer eigenen Überraschung) mit einer Fernbedienung an und ausgeschaltet werden konnte.

Was ich nun vor hatte war folgendes: Analysieren wie das Gerät funktioniert. Nachbauen. Und anschließend eventuell was tolles damit machen.

Ich habe mir schon gedacht, dass es schwer wird ihr zu erklären, wieso ich ihre Fernbedienung brauche. Also habe ich es mir eines Abends einfach geborgt, ohne zu fragen. (Falls es bei meiner Analyse kaputt gegangen wäre, hätte ich das Teil einfach verschwinden lassen. Und wenn meiner Mutter aufgefallen wäre, dass es geklaut wurde, hätte ich einfach die polnischen Nachbarn beschuldigen können)

Vier Buttons um verschiedene Farben und Funktionen der Lampe zu steuern. Mir würde auch schon genügen, wenn ich das Teil an und ausschalten könnte.

Also ersteinmal das ganze aufgeschraubt:

Hey, das ist ja super! Das sieht sehr einfach aus. Ich wollte nun zu aller erst wissen, wie die Fernbedienung der Lampe mitteilt, dass sie angehen soll. Und da fiel mir schon etwas auf:

Auf den oben verlinkten Beitrag vertrauend, habe ich angenommen, dass dieses Gerät im 433.92Mhz Bereich arbeitet, um seine Befehle zu versenden. Also habe ich mir einen 434 Mhz Empfänger und Sender gekauft, in der Hoffnung, diese mit meinem Arduino ansteuern zu können (mit dem Empfänger wollte ich das Protokoll analysieren).

Einige Tage später kam meine Bestellung an. Zu meinem Entsetzen musste ich feststellen, dass der Empfänger viel “rauschen” empfang. Es war sehr schwierig die relevanten Daten zu finden (und diese haben so merkwürdig variiert, dass ich keine Muster erkennen konnte).

Da kam mir die Idee, mir einen Logic Analyzer zu besorgen (so kann ich dann sehen, wann und wie lange eine 1 und eine 0 gesendet werden, indem ich direkt an dem Gerät selbst messe). Ich wollte mir schon seit längerem Bus Pirate gönnen und dieser ist in der Lage als (laut offiziellen Informationen ein sehr schlechter) Logic Analyzer zu dienen. Nachdem mein Bus Pirate ankam, schloss ich ihn direkt an und begann mit dem reversen!

Ich musste nun meinen Bus Pirate an die Pins anlegen, an denen ich messen/sniffen wollte. Dafür habe ich erstmal das oben dargestellte Element mit der Aufschrift “LR1 433.92″ (welches anscheinend das hier ist, genauer gesagt das hier) auf der Rückseite gesucht:

Und nun einfach die Kabel angelegt (nachdem ich mir sicher war, dass es hier um höchstens 5V geht, was der Bus Pirate anscheinend vertragen kann).

Nun musste ich nur noch die Kabel halten, sowie den Button der Fernbedienung drücken, und gleichzeitig das Sniffen in der Software starten (da hierbei aufgrund mangelnder Speicher nur sehr kurz aufgezeichnet werden kann, muss das alles sehr schnell gehen). Mit nur 2 Händen ist das ziemlich schwer!

Nach einigen Versuchen (und einem 5 Minuten (!) anhaltenden Krampf in meiner Hand, währenddessen ich in der Wohnung gebrüllt habe “HAHAHA, ICH BIN BEHINDERT” … habe ich Magnesiummangel?) hatte ich endlich eine Aufnahme:

Wobei hier nur die oberste Zeile/Aufnahme relevant ist.

Nun konnte ich entweder so cool sein, und analysieren was hier genau einen Bit darstellt (und ob es eine 1 oder eine 0 repräsentiert) oder aber, ich könnte das ganze einfach dumm nachbauen (Anmerkung: ich bin dumm).

Ich habe mir aufgeschrieben, wie lange eine “1″ gesendet wird, und wie lange die darauffolgende 0 etc. Was dann ungefähr so aussah:

1 = 300 us
0 = 800 us
1 = 800 us
0 = 300 us
1 = 800 us
0 = 200 us
1 = 800 us
[...]

Das habe ich nun in Arduino implementiert, wobei ich dafür den 434 Mhz Sender benutzt habe:

Und der Code dazu:

#define DATA_PIN 10

int send_1[] = {300, 800, 800, 300, 800, 200, 800, 300,
                200, 800, 300, 800, 800, 200, 800, 300,
                800, 200, 800, 200, 800, 300, 800, 200,
                300, 800, 800, 200, 300, 800, 300, 700,
                800, 300, 800, 200, 300, 800, 300, 700,
                300, 800, 300, 800, 200, 800, 300, 800,
                200};

int state;

void setup() {
  state = HIGH;
  pinMode(DATA_PIN, INPUT);
  Serial.begin(9600);
  Serial.println("Zu deinen Diensten!");
}

void loop() {
  while(Serial.available() == 0);
  while(Serial.read() != -1);
  int a;
  for(a = 0; a < 8; a++) {
    int i;
    for(i = 0; i < 49; i++) {
      digitalWrite(DATA_PIN, state);
      digitalWrite(13, state);
      delayMicroseconds(send_1[i]);
      state = (state == HIGH) ? (LOW) : (HIGH);
    }

    digitalWrite(DATA_PIN, state);
    digitalWrite(13, state);
    delay(8);
    state = HIGH;
  }
  digitalWrite(13, LOW);
  delay(5000);
}

Ganz einfach! Und funktionieren tut es. Damit ich irgendwas aufregenderes anstelle, habe ich einen Webserver bei mir auf dem Rechner aufgesetzt, welches per serieller Verbindung meinem Arduino befiehlt, das Licht an/auszumachen. Nun kann ich mit jedem internetfähigen Gerät, das Licht ausschalten. Hier beispielhaft mit meiner DSi:

Demnächst baue ich noch eine Klatsch-Funktion ein, sodass das Licht anspringt wenn man klatscht. Und falls ich den Spaß daran nicht so schnell verliere, wirds enden wie in einer Folge von The Big Bang Theory.

Wie auch immer. Ich hoffe, dass einige von euch trotzdem Spaß beim lesen hatten. Ich fühle mich jedesmal immer so doof, wenn ich noch am Anfang eines langen Weges stehe. Hofft mit mir, dass ich irgendwann in der Lage sein werde, spannendere Geräte zu analysieren!

Demnächst blogge ich wohl über das SFT09 Format, welches ich so gut wie fertig analysiert habe.

Disgu(i)sting

Ja, ich lebe noch.

Der letzte Blogeintrag ist fast schon ein viertel Jahr her. Ich hatte leider während der Semesterferien absolut keine Zeit für meine Hobbys. Ich musste zwangsweise etwas Energie in mein Real-Life investieren, und wer will das schon, richtig? Mir hat irgendwie auch die Motivation gefehlt irgendein Verschlüsselungssystem zu erforschen.

Gehen wir einen Tage zurück: Ich hatte keinen Zugang zum Internet und so langsam sind mir die Bücher ausgegangen, und so musste ich mir anders behelfen. Klar, ich könnte rausgehen in die Natur (haha!), aber ich hatte noch in meiner VirtualBox eine Applikation die darauf gewartet hat analysiert zu werden. Also wurde ich rückfällig, und saß dann gestern Abend wieder vor dem Rechner, um etwas zu analysieren. Das heutige Target nennt sich “Disguise” (na, war der Titel von dem Blogpost nicht einfallsreich?).

Diesmal war es etwas anders. Dieses Programm setzt zwar wieder auf Security-by-obscurity, aber einen Unterschied zu meinen vorherigen Targets hat es: es ist nicht direkt gebrochen, allein wenn man den Schlüssel und den Algorithmus gefunden hat.

In diesem Fall musste ich (un?)glücklicherweise tatsächlich eine Kryptoanalyse durchführen. Es ist meine erste echte Kryptoanalyse von einem unbekannten Verfahren gewesen, und wie das Leben so spielt, war es garnicht so schwer. Ich bin quasi in das Thema hineingerutscht.

Nun, was ist denn dieses Disguise? Auf der Webseite heißt es:

I share with you, with Disguise, a SECURE dual-keys proprietary multi-stage encryption algorithm to protect your PRECIOUS DATA.

(die Hervorhebungen sind originalgetreu übernommen)

Na sieh sich das mal einer an. Klingt doch super! Wäre da nur nicht dieses kleine winzige Wort “proprietary”, gäbe es keinen Grund für mich dieses Programm zu analysieren. Denn sonst hätte ich gedacht, dass das Verfahren etwas wie AES ist. Aber so weiß ich, dass der Programmierer vermutlich einen eigenen Verschlüsselungsalgorithmus entworfen hat. Und wer schonmal einen Kryptoexperten erlebt hat, der euch förmlich anbettelt, niemals einen eigenen Verschlüsselungsalgorithmus zu entwerfen, der wird spätestens in diesem Blogeintrag erfahren wieso.

Mittlerweile scheint es mir so, als könne man schlechte Verschlüsselung bereits an der GUI des Programmes entlarven. Vielleicht erinnert sich noch jemand an das hier. Jedenfalls, ist dieses Programm genauso hässlich:

Ekelhaft. Na vielleicht tut es ja seine Arbeit gut. Nämlich: Daten sicher verschlüsseln (hey, ihr seid auf meinem Blog, was glaubt ihr?)

Vorerst machen wir eine Blackbox Analyse. Ich werde mir also vorerst nicht den Programmcode anschauen. Ich werde eine Datei einspielen, und mir das Resultat anschauen.

Ich habe also testweise eine Datei verschlüsseln wollen. Und in dem Moment hatte mich das Programm nach zwei Daten gefragt. Es wollte von mir zwei so genannte “Signaturen” haben. Im Prinzip meint der damit nur ein Passwort. Ich sollte also zwei Passwörter eingeben. Allerdings durften diese nicht länger als 8 Zeichen sein. 8 Bytes? Das sind nur 64 Bit für einen Schlüssel. Allerdings will er zwei mal 8 Bytes. Wer weiß, was er mit diesen Passwörtern genau tut ?!

Ich werde im Laufe dieses Blogeintrages folgenden Plaintext als Eingabedatei “god.txt” verwenden (damit hier einige nicht rumheulen: es ist tatsächlich die erste txt Datei auf meinem Rechner, die mir unter die Finger kam; es hat keine weitere Bedeutung):

Is God willing to prevent evil, but not able? Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent.
Is he both able and willing? Then whence cometh evil?
Is he neither able nor willing? Then why call him God?

Nach der Verschlüsselung hatte ich eine Datei “goddis.txt”, mit dem Inhalt:

Na das sieht doch ziemlich verschlüsselt aus. Was mir als erstes aufgefallen ist: die Ausgabedatei ist um 33 Bytes größer als das Original. Was hat der Algo da bloß getan? Beim Versuch andere Dateien zu verschlüsseln, ist jedesmal die Ausgabedatei um 33 Bytes größer.

Ich mache jetzt etwas ganz simples. Ich werde die Ausgabe Datei goddis.txt mal nach der statistischen Häufigkeit der Bytes untersuchen. Da bietet mir mein Hexeditor HxD eine passende Funktionalität. Die Ausgabe sieht so aus:

Es gibt da nicht viel zu sehen. Man erkennt bloß, dass einige Bytes garnicht vorkommen, wohingegen die letzten Bytes (0xF4 bis 0xF7) verglichen mit den anderen Bytes, ziemlich oft in der verschlüsselten Datei auftauchen. 0xF7 taucht sogar ganze 17 mal auf (das sind 6,32% der ganzen Datei).

Schauen wir uns das Resultat der Verschlüsselung von standardisierten Verschlüsselungsalgorithmen an. Hier in dem Fall ist es AES:

Die statistische Verteilung der Bytes sieht schon ziemlich zufällig aus. Das Byte 0×35 kommt hier am häufigsten vor, mit genau 6 Auftritten (das sind 2,49% der Datei). Zum Vergleich schauen wir uns noch eine rein zufällige generierte Datei an:

Es gibt in diesem Fall mehrere Bytes die das Maximum darstellen. Sie tauchen genau 4 mal auf, und machen damit 1,66% der Datei aus.

Verglichen damit steht Disguise sehr doof da. Es gibt einem das Gefühl, dass die Ausgabe nicht wirklich durchgewürfelt ist; und vielleicht haben wir sogar eine Möglichkeit, den Algorithmus zu brechen.

Genug Blackbox Analyse. Wir öffnen das Programm mit unserem Lieblingsdisassembler/debugger und schauen uns an, was das Programm tut. Da ich in diesem Beitrag mehr auf die Analyse des Verfahrens eingehen möchte, und nicht schon wieder auf das Reverse Engineering (dazu schaut ihr lieber hier nach), werde ich kurz beschreiben was ich alles über den Algorithmus herausgefunden habe:

Es gibt eine erste Runde die ich “Phase 1″ getauft habe. In dieser Phase wird ein “Pseudo”-Ciphertext generiert, der einfach wieder zurück zum Ursprungszustand versetzt werden kann. Danach folgt die Phase 2, wo dann die zweite Signatur angewendet wird, um es zu verschlüsseln. Und dann haben wir unsere verschlüsselte Datei.

Ein etwas tieferer Einblick: Zuerst wird aus der Signatur 1 (hier der Einfachheit zur Liebe: “sign123″) etwas generiert, was ich sig1c nenne. Dabei wird folgendermaßen vorgegangen: Wir lesen das aktuelle Byte aus (hier “s” = 0×73). Dieser wird reversed zu 0×37. Nun führt man eine OR-Verknüpfung mit dem Wert 0×08 durch (= 0x3F) und negiert anschließend das Ganze (= 0xC0). Das macht man mit allen Bytes der Signatur. Alles hinter der Signatur ist 0×00. Diese pseudo-Verschlüsselung wird genau 31 mal angewandt. Nun wird ein 0×00 Byte angeschlossen und dahinter wird ein konstanter Wert “03″ hinzugefügt. Das sind insgesamt 33 Bytes, welcher der Verschlüsselten Datei vorne angehangen werden (das erklärt schonmal dieses Mysterium!).

Aber mooooment. Ich sagte gerade, dass hinter dem sign123 nur noch 0×00 Bytes folgen. Wenn man genau dieses Verfahren auf 0×00 anwendet, dann kommt stets 0xF7 heraus. Das könnte eventuell die statistische Häufigkeit der 0xF7 in der Ausgabe Datei erklären.

Das erzeugte sig1c sieht nun so aus: C0 61 81 11 E4 D4 C4 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 00 03

Das ist der Header, der jeder verschlüsselten Datei hinzugefügt wird (wobei die ersten 7 Bytes variieren, aufgrund der ersten Signatur; der Rest ist stets gleich!).

Der eine oder andere fragt sich nun: Wieso ist die Signatur nur 7 Bytes lang, obwohl das Programm 8 Zeichen haben will? Ich weiß nicht ob das so gewollt ist, aber das Programm liest nur 7 Bytes, und reserviert das 8te für das 0×00 Byte, um den String abzuschließen. Obwohl das total überflüssig ist. Wie wir nachher sehen werden, hat dieser kleine “Bug” mir Tür und Tor geöffnet.

Dieses sig1c-Verfahren wird auf die ganze Plaintext-Datei angewandt. Nun haben wir diesen Pseudo-Ciphertext, der wieder zurück zum Urprungszustand versetzt werden kann (es ist reversible/umkehrbar).

Auf diesen Zustand wird nun die Phase 2 angewandt. Dieser geht wie folgt:

Die Datei wird in 8-Byte Schritten eingelesen. Nun wird mit jedem Byte dessen mit dem aktuellen Byte der zweiten Signatur XOR verknüpft. (Bedenke: das letzte Byte der zweiten Signatur ist auch 0×00! Einfachheitshalber ist meine zweite Signatur “ABCDEFG”).

Beispiel von oben: Das erste Byte war 0xC0. Dieser wird mit 0×41 (“A”) geXORed. Es ergibt 0×81. Das Ergebnis des ersten Durchlaufes ist: 81 23 C2 55 A1 92 83 F7.

Nach jedem Durchlauf der 8 Byte, wird ein “shuffle” durchgeführt. Die Signatur2 wird verwürfelt. Allerdings hat sich der Programmierer hier sehr dumm angestellt (aber er hat anscheinend Ideen in die richtige Richtung gehabt!): Die Verwürfelung der Signatur ist nicht ständig das selbe. Es gibt 5 verschiedene Funktionen. Ein Counter wird jeweils modulo 5 geteilt, und jenachdem wird die jeweilige Funktion aufgerufen. Der Counter wird anfangs auf das 4te Byte des sig1c gesetzt (hier: 0×11 = 17).

17 modulo 5 ergibt 2. Es wird also die zweite Funktion zum shufflen der Signatur aufgerufen. Diese Funktion sieht in C so aus:

unsigned char op_value = signature2[3];
int i;
for(i = 0; i < 8; i++)
{
signature2[i] = signature2[i] ^ op_value;
}

es wird das 4te Byte der Signatur ausgelesen, und für die nachfolgenden Operationen verwendet. Nun wird jeder Wert der Signatur mit diesem Wert geXORed.

Das heißt quasi: Unsere aktuelle Signatur2 ist 41 42 43 44 45 46 47 00. Das dick markierte ist unser op_value. Zuerst XORed er also 0×41 mit 0×44. Dann 0×42 mit 0×44 usw. Irgendwann ist er aber bei sich selbst, er XORed also 0×44 mit 0×44. Wie jeder wissen sollte, ergibt das zwangsläufig immer 0×00. Das ist sehr fatal, wenn dieser Wert später in der Verschlüsselung Verwendung finden soll! Nach dem Shuffle haben wir eine Signatur2 die wie folgt aussieht: 05 06 07 00 01 02 03 44

Beachte: das letzte Byte ist 0×44, da hier 0×00 mit 0×44 geXORed wurde.

Nun, das ist der ganze Algorithmus. Nun machen wir uns daran, den Algorithmus anzugreiffen!

Wenn wir genau nachdenken, dann baut die Verschlüsselung darauf auf, dass der Pseudo-Ciphertext jeweils mit der zweiten Signatur XOR-verknüpft wird. Allerdings haben wir gerade gesehen, dass die zweite Signatur zwangsweise irgendwo eine 0×00 enthält. Irgendein Wert mit 0×00 geXORed ergibt wieder den Wert. Es passiert also nichts. Das heißt im Klartext: Ein Byte wird in dem Ursprungsformat bleiben, und nicht verändert.

Wenn ich mir jetzt in der fertig verschlüsselten Datei goddis.txt den nächsten 8-Byte Block anschaue, sehe ich das hier:

F2 F1 F0 F7 F6 F5 F4 B3

Wir erinnern uns, der Header bestand im zweiten Block nur aus 0xF7. Hier eine kleine bildliche Erläuterung:

Und da es ein XOR Verfahren ist, könnten die Pfeile auch eine Spitze auf beide Seiten haben. Denn ich kann auch Rückwärts von 81 durch XORen mit 0×41 wieder 0xC0 erhalten.

Ich sehe hier, dass beim XORen des zweiten Blockes, ein Fehler entsteht. Und zwar bleibt der 0xF7 bestehen, wie bereits erwähnt. Wenn wir nun die Ausgabe-Bytes (also F2 F1 F0 F7 F6 F5 F4 B3) wiederum mit 0xF7 alle XORen, haben wir die aktuelle Signatur2 (nämlich 05 06 07 00 01 02 03 44) errechnet. Aufgrund des 0×00 Byte-Bugs am Ende der Signatur, haben wir hier 0×44 (“D”) am Ende hängen. Wir wissen also, mit welchem Wert die Signatur geshuffled wurde. Wenn wir also alle signatur Bytes wieder mit 0×44 XORen, erhalten wir “ABCDEFG”. Tada!

Wir haben den zweiten Signatur-Key errechnet, dank der unzähligen Bugs im Algorithmus. Das hier vorgestellte Verfahren würde wohl in die Kategorie “Known Plaintext” fallen (beispielsweise wurde WEP dadurch gebrochen). Da wir in diesem Fall wissen, wie der Plaintext (hier eher Pseudo-Ciphertext) im Header aussieht (nämlich fast nur 0xF7er Bytes), können wir in jedem Fall den zweiten Signatur Key errechnen. Zur verdeutlichung:

Und mit diesem Key können wir nun sig1 entschlüsseln.

Wir haben allerdings ein Problem. Beim shufflen wird nicht immer XOR verwendet. Wir erinnern uns: es gibt 5 verschiedene Funktionen, um die Signatur zu shufflen. Eine davon verwendet ein “AND” zum verknüpfen, ein anderer ein “OR”.

Nehmen wir an, es wurde ein OR verwendet. Ich schaue mir diese shuffle Funktion an. Und als Operator wird das letzte Byte der Signatur verwendet. Allerdings ist das letzte Byte ja immer 0×00! D.h., beim shufflen werden alle Bytes der signatur mit 0×00 geORed. Das Resultat: es verändert sich nichts an der Signatur! Der nachfolgende 0xF7er Block wird mit der Original Signatur verschlüsselt. Wir XORen also wieder den Ciphertext mit 0xF7, und erhalten unsere original Signatur2. Das ist wieder ein trivialer Bug!

Anders sieht es aus, wenn “AND” zum shufflen benutzt wurde. Die passende Funktion dazu benutzt das 5te Byte der Signatur zum shufflen. Dieser könnte alles mögliche sein (alle printable ASCII Zeichen). Doch nicht verzagen, eddy fragen!

Bei einem AND können wir also nicht mit einer so einfachen Möglichkeit die Signatur2 errechnen. Aber wir können die aktuelle geshufflete Signatur für den 0xF7er Block errechnen, indem wir wieder diesen Ciphertext mit 0xF7 XORen. Und mit diesem Key rechnen wir ganz normal weiter.

Man sieht zwar noch meine Debug-Ausgaben, aber ich denke es ist ersichtlich, dass dieses Programm eine verschlüsselte Datei brechen kann, ohne zusätzliche Informationen, nur allein die verschlüsselte Datei! Wie toll ist das bitte? Hier der C-Quelltext (Bitte bitte entschuldigt den dreckigen Code! Es ist sehr schwer zu coden, und nebenbei die Analyse zu betreiben): disdis.c (hab jetzt absolut keine Lust die ganzen Debug Informationen zu entfernen…).

In diesem Blogpost liest man viele verschiedene Werte, und ich bin mir sicher, dass die meisten dem nicht folgen konnten und einfach nur verwirrt waren. Ich werde versuchen dazu ein paar Bilder mehr zu basteln (eventuell sogar eine Flash Animation?).

Wie auch immer; ich bin froh, denn: Der Verschlüsselungsalgorithmus ist gebrochen!

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.

OTRKEY-Breaker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Irgendwann werden die ersten 10 Bytes der Datei ausgelesen:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schleife {

}

Schleife {

}

Schleife {

Schleife {

}

}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/BFOc2rFp6YSmM+PUpdaen2HH45uQ+xTkqoejKUAqefktbOTBOlLqYGLfIdv+vn/uIyQ09eX70HdsSEPp

Ai8qU3dzUIyrj/SDgTEZlToeaBPZhPr04L0ZONliqKvNKNWwgcV4A0+Vwalgfpl/JnFF2JkIulRRMXlSoP9

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

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

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

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

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

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

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

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

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

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

Und ich kann mich am Video erfreuen:

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

DOWNLOAD (lieber nicht mehr benutzen; siehe unten)

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

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

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

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

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

OTRTOOL

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