⏱️ Lectura: 12 min
skitter-creek-bath-salts, mediante lo que su autor llama scrambling de DRAM, reescribe las tablas de traducción de direcciones dentro del controlador de memoria de una CPU AMD, y con ese único cambio deja expuestas regiones de DRAM que ni el propio kernel puede ver. El proyecto, publicado en GitHub por el investigador conocido como xoreaxeaxeax, declara un objetivo directo: desbloquear el Platform Security Processor (PSP), el modo de administración del sistema (SMM), el estado de bajo consumo C6 de la memoria y el microcódigo de la CPU.
📑 En este artículo
La técnica no depende de un bug de software puntual. Ataca la capa donde una dirección deja de ser un número abstracto y se convierte en un voltaje sobre un chip físico de DRAM: el controlador de memoria (MCT/IMC). Si esa capa se puede reprogramar, cualquier región de memoria protegida (un carveout reservado para el PSP o para SMM) deja de estar realmente aislada del resto del sistema.
TL;DR
- skitter-creek-bath-salts, de xoreaxeaxeax, manipula los registros de traducción del controlador DRAM para exponer memoria protegida en CPUs AMD.
- El objetivo declarado del proyecto es desbloquear cuatro subsistemas: PSP, SMM, el estado C6 de DRAM y el microcódigo de la CPU.
- Funciona sobre CPUs AMD Family 16h, la última generación cuyas hojas de datos documentan públicamente los registros de traducción del controlador de memoria.
- AMD dejó de publicar esa documentación desde Family 17h en adelante, lo que complica repetir la técnica tal cual en hardware más reciente.
- El repositorio incluye un módulo de kernel, herramientas de espacio de usuario, ejemplos y un directorio de análisis, bajo licencia abierta.
- El proyecto acumula 1.400 estrellas y 119 forks en GitHub.
- El autor sostiene que el enfoque conceptual se extiende a ARM y RISC-V, aunque el código publicado solo cubre AMD.
Qué pasó
xoreaxeaxeax subió a GitHub el repositorio skitter-creek-bath-salts, un conjunto de herramientas (módulo de kernel más utilidades de espacio de usuario) que reescribe cómo el controlador de memoria de una CPU AMD traduce direcciones físicas hacia celdas reales de DRAM. El README lo resume con una frase que juega con una garantía que los programadores dan por sentada: &x == &x, “usualmente”. Cuando esa igualdad deja de sostenerse porque la dirección física fue reasignada por debajo del sistema operativo, las protecciones que dependen de “esta región de memoria es solo para el PSP” o “esta región es solo para SMM” pierden su base.
El repositorio no entrega un exploit de un solo clic. Es una caja de herramientas de investigación: incluye carpetas kernel/, userspace/, examples/, analysis/ y data/, además de un Makefile y dos documentos, README.md y USAGE.md, que describen el flujo de uso completo.
Contexto e historia
La Family 16h de AMD corresponde a la arquitectura de bajo consumo Jaguar, usada en APUs como Kabini y Temash a partir de 2013. Según el propio repositorio, es la última generación de procesadores AMD cuyas hojas de datos públicas documentan los registros de traducción del controlador DRAM, y además reconocen explícitamente que esos registros no tienen forma de bloquearse. A partir de la Family 17h, con la llegada de Zen, esa información desapareció de la documentación pública.
Ese detalle es la bisagra del proyecto: no es que AMD haya cerrado el mecanismo, es que dejó de describirlo. El propio README lo dice sin rodeos: “el odyssey de *p es similar a través de generaciones y arquitecturas, y las transformaciones subyacentes se extienden incluso a ARM, RISC-V y más allá; skitter-creek-bath-salts nos muestra solo cómo empezar”. Es una admisión de alcance limitado, no una promesa de que la técnica funcione igual en cualquier CPU moderna.
Detalles técnicos y rendimiento del scrambling de DRAM
El README documenta, capa por capa, todo el camino que recorre un simple *p en C antes de tocar una celda de memoria real. Empieza en el núcleo de la CPU: chequeo de forma canónica de la dirección virtual, suma de la base de segmento (FS/GS), consulta a la TLB y, si falla, un recorrido de tablas de páginas (PML4, PDPT, PD, PT) con chequeos de privilegio, NX, SMEP/SMAP y claves de protección en cada nivel. Si la CPU está virtualizada, ese recorrido se repite en EPT o NPT, multiplicando por hasta cinco los accesos a memoria por cada acierto real de traducción.
Recién ahí aparece una dirección física, y todavía falta lo importante para este proyecto: la resolución de tipo de memoria vía MTRR e IA32_PAT, el paso por caché L1/L2/LLC con coherencia MESI/MOESI, y finalmente el controlador de memoria (MCT/IMC). Es en esta última capa donde actúa skitter-creek-bath-salts: reescribe el DRAM hole remap, el mapeo de exclusión de regiones reservadas y, sobre todo, el hash de interleave que reparte una dirección física entre canal, rank y banco mediante operaciones XOR configurables por BIOS. Al final de esa cadena hay todavía un bank swizzle (otro scramble configurable) antes de llegar al chip-select real.
La idea central es simple de enunciar y compleja de ejecutar: si el hash de interleave y el swizzle son configurables, y el firmware nunca los bloquea después del arranque, un programa con privilegios suficientes puede reescribirlos y hacer que direcciones que antes apuntaban a un carveout protegido (por ejemplo, la RAM reservada para el PSP) ahora aparezcan mapeadas en un rango accesible desde el sistema operativo. Nada del hardware “se rompe”: lo que se rompe es la suposición de que esas rutas de traducción son estables e invisibles para el software no privilegiado.
💭 Clave: el scrambling de DRAM no busca una falla de un componente aislado. Busca el punto donde convergen todos: si el controlador de memoria decide en última instancia a qué celda física corresponde una dirección, controlar esa decisión anula cualquier aislamiento que se apoye en ella.
Cómo empezar o probarlo
El repositorio se clona y compila con las herramientas estándar de desarrollo en Linux:
git clone https://github.com/xoreaxeaxeax/skitter-creek-bath-salts.git
cd skitter-creek-bath-salts
makeEl Makefile construye tanto el módulo de kernel como las utilidades de espacio de usuario descritas en USAGE.md. A alto nivel, el flujo documentado es: cargar el módulo del kernel con privilegios de root, usar las utilidades de userspace/ para inspeccionar el mapa de regiones DRAM que ve el controlador de memoria, y desde ahí aplicar la reescritura de traducción sobre el rango que se quiera exponer. Los parámetros exactos por placa base están en examples/ y USAGE.md: cada placa configura el interleave distinto, así que no hay un comando único que sirva para todo el hardware.
Antes de tocar nada, conviene fijar una línea base del propio sistema con herramientas ya presentes en cualquier distro Linux:
# Ver los rangos de tipo de memoria activos (MTRR)
cat /proc/mtrr
# Buscar si el kernel reporta actividad del PSP en el arranque
sudo dmesg | grep -i pspCorrer ese par de comandos antes y después de aplicar una reescritura de interleave es lo mínimo para confirmar que el mapa de memoria realmente cambió, en vez de asumirlo.
⚠️ Ojo: esto es hardware de laboratorio, no una herramienta de producción. Requiere acceso físico o administrativo total a la máquina, un procesador AMD Family 16h concreto y cargar un módulo de kernel sin firmar. No es un ataque remoto ni algo que se ejecute contra un servidor de terceros.
Tampoco existe una ruta equivalente para Windows o macOS: la técnica opera reescribiendo registros específicos del controlador de memoria de AMD desde un módulo de kernel de Linux, algo que no tiene análogo directo en esos sistemas operativos ni en hardware que no sea Family 16h.
Impacto y análisis
La superficie que expone este trabajo importa más allá de un modelo de CPU concreto porque golpea una suposición de diseño extendida: que la seguridad de un componente (PSP, SMM, un enclave, un hipervisor) puede apoyarse en que “esta región de memoria física es invisible para el resto del sistema”. El scrambling de DRAM muestra que esa invisibilidad depende de una capa de traducción configurable que, al menos en Family 16h, nadie bloqueó.
| Subsistema | Qué protege normalmente | Qué expone el scrambling |
|---|---|---|
| PSP | Firmware de seguridad aislado del sistema operativo | Acceso a memoria fuera del carveout reservado |
| SMM | Código privilegiado invisible para el SO y el hipervisor | Lectura o escritura potencial de sus regiones de memoria |
| C6 (DRAM) | Estado de bajo consumo que retiene contenido de memoria | Acceso a datos que deberían quedar fuera del mapa normal |
| Microcódigo | Parches de CPU firmados y cerrados al usuario | Superficie adicional para inspeccionar el comportamiento del núcleo |
La limitación honesta es la misma que reconoce el propio autor: esto se probó y documentó sobre una generación de CPU discontinuada hace más de una década, precisamente porque es la última con datasheets públicos que describen el mecanismo. Nada en el repositorio demuestra que el mismo hash de interleave, sin bloqueo, siga existiendo tal cual en un Ryzen o EPYC actual. Es una hipótesis de investigación razonable, no un hecho verificado para Family 17h en adelante.
Diagrama simplificado del camino que ataca skitter-creek-bath-salts
flowchart TD
A["CPU: direccion virtual"] --> B["MMU: page walk"]
B --> C["Direccion fisica"]
C --> D["Cache y coherencia"]
D --> E["Controlador de memoria (MCT o IMC)"]
E --> F["Hash de interleave: canal, rank, banco"]
F --> G["Bank swizzle / scrambling"]
G --> H["Celda DRAM real"]
subgraph Zona reescrita por el proyecto
F
G
endQué sigue
El propio README es explícito sobre el alcance: “skitter-creek-bath-salts nos muestra solo cómo empezar”. Eso deja dos preguntas abiertas para cualquiera que quiera continuar la investigación. Primero, si los registros de interleave y swizzle en procesadores AMD posteriores a la Family 16h, donde ya no hay datasheet público, siguen siendo reprogramables de la misma forma o si fueron bloqueados a partir de Zen. Segundo, si las transformaciones equivalentes en controladores de memoria ARM y RISC-V, que el autor menciona como extensión conceptual, son replicables con herramientas similares. El repositorio no responde ninguna de las dos: las deja planteadas.
📖 Resumen en Telegram: Ver resumen
Si trabajás con seguridad de firmware o simplemente te interesa ver la traducción de direcciones en acción, cloná el repositorio y corré cat /proc/mtrr en tu propia máquina antes de leer USAGE.md: vas a tener una línea base real contra la cual comparar cada paso del proyecto.
Preguntas frecuentes
¿Qué es el scrambling de DRAM en este contexto?
Es la reescritura deliberada de los registros del controlador de memoria que deciden a qué canal, rank y banco físico corresponde una dirección. Al cambiar ese mapeo, direcciones que antes apuntaban a una región protegida pasan a ser accesibles desde otra parte del sistema.
¿Necesito hardware especial para probarlo?
Sí. El proyecto está documentado y probado sobre CPUs AMD Family 16h (arquitectura Jaguar, APUs como Kabini y Temash), la última generación con datasheets públicos que describen estos registros.
¿Es un ataque remoto?
No. Requiere cargar un módulo de kernel con privilegios de administrador en la máquina objetivo, es decir, acceso físico o administrativo previo, no una vulnerabilidad explotable desde la red.
¿Por qué AMD dejó de documentar estos registros?
El repositorio no lo explica, solo constata que la documentación pública de estos registros desapareció a partir de la Family 17h. Es consistente con una tendencia general de los fabricantes de CPU a reducir la documentación pública de estructuras internas sensibles a la seguridad.
¿Funciona en CPUs Intel o ARM?
El código publicado es específico para el controlador de memoria de AMD. El autor plantea que el concepto se extiende a ARM y RISC-V, pero el repositorio no incluye una implementación para esas arquitecturas.
¿Qué es un “carveout” de memoria?
Es una región de DRAM que el firmware reserva y marca como invisible para el sistema operativo, típicamente para que la use en exclusiva un componente como el PSP o el código de SMM.
Referencias
- Repositorio skitter-creek-bath-salts en GitHub: código fuente, README técnico y documentación de uso del proyecto.
- Wikipedia: AMD Platform Security Processor: contexto general sobre el subsistema PSP que el proyecto busca desbloquear.
- Wikipedia: System Management Mode: explicación del modo de ejecución SMM presente en procesadores x86.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Maxence Pira en Unsplash
0 Comentarios