Theorie und ihre Nützlichkeit Marc Ruef | 22.10.2007 Leider bin ich immerwährend benachteiligt. Für die meisten Studenten und Akademiker bin ich ein typischer Praktiker, der sich im Selbststudium die für ihn und seine Arbeiten wichtigen Dinge selber beigebracht hat. Für die vielen Praktiker bin ich jedoch gerne der Theoretiker, der sich an der Komplexität von Problemen sowie der Lösung dieser auf Papier erfreuen kann. Irgendwie bin ich also nirgends so richtig akzeptiert. In manchen Situationen kann man dies aber auch als Vorteil sehen. Als ich das codEX Project (http://www.computec.ch/projekte/codex/) angefangen und vorgestellt habe, haben mich sehr viele Akademiker (Studenten und Professoren) angeschrieben. In ihren Beiträgen haben sie mich darauf hingewiesen, dass es eine Vielzahl an akademischen Publikationen zum Thema Source Code Analysis gibt. Ich solle mich entsprechend darin üben, die gegenwärtigen Arbeiten zu respektieren und bei meiner eigenen Tätigkeit auf eben diese aufzubauen. Der österreichische Philosoph und Logiker Ludwig Wittgenstein schrieb in seinem Vorwort zu seinem ersten Hauptwerk Tractatus Logico-Philosophicus, dass es ihn nicht interessiere, was andere vor ihm gedacht oder gemacht haben. Sein kleines Schriftstück seien seine Gedanken, an denen er sich erfreue und die er ebenfalls gerne anderen zur Verfügung stelle: "Wieweit meine Bestrebungen mit denen anderer Philosophen zusammenfallen, will ich nicht beurteilen. Ja, was ich hier geschrieben habe, macht im Einzelnen überhaupt nicht den Anspruch auf Neuheit; und darum gebe ich auch keine Quellen an, weil es mir gleichgültig ist, ob das was ich gedacht habe, vor mir schon ein anderer gedacht hat." Ich sehe das selbst ähnlich, denn grundsätzlich geht es bei meinen Projekten meistens darum, mich vom Fernseher wegzulocken und mein Gehirn mit Puzzles in Betrieb zu halten. Dennoch schätze ich andere Arbeiten sehr. Wer einmal einen Blick in Die Kunst des Penetration Testing (http://www.amazon.de/dp/3936546495/), mein neuestes Buch, geworfen hat, der wird eine Vielzahl an Zitaten und Literaturverweisen finden. Den Arbeiten meiner Vordenker zolle ich also dennoch ein hohes Mass an Respekt, keine Frage. Interessiert mich ein Thema, lese ich jedes Buch, jeden Fachbeitrag und jedes Posting, das ich dazu finden kann. Die Analyse von Software ist seit Jahren, schliesslich muss ich beruflich regelmässig Quelltext-Analysen durchführen, ein solches Steckenpferd von mir. Verschiedene Leute, darunter Halvar Flake (http://addxorrol.blogspot.com), der seit Jahren für seine Binary-Analysen bekannt ist, haben mir das Buch Principles of Program Analysis (http://www2.imm.dtu.dk/~riis/PPA/ppa.html) empfohlen. Alleine der Verlag, in dem das Buch aufgelegt wurde, nämlich Springer, lässt den akademischen Hintergrund dessen vermuten. Und schon beim ersten Durchblättern habe ich gemerkt, dass dies ein Buch für Studenten sein muss: Eine Vielzahl von Pseudocode, Formeln und Diagrammen. Meine Vorfreude war ungebrochen, auch wenn ich plötzlich daran zweifelte, dass sich aus diesem Werk ein konkreter praktischer Nutzen für meine tägliche Arbeit sowie codEX erschliessen sollte. Sodann wagte ich mich an das erste Kapitel, welches ein kleines Programm zur Faktorisierung einführte. Dabei wird eine simple Programmiersprache names WHILE gebraucht, die sich an klassischem Pascal orientiert. Es wurde angedeutet, dass eben diese aus einem initialen Funktionsaufruf, einer simplen Kontrollanweisung mit if und drei Variablenzuweisungen bestehende "Anwendung" die Grundlage für das Buch bilden sollte. Alle nachfolgenden Beispiele diskutierten eben diese (S. 2ff): coderead(x); (if x>0 then y:=1 else (y:=2;S)); z:=y/code Die Komplexität der Betrachtungen erschien mir schon sehr bald, etwa in der ersten Hälfte des ersten Kapitels, als unendlich gross und kaum praxistauglich. Einfache Analysen wie die Reaching Definitions erfordern eine Unmenge an Formeln, selbst bei einem solch simplen Konstrukt. Komplexe Probleme wie eigens geschriebene Funktionen und objektorientierte Programmierung werden gänzlich ausgelassen. Der Leser wird schlussendlich mit einem Haufen Formeln zurückgelassen. Geht es dann an die Transformationen, um eine Simplifizierung des Programmcodes bzw. dessen Formalisierung anzustreben, werden wiederum die echten Probleme der richtigen Programmierung ignoriert. So wird behauptet, dass eine Anweisung (bzw. ein Ausdruck), die keine Variablen beinhaltet, stets die gleiche Rückgabe liefern wird (S. 28): "The second axiom ass2 expresses the second ingredient of the transformation - expressions can be partially evaluated; it uses the fact that if an expression contains no variables then it will always evaluate to the same value." Dies mag auf den ersten Blick stimmen, denn so sind Zeichenketten stets als statisch anzusehen. Wird jedoch eine Funktion x() ohne statische x(1, 2) bzw. ohne variable Argumente x(y) aufgerufen, muss diese nicht zwingend mit statischen Rückgabewerten aufwarten. Die eigens geschriebene Funktion könnte ja einfach den dynamischen Wert von time() zurückliefern oder sich auf systeminterne Werte im Sinn eines phpinfo() beziehen. Rekursive Funktionsaufrufe lassen die Komplexität explodieren. Die Autoren wünschten sich wohl viel mehr - wenigstens im Rahmen der didaktischen Diskussion -, dass die Realität einfacher ist, weder sie halt nunmal dargeboten wird. Doch auch schon andere (http://video.google.com/videoplay?docid=-5897236579900914407) haben bei praktischen Implementierungen die Schwierigkeit dessen erfahren müssen. Ohne Zweifel, das Buch besticht mit einer Fülle an Informationen. Es ist das wohl beste zum Thema, welches ich bisher gefunden habe. Und ich kann es nur jedem empfehlen, der sich ernsthaft und systematisch mit Quelltext-Analysen auseinandersetzen will. Zeitgleich muss man sich im Klaren sein, dass akademische Lehrbücher gerne ihre eigenen simplifizierten Modelle heranziehen, um der Komplexität und den Widersprüchen der harten Realität zur Vermittlung des Wissens zu entgehen. Auch weiterhin gibt es ungelöste oder unbefriedigend gelöste Probleme auf diesem Gebiet. Man sollte es deshalb den kommenden Wittgensteins nicht verübeln, wenn sie doch lieber ihr eigenes Rad komplett neu erfinden wollen. Das Schlimmste was ihnen passieren könnte, ist herauszufinden, dass sie gescheitert sind. Solange man daraus lernt, ist dies im Sinne der These/Antithese/Synthese jedoch gar nicht mal negativ auszulegen...