原预帖（https://bbs.kanxue.com/thread-291815.htm）：

本人在去年购买了一台ZTE G7615V2设备，今年拿出折腾时发现设备有签名校验与全盘加密，无法加载第三方固件。遂进行研究，历时约十小时终于使用原创方案将签名校验破解并拿到了全盘加密的密钥（同型号通用），于是，这台设备极强的性能总算能被释放，成为了一台万能Linux小主机。

(50块钱 2.5G usb3.0 wifi6 还有一个内嵌的小olt!)

此方案理论上可用于ZTE全系列使用U-BOOT的设备（FTTR与路由器等）。

ps:终于高考完了有空整理了!早就想分享了(

正文：

以下我不会提供提取的uboot和固件什么的，如果想尝试请自行购买设备！

本文仅供逆向技术交流，禁止用于任何违法用途，作者不承担任何连带责任，禁止用于不属于自己的设备！
重点是技术交流！
不要做一键工具什么的！不要让贩子占便宜！不要让属于我们geek的设备变成贩子盈利的工具！
（每个不同编译版本的uboot需要重新分析，且基本上每个月会重新编译一次）
（如果看不懂本文请先入门逆向工程）

这个设备双核armv8 256Mram/flash wifi6 1x2.5g+3x1g 自带2.5golt(纯软件实现gpon控制平面) 1xusb2+1xusb3 10g上行gpon
可玩性拉满！

开始（我买的这个telnet卖家帮我开好了，不要问我怎么开的，有工具，不行的话找人付费开）！
使用打开了telnet的此设备查看/proc/mtd，尝试读取uboot固件，发现为乱码，后证实设备启用了全盘加密。
于是拆机，连上ttl线，打开tty(波特率115200)，发现设备使用uboot引导，于是多次敲击enter进入uboot控制台。
仔细观察后发现有zxboot命令（ZTE专属的启动命令），tftpput命令被去除，无法用tftp导出内存。
此时开始思考对策。想到uboot既然能够执行，则它一定被解密后加载在了内存某处。于是使用bdinfo查看信息中的重定向基址：

=> bdinfo
...
relocaddr   = 0x000000009f6a8000
...

uboot被自动解密后加载到了这个地址（0x9f6a8000），我们使用mtd list查看mtd分区表

=> mtd list
...
  - 0x000000000000-0x000010000000 : "spi-nand0"
          - 0x000000000000-0x000010000000 : "whole flash"
          - 0x000000000000-0x000000300000 : "u-boot"
...
          - 0x000001700000-0x000004700000 : "kernel1"
          - 0x000004700000-0x000007700000 : "kernel2"
...
          - 0x000001700000-0x000003b00000 : "rootfs1"
          - 0x000004700000-0x000006f00000 : "rootfs2"

这时不难发现，rootfs分别包含在各自的kernel分区中（奇怪喵！）。先擦除kernel2确保只有kernel1可用避免failsafe，然后我们可以得知uboot分区的大小。uboot的md命令可用（通过16进制查看内存），便vibecoding一个py脚本uboot.py，通过串口使用md命令读取重定位后的uboot固件（起始0x9f6a8000，长度0x300000）得到uboot.bin
打开ghidra进行分析，加载uboot.bin，baseaddr写0x9f6a8000开始分析（armv8，64位，小端）。
尝试修改rootfs字节后zxboot，不出意外地报错
version crc failed

遂在ghidra搜索字符串，找到如下代码（图1）

我们发现上面的
iVar2 = *(int *)(lVar5 + 100);
iVar1 = FUN_9f70fb04(uVar3,&DAT_88000000 + *(uint *)(lVar5 + 0x60),*(undefined4 *)(lVar5 + 0x5c));
如果修改这里难。我们看到
if (iVar2 == iVar1) {

对应
9f6d49d8 1f 03 00 6b       cmp          w24,w0

如果使用mw命令在zxboot前修改内存呢？
遂写出mw.l 0x9f6d49d8 0x6b00001f
作用是把这行改成cmp w0,w0
我们看到还有一个rsa校验
if (iVar1 == 0) {
    FUN_9f7126f4(s_Do_not_RSA_Verify_9f730666);
}

对应
9f6d4a20 a0 00 00 35       cbnz         w0,LAB_9f6d4a34

遂写出mw.l 0x9f6d4a20 0x340000a0
作用是把这行改成cbz w0,LAB_9f6d4a34
这时尝试zxboot，启动了！但是，当我刷入在系统中通过dd命令提取的明文rootfs后启动失败了，提示not found jffs2 node

为什么呢？遂查找字符串找到这样如下代码（图2）

因为分区合并所以搜索jffs2头没问题啊，但是为什么找不到呢？难道说是全盘加密的？
发现FUN_9f6d46c8(&local_40,&local_40,0x40);很可疑，进一步查看

发现（图3）代码

FUN_9f6d4668(auStack_108);可疑！进一步查看

发现（图4）代码

经过查看 这是一个哈希函数（其实就是密钥派生！）
FUN_9f7112a4其实是memcpy.
void FUN_9f6d4668(undefined8 param_1)的参数其实就是全盘加密的密钥派生输出指针！
于是对机器码进行修改，重启设备（避免指令缓存），一行mw把这个指针改成已知内存地址，应用之前两个mw后zxboot然后md一下已知内存地址，看到了全盘加密密钥（经过验证这个型号的通用！），这个部分请自己写mw指令，我不提供（其实很简单）。
我们分析之前FUN_9f6d46c8里面的FUN_9f6d8fe8，其实就是aes解密。
至此，破解完成！
修改uboot环境变量自动先mw再zxboot就可以实现持久化。
然后可以自由的定制系统了喵！安全启动和全盘加密已经被crack了喵！
对了，底层是jffs2，全盘aes加密在内核，所以设备看似可以挂载/成可读写其实修改不会被保存还有概率破坏文件系统。建议修改后aes加密然后在uboot里面tftp上传然后烧录喵！
大家可以在帖子下面进行技术讨论喵！

[招生]科锐逆向工程师培训(2026年7月3日实地，远程教学同时开班, 第56期)！

上传的附件：

• uboot.py （7.13kb，7次下载）