折腾140捡的中兴远航10，BL解了，Alpha也刷上了
1 天前 · 7 次浏览
今天去镇上的手机店，把一台屏幕报废、伊拉克成色的 vivo X27 抵了 100 块，又补 140 块，拿下一台中兴远航 10 5G，准备当热点机用。
这次查资料、拆旧工具、看日志、写脚本基本都是 Codex 陪我弄的。技术确实强，资料这么少又这么旧，没它帮忙的话，我自己折腾两三天都不一定能搞明白。就是语言能力实在一言难尽，最初那版人机味冲得不行，后面又请教了 DeepSeek 半天，才改成现在这样。这篇也是 Codex 起的稿。
机器是 ZTE 7530N / P633S07，MT6833（天玑 700），到手就是 MyOS 11.0.37_7530N_CT，Android 11，安全补丁 2022-11-05。
到手先抓了几个 prop，锁得死死的：
ro.boot.flash.locked=1
ro.boot.vbmeta.device_state=locked
ro.boot.verifiedbootstate=green
ro.oem_unlock_supported=1
sys.oem_unlock_allowed=0前面主要参考了酷安用户天凝Official在 2022 年发的《中兴远航10骨灰级调教指南》(加入不满3天不让发外链就不贴了)。他当时的路线是在 Windows 装好 MTK 驱动和 UsbDk，用 MTKAuthBypassTool 的 Disable Auth 把 Preloader 切到下载端口，再让另一个解锁工具接管；后面降级 MyOS 11.0.25，从卡刷包提取 boot，Magisk 修补后刷入。
那篇对应的是 MyOS 11.0.23、11.0.25 那批机器，放在 2022 年当时的固件和工具环境下应该能跑。我拿到这台已经是 11.0.37，照着做到 Disable Auth 这里就卡死了：MABT 能把手机 crash 进 BROM，但 Auth 过不去，后面的解锁流程自然也接不上。不能因为我现在复现失败就说人家当年写错了，只能说机器版本、旧 payload 和驱动环境都变了，这套老方法已经不适合直接照搬。
Windows 上先试了 MTK GSM Sulteng v1.3.7 和 MTK Auth Bypass Tool 3.1。把 Sulteng 拆开看了一眼，就是个 .NET 图形壳，里面捆着大约 2021 年的 mtkclient 1.5。那个“UNLOCK BOOTLOADER”按钮调的还是：
mtk da seccfg unlock手机关机插线，Windows 会短暂认到 0e8d:2000 Preloader，几秒握不上就掉端口，进充电页或者正常开机。MABT 的 Crash Preloader To BRom 倒是能把它切成 0e8d:0003，日志也出过：
Switch preloader to bootrom...crash succeed!
BootMode : BootRom
SecCFG : SBC+SDA
Disable BRom protection...
MTK Auth Disable(SLA/DAA) error!一开始看到 crash succeed 还以为有戏，后面才反应过来，它只是把手机弄进了 BROM，Auth 还是没过去。
为了抢那几秒端口，我试过动态盯 VID/PID、自动关旧工具、提前加载新版 mtkclient，结果还是 Handshake failed。后面又发现 MABT 会给 PID_0003 的设备实例写回：
UpperFilters=libusb0我电脑上还装着 UsbDk，两套 USB 接管一起抢设备，端口反复消失，还出过 Enumeration failed。换 USB 口以后 COM 号也一直变，盯着 COM6、COM10 没什么意义，认 0e8d:2000/0003 还靠谱一点。
手机能进 BROM，Auth 就是不过。老 payload、驱动冲突、只有几秒的端口窗口全碰到一起了，Windows 这条先放弃，直接换 Ubuntu Live。
Ventoy 起了个 Ubuntu 24.04.4 Live，装官方 mtkclient 2.1.4，配好 udev，再把会抢设备的 ModemManager 停掉。这边 Preloader 和 MT6833 target config 都能正常读，crash 进 BROM 后第一次跑 DA 又报：
DAA_SIG_VERIFY_FAILED (0x7024)把手机彻底断开，冷启动重新接，用最新版 mtkclient 的 --crash printgpt 从头再跑，这次 Kamakiri 过了，DA stage 1/2、DRAM、DA Extensions 都正常，GPT 也完整读了出来：
Successfully bypassed security
DA SLA is disabled能读 GPT 后先备份。正常玩机肯定先备全字库，我这次没读 userdata，只备了 NV、persist、seccfg、两槽 boot/vbmeta 等 32 个关键分区，不算完整全字库。Ubuntu 和 Windows 各算了一遍 SHA-256，全部对上才继续。
原始 seccfg 看过是 mtkclient 支持的 V4，解锁跑的是：
python mtk.py --debugmode da seccfg unlock没有加 --critical，也没动 vbmeta、boot、FRP 和其他分区。日志：
Detected V4 Lockstate
hwtype found: V4
Successfully wrote seccfg.写完我马上把整个 seccfg 重新读出来，和原始镜像比了一遍：lock_state 从 1 变成 3，dm_verity_state 和 sboot_runtime 都没变；差异只在前 0x200，后面完全一样。
重启进系统再看：
ro.boot.flash.locked=0
ro.boot.vbmeta.device_state=unlocked
ro.boot.verifiedbootstate=orange
ro.boot.veritymode=enforcing到这里 BL 就解完了。
Root 用的是我主力机上提取的 Alpha 30700，包名 io.github.vvb2060.magisk，证书 CN=vvb2060。
当时活动槽是 _b，boot 里有 Ramdisk，所以拿原厂 boot_b.bin 在 Alpha 里单独修补。产物完整 40 MiB，和 boot_b 分区一样大；header version 还是 2，ramdisk 能解压，Magisk 标记和 AVB footer 都在，kernel 和原厂逐字节一样。
进 fastboot 看了一眼：
current-slot: b
unlocked: yes
secure: no先试了 fastboot boot 临时启动，回到系统没有 su 和 magiskd，没成。
最后刷 B 槽：
fastboot flash boot_b magisk_patched.img
fastboot rebootSending、Writing 都是 OKAY。开机后跑：
adb shell su -c id返回：
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0magisk -V 是 30700，magiskd 正常。最后直接把手机里的 boot_b 块设备读出来算 SHA-256，和刷入镜像完全一致。
A 槽我没动。这手机在手机店的二手垃圾堆里不知道躺了多久，A 槽是什么时候留下的、对应哪版系统都无从考究。实际看 boot_a 和 boot_b 的哈希、kernel 大小、ramdisk 大小也都不一样，拿 B 槽的修补镜像直接覆盖过去没什么意义，谁知道会出什么问题。反正这么老的机器大概率也等不到系统更新，先放着不管。
140 块拿来当热点机，顺便把 BL 和 Root 都折腾明白了，值。