Diese Challenge (hypercomputer 1) erinnert nicht nur vom Namen her an die Supercomputer-Challenge aus dem vorjährigen plaidCTF 2012. Auch die Aufgabenstellung selbst weist bereits auf diese Challenge hin und vermerkt, dass es diesmal einfacher sein soll. Neben der Beschreiben erhalten wir die IP-Adresse eines SSH-Servers von dem wir uns dieses Binary kopieren.
Eine erste Untersuchung zeigt uns…
root@linux64:~/Plaid2013# file hypercomputer
hypercomputer: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x0b7c8d904831417f536c59b59fdecfc738136536, stripped
…, dass es sich um ein 64bit Linux-Binary handelt, das beim normalen, testweisen Ausführen diese Ausgabe liefert:
root@linux64:~/Plaid2013# ./hypercomputer ...Welcome to Hypercomputer!... ...This could take a very long time...
Es ist jedoch nicht so, dass dieser Text sofort erscheint – vielmehr dauert es mehrere Sekunden, was darauf schließen lässt, wie lange die gesamte Berechnung und Ausgabe der Flagge dauern könnte. Im letzten Jahr musste der Assembler-Code per Hand untersucht und optimiert werden, also sehen wir uns auch diesmal das Programm im Debugger an.
root@linux64:~/Plaid2013# gdb ./hypercomputer
GNU gdb (GDB) 7.4.1-debian
Reading symbols from /root/Plaid2013/hypercomputer...(no debugging symbols found)...done.
(gdb) run
Starting program: /root/Plaid2013/hypercomputer
...Welcome to Hypercomputer!...
...This could take a very long time...
^C
Program received signal SIGINT, Interrupt.
0x00007ffff787cbc0 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
Durch die Unterbrechung der Programmausführung mit CTRL+C sehen wir, dass die Ausführung in der Funktion nanosleep(), die eine bestimmte Zeit abwartet, angehalten wurde. Dies erinnert schon an das Vorjahr, in dem der Programmablauf ebenfalls durch solche Funktionen künstlich verzögert wurde.
Continue reading
