AK's weblog

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.

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.

Dass mutt-ng so ziemlich eingeschlafen ist, wird mittlerweile jeder bemerkt haben, der mutt-ng selber verwendet. Tja, der Grund dafür ist, dass ich in Retrospektive betrachtet einfach nicht wusste, wie man das anzugehen hatte, um das ganze manageable zu halten. Insbesondere um das Mergen von Änderungen in upstream hab ich mir keine Gedanken gemacht, aber auch sonst wusste ich noch nicht so recht was über professionelles Patch-Management.

Die Probleme, die daraus resultieren, sind natürlich mannigfaltig: neue Features in mutt waren schwierig zu mergen, und das Tracken von Security Fixes ebenso problematisch. Irgendwann war dann ein Punkt erreicht, wo ich nicht mehr so recht motiviert war, da noch wirklich weiter dran zu arbeiten. Der damalige Stress in der Arbeit und schließlich das Bundesheer trugen ihr übriges dazu bei. Und auch die anderen Entwickler sahen die Probleme, die es bei mutt-ng gab.

Da aber mutt-ng doch einige sehr praktische Patches und Fixes enthält, die ihren Weg bis jetzt nicht in mutt gefunden haben, hab ich mich jetzt aufgerafft, und mir ein paar Gedanken gemacht, wie man denn das ganze besser machen kann, nachvollziehbarer, und vor allem so, dass Patches auch unproblematisch ihren Einzug in das offizielle mutt halten könnten. An Tools, um das Patch-Management zu unterstützen, hatte ich dazu transvn (welches auf Subversion aufbaut) und stgit (welches auf git aufbaut, das bei der Kernel-Entwicklung eingesetzt wird) evaluiert, mit keinem der beiden Tools war ich jedoch so wirklich zufrieden. Während sich transvn regelmäßig sein Repository zerschoss, und damit praktisch unbrauchbar war, hat git mit stgit doch den Vorteil, den Export und vor allem inkrementelle Updates aus CVS- und Subversion-Repositories zu unterstützen. So richtig zufrieden war ich damit jedoch nicht, weil es ja eine Bindung an ein bestimmtes Versionsverwaltungstool bedeutete. Und meine Anforderungen lagen nicht primär in der Versionsverwaltung, sondern im Patchmangement.

Mika hat mich dann freundlicherweise auf quilt verwiesen, ein Tool, dessen einziger Zweck Patchmanagement darstellt, unabhängig von jeder Versionsverwaltung, jedoch damit kombinierbar. Quilt verfolgt das Konzept eines Stacks, also ein Stapel von Patches. Man nimmt einen ungepatchten Sourcetree, sowie diesen Patchstapel, und kann einen Patch nach dem anderen, oder auch alle auf einmal hintereinander, applien. Wenn es ein Problem mit einem Patch gibt, so schreit quilt, und man kann dann manuell intervenieren, indem man z.B. den Patch durch einen aktuelleren ersetzt, oder den Patch trotzdem anwendet, und die fehlgeschlagenen Teile manuell einfügt. Damit kann es zwar zu Abhängigkeiten von Patches untereinander kommen, wenn diese etwa die gleichen Stellen oder sehr nahe beieinanderliegende Stellen im Source patchen. Praktisch hat sich dieses System jedoch bewährt, so schreibt eine wirkliche gute Einführung in quilt, die man bei SuSE findet, vom Extremfall, dass es zu einem Sourcetree wie dem Linux-Kernel mehr als tausend Patches zu verwalten gäbe, und dass das Ziel der Entwicklung von quilt es war, die SuSE-Kernelsourcen besser verwaltbar zu machen.

Nachdem ich also endlich die passenden Werkzeuge zur Verfügung hatte, hab ich mich gestern und heute hingesetzt, die Patches, die in mutt-ng eingeflossen sind, in aktuellen Versionen zu sammeln, sowie meine eigenen Änderungen aus mutt-ng zu extrahieren (wobei ich größtenteils auf frühere Versuche mit stgit zurückgreifen konnte), und mutt-ng neu zu bauen. Die Patches verwalte ich mich mit quilt, und das patches-Verzeichnis speichere ich in meinem Subversion-Repository. Mittlerweile ist dieser neuerliche Versuch schon soweit, dass ich sagen kann, dass ich ganz zufrieden bin mit der Funktionalität. An ein paar Stellen hakt es zwar noch, aber die hoffe ich in den nächsten Tagen beheben zu können, und das noch dazu in einer Form, die an die ursprünglichen Autoren zurückfließen können. Die derzeitigen Patches sind gegen das Release 1.5.12, bald werde ich jedoch versuchen, die Patches auf den CVS-Tree von mutt anzupassen.

Und so holt man sich die Patches und applied sie:
$ svn co http://bereshit.synflood.at/svn/mutt-patches/trunk/ mutt-patches
[...]
$ export PATCHES_DIR=`pwd`/mutt-patches/patches
$ cd $MUTTDIR
$ ln -s $PATCHES_DIR patches
$ quilt push -a
[...]
$ ./prepare
[...]
$ ./configure --your-favorite-options
[...]
$ make
Wie schon oben geschrieben, getestet ist das derzeit nur mit mutt 1.5.12.

So richtig öffentlich möchte ich das noch nicht stellen, da ich das ganze einerseits noch "runder" machen will und andererseits noch mehr Erfahrung im Patchmanagement sammeln will, insbesondere beim Einspielen von neuen Versionen der Patches.

Was mich im übrigens im Zuge der Arbeiten gestern und heute auch erstaunt hat, war, wieviel sich bei mutt mittlerweile getan hat. Header-Caching ist dazugekommen, und auch der GNUTLS-Patch wurde offenbar integriert. Immerhin diesen positiven Effekt hatte mutt-ng, nämlich die mutt-Entwicklergemeinde wachzurütteln, und klarzumachen, dass soviele praktische, jedoch nicht integrierte Features verfügbar sind. Einige weitere Patches, wie NNTP-Support oder die Sidebar, die wohl beliebtesten und am meisten verwendeten Features von mutt-ng, werden wohl nicht so schnell integriert werden. Insofern hat ein neuerlicher Anlauf in Sachen mutt-ng, diesmal mehr mit Fokus auf Patchsammlung und Integration ebendieser denn einem Fork, durchaus seine Berechtigung.

nion und ich haben heute in der Nacht w3bfukk0r 0.2 released. Als wichtigste Änderungen wären HTTP/HTTPS-Proxy-Support, jede Menge Bugfixes, die Möglichkeit, mehrere URLs zu scannen, eine neue Manpage und Sourcedokumentation (inkl. Doxyfile) zu nennen. Leider hat's beim freshmeat.net-Announcement einen Fuckup gegeben, statt "It's not possible to specify more than one URL to be scanned." sollte es "It's now possible to specify more than one URL to be scanned." heissen.

Tja, schon wieder vorüber ist sie, die erste Arbeitswoche bei meinem neuen Arbeitgeber. Anfangs war es etwas stressig, weil ich mich natürlich in das Produkt, an dem ich mitarbeiten werde, einarbeiten musste. Mittlerweile funktioniert das aber schon halbwegs gut (für die kurze Zeit), und ich hab schon so Sachen gemacht wie mit der hauseigenen Library, die primär verwendet wird, experimentiert, Erweiterungen für die eingebaute Skriptsprache entwickelt, und arbeite derzeit an einem kleinen Tool, das künftighin das eine oder andere mal gebraucht werden wird. Alles in allem wirklich interessant, und ich bin so motiviert bei der Arbeit wie schon lange nicht mehr. Ich merke, die Veränderung hat mir wirklich gut getan.

So, und jetzt auf ins Wochenende!

Heute hatte ich meinen ersten Arbeitstag bei Borland, und ich muss sagen, es ist äußerst erfrischend, nach längerer Zeit wieder an etwas völlig anderem als bisher in einer komplett anderen Umgebung als bisher zu arbeiten. Heute stand nur administrativer Kleinkram und eine Einführung in das Produkt, an dessen Entwicklung ich mitarbeiten werde, sowie erste Programmierexperimente mit den Libraries am Programm. Alles in allem aber bin ich höchst motiviert, und freue mich schon auf die nächsten paar Tage.

Forced Browsing ist eine Angriffstechnik, um Ressourcen auf Webservern, also Verzeichnisse und Dateien, die eigentlich nicht referenziert werden, trotzdem aufzufinden. Bisher sind die Tools in diesem Bereich eher dünn gesäht, und so kam Nico Golde auf die Idee, dafür ein eigenes Tool zu schreiben, und zwar auf Basis eines Wörterbuchangriffs. Ich hab ihm dabei geholfen, und so haben wir ins nächtens hingesetzt, immer über Skype in Verbindung stehend, und haben das Tool, das den Namen "w3bfukk0r" trägt, zu implementieren. Heute gab's noch ein paar kosmetische Korrekturen und Verfeinerungen, und so können Nico und ich das Release von w3bfukk0r 0.1 präsentieren.

w3bfukk0r 0.1 unterstützt HTTP und HTTPS, und testet anhand eines Wörterbuchs (es wird per default eines mitgeliefert, ansonsten kann jeder User sein eigenes verwenden) auf nicht referenzierte Verzeichnisse. Geschrieben ist das ganze in C, verwendet OpenSSL, und ist unter Linux und Mac OS X getestet.

Und so verwendet man w3bfukk0r:

% ./w3bfukk0r http://nion.modprobe.de/
Starting w3bfukk0r 0.1
Scanning http://nion.modprobe.de/ with 76 words from words.txt

Found http://nion.modprobe.de/tmp/ (HTTP 200)
Found http://nion.modprobe.de/blog/ (HTTP 200)
Found http://nion.modprobe.de/img/ (HTTP 200)
Found http://nion.modprobe.de/setup/ (HTTP 200)

Found 4 directories.
Server runs: Apache/2.0.54 (Debian GNU/Linux) PHP/5.1.4-0.1~bpo2

Scan finished (4 seconds).
%

Das Experimentierstadium hat übrigens folgendes nettes Easteregg auf events.ccc.de zutage gefördert: http://events.ccc.de/i/

Nach mittlerweile fast 4 Jahren bei WebDynamite habe ich mich entschlossen, beruflich neue Wege zu gehen und neue Bereiche kennenzulernen. Fündig geworden bin ich bei Borland, die seit kurzem praktischerweise ein Development Lab in meiner Heimatstadt Linz haben. Bisher habe ich mich im Bereich Web und mobile Applikationen bewegt, und so ziemlich alles von Webprogrammierung über WAP, WAP-Push, Symbian-OS-Programmierung bis hin zur Mitentwicklung des WAP-Frontends einer Online-Musikdownload-Lösung gemacht, und nun war es für mich einfach an der Zeit, mich neuen Herausforderungen zu stellen. Meine voraussichtlichen Tätigkeiten bei Borland wird im Bereich Netzwerkprogrammierung liegen, vorwiegend mit C++, also auf jeden Fall eine Möglichkeit, die Dinge, mit denen ich mich privat schon beschäftigt habe, nun auch beruflich umsetzen zu können. Am 2. Oktober beginnt der neue Job, und ich freu mich schon drauf.

I just submitted my paper for 23C3. This year I wrote a paper about trapdoor2, which I wrote together with Clifford. I will focus on its implementation and use it as an example to show what attack vectors against a network server (and especially trapdoor2) exist, and what techniques can be employed to encounter potential attacks. Look forward to a pretty interesting lecture, showing some state of the art techniques in secure network server programming in C on Unix and Unix-like operating systems.

ndbm is library standardized by SuSv3 to store arbitrary key/value pairs into a file. Out of boredom, I wrote a small and simple implementation of it for dietlibc. The format it implements is incompatible with other ndbm implementations. I compared my implementation with BerkeleyDB and GDBM (which both feature ndbm compatibility modes), and while my implementation is a lot slower, the size of my data files is about 50 to 60 % of the ones produced by BDB and GDBM.

You can download the patch here. I submitted this patch to the dietlibc author, and he found it cool, but hasn't integrated it into dietlibc yet. Oh, and in case anybody asks what software I use to manage my dietlibc patches: I use StGIT on top of git. I have a local copy of the CVS repository, and with StGIT, I can manage the patches in a stack (similar to Andrew Morton's patch scripts and transvn) and keep everything up to date if any changes in the CVS repository or on any patch are done.

After the generally positive feedback that I got for the first few steps with my prototypical IMAP client, I put further effort into it, and implemented cool features like replying, group-replying (aka "Reply All") and sending mails. Currently, the only transport protocol implemented is SMTP, but I made everything as generalized as feasible, so replacing SMTP with e.g. the local "sendmail" command wouldn't be much of an effort. In addition, I added (hear! hear!) support for showing threads. This means that threads of email discussions, be it a long conversation between you and a friend or a discussion on a mailing list, is shown in its structure. Again, I compiled a feature show of new features since the last posting as screencast.

Today I spent a few hours of hacking on an IMAP mail client in Ruby which I codenamed "liam" (backwards for mail, haha, how funny). I based it on basically two libraries, namely Ruby's Net::IMAP, which provides a very complete (but a bit complicated) interface to IMAP, and Clifford's STFL, the Structured Terminal Forms Library, which is pretty new, but definitely the best ncurses widget library around.

The functionality is currently really simple: you start the program, it connects to your IMAP server, reads all available mailboxes from it, and lets the user decide which one to open. After selecting the right mailbox from the list, it is opened and the message envelopes from this mailbox are downloaded. Then, the user can again select the message he wants to view. Then, the message is downloaded and the raw message is presented to the user using the less(1) pager. The user can view this message. When he quits less, he is again presented with the list of messages in the mailbox. To return to the list of mailboxes, a simple press of the 'q' key is enough. From there, it is possible to select another mailbox, or to quit liam by again pressing 'q'.

This probably sounds pretty difficult, but it's extremely simple. To visualize this more efficiently, I prepared a simple screencast, which you can view here.

But what is my goal with this prototype? I don't know yet. It is definitely not here to replace mutt-ng (which is not dead yet, I'm currently preparing a "relaunch" since I now know my requirements much better than at the beginning of the project), but it's more a prototype to experiment on the future of terminal-based email clients. Sooner or later, mutt (and mutt-ng) will require a rewrite, and with this prototype I can find out what will be important for a new design, and where the stumbling blocks might be. Anyway, any feedback is welcome.

Update: more hacking on liam (including a new STFL widget), and a new screencast to demonstrate email viewing.

A few weeks ago, Sven reminded me of an inherent problem of the current design of tpp's file format, namely it's line-based file format which gives no options to e.g. set text properties like bold or underlined for only a single word or a phrase. Currently, the whole line must be made bold, underlined or whatever.

For those who don't know: tpp is the "PowerPoint for the console" that I wrote together with Nico Golde and currently the (IMHO) only mature solution to do presentations solely using text terminals.

A quick look over the existing commands in the current file format shows three (no, four, nobody
expects the Spanish Inquisition!) classes of commands:

• presentation-wide commands: presentation title, author, date, header, footer, border
• slide-wide commands: header, footer (to override to presentation-wide default, if set)
• line-wide commands: output, shell output, special effects, alignment
• character-wide commands: text color, text properties like bold, underlined, reverse, ...

Now, the goal is to reflect this new specialization and change in what tpp should provide into a new, better file format, to make tpp more flexible than right now.

One option would be to use an XML schema, but that is not a very attractive option, since XML would be a lot too verbose to actually make it fun to write tpp presentations.

Another approach would be to keep with most of the current problems, and to introduce additional, Wiki-like formatting methods, like using stars or underlines or something like [bold|The text supposed to be bold] or [bold,fgcolor=blue,bgcolor=white|blue/white text, bold]. The only disadvantage: it would make the parser a lot more difficult than it currently is. But probably it is
too simple, anyway.

So, what's your opinion on that? I would like to hear your comments, and to do some brainstorming instead of just starting some experimental quick-shot implementation.

Today I finally sat down to remodel my HTTP stack/server from a forking model to a multithreaded model using the pthread library. Actually, this is my first project where I use POSIX threads, and I was delighted how easy it was to integrate them into my relatively well-designed program.

The server now works as follows: the "main" thread first creates a number of worker threads, and then accepts connections, puts them into a queue and then notifies the worker threads. The next worker thread that is ready takes the connection from the queue and handles the incoming requests. This is definitely a very simple design, which was also very easy to implement. The results can be found in httpstack/branches/pthread in the SVN repository. As usual, comments are welcome.

The next thing is where I will move that project. One idea I had was to integrate a database connection pool, and in addition probably a simple object-relational mapper, then an HTTP management interface for the whole thing and then some CMS.