PinBreaker: diseñando un laboratorio de reversing básico sobre un PIN hardcodeado
Un laboratorio de reversing corto y directo, una app Android que valida un PIN en el cliente y deja el secreto a la vista de quien abra el APK.
Principiante · Android
URL del reto: labs.thehackerslabs.com/machines/68
Por qué la diseñé
PinBreaker es un laboratorio corto y directo para meter una idea concreta, cómo un mecanismo de validación que parece simple queda expuesto cuando la lógica sensible se deja en el cliente. La monté para cambiar de terreno, aquí no hay intrusión remota ni escalada, el objetivo es un APK y el trabajo es análisis estático.
Quería romper la costumbre de levantar máquina, escanear y enumerar, y llevar el foco al binario que se distribuye al usuario. Muchos fallos viven en cómo se empaqueta y se reparte la lógica de una aplicación, no en un servicio expuesto a red.
La máquina de un vistazo
Esto es un paquete con un APK y unas instrucciones, no una máquina de red. La cadena es mínima, se descompila la app, se localiza la validación del PIN dentro del código, se saca el PIN embebido y con él se deriva la flag por SHA256.
Cómo la monté, paso a paso
El objetivo es un APK, no un servicio
En lugar de una máquina accesible por red entregué un paquete pequeño con el APK y un PDF de uso. Ese cambio es a propósito, quería que el reconocimiento fuera identificar el tipo de objetivo y elegir el enfoque, el análisis de la propia aplicación, y no escanear puertos. No todos los fallos explotables piden interacción dinámica, a veces basta con inspeccionar con calma el artefacto correcto.
La validación escondida en el propio código
Toda la lógica que importa está en la actividad principal de la app. Con jadx se abre el código descompilado y se llega a una función que compara el PIN introducido con un valor fijo guardado dentro. No hace falta instrumentación, hooking ni emulador, basta con seguir el flujo y encontrar dónde se decide aceptar o rechazar. Ese es el error que quería representar, poner la lógica sensible en el cliente y asumir que, por estar compilada, ya queda protegida.
El PIN que deja de ser secreto
En cuanto el PIN está embebido en la app, deja de ser un secreto. Quien tiene el APK tiene la lógica que gobierna la autenticación local, así que el control deja de ser una barrera y pasa a ser una pista. El último paso solo formaliza la entrega, derivar la flag con el SHA256 del PIN. Aquí no hay explotación espectacular porque no hacía falta, la debilidad ya estaba en el modelo de confianza.
Qué quería enseñar
PinBreaker es una introducción a los fallos de diseño en apps móviles donde la validación se resuelve entera en el cliente. Enseña a reconocer una mala decisión que vuelve trivial el bypass, más que a montar una cadena compleja.
| Fase | Qué enseña | Error que representa |
|---|---|---|
| Entrega del APK | El artefacto distribuido también es superficie | Confiar en que el cliente oculta la lógica |
| Análisis con jadx | El reversing básico basta para auditar el flujo | Sin protección sobre la lógica de validación |
| Validación en MainActivity | La autenticación local se desmonta leyendo | PIN o secreto hardcodeado |
| Extracción del PIN | Un secreto embebido deja de serlo | Credenciales o claves en el cliente |
| SHA256 | El valor recuperado completa el flujo | Depender de un secreto ya recuperable |
La idea que se lleva uno fuera del laboratorio es clara, una aplicación no debe guardar secretos ni decidir seguridad en el lado cliente. Ofuscar, empaquetar o compilar no arreglan ese problema de fondo.