HackIt Nivel 10: reverse engineering

Tras seguir las pistas dadas en los anteriores posts sobre el HackIt Nivel 9 (léanse también los comentarios), llegamos al fatídico nivel 10. Aquí nos quedamos cuando sonó el ¡gong! del GAME OVER 😉 A primera vista la cosa no pinta muy bien, dado que tras descargar el zip y descomprimirlo, vemos que efectivamente se trata del juego Breakout, por lo que dice el «enunciado» de la pista y por las librerías gráficas que carga:


[juanan@localhost game]$ ldd go
linux-gate.so.1 => (0x00110000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0x02216000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00a6e000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x061ea000)
libm.so.6 => /lib/libm.so.6 (0x004bb000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x002aa000)
libc.so.6 => /lib/libc.so.6 (0x00360000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00bcc000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00bae000)
libdl.so.2 => /lib/libdl.so.2 (0x004e6000)
/lib/ld-linux.so.2 (0x00341000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00639000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x0063e000)

pero, si analizamos el tipo de fichero:

[juanan@localhost game]$ file go
go: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), corrupted section header size

vemos que es un fichero ejecutable ELF para Linux, y ¡ojo al parche!, las cabeceras están manipuladas (corrupted section header size) :-O Me temo que a GDB no le gustará nada de nada…


[juanan@localhost game]$ gdb go
GNU gdb Red Hat Linux (6.6-45.fc8rh)
(no debugging symbols found)


Pues vaya… no hay tabla de símbolos, así que ¿cómo indicar los puntos de ruptura? ¿cómo depurar el programa? Os dejo con el reto, y os animo a proponer vías de solución en los comentarios. Yo voy a por un café y cumplimentar papeleos de la universidad…

3 comentarios en «HackIt Nivel 10: reverse engineering»

  1. Hmm, no es mucha ayuda pero, con un vistazo rapido usando strace, vemos que intenta leer del archivo «license.txt» del mismo directorio:

    brk(0) = 0x977a000
    brk(0x979b000) = 0x979b000
    open(«license.txt», O_RDONLY) = 3
    fstat64(3, {st_mode=S_IFREG|0664, st_size=22, …}) = 0
    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8

    Ademas de eso si usamos el comando «strings» podemos mirar los strings en cleartext del ejecutable, entre los resultados curiosos tenemos este output:

    error: wrong license number
    error: license file not found!
    error closing license file!
    license.txt
    p@Pong
    pong
    Failed to open display

    Asi pues, escribiendo ‘p@Pong’ y ‘pong’ en el archivo license, el ejecutable hace un read() mas que la anterior ocasion en el output de strace:

    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8015000
    read(3, «p@Pongnpongn», 4096) = 12
    read(3, «», 4096) = 0
    fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), …}) = 0

    Esto a lo mejor sirve de pista a alguien, si consigo algo mas de tiempo, se puede probar a desensamblar en IDA o algo.

  2. Este es otro en el que me he encallado. (con lo fácil que es el nivel 11!).

    LIDA da el error: ERROR: 08048F50 not found in address range!

    He conseguido depurar con ald y rastrearlo pero por ahora sin demasiado éxito

    No sé, quizás habría que abordarlo de otra forma …

  3. Usando objdump se puede saber la dirección de entrada del código:

    $ objdump -x go

    Se obtiene la dirección de entrada 0x08048f50 (que coindice con la que a Xabier LIDA le da como error)

    Ahora se puede establecer en el gdb el primer punto de ruptura en esa dirección:
    (gdb) break *0x08048f50

Responder a Anom Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.