最近家里的移动宽带到期了，闲置了一台H3-2S的光猫，原本我也有一台MIPS的友华光猫，固件修改后我自己也很满意了。但这台闲置的光猫是ARMv7l的，测试后发现性能更好一些（是MIPS的一倍多）。于是就想着也改改，加一些自启脚本，装frpc、alist、kms、aria2c、clash、甚至还能跑一点自己写的Java程序。通过分析一通之后，我发现这个光猫的rcS相关的自启内容里一点破绽都没有，原本的alipay的dns也注释了，要加自启脚本就必须改rootfs里的rcS。由于系统里没有dd，但有nandump，我给dump出来，使用binwalk分析了一下，果然从kernel里解出了文件系统。整个固件的文件结构大概是这样的：中兴文件结构，占480bytes，然后是uImage头64bytes，然后会执行一段程序，解压gzip。gzip解压出来之后，解压的字节中又有一段程序，然后再解压一个lzma块，这个lzma块解压出来就是rootfs.cpio了。这个cpio是没有任何压缩的。但我用python的cpio库libarchive的时候遇到了不小的挑战，就是cpio解压后什么都不改，再压回去，对比改动发现差异很大，里边有一些数据的大小写都发生了变化，小写全都变成了大写。我想探究里边的原因，耗费了一天时间也没找出来，于是我只好人肉修改cpio的16进制内容，找到rcS部分，把alipay.sh的注释打开，然后改一小段。剩下的就是还原回去并刷进去的工作了，这个还原工作异常艰难：首先是gzip解压的时候不知道gzip块的长度，不知道什么时候会结束，虽然不影响解压，但肯定影响还原啊。好在gzip解压的时候，异常信息里会提示无法解码的字节，那直接搜索这个字节就能找到结束的附近了。然后观察右侧的块特征，终于找到了结束位，顺带还发现了dtb的开始位置和整个分区的结束位置、还有crc32的偏移量。然后是lzma的结束位，这个就比gzip难多了，因为这个lzma解压的时候没有报任何异常，直接就解压出来了，再尝试压回去会发现大小完全对不上，大了1M多不止。尝试了好几个库和xz\tar等格式，发现也对不上，应该就是lzma的压缩格式。后来我开始怀疑是不是lzma的结束位置不对，可没有任何异常啊，应该不会不对吧。我带着这个怀疑，使用linux中的lzma去检查这个文件块，发现lzma竟然无法识别，而我压缩回去的lzma则能识别，而且完全没问题。我好奇它究竟用的什么lzma算法啊，难道老版本的不支持？于是我开始翻python的lzma库源代码，发现它果然捕获了异常，而且直接把异常吃掉了。真狗！我把那段代码拷贝出来。lzma则是非常难，因为lzma的那次压缩是在gzip解压之后，又执行了一段，那偏移量完全都不知道怎么对上，载入到IDA里也是一堆未识别的地址。好在它的库函数会有俩个不同的异常，一个是流未结束，一个是字节无法解析。流未结束就是截取少了，字节无法解析就是截取多了，然后写了一个二分查找的方法，找到了lzma解压的位置，位置结束后俩个字节处就是lzma的长度数值。然后我测试了一下，将截取的lzma解压出rootfs.cpio后再原封不动的压缩回去，大小竟然比原来的小了几十字节。这可不行，我又尝试了一下用linux自带的lzma压缩：果然还原了，和原文件md5值一字不差，看来linux的lzma算法还是和python的lzma有些小差异。至此，整个逆向过程告一段落。IDA可以直接载入uImage的文件去查看gzip的解压逻辑，来验证gzip的结束偏移的地址是否正确。经过一番验证，也找到了双固件切换的的方法，也完成了文件系统提取也压缩回去的程序工具，但改完的固件始终无法启动，查看gzip解压的出来的数据块，发现了大量证书内容：感觉要裹足不前了......，目前的水平对arm反汇编的能力严重不足。
所以把成果文件贡献出来，看有没有大神有兴趣挑战，如果成功，我将分享我开发的中兴固件拆包打包工具（现在不分享是因为打包的固件无法启动，有变砖风险）。c71K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6U0L8r3!0#2k6q4)9J5k6e0p5^5z5g2)9J5k6h3y4F1i4K6u0r3N6$3g2T1i4K6u0r3M7$3S2S2M7X3g2Q4x3@1k6U0L8$3c8W2i4K6y4p5j5g2W2h3g2V1&6*7e0i4k6m8y4%4A6W2i4@1g2r3i4@1u0o6i4K6R3^5i4@1f1^5i4@1q4q4i4@1u0r3i4@1f1&6i4K6V1%4i4@1q4q4i4@1f1%4i4@1p5H3i4K6R3I4i4@1g2r3i4@1u0o6i4K6W2m8y4X3S2&6P5q4!0q4c8W2!0n7b7#2)9^5z5b7`.`.文件说明：
该文件为吉比特，中兴芯片光猫固件：2023年5月8日 我已自己挑战成功，实现了通用工具：结帖啦：我的轩辕悠悠
---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-276970.htm
[原创]中兴ZTE ZX279128S芯片固件解密
173 浏览
24 回复
建议备份一下出厂时 /GN25L95_datas bob校准数据 /wlan wifi校准数据。校准丢失会影响光猫性能
mark
微启宇
这有官方的固件，建议折腾官方可升级的固件而不是自己dump下来的， 自己dump下来然后在刷入会有无法启动的风险（我以前就这样玩废好几台光猫）。 [固件]& ... 我有串口小板的，这个帖子的固件我下过，没花猫币就找到了,而且我还测试过，他的固件只是比我的版本早些而已，大概是2021年6月20日的。
说一下最终结论吧，实际上到这里，固件的解密工作已经完成得差不多了。有dtb和rootfs了，然后放到相应得kernel源码里编译一份zImage就完成了。
所有的校验工作都是在uboot里，我把uboot载入到IDA里看了一下，uboot有Hash和RSA校验
ROM:00006E0B 0000000E C HASH timeout\n
ROM:00006E19 0000000D C RSA timeout\n
ROM:00006E26 0000000D C AES timeout\n
同时会根据固件头的Magic Number去找uImage的入口
ROM:00023974 DCB 0x99,0x99,0x99,0x99,"DDDDUUUU",0xAA,0xAA,0xAA,0xAAROM:00024134 DCB 0x99,0x99,0x99,0x99,"DDDDUUUU",0xAA,0xAA,0xAA,0xAAROM:00024B18 DCB 0x99,0x99,0x99,0x99,"DDDDUUUU",0xAA,0xAA,0xAA,0xAA与这个uboot相匹配的CPU还有
ROM:0005446F 00000014 C CPU : ZX279128@A9,
ROM:00054483 00000015 C CPU : ZX279128S@A9,
ROM:00054498 00000015 C CPU : ZX279127S@A9,
验证通过后会跳到
ROM:00006E84 0000000C C verify OK!\n
如果出现问题则会
ROM:00006EA3 00000016 C code hash error !! \n
否则，则会
ROM:00006EB9 00000012 C code hash ok !! \n
uboot的版本信息
ROM:0005122B 00000030 C U-Boot 2013.04-svn1633 (Oct 19 2021 - 10:18:42)
启动参数
ROM:00051296 00000082 C bootcmd=setenv bootargs mem=512M console=$(console) ubi.mtd=5 root=ubi0:rootfs rootfstype=ubifs init=/linuxrc ro;bootm 0x42000100
ttl波特率
ROM:00051324 00000010 C baudrate=115200
串口参数
ROM:0005140D 00000019 C console=ttyAMA0,115200n8
载入地址
ROM:000513B5 00000014 C loadaddr=0x44000000
相关的文件名：
ROM:00051426 00000013 C bootfile=uboot.bin
ROM:00051439 0000001E C bootloaderfile=bootloader.bin
ROM:00051457 00000016 C linuzfile=vmlinuz.bin
ROM:0005146D 00000015 C fullfile=upgrade.bin
配置文件：
ROM:0005148D 0000001E C configfile=zxic_pubconfig.bcb
接下来会校验zImage的magic number：
ROM:0005489D 0000001D C Bad Linux ARM zImage magic!\n
内置了gzip解压算法
ROM:00054B04 00000051 C GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to recover\n
也内置了lzma解压算法
ROM:00054B55 00000046 C LZMA: uncompress or overwrite error %d - must RESET board to recover\n
其他压缩格式会提示
ROM:00054B9B 00000023 C Unimplemented compression type %d\n
验证uImage的magic number
ROM:00054BF7 00000012 C Bad Magic Number\n
uImage头部crc32验证
ROM:00054C09 00000015 C Bad Header Checksum\n
uImage数据crc32验证
ROM:00054C39 0000000E C Bad Data CRC\n
后面就是从tftp载入镜像的内容，也会校验上述逻辑
支持的芯片代号：
ROM:0005C1FC 0000001A C Board: ZXIC zx279127sevb\n
ROM:0005C216 0000001A C Board: ZXIC zx279128sevb\n
ROM:0005C230 00000019 C Board: zxic zx279128evb\n
RO
...(已截断)
这有官方的固件，建议折腾官方可升级的固件而不是自己dump下来的， 自己dump下来然后在刷入会有无法启动的风险（我以前就这样玩废好几台光猫）。 [固件]& ... 我有串口小板的，这个帖子的固件我下过，没花猫币就找到了,而且我还测试过，他的固件只是比我的版本早些而已，大概是2021年6月20日的。
说一下最终结论吧，实际上到这里，固件的解密工作已经完成得差不多了。有dtb和rootfs了，然后放到相应得kernel源码里编译一份zImage就完成了。
所有的校验工作都是在uboot里，我把uboot载入到IDA里看了一下，uboot有Hash和RSA校验
ROM:00006E0B 0000000E C HASH timeout\n
ROM:00006E19 0000000D C RSA timeout\n
ROM:00006E26 0000000D C AES timeout\n
同时会根据固件头的Magic Number去找uImage的入口
ROM:00023974 DCB 0x99,0x99,0x99,0x99,"DDDDUUUU",0xAA,0xAA,0xAA,0xAAROM:00024134 DCB 0x99,0x99,0x99,0x99,"DDDDUUUU",0xAA,0xAA,0xAA,0xAAROM:00024B18 DCB 0x99,0x99,0x99,0x99,"DDDDUUUU",0xAA,0xAA,0xAA,0xAA与这个uboot相匹配的CPU还有
ROM:0005446F 00000014 C CPU : ZX279128@A9,
ROM:00054483 00000015 C CPU : ZX279128S@A9,
ROM:00054498 00000015 C CPU : ZX279127S@A9,
验证通过后会跳到
ROM:00006E84 0000000C C verify OK!\n
如果出现问题则会
ROM:00006EA3 00000016 C code hash error !! \n
否则，则会
ROM:00006EB9 00000012 C code hash ok !! \n
uboot的版本信息
ROM:0005122B 00000030 C U-Boot 2013.04-svn1633 (Oct 19 2021 - 10:18:42)
启动参数
ROM:00051296 00000082 C bootcmd=setenv bootargs mem=512M console=$(console) ubi.mtd=5 root=ubi0:rootfs rootfstype=ubifs init=/linuxrc ro;bootm 0x42000100
ttl波特率
ROM:00051324 00000010 C baudrate=115200
串口参数
ROM:0005140D 00000019 C console=ttyAMA0,115200n8
载入地址
ROM:000513B5 00000014 C loadaddr=0x44000000
相关的文件名：
ROM:00051426 00000013 C bootfile=uboot.bin
ROM:00051439 0000001E C bootloaderfile=bootloader.bin
ROM:00051457 00000016 C linuzfile=vmlinuz.bin
ROM:0005146D 00000015 C fullfile=upgrade.bin
配置文件：
ROM:0005148D 0000001E C configfile=zxic_pubconfig.bcb
接下来会校验zImage的magic number：
ROM:0005489D 0000001D C Bad Linux ARM zImage magic!\n
内置了gzip解压算法
ROM:00054B04 00000051 C GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to recover\n
也内置了lzma解压算法
ROM:00054B55 00000046 C LZMA: uncompress or overwrite error %d - must RESET board to recover\n
其他压缩格式会提示
ROM:00054B9B 00000023 C Unimplemented compression type %d\n
验证uImage的magic number
ROM:00054BF7 00000012 C Bad Magic Number\n
uImage头部crc32验证
ROM:00054C09 00000015 C Bad Header Checksum\n
uImage数据crc32验证
ROM:00054C39 0000000E C Bad Data CRC\n
后面就是从tftp载入镜像的内容，也会校验上述逻辑
支持的芯片代号：
ROM:0005C1FC 0000001A C Board: ZXIC zx279127sevb\n
ROM:0005C216 0000001A C Board: ZXIC zx279128sevb\n
ROM:0005C230 00000019 C Board: zxic zx279128evb\n
RO
...(已截断)
这有官方的固件，建议折腾官方可升级的固件而不是自己dump下来的， 自己dump下来然后在刷入会有无法启动的风险（我以前就这样玩废好几台光猫）。 [固件] 中国移动H3-2s全国省份固件，支持网页升级 e60K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2U0K9r3W2F1j5h3c8K6L8q4)9J5k6h3&6W2N6q4)9J5c8X3k6G2M7Y4g2E0i4K6u0W2M7r3S2H3i4K6y4r3L8h3!0V1i4K6y4p5N6X3W2W2N6%4c8Z5M7X3g2S2k6q4)9J5y4X3q4E0M7q4)9K6b7Y4c8A6k6q4)9K6c8o6p5%4x3o6j5%4x3q4)9J5y4X3q4E0M7q4)9K6b7X3S2A6k6$3S2D9K9h3N6Z5N6q4)9K6c8p5R3K6i4K6u0V1x3W2x3`.
玩嵌入式设备没有usb转串口线是没法看日志排查错误的，最好也要NAND flash的烧录器，一旦出现变砖问题可以用热风抢拆盘写数据。
最后于 2023-4-25 07:18
被微启宇编辑
，原因：
玩嵌入式设备没有usb转串口线是没法看日志排查错误的，最好也要NAND flash的烧录器，一旦出现变砖问题可以用热风抢拆盘写数据。
最后于 2023-4-25 07:18
被微启宇编辑
，原因：
XYUU
微启宇
中兴的光猫自带基于lxc容器技术的OpenWRT子系统你可以在里面折腾这个容器的权限和宿主系统同级没必要折腾宿主系统，进入openwrt是 ... 用usb转串口接到光猫然后用串口工具看看uboot启动时的日志，看看uboot是否正常载入内核和报啥错误。
最后于 2023-4-25 07:14
被微启宇编辑
，原因：
微启宇
中兴的光猫自带基于lxc容器技术的OpenWRT子系统你可以在里面折腾这个容器的权限和宿主系统同级没必要折腾宿主系统，进入openwrt是 ... 用usb转串口接到光猫然后用串口工具看看uboot启动时的日志，看看uboot是否正常载入内核和报啥错误。
最后于 2023-4-25 07:14
被微启宇编辑
，原因：
说一个另外的思路，从已有固件中获得内核版本，然后将cpio的文件系统放入内核源码，编译为zImage,然后和dtb一起制作成uImage，uImage就是系统uboot可引导的固件类型，这样也许就要替换uboot了。
我自己根据原版固件的版本通过源码编译的kernel制作成的zImage和uImage已经放在分享的云盘里了，这个zImage和uImage的rootfs里的/etc/init.d/rcS里的末尾加了一个自启的shell入口，即：/userconfig/init.sh，另外还加入了crond的服务器启动,配置路径也在/userconfig/crond。文件系统是基于原版固件的最新版本制作的，仅加了如下内容：if [ -x /userconfig/init.sh ]
then
/userconfig/init.sh
fi
crond -c /userconfig/crond编译后的数据放在了complie目录了。
最后于 2023-4-29 09:58
被XYUU编辑
，原因：
我自己根据原版固件的版本通过源码编译的kernel制作成的zImage和uImage已经放在分享的云盘里了，这个zImage和uImage的rootfs里的/etc/init.d/rcS里的末尾加了一个自启的shell入口，即：/userconfig/init.sh，另外还加入了crond的服务器启动,配置路径也在/userconfig/crond。文件系统是基于原版固件的最新版本制作的，仅加了如下内容：if [ -x /userconfig/init.sh ]
then
/userconfig/init.sh
fi
crond -c /userconfig/crond编译后的数据放在了complie目录了。
最后于 2023-4-29 09:58
被XYUU编辑
，原因：
如果有人能找到该固件通过使用数据库配置能启动busybox的crond服务的话，那也是极好的，至少能实现不少事情了，运营商的这种芯片的光猫市占率极高。
感谢分享
微启宇
中兴的光猫自带基于lxc容器技术的OpenWRT子系统你可以在里面折腾这个容器的权限和宿主系统同级没必要折腾宿主系统，进入openwrt是这个命令 `saf console` 进入密 ... 感谢分享，我的这个光猫实际上，只是用了中兴的芯片，里边的系统是被阉割过了的，所以是没有saf命令了，同时/opt/upt/framework/目录下都是空的，/opt/upt/apps/下也都是空的，折腾也是不得已。
最后于 2023-4-24 09:14
被XYUU编辑
，原因：
中兴的光猫自带基于lxc容器技术的OpenWRT子系统你可以在里面折腾这个容器的权限和宿主系统同级没必要折腾宿主系统，进入openwrt是这个命令 `saf console` 进入密 ... 感谢分享，我的这个光猫实际上，只是用了中兴的芯片，里边的系统是被阉割过了的，所以是没有saf命令了，同时/opt/upt/framework/目录下都是空的，/opt/upt/apps/下也都是空的，折腾也是不得已。
最后于 2023-4-24 09:14
被XYUU编辑
，原因：