厂商型号：YR-CP100
主板版本：CP102-MAIN-V2.2
主要芯片：RG200U-CN V3MF-D10-DDC（移远通信）
其他硬件：塑料外壳，3根FPC天线（疑似5G/4G),2根WIFI天线。1个USB Type-C 接口，1个RJ45网线接口。
开盖后取下主板风扇可见各个模块及2个SIM芯片（预计为移动和电信）还有一个空SIM芯片引脚，以及一个没有引出接线位置的SIM卡槽标识位置。
固件备份
经过不懈努力终于在一众工具中找到了我能正常使用的备份工具。
除了spd_dump是可用的，还有SPRDC_Core也是可用的。但是这两个工具对本设备仍然有一些概率性的玄学问题，比如莫名其妙的信号灯超时时间已到报错。
备份分区表：
<?xml version="1.0" encoding="utf-8"?>
<Partitions>
<Partition id="prodnv" size="4" />
<Partition id="miscdata" size="1" />
<Partition id="recovery" size="16" />
<Partition id="misc" size="1" />
<Partition id="trustos" size="1" />
<Partition id="sml" size="1" />
<Partition id="uboot" size="2" />
<Partition id="boot" size="16" />
<Partition id="system" size="53" />
<Partition id="userdata" size="0xFFFFFFFF" />
<Partition id="nr_fixnv2" size="6" />
<Partition id="nr_runtimenv2" size="9" />
<Partition id="nr_pmsys" size="1" />
<Partition id="nr_agdsp" size="6" />
<Partition id="nr_modem" size="27" />
<Partition id="nr_v3phy" size="6" />
<Partition id="nr_nrphy" size="3" />
<Partition id="nr_nrdsp1" size="2" />
<Partition id="nr_nrdsp2" size="2" />
<Partition id="nr_deltanv" size="1" />
<Partition id="ubipac" size="248" />
</Partitions>
这个东西的价格和性能符合我的预期，到的第一天内置移动卡5G测速150Mbps下 50Mbps上，不过这个WI-FI性能就比较怪异了，特别是延迟极端的不稳定，插线用倒是完全没问题，跟手机USB网络共享的热点延迟一致。
简单逆向分析
通过hexdump查看分区镜像文件数据头部的魔数（Magic Number）为：DHTB
xfox@fedora:~/Dev/YR-CP100$ hexdump /home/xfox/Dev/YR-CP100/all_part_backup/system_payload.bin -C | head -5
00000000 44 48 54 42 01 00 00 00 00 00 00 00 00 00 00 00 |DHTB............|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000030 00 2e df 01 00 00 00 00 00 2e df 01 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
查询相关资料可以确定这是紫光展锐设备特有的DHTB分区格式Dynamic Hybrid Trusted Boot，根据已有信息，DHTB分区会把原始分区放置在DHTB数据头后。
直接使用ImHex编辑器查看整个system.img发现0x1000处出现了68 73 71 73 -> hsqs字样。
结合DS对hexdump回显的前几十行原始数据的分析：
根据你之前 hexdump 的结果：
在 0x30 处的值 00 2e df 01 (小端序为 0x01df2e00，约30MB) 很可能指示了**某个数据段的长度。**
在 0x1000 处出现了 68 73 71 73 (hsqs)，这很可能是**一个有效数据块的起始标志**，但它不是UBI格式。
因此，你的 system.img 结构很可能如下：
偏移量 0x0: DHTB 文件头 (包含长度等信息)
偏移量 0x1000: 某个数据块开始 (可能是压缩的映像，如 squashfs)
所以确定原始分区是一个基于Linux的SquashFS只读压缩文件系统，通过dd命令取出原始分区:
dd if=system.img of=system_payload.bin bs=4096 skip=1
SquashFS分区镜像可以直接挂载。
确定架构
cat /etc/os-release
ID=unisoc-initgc
NAME="unisoc-initgc-distro"
VERSION="udx710-module+unisoc-initgc-1.0+W25.38.5:10.52.14+user+native (sumo)"
VERSION_ID=udx710-module-unisoc-initgc-1.0-w25.38.5:10.52.14-user-native
PRETTY_NAME="unisoc-initgc-distro udx710-module+unisoc-initgc-1.0+W25.38.5:10.52.14+user+native (sumo)"
DISTRO_CODENAME="sumo"
从Yocto sumo的时间点看貌似是2018年的老版本了，Linux Kernel 4.14.98估计是厂商提供给开发者的SDK。
比较有趣的是，解包后里面开发者写的后台PHP代码基本上和安全俩字没什么关系，连我这个纯外行都能看出来有明显的漏洞，群友们表示尝试过修改镜像并刷回但是因为没有厂商提供的证书签名启动不了。
所以后续Crack完全没必要改来改去硬刷镜像，理论上可以通过Web渗透完成既定目的。
2026年1月26日，Got Shell！
昨天通过对后台PHP代码的查看确定了后台处于不设防的状态:
function quoteArgument($value) {
return empty($value) ? "'null'" : "'{$value}'";
}
function quoteArgument_int($value) {
return empty($value) ? "0" : "'{$value}'";
}
function execShell ($cmd) {
$result = shell_exec($cmd);
$json = json_decode($result);
if ($json->result === 0)
return "success";
else
return "error";
}
今天一通尝试，终于构造了post请求拿下了root shell，看/usr/bin有adbd看起来可以启用adbd.
/etc/init.d/下发现了adbd-init 当然，默认是没启用。
2026年1月27日
扒拉到/etc/usbenum/usbenum.ini
[machine]
machine=udx710-module
[property]
virtualcn=0
diag=1
log=1
debug=1
usbch=mode0
iq_vser=close
udc=29100000.dwc3
afterpowerloss=1
#virtualcn 0-rndis|1-ecm|2-ncm|3-mbim|4-8*AT|5-1*ecm|6-2*ecm|7-3*ecm|8-4*ecm|9-1*ncm|10-2*ncm|11-3*ncm|12-4*ncm|13-test
看上去我完全有机会使用USB cdc-ncm 替换RDNIS，当然...前提是能修改好镜像。
似乎可以通过overlay完成对SquashFS的写入存储？但是一改/etc/fstab就涉及现有鸡还是现有蛋的问题了，早于系统启动之前完成修改是不可能的，最终还是得诉诸于修改和重新打包刷入system镜像。