AK's weblog

Der Fahrplan zum 23C3 ist online. Es sind wieder etliche interessante Vorträge am Start. Es sind zuviele, um sie aufzuzählen, klickt euch selber durch. Und auch Truly Yours ist wieder vertreten.

Das Prinzip von "The War Tapes" ist ganz simpel: die Regisseurin, Deborah Scranton, gibt ein paar Soldaten der Nationalgarde Videokameras, um ihren Alltag im Irak zu dokumentieren. Heraus kommen über 900 Stunden Material, die dann auf knapp 100 Minuten zusammengeschnitten werden, und wahrscheinlich die authentischste und realistischste Dokumentation des Irakkrieges darstellen, ohne irgendeine bestimmte politische Sichtweise oder Interpretation zu betonen. Jetzt müsste der Film nur noch bei uns in die Kinos kommen... Hier auf jeden Fall schon mal der Trailer:


Update: auf Youtube sind ein paar Ausschnitte zu finden, hier und hier. Warning: graphic content ahead.
Update 2: ich hab mir den Film mittlerweile angeschaut (*hust*Bit*hust*torrent*hust*), und er ist sehr empfehlenswert, andererseits auch wirklich heftig.

Ende August habe ich ja einen Brief an die Beschwerdekommission geschrieben, zu dem dann auch Ermittlungen durchgeführt wurden, und ich auch eine telefonische Stellungnahme Anfang Oktober abgegeben habe. Jetzt ist endlich der Brief mit der Entscheidung gekommen. Leider nein.

Die Beschwerdekommission ist zu dem Schluss gekommen, dass mir kein Unrecht zugefügt wurde. Die letztendliche Erledigung bei einer Beschwerde fällt dem Bundesminister zu (bzw. jemandem in seinem Auftrag), und dieser schreibt mir, dass mein "Beschwerdevorbringen mit dem erhobenen Sachverhalt im Wesentlichen nicht übereinstimmt" und meine Beschwerde "daher zu Unrecht erhoben wurde". Bin ich eigentlich der einzige, der da einen gewissen Zynismus herausliest, a la "Sie haben gelogen, Herr Rekrut!"? Mit der Aussage der Beschwerdekommission kann ich mich anfreunden, dass mir kein Unrecht zugefügt wurde (der freundliche Herr bei der fernmündlichen Stellungnahme hat mir erklärt, dass die Aktionen des OvT, obwohl hart, durch das Hausrecht gedeckt sein sollten), beim Statement aus dem Ministerium selbst stößt es mir doch schon etwas sauer auf. Für sämtliche beschriebenen Vorfälle gibt es mehrere Zeugen, ich habe auch nichts von Relevanz weggelassen, und die Vermutung der möglichen Pflichtverletzung basiert auf der Einschätzung durch mehrere erfahrene Offiziere (!!).

Natürlich werde ich die Sache nicht mehr weiter verfolgen, da mein Vorhaben mit Einreichung der außerordentlichen Beschwerde, war, rauszufinden, ob nicht wirklich eine eventuelle Pflichtverletzung stattgefunden hat. Zumindest das habe ich als Soldatenvertreter meines ET in der Stellungskommission meinen Kameraden geschuldet. Damit wäre auch das letzte offene Kapitel Bundesheer für mich abgeschlossen.

In den letzten 2 Wochenenden hab ich an einem neuen Tool gebastelt, und zwar an noos, einem RSS-Feedreader für die Konsole. Zwar gibt es sowas schon, wie etwa snownews und raggle. Mit beiden Readern war ich aber nicht sehr zufrieden, snownews etwa wirkte auf mich immer etwas krude und das Interface etwas plump zusammengehackt, und raggle verhielt sich immer äußerst behäbig. Also hab ich mich mal rangesetzt, und was eigenes geschrieben. Und somit kann die Version 0.1 von noos präsentieren, die allerdings noch eher ein pre-alpha-Version ist, mit lediglich den rudimentärsten Features.

noos 0.1 hier runterladen

Die Abhängigkeiten sind etwas umfangreicher. Als UI-Toolkit habe ich STFL verwendet, da ich damit schon ein paar Prototypen und halbfertige Projekte realisiert habe. Zum Downloaden und Parsen der RSS-Feeds hab ich auf libmRss zurückgegriffen, welche wiederum abhängig ist von libnxml, die ich für den OPML-Import verwendet habe. Und als Storage-Backend für den Item-Cache hab ich mich für das bewährte SQLite entschieden. Zwei Wochenende und 1000 Zeilen C++ später steht also eine erste verwendbare Version. Die Features sind noch etwas dürftig, und das Rendering des HTML in den Descriptions ist noch total zum vergessen, aber es ist schon ein guter Ansatz sichtbar.

Und hier noch ein Screenshot:

Feedback welcome.

Diese Liste ist heute um einen Punkt länger geworden. Und zwar bin ich eher zufällig auf Sar-El gestoßen (mehr bei Wikipedia). Die Idee von Sar-El ist, dass man sich freiwillig meldet, und dann 3 Wochen lang als Freiwilliger in der Israelischen Armee mitarbeitet. Die Einschränkungen: man trägt keine Waffe. Man leistet keinen Eid oder Schwur, und ist offiziell eigentlich garnicht Mitglied der Israelischen Armee (obwohl Uniformträger; kriegsrechtlich "Non-Combatant"). Man kriegt nichts bezahlt, lediglich Unterkunft und Essen zur Verfügung gestellt, d.h. Flug etc. muss man sich selbst bezahlen.

"Und warum will der AK so einen Scheiß machen?" - weil's doch eine sehr schräge Art ist, seinen Urlaub zu verbringen. Ich denke aber, das könnte eine durchaus interessante Erfahrung werden, man lernt neue Leute kennen, man erlebt die Abläufe in einer fremden Armee, und man sieht auch noch ein anderes Land, in das man für gewöhnlich nicht kommt. Und es gibt noch einen zwingenden Grund, warum man das unbedingt mal erlebt haben muss: die feschen, jungen Soldatinnen in der Israelischen Armee! Wer's nicht glauben will, der sehe selbst.

Danke, dass ihr mir meine An- und Rückreise nach Berlin zum 23C3 jetzt schon vermiest. Nicht nur, dass ich mein Bier nicht mehr im Handgepäck mitnehmen darf, und die im Duty-Free-Shop gekauften Getränke ebenfalls nicht konsumieren darf, nein, jetzt werden voraussichtlich auch noch die gesamten Kontrollen wesentlich strenger und (für mich) anstrengender. Al Kaida soll nämlich um die Weihnachtszeit zuschlagen. Und wofür diese Panikmache? Wieder für den Arsch. Investiert das für den Kampf gegen den Terror verprasste Geld in die Herzinfarkt- und Schlaganfallvorsorge, da kann man mehr Menschenleben damit retten, anstatt Reisende zu schikanieren und faktische Getränkemonopole an Bord der Flugzeuge zu etablieren. Takbir!

Fefe schreibt in seinem Blog über die Fehlermeldung, die gcc bei "long long long" ausspuckt. Ich hab mir das noch etwas weiter angeschaut, und das mal mit 5 mal "long" ausprobiert:
$ cat t.c
long long long long long foo = 0;
$ gcc -c t.c
t.c:1: error: 'long long long' is too long for GCC
t.c:1: error: 'long long long' is too long for GCC
t.c:1: error: 'long long long' is too long for GCC
$
Und um ehrlich zu sein: wenn ich sowas sehe, möchte ich nicht wissen, was für ein Hack das Parsen von "long long int" bzw. "long long long" in gcc sein muss...

Durch ein sehr simples Demo-Programm aus dem lokalen IRC-Channel bin ich inspiriert worden, das ganze etwas zu verbessern, und ein paar simple Funktionen zu schreiben, mit denen man zur Laufzeit erkennen kann, ob innerhalb eines bestimmten Code ein Breakpoint gesetzt worden ist. Den Code dazu gibt's hier zum anschauen, und hier eine kurze Session:
$ gcc -g antibreak.c -o antibreak
$ ./antibreak
i=0
i=1
i=2
$ gdb antibreak
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) break antibreak.c:11
Breakpoint 1 at 0x8048408: file antibreak.c, line 11.
(gdb) break antibreak.c:19
Breakpoint 2 at 0x804843d: file antibreak.c, line 19.
(gdb) break antibreak.c:32
Breakpoint 3 at 0x80484ce: file antibreak.c, line 32.
(gdb) r
Starting program: /home/ak/antibreak/antibreak
found breakpoint at address 0x0x8048408
found breakpoint at address 0x0x804843d
found breakpoint at address 0x0x80484ce

Program exited with code 01.
(gdb) quit
$
Um das gleich mal am anfang zu klären: ja, das funktioniert auch ohne -g, allerdings kann man dann im gdb keine Breakpoints auf Zeilennummern setzen.

Der Hintergrund: gdb setzt Breakpoints, indem der Maschinencode im Speicher so verändert wird, dass an der jeweiligen Stelle ein INT 3 (Opcode 0xCC) reingeschrieben wird.. Wird diese Stelle nun ausgeführt, löst dieser INT 3 einen Trap aus, bei dem sich gdb reinhängt, und vor einem Continue an die Stelle noch den vorherigen Opcode reinschreibt.

Die von mir geschriebenen Funktionen machen es nun so, dass man eine Start- und eine Endadresse angibt, und dieser Bereich von einem simplen x86 Opcode Decoder angeschaut wird, und wenn ein INT 3 gefunden wird, wird die Adresse der Instruktion zurrückgeliefert. Von diesem Punkt weg kann man dann solange weitere INT-3-Instruktionen suchen, bis man die Endadresse erreicht hatt. Den Opcode Decoder hab ich übrigens nicht selbstgeschrieben, sondern über Google gefunden, und für kompakt genug befunden, um den schnell mal via copy/paste zu verwenden. Als End-Adresse hab ich übrigens in allen Fällen die Startadresse der nächsten Funktion im Sourceode verwendet. Klar, das verlässt sich auf ein gcc-spezifisches Verhalten, aber hey, das ganze ist sowieso auch x86-spezifisch, also, was soll's?

Wer übrigens noch mehr über ein paar nette Anti-Debugging-Techniken unter Linux lesen möchste (kein Voodoo-Techniken, aber trotzdem ganz interessant für n00bs wie mich), dem kann ich nur diesen Text empfehlen.

Wie ich übrigens aus gut informierten Kreisen erfahren habe, gibt es noch eine andere Debugging-Technik, die auf den Debug-Registern des x86 aufbauen, und das dürfte von neueren gdb-Versionen schon (teilweise) unterstützt werden. Insofern ist nicht garantiert, dass das in Zukunft auch nur irgendwie funktioniert.