E2633转正官方版分析（Telnet篇）

1.1 Config.bin的加解密#

config.bin 不是明文 XML，而是 ZTE 的 Type-4 外层容器。E2631 中使用的是 AES-256-CBC。 中兴巡天及其套娃机的值有多组，这里仅展示一组：

解包流程如下：

回写流程如下：

1.2 修改Config.bin开启Telnet#

这里提供一个一键开启Telnet脚本config-telnet-enable.zip

PortControl 中 TELNET 行：

1
<DM name="ServName" val="TELNET"/>
2
<DM name="PortEnable" val="1"/>

TelnetCfg 中启用 LAN、关闭 WAN：

1
<Tbl name="TelnetCfg" RowCount="1">
2
  <Row No="0">
3
    <DM name="TS_Enable" val="1"/>
4
    <DM name="Wan_Enable" val="0"/>
5
    <DM name="Lan_Enable" val="1"/>
6
    <DM name="TS_Port" val="23"/>
7
    <DM name="TS_UName" val="admin"/>
8
    <DM name="TS_UPwd" val="admin"/>
9
  </Row>
10
</Tbl>

2.1 Tag 、Wifi 分区读取#

在路由器 Telnet 终端执行：

1
cat /proc/mtd

可以看到：

1
mtd2: 00100000 00020000 "tag"
2
mtd3: 00100000 00020000 "wifi"

两者大小均为 0x100000，即 1048576 字节。

Tag 分区是裸结构化数据，直接读设备节点：

1
cat /dev/mtd2 > /tmp/tag-backup.bin

Wi-Fi 分区（mtd3）是 JFFS2 文件系统，开机已经挂载在 /wlan，里面只有 caldata 一个文件（196,608 字节）。备份时直接读这个文件 —— 恢复时原样写回即可，不需要任何解包步骤：

1
cat /wlan/caldata > /tmp/caldata-backup.bin

确认电脑的 TFTP 服务已启动，根目录允许写入。

上传 Tag 备份：

1
tftp -p -l /tmp/tag-backup.bin -r tag-backup.bin 192.168.5.7

上传 Wi-Fi 校准备份：

1
tftp -p -l /tmp/caldata-backup.bin -r caldata-backup.bin 192.168.5.7

192.168.5.7请替换为电脑当前的局域网 IP。

2.2 修改 Tag：setmac 命令与 mtd_write_tag 工具#

Tag 分区（mtd2）是裸结构化数据加 CRC32 校验，Tag 中同时存在主 MAC、第二 MAC、MAC 前缀、D-SN、S/N、型号和 Wi-Fi 信息。按场景有两种修改方式：

1
setmac                        # 无参数时打印帮助
2
setmac show2                  # 列出全部具名参数
3

4
setmac <action type> <para_id> [<hex string para_val>]

1
setmac show2

1
===============Current Status of TagParam===============
2
Mac[ID: 256] is set to AA BB CC DD EE FF
3
OUI[ID: 768] is set to AABBCC
4
DeviceSerialNumber[ID: 512] is set to XXXXXXXXXXXXXXXXX
5
WirelessNetName[ID: 1024] is set to Example-SSID
6
WlanPass[ID: 1296] is set to ExamplePass
7
...
8
==============

1
# 1. 读当前型号
2
setmac 2 33024
3
#   2633 设备预期返回：5a58484e204532363333   ( "ZXHN E2633" )
4

5
# 2. 写入 E2631
6
setmac 1 33024 5A58484E204532363331
7

8
# 3. 回读验证
9
setmac 2 33024
10
#   预期返回：5a58484e204532363331

1
printf 'ZXHN E2631' | hexdump -v -e '1/1 "%02x"'
2
# 5a58484e204532363331

1
setmac 2 256                       # 读当前主 MAC
2
setmac 1 256 AABBCCDDEEFF          # 主 MAC（2.4G）
3
setmac 1 257 AABBCCDDEE00          # 第二 MAC（5G）
4
setmac 1 768 AABBCC                # OUI = MAC 前三字节
5
setmac show2                       # 回读确认

1
reboot

方法二：mtd_write_tag 整区写入（备选）#

mtd_write_tag 是自己编译的 ARMv7 MTD 写入工具，点此下载 mtd_write_tag_armv7（common-tools 包内也附带，见 6.1 节）。它按 MTD 的擦除块、写入页和坏块规则执行整区擦写，适合需要整区替换（例如离线改好整个 Tag 镜像），或 setmac 不可用的设备。该工具只针对 Tag 的 MTD 写入流程，不能未经验证地用于 Wi-Fi、Bootloader 或其他分区。

若需要离线生成改好的 Tag 镜像，可使用脚本改型号为E2631：把 tag-backup.bin 重命名为 tag.bin，与脚本放在同一级目录，双击脚本即可得到 tag-E2631.bin，其他信息仍是自己设备贴纸上的。

Tag 结构（离线自行修改镜像时，需要自己重算 CRC32）：

1
0x00  33 33 33 33
2
0x04  payload size，小端
3
0x08  CRC32，小端
4
0x0c  记录区
5
尾部  ff 填充

CRC32 计算范围从 0x0c 开始，长度由 payload size 决定。

先把改好的 Tag 镜像和工具通过 TFTP 传入路由器（192.168.5.7 是电脑的 TFTP 地址，请按实际网络修改）：

1
ping -c 3 192.168.5.7
2

3
rm -f /tmp/tag.bin /tmp/mtd_write_tag
4
tftp -g -l /tmp/tag.bin -r tag.bin 192.168.5.7
5
tftp -g -l /tmp/mtd_write_tag -r mtd_write_tag_armv7 192.168.5.7

上面脚本生成的是 tag-E2631.bin，传输时按实际文件名填写 -r 参数即可。

先确认程序用法：

1
chmod +x /tmp/mtd_write_tag
2
/tmp/mtd_write_tag

应能看到类似用法：

1
Usage: /tmp/mtd_write_tag --yes /dev/mtdN file.bin
2
Example: /tmp/mtd_write_tag --yes /dev/mtd2 /tmp/tag.bin

确认输入文件为目标 Tag 分区大小后执行写入：

1
ls -l /tmp/tag.bin
2
cat /sys/class/mtd/mtd2/name 2>/dev/null
3
cat /sys/class/mtd/mtd2/size 2>/dev/null
4

5
/tmp/mtd_write_tag --yes /dev/mtd2 /tmp/tag.bin
6
sync

出现 MEMUNLOCK warning: Operation not supported 或 fsync: Invalid argument 时，不要只根据警告判断成功或失败，必须继续做读回校验。

写入后在路由器端读回并校验 MD5：

1
md5sum /tmp/tag.bin
2

3
rm -f /tmp/tag-readback.bin
4
cat /dev/mtd2 > /tmp/tag-readback.bin
5
md5sum /tmp/tag-readback.bin

两次 MD5 一致，且程序没有报告擦除、写入或读回错误，才可认为 Tag 写入成功。若不一致，保留终端输出，不要重启设备，也不要继续写 Bootloader 或整片 NAND。

2.3 恢复 Wi-Fi 分区：用 2.1 的备份文件写回#

Wi-Fi 分区（mtd3）是 JFFS2 文件系统，开机时挂载在 /wlan，里面只有一个 caldata 文件（196,608 字节）。它与 Tag 性质完全不同：

为什么不能用 cat 写： cat 文件 > /dev/mtd3 会被直接拒绝，写请求根本不生效：

1
# cat /tmp/wifi.bin > /dev/mtd3
2
/bin/sh: can't create /dev/mtd3: No child processes
3
# echo $?
4
1

在 E2631（192.168.5.2）上实测：完整 1 MiB 分区镜像、仅 4 字节内容、追加模式 >>，三种写法返回同一错误；先 umount /wlan 再写也照样失败；写入前后 cat /dev/mtd3 | md5sum 完全相同，分区内容零变化。权限与 MTD 标志均正常（/dev/mtd3 为 crw-r--r--，/sys/class/mtd/mtd3/flags = 0x400，即 MTD_WRITEABLE）。

所以”把自己那份原样写回、MD5 一致”是个假象：写操作从未生效，读回的又是分区原有内容，两者当然一致 —— MD5 相同完全不能证明写入成功。

为什么不能用 setmac： 它依赖 libtagparam.so，只认 Tag 分区。

正确做法：恢复挂载点里的 caldata，擦除、ECC、坏块跳过、磨损均衡全部交给 JFFS2。

先确认挂载状态：

1
mount | grep wlan
2
ls -l /wlan/

正常应看到：

1
/dev/mtdblock3 on /wlan type jffs2 (rw,relatime)
2
----------    1 Z500_w9b root        196608 Jan  1  1970 caldata

把 2.1 备份的 caldata-backup.bin 传回设备：

1
tftp -g -l /tmp/caldata -r caldata-backup.bin 192.168.5.7

写回挂载点：

1
cp /tmp/caldata /wlan/caldata
2
sync
3

4
md5sum /tmp/caldata /wlan/caldata

两个 MD5 必须一致。随后让驱动重新加载校准数据：

1
rmmod mt7916
2
insmod /lib/modules/mt7916.ko

mt7916 通常被 tm、plat_zxylzb_9128S 等模块引用，rmmod 会直接失败，此时 reboot 即可。

3.1 接口和表单#

抓到的 Web 流程：

1
GET  /?_type=vueData&_tag=vue_nowversion_lua
2
POST /?_type=vueData&_tag=prepare_firmware_upgrade
3
POST /?_type=vueData&_tag=do_firmware_upgrade

multipart 字段名：

1
VersionUpload

核心表单头：

1
Content-Type: multipart/form-data; boundary=...
2
Content-Disposition: form-data; name="VersionUpload"; filename="firmware.bin"
3
Content-Type: application/octet-stream

3.2 SessionTimeout 的定位#

页面返回过 logintoken，响应头也返回过 X_XSRF_TOKEN。曾出现：

1
HTTP 200
2
IF_ERRORSTR = SessionTimeout

以及多种 token 组合均失败：

1
prepare same token  => SessionTimeout
2
prepare sessOnly    => SessionTimeout
3
prepare sessionOnly => SessionTimeout

后续在同一登录 Session 内获取页面 token、Cookie 和 XSRF token，并先调用 vue_loadprevent_data，曾得到：

1
prepare same:<page token> => SUCC

这只说明准备阶段通过，不说明上传和刷写一定成功。

3.3 升级管理器调试#

Telnet 下可以打开升级管理器日志并查看状态：

1
sendcmd cspd.cspd.upgrade_mgr setDebug 1
2

3
sendcmd cspd.cspd.upgrade_mgr show
4

5
sendcmd cspd.cspd.upgrade_mgr -p
6

7
sendcmd cspd.cspd.upgrade_mgr -l

show 中的 State、Location、TempDirName、FlashingPid 和 MediaPid 可帮助判断升级是否真正进入后端。研究中 Web 失败后常见：

1
State       :0
2
Location    :
3
TempDirName :
4
MediaPid    :

同时没有 /var/tmp/fw.bin，这更像请求未进入后端刷写，而不是固件已经写入。

3.4 请求体上限实验#

/bin/httpd 中发现：

1
content length is beyond limit.
2
Http request body read fail.
3
Upload file fail for not enough space, g_nContentLength(%d) >= g_nAllowedSpace(%d)
4
fwrite fail when upload.
5
VersionUpload
6
/var/tmp/fw.bin
7
do_firmware_upgrade
8
my_upload_file

这证明有 body length、临时空间和写文件分支；字符串本身不能证明唯一的上限数值。

3.5 /tmp 空间与 Web 限制#

当时读取到：

1
/var/tmp 约 40960 KiB，可用约 40736 KiB
2
/tmp     约 20480 KiB，可用约 19456 KiB

官方包约 21.38 MiB，在 /var/tmp 理论上放得下，但仍被 HTTP 处理路径重置。磁盘空间够，不等于请求体限制够，也不等于升级进程会接受该文件。

3.6 Wireshark 过滤器#

只看 HTTP 上传：

1
ip.addr == 192.168.5.1 && ip.addr == 192.168.5.7 && tcp.port == 80

只看电脑到路由器：

1
ip.src == 192.168.5.7 && ip.dst == 192.168.5.1 && tcp.dstport == 80

只看重置/重传：

1
tcp.flags.reset == 1 || tcp.analysis.retransmission

早期过滤 udp 只能看到 DNS、多播或调试包，不能证明 HTTP 升级。抓包中由 192.168.5.1:80 返回 RST, ACK，与设备端连接关闭相符。

3.7 Web 结论#

• 进度 100% 只表示浏览器发完请求，不表示设备已经校验或写入。
• SessionTimeout 和 ERR_CONNECTION_RESET 必须分层排查。
• 大于几百 KiB 的正式升级包应走 Telnet + TFTP + 本地 fw_flashing，不应继续反复提交 Web 请求。
• 隐藏页面是真实刷写路径，不是安全测试页面。

4.1 参数和最小失败测试#

1
/bin/fw_flashing
2

3
/bin/fw_flashing -h

输出包含：

1
fw_flashing:no parameter
2
d:r:p:f:m:v:

确认 -f：

1
echo test > /var/tmp/fw-test.bin
2

3
/bin/fw_flashing -f /var/tmp/fw-test.bin
4

5
echo $?

输出：

1
fw_flashing name=/var/tmp/fw-test.bin,states.st_size =5
2
read magic failed!
3
GetVersionInfo error==========fw_flashing error==========

说明 -f 确实接受路径，并要求带固件 Magic/版本头。

4.2 官方包成功刷写#

电脑端确认：

1
dir fw.bin
2

3
certutil -hashfile fw.bin MD5

路由器获取并校验：

1
cd /var/tmp
2

3
rm -f /var/tmp/fw.bin
4

5
tftp -g -l /var/tmp/fw.bin -r fw.bin 192.168.5.7
6

7
ls -l /var/tmp/fw.bin
8

9
md5sum /var/tmp/fw.bin

本次包 MD5：

1
de682a3dce2b128cf7edeb8ac5f958a1

执行：

1
/bin/fw_flashing -f /var/tmp/fw.bin

关键输出：

1
RunningVerStartAddr:700000
2
RunningHeadHighAddr:2300000
3
g_ver_towrite=2
4
g_upgrade_startaddr=0x2300000
5
g_upgrade_endaddr=0x3f00000
6
firmware_size=22413312
7
firmware_offset=0x214
8
sect_size=0x20000
9
WriteVersion head success!
10
==========fw_flashing success==================

说明程序选择备用高槽、擦除并写入了包体，同时更新了版本头。

4.3 确认当前槽#

1
cat /proc/cmdline
2

3
cat /proc/zte/verinfo/versionstates
4

5
cat /proc/zte/verinfo/softVersion
6

7
cat /proc/zte/verinfo/othersoftVersion

槽位关键字段：

本次低槽运行时确认：

1
currentverphyaddr: 0x00700000
2
backverphyaddr:    0x02300000

另一次从高槽启动时，/proc/cmdline 尾部出现 0x2300000。两者一致时，才是较强的槽位证据；不能只看 root=/dev/mtdblock8。

4.4 已确认的检查方向#

从 /bin/fw_flashing 字符串、符号和运行输出来看，存在：

1
read magic failed!
2
GetVersionInfo
3
check_ver_board
4
invalid vid version!
5
CheckBootFile
6
CheckFile
7
Checkheader
8
CspUserMtdRead / Write / Erase
9
flash addr overflow
10
uImage
11
CRC
12
CspSwitchVersion

合理的校验链：

1. 文件大小和可读性。
2. Magic、版本和升级头。
3. 板型、VID、版本关系。
4. 长度和目标槽范围。
5. uImage 头部/数据 CRC，具体分支由版本决定。
6. 擦除、写入和写后读回。
7. 写版本头、切换或等待下一次启动选择。

未找到明确 RSA 公钥验证调用。RSA 可能在 cspd、Web、BootROM 或其他库中，不能仅凭 fw_flashing 字符串判断。

5.1 Tag 直接写失败#

尝试 cat、mknod、chmod 后仍 MD5 不一致。设备没有 mtd_debug、flash_erase、nandwrite，只有 fw_flashing、upgradetest 等程序；这些程序没有暴露 Tag 写入接口。

最终是自己编译 MTD ioctl 工具（mtd_write_tag）完成写入的。

后来才发现，官方固件本身就自带 /bin/setmac（见 2.2 节），它通过 libtagparam.so + libmtduserapi.so 自动完成擦除并重算 CRC32 —— 改 Tag 用一条命令就够了，不需要自编译任何工具。mtd_write_tag 仍然可用，适合需要整区替换或 setmac 不可用的场景。

5.2 Web 反复失败#

1
升级准备失败：SessionTimeout
2
上传连接失败
3
net::ERR_CONNECTION_RESET

进度 31%、62%、97%、100% 后都见过失败。用小文件先拆分问题，确认大文件主要被 HTTP 路径限制后，停止继续提交 22 MiB 包，转为本地 fw_flashing。

5.3 未验证自动回退#

已确认 currentverphyaddr、backverphyaddr、两个 IsBad 字段，但没有故意刷坏包测试回退。不要为了得到一个“确定答案”而破坏当前可启动槽。

6.1 目录#

1
common-tools/
2
  README.md
3
  zte_type4_config_tool.js
4
  enable_telnet_admin.bat
5
  zte_firmware_analyzer.js
6
  fw_slot_status.sh
7
  mtd_write_tag_armv7

点此下载

6.2 Type-4 配置工具#

1
node common-tools/zte_type4_config_tool.js inspect config.bin
2

3
node common-tools/zte_type4_config_tool.js decrypt config.bin config.xml --profile e2631
4

5
node common-tools/zte_type4_config_tool.js encrypt config.xml config-new.bin --profile e2631
6

7
node common-tools/zte_type4_config_tool.js enable-telnet config.bin config-telnet.bin --profile e2631 --user admin --password admin

其他机型必须显式提供已验证种子：

1
node common-tools/zte_type4_config_tool.js decrypt config.bin config.xml --key-seed MODELKeyXXXXXXXX --iv-seed MODELIvXXXXXXXX

6.3 固件分析工具#

1
node common-tools/zte_firmware_analyzer.js firmware.bin
2

3
node common-tools/zte_firmware_analyzer.js firmware.bin --signature-offset 0x37fdcc --signature-size 564

输出哈希、可打印头部、型号标记、uImage CRC 和指定签名区零字节数。签名区非零不等于签名有效。