Preparación del laboratorio
Contenido descargable del reto:
El archivo descargable del reto contiene el binario golfer.
Análisis estático
Para determinar el tipo de archivo con el que estamos trabajando, utilizamos el comando file, que nos proporciona información básica sobre el archivo.

Un ELF de 32 bits es un formato estándar para ejecutables y bibliotecas en Unix. Contiene código y datos para la ejecución en arquitecturas de 32 bits.
Para obtener más información del ejecutable, podemos utilizar el comando readelf para analizar la cabecera (header). La cabecera proporciona información sobre la estructura y organización del archivo, desde su tipo y arquitectura hasta la ubicación de sus diferentes secciones (código, datos, etc.).
$ readelf -h golfer
ELF Header:
Magic: 7f 45 4c 46 01 61 34 66 54 55 48 7d 79 52 7b 6c
Class: ELF32
Data: <unknown: 61>
Version: 52 <unknown>
OS/ABI: <unknown: 66>
ABI Version: 84
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x800004c
Start of program headers: 44 (bytes into file)
Start of section headers: 808673127 (bytes into file)
Flags: 0xbeef7242
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
readelf: Warning: possibly corrupt ELF file header - it has a non-zero section header offset, but no section
headers
El análisis de la cabecera revela un problema con los encabezados de sección. Aunque se indica un desplazamiento no nulo para las secciones, no hay ninguna sección definida.
Me explico: el campo Start of section headers indica que el programa debería comenzar en el byte 808673127; sin embargo, el valor 0 en Number of section headers indica que no hay secciones disponibles.
Al no tener secciones definidas, se impide la localización del código a ejecutar, lo que provocará que el programa no pueda iniciarse correctamente.
Es importante guardar el punto de entrada del programa, 0x800004c, para facilitar el proceso de depuración.
La dirección también puede aparecer escrita como
0x0800004c. Ambas representan el mismo valor, ya que los ceros añadidos a la izquierda no modifican una dirección hexadecimal.
Análisis dinámico
A continuación, se procede a ejecutar el programa para verificar su comportamiento.
$ ./golfer
Como se anticipaba, el programa no realiza ninguna operación visible.
Análisis del código
Utilizando la herramienta Radare2 (r2), abrimos el archivo:
r2 golfer
Una vez dentro, ejecutamos el comando pd para inspeccionar el contenido del binario.

Podemos observar que la dirección de memoria 0x0800004c ejecuta un salto (opcode e9) hacia 0x8000127, lo cual coincide con el análisis previo realizado con readelf.
0x0800004c e9d6000000 jmp 0x8000127
El opcode e9 en arquitectura x86 indica una instrucción jmp (salto), y el valor d6 especifica la distancia en bytes desde la instrucción actual hasta la dirección de destino.
En este caso, la instrucción jmp ocupa 5 bytes porque está codificada como e9 seguida de un desplazamiento relativo de 32 bits correspondiente a d6 00 00 00.
Por ello, el desplazamiento se aplica desde 0x08000051, la dirección inmediatamente posterior a la instrucción.
Al sumar el desplazamiento d6, equivalente a 214 en decimal, se obtiene la dirección de salto 0x08000127, que es el destino al que el programa redirige su ejecución.
Para evitar dicho salto, se sobrescribirá esta instrucción para que, en lugar de realizar el salto, ejecute un nop (No Operation), lo que significa que no realizará ninguna acción.
Explotación
Para modificar el binario, primero lo reabrimos en modo escritura: oo+.
Luego, se debe seleccionar la dirección de memoria que se desea modificar, en este caso 0x0800004c, utilizando el comando s.
s 0x0800004c
A continuación, se inserta el nop con el comando wao nop y se verifica que los cambios se hayan aplicado correctamente con el comando px4, que muestra los bytes en formato hexadecimal.
El opcode de
nopen hexadecimal es0x90en arquitectura x86.

Por último, se sale de Radare2 con el comando q y se ejecuta el binario de nuevo para obtener la flag.

La flag ha sido obtenida con éxito y ha sido censurada para respetar las reglas de HTB.
Lecciones aprendidas
El uso de herramientas como file y readelf permiten identificar rápidamente la arquitectura y detectar inconsistencias en la cabecera de un binario ELF.
Radare2 facilita la inspección y modificación directa de instrucciones. En este caso, sustituir el salto inicial por un nop permitió cambiar el flujo de ejecución y alcanzar el código que mostraba la flag.
El reto demuestra la importancia de combinar el análisis de la estructura del archivo con la revisión de las instrucciones que se ejecutan desde su punto de entrada.