Für die “Bin-Pwn 100” Challenge wird uns ein Archiv bereit gestellt sowie die recht simple Aufgabenbeschreibung:
Retrieve the key!
genannt.
Wir arbeiten uns also langsam vor, entpacken als erstes die Datei und sehen uns den Inhalt genauer an:
rup0rt@linux:~/PoliCTF2012$ tar xfvz umad.tar.gz jpeg/ jpeg/jconfig.h jpeg/jpeglib.h jpeg/jmorecfg.h jpeg/jerror.h libjpeg.a Makefile umad.cpp
Im Archiv befinden sich Header-Dateien der JPEG-Bibliothek, die statisch kompilierte JPEG-Bibliothek selbst (libjpeg.a) sowie eine C++-Quellcodedatei “umad.cpp” und deren Makefile. Wir kompilieren zunächst den Quellcode mit Hilfe der “Makefile” um so das Verhalten abzuschätzen.
rup0rt@linux:~/PoliCTF2012$ make g++ -o umad umad.cpp -L. -ljpeg rup0rt@linux:~/PoliCTF2012$ ./umad Done rup0rt@linux:~/PoliCTF2012$ ls -lh drwxr-xr-x 2 creeq creeq 4.0K May 26 00:23 jpeg -rw-r--r-- 1 creeq creeq 1.4M Aug 8 16:11 libjpeg.a -rw-r--r-- 1 creeq creeq 56 May 26 00:30 Makefile -rw-r--r-- 1 creeq creeq 13K Nov 21 17:15 out.jpeg -rwxr-xr-x 1 creeq creeq 422K Nov 21 17:15 umad -rw-r--r-- 1 creeq creeq 3.3K May 26 10:51 umad.cpp
Anhand der Kompilierungszeile der Makefile erkennen wir, dass sowohl die JPEG-Header-Dateien (-l) als auch die statische JPEG-Library (-L) tatsächlich für die Kompilierung verwendet werden. Die Ausführung des erstellten Programmes “umad” liefert eine weitere Datei “out.jpeg”, die wir uns als nächstes ansehen.
Bis auf die Frage “U MAD ?” ist an diesem Bild nichts besonderes erkennbar. Auch nach binärer Betrachtung scheint es sich um ein herkömmliches JPEG-Bild zu handeln. Das Betrachten des C++-Quellcodes sowie der Header-Dateien lässt uns ebenfalls keine besonderen Auffälligkeiten vorfinden.
Passend zur Aufgabe “Binary-Pwn” wird sich die Manipulation daher wohl in der statischen JPEG-Library “libjpeg.a” befinden. Statisch erstellte Bibliotheken bestehen in der Regel aus einer Sammlung von Objekt-Dateien (.o), die zu einem AR-Archiv zusammen gefasst und dabei mit der Dateiendung (.a) versehen werden.
rup0rt@linux:~/PoliCTF2012$ file libjpeg.a
libjpeg.a: current ar archive
Um an den Inhalt des Archives zu gelangen, müssen wir die Daten demnach mit dem Werkzeug “ar” entpacken:
rup0rt@linux:~/PoliCTF2012$ mkdir libjpeg
rup0rt@linux:~/PoliCTF2012$ cd libjpeg/
rup0rt@linux:~/PoliCTF2012/libjpeg$ ar x ../libjpeg.a
rup0rt@linux:~/PoliCTF2012/libjpeg$ ls
jaricom.o jcmarker.jpeg jdarith.o jdmaster.o jidctfst.o
jcapimin.o jcmarker.o jdatadst.o jdmerge.o jidctint.o
jcapistd.o jcmaster.o jdatasrc.o jdpostct.o jmemmgr.o
jcarith.o jcomapi.o jdcoefct.o jdsample.o jmemnobs.o
jccoefct.o jcparam.o jdcolor.o jdtrans.o jquant1.o
jccolor.o jcprepct.o jddctmgr.o jerror.o jquant2.o
jcdctmgr.o jcsample.o jdhuff.o jfdctflt.o jutils.o
jchuff.o jctrans.o jdinput.o jfdctfst.o
jcinit.o jdapimin.o jdmainct.o jfdctint.o
jcmainct.o jdapistd.o jdmarker.o jidctflt.o
In der Bibliothek finden wir neben den erwarteten Objekt-Dateien (.o) auch die JPEG-Datei “jcmarker.jpeg”, die vom Dateityp her für gewöhnlich in statischen Librarys nichts zu suchen hat. Da das Öffnen im Bildbetrachter fehlschlägt, folgt die Analyse mit dem Werkzeug “file”.
rup0rt@linux:~/PoliCTF2012/libjpeg$ file jcmarker.jpeg
jcmarker.jpeg: data
Dieses meldet uns, dass die Datei “nur” aus Daten besteht, was bedeutet, dass der Datei-Magick nicht erkannt werden konnte. Wir öffnen nun also selbst einen Hex-Editor.
Ansatt eines herkömmlichen JPEG-Headers finden wir am Anfang der Datei jedoch nur die 10 Zeichen “#!/bin/sh\x0a”, die einer normalen Shebang-Zeile entsprechen. Da anschließend jedoch nur Binärdaten folgen, kann es keine BASH-Datei sein!
Bei der Untersuchung, wie ein normaler JPEG-Header aussehen sollte, finden wir heraus, dass dieser ebenfalls nur 10 Bytes groß ist. Das lässt die Vermutung zu, dass im vorliegenden Bild nur der Header ersetzt wurde. Um diesen Zustand zu korrigieren, öffnen wir das von “umad” erstellte Bild “out.jpeg” ebenfalls im Hex-Editor und ersetzen die ersten zehn Bytes der Datei “jcmarker.jpeg” mit dem korrekten JPEG-Header.
Anschließend versuchen wir die veränderte “jcmarker.jpeg”-Datei erneut mit einem Bildbetrachter zu öffnen und sehen diese Ausgabe:
Es handelt sich um das ursprüngliche “U MAD ?”-Bild, das jedoch diesmal um den Schlüssel, der zum Lösen der Challenge erforderlich ist, ergänzt wurde!
Die Lösung lautet somit “8d66668deee4964c2c429e2ae64ccc8667b5d911“.