Fuzzing de banda base: buscar fallos en el módem de un teléfono sin tocar el aire

Primera entrega de Radiografía del clúster, la serie que desgrana línea a línea qué corre de verdad en el clúster del grupo ANTS . Empezamos por la que más trabajos envía y ninguna GPU usa: seguridad de bandas base celulares.

La pregunta #

El procesador de banda base es el ordenador dentro del teléfono que habla con la red móvil. Ejecuta un firmware propio, cerrado, y parsea mensajes que llegan por radio antes de que el sistema operativo vea nada. Históricamente es una fuente rica de fallos disparables en remoto, y a la vez uno de los componentes más difíciles de analizar: no hay código fuente, apenas hay depuradores y el hardware es opaco.

La línea pregunta algo concreto: ¿qué fallos esconden los manejadores de protocolo de un módem comercial, y cuáles de ellos son explotables?

Cómo se aborda #

El objetivo es la imagen de un módem Shannon de Samsung. Se emula con FirmWire , un emulador de sistema completo para bandas base, y sobre él corre AFL apuntando a las tareas de la capa 3 de GSM/GPRS: control de llamada (CC), servicios suplementarios (SS), SMS, gestión de movilidad (MM/GMM), gestión de sesión (SM) y SNDCP. Cada tarea del módem es una campaña de fuzzing distinta, con sus propias semillas.

El proceso tiene cuatro etapas:

1. Campañas de fuzzing con hasta 150 instancias de AFL en paralelo, en tandas de unas ocho horas que continúan desde las semillas guardadas.
2. Deduplicación y triaje. Los crashes se deduplican por el SHA-256 de su contenido antes de emular nada, y solo los únicos pasan a un re-triaje best-of-5 que separa los reproducibles de los espurios. Los cuelgues tienen su propio triaje, porque un input puede meter al módem emulado en un bucle infinito.
3. Cobertura y trazas de cada crash único, con la pila de llamadas y el contador de programa en el momento del fallo.
4. Análisis de causa raíz. Para los candidatos serios se confirma dinámicamente, dentro del emulador, si existen primitivas de explotación: escrituras controladas del contador de programa, cadenas de llamadas encadenadas, retornos “cómodos”. Como el arranque del firmware no es determinista, cada confirmación se repite en varios arranques.

Un servidor MCP (Model Context Protocol) hace de puente entre un asistente y el clúster: cuando el fuzzer encuentra un candidato, la herramienta encola una verificación de veinte minutos que repite el caso tres veces y devuelve solo las líneas de fallo, o una ejecución con toda la salida para ingeniería inversa dinámica.

Qué se aprende #

Los comentarios de los scripts marcan bien el alcance. Todo ocurre en emulación: «EMULADOR, PAL ≠ OTA». Confirmar que un mensaje rompe el firmware emulado no equivale a demostrarlo por el aire, y la línea lo distingue con cuidado. Lo que sí produce es un inventario de fallos únicos por tarea de protocolo, con su reproducibilidad y su cobertura, y para algunos de ellos la prueba de que el fallo controla la ejecución.

También enseña algo sobre el propio fuzzing de firmware: los cuelgues son tan importantes como los crashes (de ahí un triaje específico con timeout de cinco minutos por réplica), y la deduplicación por contenido antes de emular es lo que hace viable revisar miles de candidatos.

En el clúster #

Es una carga infinitamente paralela, de un núcleo y poco más de un gigabyte por instancia, que corre con prioridad rebajada en los núcleos que los trabajos de GPU dejan libres. Los miles de verificaciones cortas son las réplicas del servidor MCP; las tandas largas son las campañas de AFL.

En la siguiente entrega , la línea que intenta hacer más seguro un modelo de lenguaje.

Cifras de la contabilidad de Slurm (capacidad reservada, no uso medido) y de los sbatch archivados. Entrada anonimizada: sin usuarios, rutas, correos ni nombres de proyecto identificables. Las citas son de los comentarios de los scripts.