
Desbloqueo del bootloader del ZTE Blade V40 Vita (P606F02 / Unisoc UMS9230 / UFS) mediante CVE-2022-38694: scripts de Linux, la solución al cuelgue posterior al desbloqueo de FBE y las dos trampas que nadie documenta
Notas y scripts para Linux para desbloquear con
CVE-2022-38694. Realizado en mi
EEA_P606F02 ejecutando MyOS11.0.13_8045_EEA.
Dos cosas deciden si esto funciona y ninguna está documentada en ningún sitio:
SEND fdl2-dl.bin → connection closed). Mantén pulsado solo VOL_UP + VOL_DOWN.
Pulsa POWER una vez si necesitas un reinicio.misc no
hace nada — este bootloader lo ignora. Borra userdata + metadata mediante BROM en su lugar.| Modelo | ZTE Blade V40 Vita — ZTE 8045 / EEA_P606F02 |
| SoC / almacenamiento | Unisoc UMS9230 / UFS |
| Paquete | ums9230_universal_unlock_UFS. Los fdl2-*.bin de UFS tienen 934088 bytes; los de eMMC son de ~1 MB. Los loaders incorrectos pueden borrar el teléfono |
| SO / ranura | Android 11, MyOS11.0.13 · ranura _b |
git clone --recursive https://github.com/TomKing062/CVE-2022-38694_unlock_bootloader
cd CVE-2022-38694_unlock_bootloader
gcc chsize.c -o chsize
gcc gen_spl-unlock.c -o gen_spl-unlock
cd spreadtrum_flash && make # spd_dump
Coloca chsize, gen_spl-unlock, spd_dump y los cuatro archivos del paquete UFS
(fdl1-dl.bin, fdl2-dl.bin, fdl2-cboot.bin, misc-wipe.bin) en un mismo directorio de trabajo.
Los scripts a continuación se ejecutan contra ese directorio.
Teléfono apagado → mantén pulsado VOL_UP + VOL_DOWN → conecta el USB → sigue manteniéndolos pulsados. Debes ver el USB 1782:4d00:
for d in /sys/bus/usb/devices/*/; do
[ "$(cat $d/idVendor 2>/dev/null)" = 1782 ] && echo "BROM: $(basename $d)"
done
19d2:135x es el USB normal del teléfono, no el BROM. Un teléfono en boot-loop está bien — cada reinicio
vuelve a ejecutar la BootROM, que vuelve a muestrear las teclas al reiniciar.
Un paso a la vez, volviendo a entrar en BROM antes de cada uno. Mantén las teclas de volumen pulsadas mientras se ejecuta.
cd /path/to/working-dir
sudo /path/to/repo/scripts/unlock.sh 1 # back up SPL + uboot_b, erase SPL (won't boot after this)
sudo /path/to/repo/scripts/unlock.sh 2 # prep images locally, phone not needed
sudo /path/to/repo/scripts/unlock.sh 3 # write fdl2-cboot.bin to uboot_b
sudo /path/to/repo/scripts/unlock.sh 4 # the unlock. ends in "connection closed" = success
sudo /path/to/repo/scripts/unlock.sh 5 # read miscdata @8192: 64 zeros = locked, string+2 hashes = unlocked
sudo /path/to/repo/scripts/unlock.sh 6 # restore uboot/SPL. never skip this
El paso 4 termina en EXEC FDL1 → timeout → connection closed. Eso es el desbloqueo funcionando, no
fallando. Si el paso 5 muestra ceros, ejecuta el paso 4 de nuevo.
El paso 3 deja el teléfono incapaz de arrancar Android (el payload no es un bootloader real) — el paso 6
devuelve tu uboot_bak.bin original. No te detengas entre medias.
Las claves FBE en trustos están selladas al estado de bloqueo, por lo que /data nunca puede montarse. El borrado es
obligatorio:
sudo /path/to/repo/scripts/fix-post-unlock-hang.sh
Mantén presionadas las teclas de volumen; se rearma a sí mismo hasta que captura el BROM. Borra userdata + metadata,
escribe el BCB, reinicia. Se capturó al tercer intento y tardó menos de un minuto.
adb shell getprop ro.boot.flash.locked # 0
adb shell getprop ro.boot.verifiedbootstate # orange
adb shell getprop ro.boot.vbmeta.device_state # unlocked
fastboot getvar es inútil en este dispositivo (devuelve vacío para todo), así que no busques
ahí para confirmación.
Este es un dispositivo VAB sin partición recovery. Consulta siempre el slot activo antes de
flashear:
adb shell getprop ro.boot.slot_suffix
La imagen de arranque B06 de fábrica necesita que su salida de Magisk se vuelva a firmar antes de flashearla. El procedimiento probado en Windows para el flasheo de fábrica, la firma AVB y la recuperación está en docs/windows-flash-root.md. Si dejas inservible una imagen de arranque, BROM sigue funcionando. Mapa de particiones: docs/partition-table.md.
Re-bloqueo: es posible (poner a cero el token de miscdata a través de BROM) pero no tiene sentido para la seguridad —
el fallo de BootROM es permanente, cualquiera puede volver a desbloquear con estos mismos pasos.
Crédito: CVE-2022-38694 es de NCC Group. Las herramientas son de TomKing062. Los scripts de aquí son MIT. Borra tu teléfono; eso es responsabilidad tuya.