Kit de explotación para el bootROM Exynos 9830 que ofrece bypass de arranque firmado, inyección de claves personalizadas y payloads de volcado de memoria para dispositivos Samsung SM-G985F.
[!CAUTION] El conjunto de claves actual y los archivos generados son capaces de realizar fusing. Una vez que un dispositivo ha sido fusionado, el cambio de eFuse es irreversible y el dispositivo debe seguir usando imágenes de arranque y material de claves que coincidan con la clave fusionada. El uso de estos archivos o flujos es bajo su propio riesgo debido al comportamiento de fusing; todas las consecuencias siguen siendo responsabilidad del usuario que los ejecuta. Verifique el archivo eFuse, las claves privadas, el FWBL1 firmado, las imágenes LK /
sboot.biny el dispositivo de destino antes de ejecutar cualquier flujo de fusing.
sudo apt-get update
sudo apt-get install -y gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu
brew tap messense/macos-cross-toolchains
brew install aarch64-unknown-linux-gnu
python3 -m pip install -r requirements.txt
El archivo requirements.txt incluye coloredlogs, cryptography, hexdump, libusb, pyusb y pycryptodome.
En Windows, el dispositivo USB BootROM 04e8:1234 debe usar un controlador compatible con WinUSB/libusb
antes de que PyUSB pueda abrirlo. Ver exploit/windows/README.md.
El repositorio incluye un paquete de controladores WinUSB en
exploit/windows/Exynos_USB_Device.inf, con su catálogo correspondiente y archivo
de importación de certificados en el mismo directorio.
sboot.binpython3 exploit/split.py bootLoaderFiles/originalSboot_K/sboot.bin -o exploit/extra/images
El script de división escribe las partes de la imagen y un archivo split_manifest.json en el directorio de salida.
La imagen LK debe usar los IDs de comando de la clave 2 de arranque seguro de ROM para el flujo de clave personalizada:
Al aplicar el TSV de parches de LK dentro del proyecto Ghidra, el helper se invocó mediante Ghidra headless de esta manera:
GHIDRA=/path/to/ghidra_12.0.4_PUBLIC
REPO=$(pwd)
"$GHIDRA/support/analyzeHeadless" "$REPO/exynos990reverseEng" exynos990 \
-process lk.bin \
-noanalysis \
-scriptPath "$REPO/external/ghidra" \
-postScript ApplyLkPatches.java "$REPO/external/ghidra/lk_985_selected_patches.tsv"
Incrusta la clave eFuse de 32 bytes en lk.bin en el offset 0x205008, reemplazando la clave de fábrica:
dd if=external/keys/exynos9830_crecker/crecker.efuse of=exploit/extra/images/lk.bin bs=1 seek=$((0x205008)) count=32 conv=notrunc
xxd -g1 -s $((0x205008)) -l 32 exploit/extra/images/lk.bin
python3 exploit/merge.py exploit/extra/images Exynos9830
El script de fusión escribe sboot.bin en el directorio de trabajo actual.
Compila los proyectos de payload en external/payloads/ y copia los binarios resultantes en exploit/extra/payloads/:
./exploit/build_payloads.sh
El cargador UFS y el payload de clave personalizada incrustan un archivo eFuse de 32 bytes en tiempo de compilación.
De forma predeterminada, el Makefile lee external/keys/exynos9830_crecker/crecker.efuse;
sobreescríbelo con CUSTOM_KEY_EFUSE=/path/to/crecker.efuse cuando sea necesario.
El paso de preflight ejecutado por exploit/exploit.py vuelve a firmar el conjunto de imágenes SBoot en
exploit/extra/images/ in situ antes de cada ejecución firmada. No se conserva una salida
firmada separada. El paso de firma utiliza el paquete de claves compartidas, intencionadamente rastreado,
en external/keys/exynos9830_crecker/.
Comando equivalente desde la raíz del repositorio para el conjunto de imágenes completo:
python3 external/tools/sign_sboot_images.py \
--images-dir exploit/extra/images \
--keys-dir external/keys/exynos9830_crecker
Esto firma:
El firmador por lotes pasa el decimal 23 para cada imagen y no reutiliza un
valor de rollback anterior ya presente en un footer existente.
epbl.img se vuelve a cifrar primero cuando es necesario y luego se firma sobre los bytes finales.
ldfw.img y tzsw.img todavía necesitan el flujo AVB externo si se pretende
actualizar su contenido AVB.
El comando solo para FWBL1 es:
python3 external/tools/sign_tool.py \
-i exploit/extra/images/fwbl1.img \
-o exploit/extra/images/fwbl1.img \
-k external/keys/exynos9830_crecker/crecker_private.pem \
-H external/keys/exynos9830_crecker/crecker.hmac \
-s 0x3000 \
-r 23 \
-ma 0x9830 \
-m 0x142 \
-e 11 \
-t external/keys/exynos9830_crecker/crecker_stage2_tee_pubkey.bin \
-re external/keys/exynos9830_crecker/crecker_stage2_ree_pubkey.bin
Forma abreviada cuando sign_tool.py, fwbl1.img y los archivos crecker_* están en el directorio actual:
python3 sign_tool.py -i fwbl1.img -o fwbl1.img -k crecker_private.pem -H crecker.hmac -s 0x3000 -r 23 -ma 0x9830 -m 0x142 -e 11 -t crecker_stage2_tee_pubkey.bin -re crecker_stage2_ree_pubkey.bin
Ejecuta los comandos desde la raíz del repositorio salvo que se indique lo contrario.
El procedimiento de arranque observado del Exynos 9830 es:
Nota: El payload de volcado mem.bin solo puede usarse cuando no hay un sboot funcional instalado.
Envía uh.bin al bootloader mediante Heimdall:
heimdall flash --BOOTLOADER uh.bin
Ejecuta el flujo de volcado:
python3 exploit/exploit.py --dump
Revisa el volcado exynos990.bootrom.bin generado.
Partes de las herramientas de recuperación en Python de este repositorio fueron adaptadas de halal-beef/hubble.
Ese proyecto upstream se publica bajo GNU GPL v2.0, y este repositorio mantiene una licencia GPL-2.0 por compatibilidad. Consulta LICENSE y NOTICE.md.
El payload de clave personalizada del Exynos990 en external/payloads/exynos990_boot_custom_key/ se basa en el
esqueleto de payload boot-custom-key y la idea de flujo de control de
VDavid003/exynos-usbdl, un fork de
frederic/exynos-usbdl. Se ha reescrito y adaptado
sustancialmente para la cadena GET_CONFIGURATION del Exynos9830 / Exynos990, y no es una copia textual del
payload upstream. Debido a que el proyecto upstream referenciado está licenciado bajo GNU GPL v3.0, este payload se mantiene
bajo GPL-3.0-only; consulta external/payloads/exynos990_boot_custom_key/LICENSE.
| Ruta | Propósito |
|---|
bootLoaderFiles/ | Binarios del bootloader, partes divididas del bootloader, imágenes originales, imágenes descifradas y artefactos de volcado. |
bootromNotes/ | Notas de la ROM de arranque, diagramas de flujo y offsets de contexto USB. |
exploit/ | Herramientas Python, ejecutor del exploit, scripts de división/fusión, ayudante de compilación de payload y datos del SoC. |
exploit/extra/images/ | Imágenes del bootloader funcionales consumidas por los flujos del exploit. |
exploit/extra/payloads/ | Binarios de payload compilados copiados desde external/payloads/. |
external/ | Código fuente del payload, Makefile de compilación, notas descompiladas, material de claves compartido y herramientas auxiliares. |
external/keys/exynos9830_crecker/ | Paquete de claves personalizadas compartido Exynos9830 / Exynos990 utilizado por el flujo de cargador firmado. |
exynos990reverseEng/ | Archivos del proyecto de ingeniería inversa del Exynos 990. |
| Comando clave 1 | Valor | Comando clave 2 | Valor |
|---|
CMD_W_ROM_SEC_BOOT_KEY1 | 0x001 | CMD_W_ROM_SEC_BOOT_KEY2 | 0x016 |
CMD_W_USE_ROM_SEC_BOOT_KEY1 | 0x002 | CMD_W_USE_ROM_SEC_BOOT_KEY2 | 0x017 |
CMD_C_ROM_SEC_BOOT_KEY1 | 0x100 | CMD_C_ROM_SEC_BOOT_KEY2 | 0x114 |
CMD_R_USE_ROM_SEC_BOOT_KEY1 | 0x101 | CMD_R_USE_ROM_SEC_BOOT_KEY2 | 0x115 |
| Payload | Ruta de salida | Propósito |
|---|
mem.bin | exploit/extra/payloads/mem.bin | Payload de volcado de memoria del Boot ROM. |
loader.bin | exploit/extra/payloads/loader.bin | Payload de la ruta UFS usado por --ufs. |
Exynos990_boot_custom_key.bin | exploit/extra/payloads/Exynos990_boot_custom_key.bin | Payload de cargador firmado con clave personalizada usado por --signed. |
| Imagen | Material de clave usado | Revisión de rollback |
|---|
fwbl1.img | Clave privada BL1 + claves públicas Stage2 TEE/REE | 23 |
epbl.img | Clave privada Stage2 TEE | 23 |
bl2.img | Clave privada Stage2 REE | 23 |
lk.bin | Clave privada Stage2 REE | 23 |
el3_mon.img | Clave privada Stage2 TEE | 23 |
ldfw.img | Clave privada Stage2 TEE, interna + externa | 23 |
tzsw.img | Clave privada Stage2 TEE, interna + externa | 23 |
| Comando | Modo | Payload predeterminado | Notas |
|---|
python3 exploit/exploit.py --ufs | Ruta UFS | loader.bin | Inicia el flujo de payload UFS. |
python3 exploit/exploit.py --signed | Cadena de arranque firmada | Exynos990_boot_custom_key.bin | Vuelve a firmar el conjunto de imágenes SBoot y envía las imágenes. |
python3 exploit/exploit.py --dump | Volcado del Boot ROM | mem.bin | Recibe 0x20000 bytes en exynos990.bootrom.bin. |
| Paso | Nota |
|---|
| 1 | Entra en modo de descarga. |
| 2 | Crea o actualiza sboot.bin con exploit/merge.py cuando sea necesario. |
| 3 | Usa el flujo firmado de clave personalizada para llegar al modo Crecker, un modo estilo ODIN que acepta el flujo de imágenes de destino. |
| 4 | Envía el nuevo sboot.bin mediante ODIN, Heimdall u otro enviador compatible. |
| 5 | Ejecuta el payload UFS. |
| 6 | Opcional: instala CreckerRom para los flujos de One UI 7 y Strong Integrity. |
| 7 | Opcional: bloquea el bootloader después de que la configuración del objetivo esté completa. |
| Paso | Etapa | Notas |
|---|
| 1 | BootROM | Ejecución inicial de la ROM. |
| 2 | BL1 | Transferencia completa desde el BootROM. |
| 3 | EPBL | Transferencia completa desde BL1. |
| 4 | EPBL | Configura un manejador SMC mínimo. |
| 5 | BL2 | EPBL carga BL2. |
| 6 | BL2 | Transferencia parcial a BL2. |
| 7 | LK | BL2 usa EPBL para cargar LK, pero LK no se ejecuta de inmediato. |
| 8 | Monitor EL3 | BL2 usa EPBL para cargar el Monitor EL3. |
| 9 | Monitor EL3 | EPBL descifra el Monitor EL3. |
| 10 | Monitor EL3 | Transferencia completa al Monitor EL3. |
| 11 | Monitor EL3 | Inicializa y configura el manejador SMC extendido. |
| 12 | LK | La ejecución salta a LK. |
| 13 | LK / Monitor EL3 | LK llama al manejador SMC del Monitor EL3 para cargar las partes de TrustZone. |
| 14 | ODIN / objetivo personalizado | El arranque continúa hacia ODIN o el objetivo configurado. |
| Parte | Inicio | Fin |
|---|
fwbl1.img | 0x0 | 0x3000 |
epbl.img | 0x3000 | 0x16000 |
bl2.img | 0x16000 | 0x82000 |
lk.bin | 0xDB000 | 0x35B000 |
el3_mon.img | 0x35B000 | 0x39B000 |
| Etapa | Dirección de carga |
|---|
BL1 | 0x02022000 |
EPBL | 0x02026000 |
BL2 | 0x15600000 |
LK | 0xE8000000 |
EL3_MONITOR | 0xBFE80000 |
ID de fuente _boot_device | Ruta de fuente de arranque |
|---|
1 | Ruta UFS, flujo de carga UFS compartido. |
2 | Ruta de inicialización eMMC/SDMMC, flujo mmc_card_detect_and_init. |
3 | Dispositivo SDMMC/MMC 0, mmc_read_blocks(0, ...). |
4 | Ruta de carga USB. |
5 | Dispositivo SDMMC/MMC 1, mmc_read_blocks(1, ...). |
6 | Modo alternativo UFS, mismo flujo UFS central que 1 con un indicador de modo diferente. |
7 | Ruta de lectura del controlador sin procesar que no es MMC/UFS/USB. |
0xB / 11 | Ruta de respaldo USB, luego el mismo manejador USB que 4. |
| ID de fuente | Valor | Significado |
|---|
1 | 0x20 | UFS |
2 | 0x14 | eMMC |
3 | 0x00 | SDMMC_CH2 |
4 / 0xB | 0x40 | USB |
| Crédito | Contribución |
|---|
| Chimera Tool | Primer descubrimiento del exploit alrededor de 2021-2022. Chimera ofrece capacidades avanzadas de servicio para Exynos en muchos dispositivos, incluidas capacidades basadas en este exploit. |
| CVE-2024-56426 | El CVE en el que se basa este proyecto. |
| Christopher Wade | Informó CVE-2024-56426 a Samsung. |
| kethily-daniel | Proporcionó acceso a la herramienta utilizada para el rastreo de paquetes USB y la extracción de muestras. |
| BotchedRPR | Ayudó con la investigación inicial y la creación de carte2. |
| VDavid003 | Ayudó a realizar ingeniería inversa del PoC mediante volcados de paquetes y lo probó personalmente en dispositivos. |
| halal-beef / hubble | Proporcionó los volcados iniciales de paquetes USB y el análisis del PoC durante el ciclo de vida de la investigación, el código backend utilizado por el script de exploit y los diseños de SoC utilizados por los scripts de división y fusión. |
| VDavid003 / exynos-usbdl | Proporcionó el esqueleto del payload de clave personalizada GPLv3 y el flujo de referencia de descarga USB Exynos utilizado como base para el payload de clave personalizada del Exynos990. |
| R0rt1z2 | Ayudó con la creación del payload; parte del trabajo se basó en su proyecto, kaeru. |
| AntiEngineer | Compartió conocimientos de ARM, pistas y apoyo a la investigación. |
| AA | Inspiración de la vulnerabilidad y primer uso fuera de Chimera. |