• Skip Navigation

Blog von eddy14

Search for:

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

Archive for the ‘Informatik’ 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)

Bist du ein Hacker?

                              Bist du ein Hacker?
                                 von ReDragon

        Lass mich heute einen kleinen Test mit dir durchführen. Sag mir ob du
dich in dieser Beschreibung wiedererkennst: Du bekamst deinen Internet-Zugang
vor einigen Monaten und lachst nun über die Reportagen über die "Datenautobahn".
Du hast eine red-box und musst nicht für Telefonanrufe bezahlen. Du hast
crackerjack und hast ihn über eine Passwort-Datei auf einem Unix, wo du einen
Zugang hast, laufen lassen. Jeder in deiner Schule ist beeindruckt von deinem
Wissen über Computer; du bist derjenige, den die Lehrer um Hilfe bitten. Hört
sich das nach dir an? Du bist kein Hacker.
        Es gibt Tausende Leute wie dich dort draußen. Du kaufst dir 2600 und
stellst Fragen. Du liest Phrack und du stellst Fragen. Du trittst #hack bei und
stellst Fragen. Du stellst all diese Fragen und du fragst dich nun, was daran so
falsch sein soll? Letzten Endes heißt doch Hacker zu sein, Fragen zu stellen,
oder nicht? Aber du willst gar kein _Wissen_. Du willst Antworten. Du möchtest
nicht wissen, wie Dinge funktionieren. Du willst Antworten. Du willst nichts
erforschen. Alles was du willst sind Antworten auf deine verdammten Fragen.
Du bist kein Hacker.
        Beim Hacken geht es nicht um Antworten. Hacken handelt über den Pfad
den du beschreitest um die Antworten zu finden. Wenn du Hilfe brauchst, frag
nicht nach Antworten, frag nach Richtungsweisungen für den Weg den du gehen
musst um die Antworten selbst zu finden. Denn Hacker sind nicht die Leute mit
den Antworten; es sind die Leute die entlang des Weges gehen.

Ich habe mich an einer deutschen Übersetzung von dem hier versucht. Auch wenn der Text ein wenig veraltet ist (einige Webseiten nennen 1998 als Datum); ein gewisser ReDragon gibt dennoch ziemlich gut wieder, wie heute die Lage aussieht. Die Leute sind nur noch daran interessiert, ein Ergebnis zu haben. Kaum einer erfreut sich an dem Weg.

Ich versuche nunmehr seit einigen Jahren meinen Lesern zu vermitteln, wieviel Spaß mir das auseinandernehmen von Computersystemen (hauptsächlich Software, seit kurzem auch Hardware) macht. Wieviele der Leute die sich in den heutigen Security Boards herumtreiben, wollen verstehen wie ihr Computer funktioniert?

Was passiert eigentlich genau in meinem Computer, während ich diese Tasten meiner Tastatur drücke? Wie kann es sein, dass ich Informationen an meinen Computer übergebe, welcher es in ein weltweites Netzwerk von Computern verschickt, wo es für eine lange Zeit gespeichert wird, damit ihr es abrufen und lesen könnt; und das alles mit 1en und 0en?

Wie kann solch ein komplexes System mit so einer Einfachheit dahinter funktionieren? Wie kann man aus zwei Zuständen, etwas wunderbares wie den Computer erschaffen? Bei diesen Gedanken fällt mir immer ein Zitat von Darwin über das Leben auf der Erde ein: “[...] from so simple a beginning endless forms most beautiful and most wonderful have been, and are being, evolved“.

Findet ihr die Informatik nicht faszinierend? Sitzt ihr nicht sprachlos vor dem Bildschirm, wenn ihr davon lest, dass ein Compiler in der selben Sprache geschrieben ist, welche es compilen soll? Oder wie wäre es mit einem Drucker welches sich selbst druckt? Ist euch klar, dass ihr alles mögliche programmieren könntet, und so gut wie das einzige was euch beschränkt, sind eure eigenen Fähigkeiten? Ihr könntet direkt heute damit anfangen, einen Simulator für das ganze Universum zu schreiben (ich lache gerade wie ein verrückter Professor).

Auch wenn ich nur einen Bruchteil darüber weiß, wie mein Computer funktioniert, fasziniert mich jedes neue Stückchen Information darüber. Ich bin sehr glücklich über die Tatsache, dass ich immernoch auf dem Weg bin.

Manchmal fühle ich mich immernoch wie an einem dieser Tage, als ich den Computer neu entdeckte. Als ich jedes Tutorial über Programmiersprachen verschlang. Als ich jedesmal Größenwahnsinnig wurde, wenn ich ein Sicherheitssystem umgehen konnte, und mir einbildete, vielleicht irgendwann Herr aller Informationen zu werden. Und ich habe mich kein Stück geändert. Ich glaube heute noch, ich könnte irgendwann alles auf dieser Welt verstehen.

Kaum einer der Personen, die sich heute für Informatik interessieren, machen es aus Spaß am Erforschen. Wo sind die Leute geblieben, die erst mit dem Sonnenaufgang feststellen, dass sie mal wieder zu lange programmiert haben?

Ich hoffe, meinen Lesern wird nun (wenn es nicht schon der Fall war) klar, wieso ich versuche jedes Thema hier auf dem Blog detailhaft zu schildern: ich möchte, dass ihr seht, wieviel Spaß das macht. Ich möchte, dass ihr erkennt, welche Wege ich gegangen bin, um mein Ziel zu erreichen. Ich möchte, dass ihr wisst, dass das Ergebnis nicht alles sein sollte, was ihr wollt; sondern der Weg. Ich möchte euch Mittel geben, mit denen ihr euren Hunger nach Wissen zumindest für eine kurze Zeit stillen könnt.

Und ich denke, ich werde dem nicht gerecht. Also gibt es von nun an die Kategorie “Informatik” hier auf meinem Blog. Ich habe schon öfter behauptet, ich würde von nun an öfter bloggen. Ich halte mich einfach an das Sprichwort, dass Leute anfangen einem zu glauben, wenn man eine Lüge oft genug wiederholt. Ich werde von heute an öfter bloggen.

Was ich vorhabe: Eine Tutorialserie, wie der Computer von den “ersten Prinzipien” her aus der Schaltungsebende heraus gesehen funktioniert. Wenn es gut läuft, vielleicht sogar hoch bis zum Betriebssystem. Und natürlich allgemein, über die Informatik. Vielleicht schaffe ich es sogar, den einen oder anderen zu der “guten Seite” zu ziehen

Möget ihr dann erkennen, was einen durstigen Hacker ausmacht!

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.