>_
Terminal
🏴‍☠️
Mini CTF
📊
Activity
📅
Events
guest@dsr: ~
guest@dsr:~$ ./welcome.sh
guest@dsr:~$ cat hardware-hacking-en-reparaciones.md
Última modificación: 18-04-2026

Hardware Hacking dirigido a reparaciones

Author: Andrés Pérez Pérez

Idea principal

La idea central es que cualquier sistema con acceso físico es vulnerable. No es cuestión de si se puede comprometer, sino de cuánto tiempo y dinero cuesta. La charla explica los fundamentos teóricos del fault injection y termina con un taller hands-on donde la gente intenta hacer glitching sobre un microcontrolador real.


Conceptos clave

Tipos de ataques que se cubren:

  • Ataques de reloj: el procesador necesita tiempo entre ciclos para asentar los datos. Si aceleras el reloj artificialmente, algunas instrucciones se ejecutan con datos incorrectos o incompletos. El resultado es que un salto condicional (tipo "si contraseña correcta → entra") puede ejecutarse mal y saltar de todas formas.
  • Power Analysis (SPA/DPA): midiendo el consumo de corriente del chip puedes inferir qué está computando. Un 0 y un 1 consumen distinto. Con suficientes muestras y análisis estadístico (DPA) puedes sacar claves criptográficas sin abrir nada.
  • Voltage glitching: el más accesible de los tres. Cortas la alimentación un instante muy preciso y el micro "alucina". Se aprovecha la capacitancia residual del chip: al quitar tensión, el micro sigue corriendo un pelín más con lo que tenía cargado, pero con datos sucios. Resultado similar al ataque de reloj pero más bruto y más fácil de montar.

D580F737-91AB-4B94-8B12-95B2AC0B659C_1_105_c.jpeg

F4987F88-1907-4216-9639-95413918216C_1_105_c.jpeg

El ejemplo real que usa es la Xbox 360. Microsoft implementó e-fuses en el procesador: fusibles físicos integrados que se van quemando con cada actualización de firmware. Si la consola detecta que hay menos fuses quemados de los esperados, interpreta que alguien intentó hacer downgrade y bloquea el arranque. El glitch se usaba para saltarse exactamente esa comprobación y poder ejecutar firmware antiguo con vulnerabilidades conocidas.


Desarrollo

El punto más interesante de la charla es cómo se caracteriza un sistema antes de atacarlo. No puedes lanzar el pulso a ciegas: primero tienes que encontrar la ventana de tiempo exacta en la que meter el fallo. Para eso fuerzas el fallo en un bucle, vas ajustando el timing hasta que el sistema peta de formas predecibles, y a partir de ahí puedes afinar hasta dar con el momento que te interesa. Básicamente, romper cosas de forma controlada es parte del proceso.

La placa que usan en el taller es una versión propia basada en STM32, con los condensadores de desacoplo eliminados (para que el glitch sea más limpio) y un jumper para el pin de boot. El flujo es: pinchas boot, reseteas, el micro entra en modo bootloader, lanzas el script Python, y a ver si el AES falla donde interesa. La librería que usan se llama sup2b y el script principal es desktop.py con tres parámetros: offset, pre-glitch y longitud del pulso.

AD87C093-38D8-4FA7-B7BA-124B7E624303_1_105_c.jpeg


Términos técnicos

  • E-fuses: fusibles microscópicos integrados en el procesador, se queman de forma irreversible con cada actualización
  • SPA/DPA: Simple/Differential Power Analysis, análisis del consumo para inferir operaciones criptográficas
  • ChipWhisperer: plataforma open source de referencia para fault injection y side-channel attacks
  • Wire bonds: los hilos internos que conectan el die del chip con sus pines externos, muy frágiles

Conclusiones

Me llevo principalmente dos cosas. Primera: el voltage glitching es sorprendentemente accesible, no necesitas equipamiento caro, con una placa de 30€ y un script de Python puedes montar un setup funcional. Segunda: el concepto de caracterización es clave y se suele ignorar, la gente quiere ir directo al ataque pero sin entender la ventana de tiempo del sistema no hay nada que hacer.



<< cd ..

HackSimulator - Mini CTF

Top Hackers

  1. Loading...

OSINT Mini CTF

This is a timed competition. Your goal is to find all 4 flag fragments scattered across the simulated system using OSINT techniques.

Once you start, the timer will begin. Good luck.

Activity Monitor
Process Name ↕ % CPU ↓ % Memory ↕ Action

CPU 0.0%

30s history

Memory 0.0%

30s history
— processes CPU avg: — RAM avg: —
Events

Loading events...

>_
🏴‍☠️
📊
📅