// INFORME: Análisis de Vectores en Sistemas Embebidos & RF
// OBJETIVO: Auditoría de Hardware, Firmware y Espectro
// HARDWARE: RP2040 / ESP32 / SIM800 / nRF905
// CLASIFICACIÓN: Technical Deep Dive
0x01:¿Hardware Hacking? RP2040 vs ESP32
En el análisis de seguridad de microcontroladores, nos enfrentamos a dos filosofías de diseño opuestas.
Mientras que el ESP32 implementa un sistema robusto basado en eFuse y cifrado de flash, el RP2040 ofrece una protección mínima, centrada en dificultar la copia ("no trivial") en lugar de impedirla radicalmente.
Vulnerabilidades del RP2040
La arquitectura del RP2040 presenta vectores de ataque físicos claros que un auditor debe conocer:
- Flash Externa: El código reside fuera del chip. Un atacante puede desoldar la memoria y leerla con un programador estándar.
- Acceso BOOTSEL: Forzando este modo vía USB, se puede volcar la memoria completa con herramientas como
picotool save. - Debugging SWD: Otorga control total sobre el procesador, permitiendo lectura de memoria y depuración en vivo si no se deshabilita físicamente.
La Fortaleza del ESP32
En contraste, el ESP32 utiliza Secure Boot y Flash Encryption. La clave de cifrado se genera por hardware y se almacena en eFuse, siendo inaccesible para el software. El descifrado ocurre "on-the-fly" en la caché de instrucciones sin penalizar el rendimiento, creando un entorno de ejecución confiable (TEE).
| Característica | RP2040 | ESP32 |
|---|---|---|
| Bit de Seguridad | No disponible | Sí (eFuse) |
| Protección Flash | Vulnerable (Extracción Física) | Cifrado de Hardware |
| Autenticidad | Sin verificación HW | Secure Boot |
0x02: Ingeniería Inversa del Protocolo SWD
El flasheo del RP2040 revela la complejidad de ARM CoreSight.
Utilizando la interfaz SWD (Serial Wire Debug) de dos hilos (SWCLK, SWDIO), podemos controlar el DAP (Debug Access Port) independientemente del estado de los núcleos.
Esto es crítico para inyectar código sin reiniciar el sistema principal.
Nota: ¿Donde saco está información? existen miles de fuentes, papers y estudios de ingeniería que recopila muy bien Notebook LM ayudándome a profundizar para entender la arquitectura de estos dispositivos a bajo nivel
DEBUG
Para ejecutar funciones arbitrarias (como borrar la flash), utilizamos un "trampolín".
Detenemos el procesador, cargamos argumentos en los registros r0-r3, la dirección de la función objetivo en r7, y ejecutamos una rutina en ROM que invoca a r7 y luego dispara un BKPT para devolvernos el control.
0x03: RF Warfare: Detección de Jamming con IA
En el espectro de radiofrecuencia, los ataques de denegación de servicio (Jamming) son una amenaza persistente.
Existen variantes como el Jammer Constante (ruido blanco continuo) o el Jammer Reactivo (se activa solo al detectar preámbulos legítimos).
Analizando el espectro con mi hack RF mientras lanzas ataques de jammer con un M5 stick + cc1101 + nrf24 o un flipper zero con un módulo externo insertado en las GPIO se aprecia esto sin necesidad de IA y como cambian en la waterfall las ondas usando un constante o un reactivo.
Simplemente uno es constante ruido manchando y otro tiene pausas esperando esos preámbulos (básicamente fluctuaciones de ataque a tiempos o intervalos definidos que provocan por ejemplo en un altavoz con música cortes que no llegan a anular la música)
Para la detección, el análisis de métricas como el PDR (Packet Delivery Ratio) y el RSS (Received Signal Strength) es fundamental. Mis pruebas confirman que los modelos de Machine Learning superan a los umbrales estáticos.
Para un algoritmo adecuado y entrenado en una interfaz preparada para ello (vale un ESP32) el ML hace el resto como filtro (de hecho la mayoría de filtros son algoritmos ya muy usados en ML)
// RESULTADOS DE CLASIFICACIÓN (Algoritmos ML)
[+] MLP (Perceptrón): 67.5%
[+] Decision Tree: 88.7%
[+] Random Forest: 92.6%
[+] Gradient Boosting (GBT): 94.2% [WINNER]
0x04: Módulos Celulares y Comandos AT
Los módulos IoT como el SIM800L y SIM900 (los tengo) permiten control remoto vía red GSM el antiguo 2G para aquellos menos técnicos.
Sin embargo, presentan desafíos de hardware significativos: requieren picos de corriente de hasta 2 Amperios durante la transmisión de ráfagas (bursts), haciendo inviable la alimentación directa desde pines estándar de 3.3V/5V de un microcontrolador.
Nota: según mi estudio solo teórico, estoy es así pero en la práctica veremos qué no es barrera para hacer lo que tengo pensado por 20 euros sin equipos caros y complicados
Yo siempre tengo en la cabeza y me pregunto ¿Qué control de las ondas en un perímetro empresarial se tiene?
Estos comandos los he podido probar con el dongle 4G que menciono en anteriores post pero con los SIM 900 y 800 pues es más genuino ya que te remites a un hardware en crudo.
// Secuencia de Inyección de Comandos (AT)
TX -> AT+CMGF=1 // Set Text Mode
TX -> AT+CMGS="+34600XXXXXX"
TX -> "Payload: System Compromised" + 0x1A (EOF)
// Reconocimiento de Red (Cell ID / LAC)
TX -> AT+CNETSCAN
RX <- code="" ellid:a1b2="" operator:="" ovistar="" style="color: #f1fa8c;" xlev:35="">
0x05: Nordic nRF905
Para comunicaciones en bandas ISM (433/868/915 MHz), el transceptor nRF905 destaca por su eficiencia energética (2.5 µA en Power Down).
Su tecnología ShockBurst es la joya de la corona: automatiza el preámbulo, la dirección y la validación CRC.
Esto libera al microcontrolador principal de tareas de bajo nivel, permitiendo implementaciones de "Listen Before Transmit" (LBT) muy eficientes para evitar colisiones en entornos saturados.
Ya veréis lo que puede hacer este pequeño animal...
"Security is not a product, it's a mindset."
[ EOF ]