Back To The Beginning Keygen

Análisis de bytes en posiciones fijas via objdump y ltrace

Autor reto	Mazzotti
Plataforma	crackmes.one
Dificultad	1.0 / 5.0
Arquitectura	x86-64 — Unix/Linux
Modo	Normal Mode — objdump + ltrace
Analista	Jesús Ávila (Avilx)
Fecha	07 de Septiembre 2026
Portafolio	avilx.dev

SERIAL ENCONTRADO REVERSING · KEYGEN · CRACKME · x86-64

Documentación de aprendizaje en reversing | Entorno controlado

Información del Binario

Campo	Valor
Nombre	`crackme_easy`
Tipo	ELF 64-bit LSB pie executable
Arquitectura	x86-64
Enlazado	dynamically linked
Stripped	stripped (sin símbolos)
Stack Canary	Canary Found
NX	Enabled
PIE	PIE Enabled
RELRO	Full RELRO

Nota
El binario está stripped, lo que significa que no hay símbolos ni nombres de funciones. Tiene todas las protecciones activas: Full RELRO, Canary, NX y PIE. A pesar de esto el análisis del disassembly permitió identificar las comparaciones clave.

Reconocimiento

Análisis inicial

Strings

$ strings -a ./crackme_easy | grep -v "^_Z\|GLIBC\|\.so\|\."

[Mensajes del programa]
Not so fast, what is this?
WOW! Congratulations on completing so hard keygen [sarcasm] :3
Bro, what is your skill level?

Hallazgo
No hay password hardcodeado. El título “keygen” y el mensaje sarcástico "[sarcasm]" sugieren que cualquier input que cumpla un formato simple será aceptado. El binario está stripped sin símbolos visibles.

Hipótesis
El programa valida el formato del input en lugar de compararlo con un valor fijo. El siguiente paso es analizar las comparaciones en el disassembly para identificar qué bytes verifica.

Ejecución inicial

$ ./crackme_easy
10
Bro, what is your skill level?

$ ./crackme_easy
hola
Bro, what is your skill level?

Hipótesis
Inputs aleatorios como 10 y hola producen el mismo mensaje. El programa no da pistas sobre el formato esperado.

Análisis del Flujo

Comparaciones en el disassembly

$ objdump -d -M intel ./crackme_easy | grep -A 5 "cmp\|je\|jne\|jg\|jl"

11fe:  cmp rax, 0x9          ; longitud > 9 caracteres?
1202:  jbe 121f              ; si <= 9 -> fallo

1429:  cmp BYTE PTR [rax+0x1], 0x33  ; byte[1] == 0x33?
142d:  jne 143b                       ; si no -> fallo
142f:  cmp BYTE PTR [rax], 0x3a      ; byte[0] == 0x3a?
1432:  jne 143b                       ; si no -> fallo
1434:  cmp BYTE PTR [rax+0x4], 0x4d  ; byte[4] == 0x4d?
1438:  sete dl                        ; dl=1 si todos coinciden

Hallazgo
El disassembly revela tres comparaciones de bytes en posiciones fijas y una validación de longitud mínima. Los valores hexadecimales 0x33, 0x3a y 0x4d son los caracteres esperados en posiciones específicas del input.

Decodificación de valores ASCII

python3 -c "print(chr(0x3a), chr(0x33), chr(0x4d))"
: 3 M

Hallazgo

Los tres valores hex corresponden a los caracteres ‘:’, ‘3’ y ‘M’. El formato del input debe cumplir:

byte[0] = ‘:’ (0x3a)
byte[1] = ‘3’ (0x33)
byte[4] = ‘M’ (0x4d)
Longitud $\geq$ 9 caracteres

Los bytes en posiciones 2, 3, 5, 6, 7 y 8 pueden ser cualquier valor.

Verificación con ltrace

$ ltrace ./crackme_easy 2>&1
# Input: :3abMcdef

WOW! Congratulations on completing so hard keygen [sarcasm] :3

Hallazgo
El input :3abMcdef cumple todas las condiciones y activa el mensaje de éxito. El keygen acepta cualquier string que tenga ‘:’ en posición 0, ‘3’ en posición 1, ‘M’ en posición 4, y longitud mínima de 9 caracteres.

Solución

Formato identificado

Posición	Valor requerido	Libre
0	`':'` (0x3a)	No
1	`'3'` (0x33)	No
2	cualquiera	Sí
3	cualquiera	Sí
4	`'M'` (0x4d)	No
5-8	cualquiera	Sí

Key encontrada

:3abMcdef
KEY ENCONTRADA

$ ./crackme_easy
:3abMcdef
WOW! Congratulations on completing so hard keygen [sarcasm] :3

Hallazgo
El input :3abMcdef fue verificado exitosamente. El programa respondió con el mensaje de éxito.

Reflexión Final

Qué salió bien

El análisis del disassembly con objdump filtrando comparaciones permitió identificar rápidamente los tres bytes verificados y la longitud mínima. La confirmación con ltrace fue inmediata.

Lecciones aprendidas

Este crackme introduce el concepto de validación de formato en lugar de comparación con un valor fijo. El programa no busca un password específico sino que verifica que el input cumpla un patrón parcial de bytes en posiciones determinadas.

La técnica de filtrar el disassembly buscando instrucciones cmp es muy eficiente para binarios stripped donde no hay símbolos. Los valores inmediatos en las comparaciones (0x33, 0x3a, 0x4d) son directamente los códigos ASCII de los caracteres esperados.

El título sarcastico "[sarcasm]" en el mensaje de éxito era una pista de que el keygen sería trivial de romper.

Tiempo total

Fase	Tiempo
Reconocimiento inicial	5 minutos
Análisis del disassembly	10 minutos
Decodificación ASCII	5 minutos
Verificación con ltrace	5 minutos
Total	25 minutos