A propósito de por qué el café del hotel pesa tanto como la nube de Washington
Hace unos días escribí en este mismo blog sobre Mythos, el modelo de Anthropic que volvía a desnudar la fragilidad estratégica europea: dependencia de la nube estadounidense, un interruptor de emergencia en manos ajenas y una Comisión que prefiere aplazar su propia regulación antes que arremeter contra los gigantes. Aquel post terminaba con una idea incómoda: la soberanía digital europea es, hoy por hoy, una ficción operativa.
Pues bien, lo de la nube y los modelos era sólo la mitad del problema. La otra mitad se esconde tras un gesto tan banal que precisamente por eso resulta demoledor: pagar un café.
El datáfono como infraestructura geopolítica
Acercas el móvil, suena el datáfono, sigues andando. El comercio cobra en euros, el impuesto se liquida en euros. Y, sin embargo, aquí está la trampa, una parte decisiva del trayecto no es europea.
Cerca de dos tercios de los pagos con tarjeta de la zona euro se procesan por esquemas no europeos. Trece países dependen por completo de ellos. La cifra, advierte el autor, no es técnica; es geopolítica.
Y entonces aparece, otra vez, la palabra. El sustantivo que El Quijote Digital lleva semanas persiguiendo: interruptor. Una infraestructura de pagos no es sólo una tubería; también es un interruptor que alguien puede condicionar, encarecer, retrasar o apagar. ¿Qué pasaría si nos sacan de VISA?
¿Os suena? Es exactamente la misma figura que el Future of Technology Institute utilizó hace unos meses para describir la dependencia europea de la nube estadounidense en defensa. Mismo verbo, mismo dueño, mismo continente atrapado.
Dos interruptores, un mismo problema
Conviene poner los dos casos uno al lado del otro, porque revelan un patrón que ya no admite la coartada del azar:
Caso Mythos / nube
Caso datáfono / pagos
Quién controla
Hiperescalares de EE.UU.
Visa y Mastercard
Qué controla
IA, defensa, infraestructura crítica
Pago cotidiano, comercios, liquidación
Punto de presión
Acceso al modelo, condiciones de uso
Acceso al esquema, tarifas, reglas
Reflejo europeo
«Hay que regularlo»
«Construyamos un euro digital»
Diagnóstico correcto
Construir capacidad europea
Construir red privada europea
Plazo realista
Sin fecha
2026–2027 (EPI / Wero)
Lo que aparece, leído así, no son dos crisis distintas: es la misma renuncia industrial repetida en dos capas tecnológicas distintas. Y en ambas la respuesta política instintiva ha sido idéntica: legislar lo que otros producen antes que producir algo propio.
Por qué el euro digital no es la respuesta
Frente a la dependencia de Visa y Mastercard, el reflejo de Bruselas ha sido apostar por el euro digital: una moneda pública, programable, emitida por el BCE. Suena bien, suena soberano, suena tecnológico. Pero cuando se diagnostica mal el problema, se receta mal la medicina.
El problema no es que falte una moneda. Es que falta una red privada de aceptación comercial capaz de competir con las americanas en lo que de verdad importa al comerciante y al usuario: aceptación, escala, experiencia de uso, antifraude, liquidación, marca.
«Europa no carece de moneda. Carece de raíles.»
El euro digital, además, llegaría tarde, el BCE habla de una posible emisión en 2029— y mal calibrado: con límites bajos servirá poco, con límites altos tensionará los depósitos bancarios, sin privacidad creíble nadie lo usará. En el mejor escenario es una herramienta complementaria. En el peor, una excusa elegante para no construir lo que sí hace falta.
Lo que sí podría funcionar: un Bizum europeo, sin metáforas
La alternativa real, tal como se explica en el artículo publicado con notable claridad por Omar Rachedi en «La soberanía pasa por el datáfono» (El País, 20 de mayo de 2026), es menos solemne, menos vistosa y, por eso mismo, mucho más prometedora. Existe ya un memorando entre Bizum, Wero, Bancomat, MB Way y Vipps MobilePay para crear una red interoperable capaz de funcionar de Lisboa a Helsinki sin que el usuario tenga que aprender nada nuevo. Pagos transfronterizos entre particulares en 2026, entre comercios en 2027.
¿Por qué esto sí puede salir adelante mientras otras ambiciones europeas se atascan? Porque, como bien apunta Rachedi, tiene una ventaja que Bruselas rara vez compra: el hábito. No exige convertir al ciudadano a una nueva fe monetaria ni convencerlo de un experimento institucional. Se apoya en bancos, aplicaciones y comportamientos que ya existen. El ciudadano español ya usa Bizum. El portugués ya usa MB Way. El alemán ya usa Wero. Sólo falta («sólo») que hablen entre sí.
Y aquí está el verdadero diagnóstico: Europa no fracasa por falta de ideas. Fracasa cuando veintisiete buenas ideas nacionales no se hablan entre sí. Lo cual es, dicho sea de paso, exactamente lo que le ocurre también en computación en la nube, en inteligencia artificial, en defensa, en semiconductores y en cualquier otro rincón del expediente tecnológico continental.
Euro digital como capa pública
Europa depende estructuralmente de redes de pago ajenas.
El dato del BCE (los esquemas internacionales de tarjetas representaban el 61% de los pagos con tarjeta en la zona euro en 2022), la inviabilidad de actuar país por país, y la oportunidad que abre el memorando firmado en febrero de 2026 entre Bizum, Wero, Bancomat, MB Way y Vipps MobilePay para acelerar pagos paneuropeos interoperables.
Cuestión a considerar: el papel del euro digital. ¿Es un placebo institucional que distrae del verdadero problema (faltan raíles, no moneda)?. O, el euro digital no es ni sustituto de Bizum ni solución milagrosa: es respaldo público en una economía donde el efectivo pierde peso. El argumento es sencillo y elegante: si el dinero público ha existido durante siglos en forma de billetes y monedas, ahora tiene que existir también digitalmente. No para desplazar lo privado, sino para impedir que el futuro de los pagos europeos dependa exclusivamente de redes privadas y externas.
Europa ya ha aprendido con la energía, los semiconductores o la defensa que las dependencias estratégicas:
«…suelen descubrirse tarde, cuando ya se han convertido en vulnerabilidades.»
A esa lista, hoy, hay que añadir la inteligencia artificial: véase Mythos. Y los pagos: véase el datáfono. Es exactamente el mismo patrón, repetido en distinto sector. Y siempre con el mismo retraso diagnóstico.
Entonces, ¿placebo o respaldo? Probablemente, los dos.
Por un lado no se pueden confundir prioridades: si el problema diario es que Visa y Mastercard procesan dos tercios de las transacciones europeas, lo urgente es construir red privada de aceptación, no acuñar moneda digital. Quien crea que el euro digital es la respuesta al problema de los pagos cotidianos en 2026, ha leído mal el problema. El euro digital, planificado para 2029 con un calibrado todavía incierto, no va a defendernos en el datáfono de mañana.
Por otro lado, se debe recordar que una vez resuelto el plano privado, el plano público sigue ahí. Si toda la infraestructura de pagos europea quedara únicamente en manos de un consorcio bancario privado, por muy europeo que sea, seguiríamos sin esa capa pública de seguridad que históricamente ha dado a los Estados el control último sobre su sistema monetario. Una capa, conviene recordar, que en formato físico llamamos billete del BCE y que nadie discute.
Dicho de otro modo, y a riesgo de simplificar: los raíles los pone el Bizum europeo; el aval último lo pone el euro digital. Lo urgente es lo primero. Lo estructural es lo segundo. Confundir el orden (que es lo que hoy hace Bruselas) equivale a fabricar una bóveda blindada para un edificio que aún no se ha levantado.
No olvidemos que…
«Pagar siempre ha sido una cuestión de poder.»
Lo fue cuando los Estados acuñaban moneda. Lo fue cuando se construyeron los grandes sistemas bancarios. Y lo es ahora, cuando los pagos se procesan mediante redes digitales globales. Europa, en su tránsito al euro, pareció olvidarlo. Ahora le toca recordarlo a base de sustos.
El interruptor también es ético
Permitidme cerrar atando el cabo con el post anterior. Cuando hablábamos de Mythos, señalábamos lo más alarmante: que Anthropic había declarado, con notable franqueza, que su ética se aplica únicamente a Estados Unidos. Pues bien, la lógica del datáfono es la misma, sólo que más discreta. Las reglas, las comisiones, los criterios de exclusión, las políticas antifraude, los términos y condiciones de Visa y Mastercard responden también a una jurisdicción que no es la nuestra. Y, llegado el caso, también pueden activarse, modificarse o suspenderse desde fuera.
La pregunta no es si eso ha ocurrido alguna vez, ha ocurrido, y no pocas. La pregunta es si Europa puede permitirse seguir construyendo su economía cotidiana sobre infraestructura que, cuando importa de verdad, no controla. La respuesta, como ya apunté a propósito de Mythos, debería sonrojarnos.
Coda quijotesca
Decíamos hace unos días que Bruselas, al revés que el hidalgo, confunde a los gigantes con molinos y prefiere no arremeter. El datáfono añade un matiz aún más amargo: hay días en que ni siquiera ve los molinos. Los toca con el móvil, oye un pitido, sigue andando. Y se dice a sí misma que aquello era sólo un café.
Pero no era un café. Era, os podéis imaginar, un interruptor.
Y el interruptor, como tantas veces en esta historia, no es nuestro.
Referencia
Rachedi, Omar. «La soberanía pasa por el datáfono». El País, 1ª edición, 20 de mayo de 2026, p. 12. Omar Rachedi es profesor de Economía de Esade.
Sobre CrashDetectorwithAI, los handlers en SMM que se exceden, y por qué decodificar un fault bucket no es lo mismo que entender un crash.
1. El abismo entre «se ha reiniciado» y saber por qué.
Cualquiera que haya pasado más de diez minutos administrando sistemas Windows conoce el ritual. Pantalla azul, código de error en hexadecimal, QR que nadie escanea, reinicio, y un Visor de Eventos que escupe un BugCheckCode y un FaultBucketId con la misma vocación divulgativa que una inscripción en arameo. El usuario medio (y muchos profesionales) hace entonces lo previsible: copia el código, lo lanza a Google, lee tres hilos de Reddit de 2019, actualiza un driver al azar y, si la cosa no vuelve a romperse en una semana, declara cerrado el incidente.
El problema, claro, no es el ritual. El problema es que ese ritual confunde correlación supersticiosa con diagnóstico. Y en Windows, donde el crash que ves rara vez es el crash que ocurrió, esa diferencia importa.Especialmente porque puede revelar intentos de persistencia, intrusiones, o áreas de exposición de tu infraestructura (como el caso que veremos en este post, que versa sobre una utilidad de fabricante haciendo outb 0xB2 periódico lo que provoca la activación de un handler SMI con busy-wait sin timeout sobre el Embedded Controller esto genera una ventana SMM > umbral DPC watchdog y salta el DPC_WATCHDOG_VIOLATION) ver Fig. 1.
Fig. 1 — Anatomía del crash: el camino que va desde un outb 0xB2 inocente en espacio de usuario hasta la pantalla azul, pasando por dos modos de ejecución que Windows no puede instrumentar: una invocación SMI desde el modo de usuario (outb 0xB2) provoca, en sistemas con SGX activo, un Asynchronous Enclave Exit; el rendezvous SMM bloquea todos los núcleos mientras se ejecuta el handler; cuando el tiempo de espera supera el umbral, el kernel dispara DPC_WATCHDOG_VIOLATION.
El motivo de este post es probar una herramienta llamada CrashDetectorwithAI, de Claton Hendricks. Publicada bajo GPL-3.0 en GitHub (clatonhendricks/CrashDetectorwithAI), está construida con WPF sobre .NET 9 y ejecuta inferencia local de Phi-4 vía ONNX Runtime (con soporte alternativo a Ollama para quien prefiera Llama 3, Mistral, DeepSeek o Gemma). En cristiano: detecta eventos de crash, lee la información del fault bucket del Windows Error Reporting (WER) y se la entrega a un modelo pequeño que corre en tu máquina para devolverte una explicación legible y propuestas de solución, todo sin sacar un solo byte hacia la nube.
A primera vista parece un gadget de soporte técnico para cualquier usuario convencional. Y, en parte, lo es. Pero quien lleva tiempo en esto reconoce un segundo uso, mucho más interesante: es una herramienta didáctica para asomarse al subsistema de errores de Windows sin haberse leído antes los tres tomos de Russinovich. La gracia no está en que «te arregle el PC». La gracia está en que cada Blue Screen of Death (BSOD) se convierte en una oportunidad de aprender Windows por dentro.
Para ilustrarlo, os voy a desarrollar un caso realista (y, por motivos profesionales, que me ha ocurrido): un crash que Windows imputa formalmente a un driver inocente, cuando el verdadero culpable está varios anillos de privilegio más abajo, ejecutando en System Management Mode un handler que nunca debió ser tan generoso con el tiempo de espera (timeout).
Un System Management Interrupt (SMI) es la única interrupción que ningún sistema operativo puede enmascarar. La CPU abandona lo que esté haciendo, conmuta a System Management Mode, ejecuta un handler alojado en SMRAM y devuelve el control. Ese handler vive en firmware, no en el kernel de Windows.
En la mayoría de plataformas Intel, el SMI es un rendezvous síncrono entre todos los núcleos lógicos: cuando uno entra en SMM, los demás esperan. Si el handler tarda 200 ms, todo el sistema ha estado parado 200 ms. Windows no ha visto ese tiempo: para él, simplemente, no ocurrió.
WER, en cambio, sí ve las consecuencias: DPCs que no se entregan a tiempo, timers que no se sirven, watchdogs que se disparan. Y como WER no instrumenta SMM (no podría aunque quisiera), atribuye el accidente a la última víctima visible, normalmente un driver que llevaba encolada una DPC inocente.
Esta asimetría es la madre de un género entero de incidentes mal diagnosticados. El operador ve un DRIVER_VERIFIER_DETECTED_VIOLATION o un DPC_WATCHDOG_VIOLATION y, fiel al manual, jura y perjura contra el driver.
El driver, mientras tanto, mira de reojo a un handler de gestión térmica1 que se ha permitido un polling de 12 ms al Embedded Controller, multiplicado por los doce SMIs que dispara cada segundo una utilidad de fabricante que nadie pidió pero todos instalan.
3. La estación de trabajo que «falla aleatoriamente»
El escenario es banal. Windows 11, dos pantallas, treinta pestañas, un IDE, y la suite de monitorización térmica/RGB del fabricante de la placa base instalada de fábrica. Efectos:
BSOD intermitentes, una o dos veces por semana.
Bug check siempre el mismo: 0x133 (DPC_WATCHDOG_VIOLATION).
Sin patrón aparente. A veces compilando, a veces viendo Netflix, a veces con la máquina prácticamente ociosa.
El primer reflejo (el malo) es revisar drivers gráficos, de red y de almacenamiento. El segundo (también malo) es pasar el verifier.exe en modo paranoico, lo que dispara más BSODs sin acercar la respuesta. El tercero (el útil) es preguntarse qué dice exactamente WER.
Verifier.exe (Administrador del Verificador de controladores) es una herramienta nativa de Windows diseñada para probar y depurar controladores de dispositivos (drivers). Su función principal es estresar los controladores del sistema en tiempo real para detectar fallos, corrupción de memoria o incompatibilidades antes de que provoquen bloqueos graves.
¿Para qué se utiliza?
Diagnóstico de Pantallazos Azules (BSOD): Si tu sistema se bloquea frecuentemente, esta herramienta ayuda a identificar exactamente qué controlador está causando el error (y como vamos a ver, no siempre ese es el motivo).
Validación de controladores: Comprueba si los drivers están firmados digitalmente o si fueron creados para versiones anteriores de Windows.
Herramienta para desarrolladores: Ofrece opciones avanzadas para estresar la memoria I/O y registrar llamadas de sistema problemáticas.
Precauciones importantes
Dado que fuerza a los controladores a operar bajo condiciones extremas, puede causar pantallazos azules (BSOD) intencionales si detecta un fallo. Se recomienda utilizarlo únicamente en fases de depuración o cuando tu ordenador de uso diario esté experimentando fallos recurrentes y necesites encontrar al culpable.
Abrimos CrashDetectorwithAI tras el siguiente crash. La aplicación, sin que tengamos que tocar wer.dll ni rebuscar en C:\ProgramData\Microsoft\Windows\WER\ReportArchive\, presenta de forma estructurada algo equivalente a esto:
Crash event detected
─────────────────────────────────────────────
EventID: 1001 (BugCheck)
BugCheckCode: 0x00000133
Parameters: 0x0000000000000000
0x0000000000000501
0x0000000000000500
0xFFFFF80712345678
FaultBucketId: 0x133_0_nt!KeAccumulateTicks
ReportSignature: BlueScreen / 133 / nt / 10.0.26100.xxxx
WHEA records: none in last 5s
Minidump: C:\Windows\Minidump\051826-...dmp
Y, debajo, la respuesta del modelo local (Phi-4 vía ONNX) en streaming, que viene a decir, con palabras propias y prudentes, algo como (traducido y simplificado para cualquier lector):
Se trata de un DPC_WATCHDOG_VIOLATION. El parámetro 1 con valor 0 indica que se ha superado el umbral acumulado de DPC en un solo procesador. Los valores 0x501 y 0x500 son los *ticks* observado y permitido, expresados en unidades del kernel. La dirección final apunta a nt!KeAccumulateTicks, lo cual es habitual: el watchdog se dispara desde la contabilidad de tiempo del kernel, no desde la DPC culpable. Causas frecuentes: driver con DPC excesivamente larga, problema de firmware/BIOS que bloquea la CPU, o controlador de almacenamiento (storport/NVMe) bajo estrés. Recomendaciones iniciales: actualizar BIOS, drivers de chipset y de almacenamiento; revisar utilidades de fabricante que interactúen con el firmware; ejecutar LatencyMon en estado normal de uso.
Hagamos un alto aquí, porquq esta IA me está diciendo cosas raras, raras.
4. Qué hace bien la IA local, y dónde se cohíbe por diseño
La respuesta anterior es útil y razonablemente correcta. Y, lo que me parece más relevante, está calibrada: no afirma que un driver concreto sea el culpable, no inventa números, y menciona la posibilidad de un problema de firmware. Para un usuario que de otro modo habría reinstalado el driver de la NVIDIA por tercera vez, es un salto cualitativo.
Pero conviene mirar también lo que la IA no puede saber, y que cualquier ingeniero con experiencia sabe inferir:
El fault bucket es un agregador, no una causa. 133_0_nt!KeAccumulateTicks significa literalmente «aquí saltó el contador», no «aquí estaba el bug». Quien escribió el agrupador de WER lo hizo para que Microsoft pueda agrupar millones de telemetrías por similitud, no para que tú identifiques al responsable.
WER no instrumenta SMM. No hay forma, desde el espacio kernel, de que nt!KeAccumulateTicks te diga «he perdido 400 ms porque el procesador estaba en Ring −2 ejecutando código de firmware». El kernel ve el reloj saltar, no quién lo robó.
Phi-4 (o cualquier modelo de propósito general de pocos miles de millones de parámetros) no ha leído tu DSDT, tu SSDT, ni el datasheet del chipset de tu placa. Sabe en abstracto que SMIs largos pueden disparar 0x133. No sabe si los tuyos lo están haciendo.
DSDT y SSDT son tablas ACPI fundamentales en el firmware de tu placa base que comunican al sistema operativo cómo funcionan componentes como la CPU, los puertos USB y la energía.
Diferencias Clave
DSDT (Differentiated System Description Table): Es la tabla principal que describe la configuración base y todos los dispositivos principales del hardware de tu equipo. Solo existe una por sistema.
SSDT (Secondary System Description Table): Son tablas secundarias y modulares que describen componentes específicos (como la gestión de energía de la CPU o tarjetas gráficas). Un sistema puede tener múltiples SSDTs.
La buena noticia es que estos tres techos son metodológicos, no propios de la herramienta. La herramienta hace lo que sabe hacer, y lo hace bien: traducir, contextualizar y orientar. Lo que sigue es trabajo humano y, sobre todo, instrumentación. Para que veáis que todavía la IA no os va a sustituir :).
5. Bajar al cuarto de máquinas: medir SMI desde el SO
Si sospechamos que el handler SMI es el problema, hay que demostrarlo. Windows expone, indirectamente, la información suficiente.
5.1. Contador de SMI por núcleo (MSR 0x34)
En procesadores Intel, el MSR 0x34 (MSR_SMI_COUNT) es un contador monotónico de SMIs servidos por ese núcleo lógico desde el último reset. Con RWEverything, ChipSec o un driver de lectura de MSRs, se obtiene una lectura trivial:
chipsec_util msr 0x34
En una máquina sana en idle, ese contador debería incrementarse del orden de unas pocas unidades por minuto, o menos. Si en una máquina con la utilidad del fabricante activa observamos algo como:
…es decir, en torno a 12 SMIs por segundo en reposo, ya tenemos un primer indicador objetivo. No prueba la causa, pero sí que algo en la plataforma está disparando SMIs con una frecuencia que ningún diseño térmico razonable justifica.
5.2. Latencia de SMI con LatencyMon o WPA
LatencyMon (Resplendence) ofrece el indicador clínico más legible: highest measured interrupt to process latency. En el caso que nos ocupa, valores > 1500 µs en hard pagefault path y > 4000 µs puntuales son banderas rojas. El propio LatencyMon, en sistemas afectados, suele mostrar el mensaje canónico: «Your system appears to be having difficulty handling real-time audio and other tasks. […] One or more DPC routines that belong to a driver running in your system appear to be executing for too long […]». Mensaje engañoso, porque el driver que aparece en la columna acumulada de DPC suele ser inocente: en realidad ha sido desplazado en el tiempo por la ventana SMM, y el contador lo acusa a él.
Más rigurosa es la traza con Windows Performance Recorder y el perfil de CPU usage + Power, abierta en Windows Performance Analyzer. La columna SMI del System Activity aparece, en una máquina afectada, como un peine regular de picos coincidiendo con cada disparo del handler.
5.3. Cruzar con WHEA
Aunque WER lo silencia, el subsistema WHEA (Microsoft-Windows-WHEA-Logger) a veces deja rastro: PCIe Correctable Errors sin sentido aparente, thermal throttling notifications periódicas, o eventos BIOS error record (Event ID 47). Cuando aparecen sincronizados con los picos de SMI, la hipótesis se refuerza.
6. El culpable: un handler térmico, generoso, que gasta tiempo como si la máquina fuera suya, disparado por una utilidad de RGB
En el caso real que motiva este artículo, el responsable resultó ser una combinación sorprendente:
El servicio en segundo plano de la suite del fabricante cuya marca omito porque no quiero crear polémica (control de iluminación, perfiles térmicos, overclock asistido) escribe periódicamente en el puerto 0xB2 (APMC, Advanced Power Management Control), el método canónico para invocar un software SMI y solicitar al firmware una lectura de sensores.
El handler SMI correspondiente en el firmware UEFI realiza esa lectura secuencialmente sobre el Embedded Controller vía protocolo ACPI EC, esperando handshakes del EC con un busy-wait sin timeout agresivo.
Cada invocación gasta entre 150 y 400 µs en condiciones normales, pero ante una mínima contención del EC (por ejemplo, durante una transición de estado de la batería en portátiles, o coincidiendo con eventos de teclado en estaciones con KVMs USB) salta a 8–12 ms.
Multiplicado por una cadencia de 10–15 SMIs/s, el sistema acumula ventanas SMM que, en el peor caso, superan el umbral del DPC watchdog y disparan el 0x133.
Lo elegante de este patrón es que WER no puede ver nada de lo anterior. Lo único que ve es que nt!KeAccumulateTicks se sorprendió de cuánto tiempo había pasado. Y el informe agrupado, así lo dice.
La resolución, una vez identificado el patrón, es banal:
Actualización de BIOS a la versión donde el OEM corrige el busy-wait del handler de lectura de sensores (en este caso, una nota de release de tres líneas que sólo menciona «improved system stability under sustained sensor polling»).
Desinstalación o, como mínimo, desactivación del servicio en segundo plano de la suite del fabricante; la lectura de sensores que necesite el usuario puede obtenerse con HWiNFO en lectura pasiva sin disparar SMIs adicionales.
Verificación posterior: MSR 0x34 baja a <1 SMI/s en idle, LatencyMon vuelve a verde, y los 0x133 desaparecen del Visor de Eventos.
7. Volver a la herramienta: qué se aprende por el camino
Si has llegado hasta aquí siguiendo el post, te habrás dado cuenta de algo: CrashDetectorwithAI no diagnosticó el problema. No podía. Lo que hizo, y lo hizo bien, fue:
Sacar a la luz el FaultBucketId y el BugCheckCode con sus parámetros, sin que el usuario tuviera que rebuscar en WER\ReportArchive.
Traducirlos a una explicación calibrada y útil para empezar a pensar.
Sugerir, entre otras cosas, «revisar utilidades de fabricante que interactúen con el firmware», que es exactamente el camino correcto.
Recomendar LatencyMon, que es la herramienta canónica para confirmar la hipótesis.
En otras palabras: el modelo local me puso en la pista correcta y se calló a tiempo. No fingió saber lo que no podía saber. No inventó un nombre de driver. No me mandó a desinstalar la GPU. Esa modestia, en una industria de chatbots que afirman con la misma confianza una verdad y un disparate, es una virtud técnica seria.
Hay además un argumento de soberanía que no quiero dejar pasar. La herramienta corre íntegramente en local: el fault bucket, los parámetros del BugCheck y, eventualmente, el contenido del minidump nunca salen de tu máquina. Para cualquier organización con datos sensibles, esto no es una preferencia estética: es la diferencia entre una herramienta usable y una herramienta vetada por cumplimiento. Phi-4 en ONNX Int4 ocupa una fracción de gigabyte y se ejecuta en CPU; Ollama abre la puerta a modelos mayores si la máquina lo soporta. En ambos casos, ningún tercero ve tus crashes.
8. Lecciones más allá del caso
Conviene formular en limpio:
El crash que ves rara vez es el crash que ocurrió. WER agrupa por consecuencia; el FaultBucketId es un identificador estadístico, no un diagnóstico.
SMM es invisible para el SO. Cualquier explicación de un BSOD que ignore la existencia del Ring −2 está, por construcción, incompleta. En máquinas con utilidades de fabricante particularmente entusiastas con outb 0xB2, esa incompletitud se vuelve operativa.
La IA local es un buen primer escalón, no el último. Su valor no está en sustituir al ingeniero, sino en acortar la distancia entre el código hexadecimal y la primera hipótesis razonable. Quien sabe leer un MSR no la necesita; quien no lo sabe, con ella aprende antes.
Phi-4 corriendo en tu máquina con licencia GPL-3.0 no es un juguete. Es una demostración mundana, sin marketing, de para qué sirven realmente los modelos pequeños: convertir telemetría opaca en lenguaje natural sin entregar la telemetría a nadie.
La industria de la IA lleva tres años convenciéndonos de que su utilidad pasa por mandarlo todo a la nube. Herramientas como CrashDetectorwithAI recuerdan, con discreción, que también se puede al revés: traer el modelo a la máquina, dejar el dato quieto, y usar la inferencia para enseñar en lugar de opinar. Si alguna pedagogía de la administración de sistemas merece la pena en 2026, probablemente sea esta.
Y, claro, queda el viejo asunto de fondo: la BSOD seguirá llamándose pantalla azul, el 0x133 seguirá apuntando a nt!KeAccumulateTicks, y la próxima utilidad de RGB que alguien instale seguirá invocando outb 0xB2 con la inocencia del que cree que el firmware está para servirle. Don Quijote, recordemos, no se quejaba de que hubiera molinos. Se quejaba de que nadie quisiera mirarlos de cerca.
Microsoft Learn. Bug Check 0x133: DPC_WATCHDOG_VIOLATION.
Intel. Intel® 64 and IA-32 Architectures Software Developer’s Manual, Vol. 3C — System Management Mode.
Resplendence Software. LatencyMon: Real-time monitor for kernel latency.
Notas al pie
Espero que algún estudiante de Periféricos e Interfaces llegue a leer esto, pero he aquí la importancia de entender la gestión térmica (como vimos en clase) porque disparará al SMI. ↩︎
Hay una clase profesional que ha logrado algo extraordinario: convertir el conocimiento en moneda y, al mismo tiempo, vaciarlo de contenido. Se hacen llamar investigadores. Llevan corbata o americana de pana, ocupan despachos con ventana, dirigen tesis que no leen y firman artículos que no han escrito. Su patria es el cuartil. Su himno, el factor de impacto. Su dios, un acrónimo: JCR.
Conviene decirlo sin anestesia: el sistema Journal Citation Reports (y la liturgia universitaria que se ha construido a su alrededor) se ha convertido en uno de los mayores fraudes intelectuales de nuestro tiempo. No porque medir la ciencia sea malo, sino porque hemos sustituido la ciencia por la métrica. Y cuando la métrica se vuelve el objetivo, deja de medir nada. Lo formuló Goodhart hace décadas. Lo viven cada día miles de doctorandos que aprenden, antes que a pensar, a optimizar.
El arte de no aportar nada y firmarlo entre ocho
Asómese cualquiera a las bases de datos. Verá artículos firmados por diez, doce, quince autores en disciplinas donde el laboratorio cabe en un cajón. Verá catedráticos cuya producción anual rivaliza con la de un equipo de cien personas, milagro explicable solo si admitimos que han descubierto el secreto de la bilocación o, más prosaicamente, que han descubierto el intercambio cruzado de autorías. Yo te pongo en el mío, tú me pones en el tuyo, y al final del sexenio nos vamos los dos a cenar. Ciencia colaborativa, lo llaman. Mafia, lo llamaríamos en cualquier otro sector.
La autoría honorífica (ese eufemismo cobarde para nombrar el robo intelectual) se ha normalizado hasta tal punto que ya nadie se sonroja. El director del departamento firma sin haber leído. El catedrático firma porque «ha dado ideas» hace tres años en un café. El amigo firma para que devuelva el favor el trimestre siguiente. Mientras tanto, el becario que escribió cada coma del manuscrito aparece en cuarta posición, agradecido de que le hayan dejado entrar en la fiesta de su propio trabajo.
La picaresca del cuartil
Los virtuosos del JCR han desarrollado un arsenal de técnicas que avergonzaría a un trilero de la Gran Vía:
El salchichón científico: dividir un estudio que cabría en un artículo serio en seis publicaciones famélicas, cada una con un dato y media conclusión, para multiplicar la cuenta.
Los cárteles de citación: grupos que se citan recíprocamente con la fidelidad de una secta, inflando artificialmente los índices h y manteniendo a flote revistas mediocres dirigidas por sus propios miembros.
El p-hacking y el HARKing: torturar los datos hasta que confiesen, y luego escribir la hipótesis después de conocer el resultado, fingiendo que se predijo lo que ya se sabía.
La revista amiga: ese Q1 sospechosamente endogámico donde publican siempre los mismos, revisados por los mismos, citados por los mismos.
El paper de pago disfrazado: el «open access» que de abierto solo tiene el bolsillo, donde por dos mil euros publican lo que sea con tal de que el cheque no rebote.
Y luego están, claro, los casos abiertamente fraudulentos: figuras manipuladas con Photoshop, datos inventados, ensayos clínicos que nunca existieron. Los retractan a veces. Pocas veces. Y cuando ocurre, el firmante sigue en su cátedra, sigue presidiendo tribunales, sigue dirigiendo tesis. Porque en la universidad española (y en muchas otras) ser pillado mintiendo cuesta menos que ser pillado siendo honesto y poco productivo.
¿Para quién trabajamos?
Lo más obsceno del sistema no es siquiera la trampa individual. Es que toda esta maquinaria (pagada con dinero público, sostenida por el trabajo gratuito de miles de revisores, alimentada por la ansiedad de doctorandos sin contrato) engorda los beneficios de cuatro multinacionales editoriales que cobran márgenes superiores a los de Apple. Elsevier, Springer, Wiley, Taylor & Francis. Compramos a precio de oro lo que les hemos regalado, y encima les damos las gracias por permitirnos hacerlo.
Mientras tanto, la sociedad que financia todo esto recibe ¿qué? Artículos en inglés, encerrados detrás de muros de pago, escritos en una jerga deliberadamente impenetrable, sobre cuestiones que ni el propio autor cree relevantes pero que daban para un Q1. Estudios que nadie replicará (porque replicar no puntúa). Conclusiones que no llegarán al aula, ni al hospital, ni al taller, ni al campo. Conocimiento producido en circuito cerrado para consumo de la propia tribu.
La crisis de replicabilidad es la confesión silenciosa de todo esto: en psicología, en biomedicina, en economía, la mitad o más de los resultados «consolidados» se evaporan cuando alguien se molesta en comprobarlos. Pero qué importa: los autores ya tienen su plaza, ya tienen su sexenio, ya tienen su ANECA. La verdad puede esperar. El cuartil no.
La complicidad institucional
Habría que ser ingenuo para creer que esto se sostiene solo por la codicia de unos pocos. Lo sostienen las agencias evaluadoras, que llevan décadas externalizando su criterio a un índice privado, opaco y comercial diseñado en los años sesenta para librarías. Lo sostienen los rectorados, que presumen de rankings construidos sobre las mismas cifras. Lo sostienen los gobiernos, encantados de poder gestionar la ciencia con una hoja de cálculo. Y lo sostiene también una parte del profesorado, que en su día tragó con las reglas para sobrevivir y ahora las exige a la generación siguiente con el rencor del converso.
Resulta sintomático que España, país que tantas veces se queja de su atraso científico, haya construido un sistema de promoción académica donde es perfectamente posible llegar a catedrático sin haber tenido jamás una idea original, simplemente acumulando JCRs como quien acumula sellos.
Abolir el JCR no es suficiente, pero es por donde empezar
No se trata de renunciar a evaluar. Se trata de evaluar lo que importa. Evaluar la calidad antes que la cantidad. Evaluar el contenido antes que el continente. Evaluar la honestidad, la replicabilidad, la utilidad social, la formación de discípulos, la divulgación, la integridad. Hay alternativas, y existen desde hace años: la Declaración DORA, el Manifiesto de Leiden, la ciencia abierta, la revisión por pares transparente, los repositorios públicos, las métricas responsables. Lo que falta no es técnica. Falta voluntad. Y falta vergüenza.
Mientras tanto, conviene nombrar las cosas por su nombre. Quien firma lo que no ha escrito, miente. Quien intercambia autorías, defrauda. Quien fabrica datos, prevarica con dinero público. Quien preside tribunales sabiendo que el sistema premia a los tramposos, es cómplice. Y quien defiende este sistema porque le ha ido bien dentro de él, no defiende la ciencia: defiende su currículo.
La universidad puede ser muchas cosas. Pero si renuncia a la verdad —si la convierte en un trámite, en una métrica, en un negocio— deja de ser universidad y se convierte en una agencia de colocación con biblioteca. A estas alturas, ya no estamos seguros de cuál es cuál.
El día que un comité de evaluación pregunte «¿qué ha descubierto usted?» en lugar de «¿cuántos Q1 tiene?», empezaremos a tener algo parecido a una comunidad científica. Hasta entonces, seguiremos teniendo lo que tenemos: una burocracia con bata blanca.
SMM, SMI, SMRAM, Chipsec y Volatility 3 como piezas de una metodología forense para investigar degradación de enclaves SGX desde firmware o desde el modo más privilegiado del procesador.
1. La pregunta forense no es ya “cómo leo el enclave”, sino “cómo reconstruyo lo que lo rodea”
Intel SGX cambió una premisa clásica del análisis forense de memoria: la idea de que, si se alcanza suficiente privilegio, toda la memoria física puede observarse. SGX introdujo una zona protegida, el Enclave Page Cache, dentro de la Processor Reserved Memory, cuyo contenido queda fuera del alcance del sistema operativo, del hipervisor, de DMA y también del System Management Mode. En otras palabras, el Ring −2 puede seguir siendo más privilegiado que el kernel, pero no por ello adquiere derecho a leer el EPC.
Este detalle altera profundamente la forma de investigar una máquina. Durante años, SMM fue una herramienta atractiva para adquisición de memoria porque podía interrumpir el sistema operativo mediante una System Management Interrupt, ejecutar código desde SMRAM y tomar una fotografía bastante coherente del estado de la plataforma. Pero, en una máquina con SGX, esa fotografía tiene una mancha ciega. Las páginas EPC no se leen en claro. En adquisiciones y reconstrucciones SGX-aware, la lectura directa desde fuera del enclave aparece como una zona no observable, frecuentemente representada como 0xFF.
La consecuencia práctica es importante: el analista no debe interpretar la imposibilidad de leer el EPC como ausencia de evidencia. Debe tratarla como una ausencia trazable. La evidencia no vive dentro del secreto, sino en su perímetro: firmware, locks de plataforma, SMRAM, microcódigo, driver SGX, proceso anfitrión, regiones no confiables, interfaz ECALL/OCALL, patrones de AEX, reinicios, cambios UEFI y telemetría de SMI.
La tesis central de este artículo es sencilla: en un incidente donde se sospecha una intromisión vía SMI, SGX no se investiga intentando romper el enclave, sino reconstruyendo cómo fue rodeado, condicionado o degradado.
2. Dos dominios opacos obligados a convivir
SGX y SMM son dominios opacos para el sistema operativo, pero no son equivalentes. SGX protege código y datos de un enclave frente a software privilegiado. SMM protege código de firmware frente al sistema operativo. Ambos se apoyan en hardware, registros de plataforma y microcódigo, pero sus objetivos son distintos.
El enclave SGX vive en el EPC. La CPU mantiene metadatos en el EPCM para controlar a qué enclave pertenece cada página, qué permisos tiene y si puede ser usada en una transición válida. El SMM vive en SMRAM, una región protegida por el chipset y normalmente situada en TSEG. Cuando SMRAM queda bloqueada durante el arranque, el sistema operativo no debería poder leerla ni modificarla. Cuando un evento SMI se dispara, la CPU entra en SMM, ejecuta un handler y después devuelve el control al sistema interrumpido.
El modelo visual puede resumirse así: la CPU y su microcódigo son el árbitro. SMM puede ver prácticamente toda la DRAM física, pero no el EPC. El kernel y los procesos cargan, mapean y enrutan enclaves, pero tampoco leen el contenido protegido. El enclave puede usar memoria no confiable para comunicarse con el exterior, y ahí empieza el terreno forense.
Esta frontera tiene una lectura incómoda. SMM no necesita romper la confidencialidad del enclave para degradar sus garantías efectivas. Un SMI handler hostil puede actuar sobre lo que el enclave necesariamente comparte con el mundo: buffers de entrada y salida, punteros, estructuras OCALL, estado del proceso anfitrión, rutas de fichero, memoria compartida y sincronización. Puede no leer el secreto, pero puede condicionar lo que entra, alterar lo que sale o forzar salidas asíncronas repetidas.
3. El muro 0xFF y la degradación por AEX
Cuando una SMI se produce durante la ejecución de un enclave, la CPU no entrega sin más el contexto real del enclave al SMI handler. Antes ejecuta un Asynchronous Enclave Exit. El AEX guarda el estado del enclave en la State Save Area, sustituye los registros visibles por valores sintéticos y devuelve una apariencia de ejecución fuera del enclave. Desde la perspectiva de confidencialidad arquitectónica, el secreto no debería quedar expuesto.
Sin embargo, la arquitectura no borra mágicamente todo rastro microarquitectónico. La historia de los ataques contra SGX muestra que la separación ideal entre arquitectura y microarquitectura es frágil. Foreshadow demostró que era posible atacar objetivos de seguridad de SGX mediante ejecución transitoria, filtrando secretos del enclave desde la caché. SGAxe fue más allá al mostrar el impacto de recuperar claves de atestación de enclaves arquitectónicos. Para el analista forense, esto tiene una lectura directa: la versión de microcódigo, las mitigaciones aplicadas y la validez de la atestación no son metadatos administrativos. Son evidencia técnica.
En el contexto SMI, el problema adopta otra forma: una ráfaga de interrupciones de gestión (SMI) puede provocar AEX continuos. SGX no promete disponibilidad, pero muchas aplicaciones reales basadas en enclaves sí dependen de una ejecución suficientemente estable. Un SMM comprometido podría degradar el servicio sin leer el EPC. También podría sincronizar SMI con fases concretas de ejecución, observar efectos laterales o manipular memoria no confiable entre una salida y una reentrada del enclave.
Por eso, en el informe forense conviene separar cuatro planos:
Confidencialidad del EPC: si el enclave está en release mode y no hay una vulnerabilidad microarquitectónica explotable, el contenido no se lee.
Integridad del proceso anfitrión: la pila, GOT/PLT, heap, tablas OCALL y buffers compartidos están fuera del EPC y son observables.
Disponibilidad del enclave: tasas anómalas de SMI o AEX pueden indicar degradación, sabotaje o instrumentación.
Confiabilidad del adquisidor: si el SMM o la ruta de adquisición están comprometidos, el dump deja de ser neutral.
4. De SMM como adquisidor a SMM como sospechoso
El salto conceptual más relevante es este: antes SMM podía verse como un aliado del forense; ahora también debe ser tratado como un posible sospechoso. Un volcado tomado desde SMM puede ser coherente desde el punto de vista temporal, pero no necesariamente confiable desde el punto de vista de integridad si la SMRAM, los SMI handlers o el firmware UEFI han sido manipulados.
Esto no es una preocupación teórica. Las amenazas UEFI y de bajo nivel llevan años dejando de ser demostraciones de conferencia. LoJax mostró implantes UEFI en campaña real. BlackLotus confirmó que un bootkit UEFI podía eludir Secure Boot en sistemas Windows 11 actualizados mediante CVE-2022-21894. Estas familias no prueban por sí mismas una manipulación de SMI, pero sí justifican un principio de prudencia: en máquinas con SGX, el análisis de memoria que no valida firmware y plataforma es incompleto.
La pregunta forense ya no debe formularse como “¿hay malware en RAM?”. Debe formularse así: ¿puedo confiar en la plataforma que me entrega esa RAM?
5. Chipsec como herramienta de validación de plataforma
Chipsec no es un antivirus ni una herramienta que “encuentre” automáticamente un rootkit SMM. Su valor está en otro sitio: permite comprobar si las condiciones de seguridad de la plataforma son las esperables. En una investigación SGX/SMM, eso es decisivo.
Los módulos de Chipsec que deben formar parte de la adquisición incluyen, al menos, los relacionados con SMRAM, SMRR, DMA sobre SMM, SMI BIOS y ejecución de código SMM fuera de rangos esperados. En un flujo operativo, el analista debería ejecutar y conservar salida íntegra de:
chipsec_main -m common.smm
chipsec_main -m common.smrr
chipsec_main -m common.smm_dma
chipsec_main -m common.bios_smi
chipsec_main -m common.smm_code_chk
chipsec_main -m common.bios_wp
chipsec_main -m common.spi_lock
chipsec_main -m tools.smm.smm_ptr
chipsec_main -m tools.uefi.scan_image
chipsec_main -m tools.uefi.whitelist
La lectura forense de estos resultados debe ser estricta. Si SMRAM no está bloqueada, si SMRR está mal configurado, si la protección frente a DMA falla, si la configuración de SMI no está bloqueada o si SMM_CODE_CHK_EN no está habilitado y bloqueado cuando la plataforma lo soporta, la cadena de custodia se debilita antes de interpretar cualquier hallazgo SGX. Un sistema con una ruta SMM vulnerable puede estar entregando un relato manipulado.
Chipsec también ayuda a cambiar el lenguaje del informe. En lugar de escribir “no se detecta malware en RAM”, una conclusión más honesta sería: “se ha adquirido memoria con las limitaciones derivadas de SGX; el EPC no es observable en release mode; la confianza en la adquisición queda condicionada al estado de SMRAM, SMRR, SPI/BIOS WP, SMI locks y SMM_CODE_CHK_EN; dichos estados han sido comprobados o, si no se han podido comprobar, deben figurar como limitación”.
6. Qué buscar realmente en una sospecha de intromisión vía SMI
Una hipótesis SMI puede llegar por dos caminos. El primero es firmware: un bootkit UEFI o un implante SMM registra, modifica o sustituye handlers que se ejecutan antes o durante el sistema operativo. El segundo es software privilegiado: un driver, kernel module o proceso con capacidad suficiente dispara software SMI o interactúa con interfaces expuestas por firmware vulnerable.
En ambos casos hay que buscar evidencias en capas distintas.
En UEFI/SPI, importan los cambios en firmware, NVRAM, variables de arranque, degradación de Secure Boot, BIOS write protection no bloqueado y diferencias frente a una imagen OEM. En SMM/SMRAM, interesan D_LCK, SMRR, TSEG, protección DMA, SMI handlers no esperados, handlers periódicos, CommBuffers y validación insuficiente de punteros. En SGX/kernel, se buscan rangos EPC, presencia de drivers isgx o DCAP, revisión de microcódigo, flags del enclave y procesos anfitriones. En espacio de usuario, se analizan instrucciones ENCLU, runtimes SGX, tablas ECALL/OCALL, memoria compartida no confiable, pila, GOT/PLT, buffers y comunicaciones. En timeline, se cruzan picos de SMI, AEX, reinicios, cambios UEFI, actividad de enclave, errores de atestación, tráfico cifrado y eventos de sistema.
No basta con una herramienta. Hace falta una matriz de evidencias.
7. Volatility 3 como capa de reconstrucción del proceso anfitrión
Volatility 3 no va a leer el EPC de un enclave en release mode. Pedirle eso sería pedirle que viole el modelo de seguridad que precisamente se está investigando. Su papel es otro: reconstruir el contexto observable del enclave.
En una imagen Linux, el análisis con Volatility puede ayudar a identificar procesos que cargan runtimes SGX, VMAs asociadas a /dev/sgx_enclave o /dev/isgx, cadenas relacionadas con libsgx_urts, sgx_ecall, ocall_table, instrucciones ENCLU y regiones que en el volcado aparecen como páginas 0xFF. Estas señales no prueban una intromisión SMM, pero permiten seleccionar procesos anfitriones, ubicar memoria no confiable y orientar el reverse engineering posterior con radare2, Ghidra u otras herramientas.
El plugin incluido con este artículo, sgx_smi_degradation.py, sigue esa filosofía. Es deliberadamente prudente: no explota nada, no intenta leer EPC, no interactúa con firmware en vivo y no afirma por sí solo que exista compromiso SMM. Lo que hace es producir una triage table con tres tipos de evidencia:
Indicadores de plataforma importados desde Chipsec, especialmente fallos en módulos relacionados con SMM, SMRR, SMI, BIOS write protection y SMM_CODE_CHK_EN.
Indicadores temporales importados desde una línea de tiempo de SMI, buscando ráfagas o deltas anómalos.
Indicadores de proceso en el dump, buscando artefactos SGX, instrucciones ENCLU/ENCLS, cadenas ECALL/OCALL y páginas completamente 0xFF en VMAs muestreadas.
Su salida está pensada para alimentar el informe, no para sustituirlo. Una fila de alta confianza debe leerse como “aquí hay un punto que merece correlación”, no como “aquí está la prueba definitiva”.
(nota: la continuación de este sencillo plugin la he publicado en este enlace de LinkedIN)
Scope PID Process Object Evidence Score Confidence Interpretation
CHIPSEC 0 platform common.bios_smi SMILock not set 8 HIGH Plataforma o SMM no plenamente confiable...
SMI 0 platform SMI_TIMELINE max_delta=427 7 HIGH Ráfaga de SMI compatible con degradación...
PROCESS 1824 broker 0x7f... libsgx_urts.so ENCLU=14, string:ocall_table 9 HIGH Proceso anfitrión SGX con transición ENCLU...
La lectura correcta de ese ejemplo no es “SMM está comprometido”. La lectura correcta es: “hay un proceso SGX con interfaz observable, una plataforma con locks deficientes y una anomalía temporal SMI; procede correlación con firmware, SMRAM, SPI/PCR0, red, ficheros y reverse del host”.
8. Propuesta de flujo forense completo
Un procedimiento robusto debería comenzar antes de tocar la RAM. El primer paso es documentar la plataforma: modelo, BIOS/UEFI, versión, microcódigo, estado de SGX, EPC, SGX2 si aplica, Secure Boot, TPM y configuración de arranque. El segundo paso es ejecutar Chipsec y preservar íntegra la salida. El tercero es adquirir memoria con una herramienta SGX-aware, conservando metadatos de EPC aunque el contenido no sea legible. El cuarto es analizar procesos, VMAs y runtimes SGX con Volatility 3. El quinto es reconstruir interfaces ECALL/OCALL y memoria no confiable. El sexto es correlacionar con firmware, PCRs, logs, red y tiempo.
Una cadena mínima de custodia debería contener:
1. Hash de imagen RAM y herramienta de adquisición. 2. Estado SGX: CPUID, EPC, PRMRR, microcódigo. 3. Estado firmware: versión UEFI, Secure Boot, variables de arranque. 4. Estado Chipsec: common.smm, common.smrr, common.smm_dma, common.bios_smi, common.smm_code_chk, BIOS/SPI locks. 5. Evidencia SPI: dump o, al menos, hashes y comparación OEM si es viable. 6. TPM PCR0 y PCRs relevantes si existe arranque medido. 7. Volatility: procesos anfitriones SGX, VMAs, ENCLU, ECALL/OCALL, 0xFF pages. 8. Timeline: SMI, AEX si se instrumentó, reinicios, errores de atestación, cambios UEFI, actividad de red.
El objetivo es poder sostener una conclusión matizada. No “el enclave está limpio” ni “no hay malware en RAM”, sino algo más útil: “el enclave no es observable por diseño; el proceso anfitrión sí lo es; la plataforma presenta o no presenta condiciones de confianza; la hipótesis de degradación vía SMI queda apoyada, debilitada o no concluyente en función de esta matriz”.
9. Indicadores que elevan la sospecha
Hay señales que, por separado, pueden ser débiles, pero juntas merecen escalado:
SGX activo con proceso anfitrión, uso de runtime SGX y tablas OCALL visibles.
Páginas 0xFF trazables en el dump, coincidiendo con actividad SGX esperada.
Microcódigo atrasado frente a vulnerabilidades SGX conocidas.
Fallos Chipsec en SMRAM, SMRR, SMM DMA, BIOS SMI locks, BIOS WP o SMM_CODE_CHK_EN.
Variables UEFI modificadas, Secure Boot degradado o inconsistencias en PCR0.
SMI periódicas o ráfagas coincidentes con actividad del enclave.
CommBuffers o interfaces de SMI handlers que aceptan punteros de memoria controlables.
Cambios en memoria no confiable justo antes o después de transiciones ECALL/OCALL.
Tráfico cifrado sostenido desde el proceso anfitrión con errores de atestación o comportamiento anómalo.
Ninguna de estas señales aisladas basta para afirmar un rootkit SMM. Pero la suma de varias cambia la valoración del riesgo.
Apéndice. Plugin Volatility 3 incluido
El fichero volatility3_plugins/sgx_smi_degradation.py acompaña a este artículo. Su propósito es apoyar el estudio forense de una posible degradación SGX vía SMI desde una imagen Linux y evidencias auxiliares. El plugin produce filas de tipo CHIPSEC, SMI y PROCESS, con puntuación, confianza e interpretación.
Limitaciones importantes:
No lee EPC en release mode.
No sustituye Chipsec, un dump SPI ni una validación TPM/PCR.
No prueba compromiso SMM por sí solo.
Su valor está en la correlación: proceso anfitrión SGX + locks deficientes + ráfagas SMI + evidencias firmware.
Referencias técnicas seleccionadas
F. Toffalini, A. Oliveri, M. Graziano, J. Zhou, D. Balzarotti. The Evidence Beyond the Wall: Memory Forensics in SGX Environments. Forensic Science International: Digital Investigation, 2021.
V. Costan, S. Devadas. Intel SGX Explained. IACR ePrint 2016/086.
J. Van Bulck et al. Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution. USENIX Security 2018.
S. van Schaik, A. Kwong, D. Genkin, Y. Yarom. SGAxe: How SGX Fails in Practice. 2020.
El Quijote Digital 