本文仅用于个人学习与技术研究，不涉及任何商业目的。目标软件为闭源系统，本文分析仅为静态学习，未进行任何侵权或破解行为。作者不承担任何使用后果。

前不久在二手市场从网工老师傅手里拿到了华为的产品固件，最近终于有时间分析一下了。

AR502H-V2是华为的一款功能强大的边缘计算物联网关，基于ARM架构，能满足多种恶劣条件和工业领域。

查了一些官方文档，声称该设备有两套系统，分别是华为自研的VRP系统和标准debian OS，前者用于正常的路由转发以及网关功能，后者可以运行一些容器，用于数据采集，边缘计算。

先对它进行binwalk扫描，掌握一些基本信息：

结构大概是：uImage header，kernel，DTB设备树，然后一堆看不懂的证书，squashfs文件系统，然后又一堆证书。

看起来还好，让binwalk自己提取一下，这里使用preserve-symlinks这个选项，如果直接使用binwalk解包，binwalk为了安全估量，会把里面的大量软链接指向/dev/null，但实际上这反而会造成很大麻烦。

留意一下之前binwalk扫描出来的内核，这里直接用dd手工操作把它切出来，里面有两个xz压缩的东西，正好之前binwalk的解包有残留的xz，这里直接用file和hexdump查一下文件情况。

第一个1F868.xz声称是一个xz文件，hexdump扫一下就全露馅了，纯纯一个普通字符串，看起来是某个描述，这个7zXZ被binwalk当成魔数扫出来了。

第二个20728偏移的是一个货真价实的xz文件，普通xz -d会显示文件损坏，这里也是直接用binwalk把它强行解压出来了，得到一个内核。

前两次dd切出来的文件，如果hexdump会发现有一些PE，ARMd之类的字符，这里就不放图了，问了一下AI，大意是，该文件开头一直到20728这个偏移处，可能是一个用来适配UEFI的壳子，这个20728才是真内核。

先扫了一眼inittab，rc.d和rcS，没什么用，基本全是无效初始化，在init.d里找到了一个README，确认这是systemd体系，不是init体系。

这里简单介绍一下systemd体系和init体系，后者是古早linux和传统嵌入式linux的启动方案，大概就是内核执行到边界处把控制权交给init，init拉起一个pid为1的进程，然后根据inittab上的条目一条条执行初始化，中间路过一个脚本叫rcS，rcS负责启动rc.d目录里的所有程序，而rc.d里的程序大概分成两类，一类是S开头，表示启动服务，一类是K开头，表示结束服务。比如很典型的程序名就叫S50nginx,也就是启动时，第50个被启动的服务nginx。而这个init就作为daemon一直存在，收养各种子进程。

systemd跟它略有相似之处，这个systemd同样是一个pid为1的父进程，功能和init很接近，但它尝试启动时，会先去/etc/systemd/system目录下读取default.target或者multi-user.target，根据它的依赖（Requires）和期许（wants）去启动各种新的service或者target，最后完成初始化。

（这里涉及到unit的知识，target，service等等都属于unit，其中，target就是“目标”，可以把wants目录看成是一个清单，里面存着service和timer之类的unit，也就是清单上的条目；而target就是一项工程，systemd就是这个工程的负责人，它根据清单去启动所有unit，来完成这项工作。）

确定是systemd后，先去/etc/systemd/system目录看一眼，但是并没有想要的东西

不过没关系，这里补充一点，系统会按照/etc/systemd/system -> /run/systemd/system -> /usr/lib/systemd/system或者/lib/systemd/system的顺序寻找default.target或者multi-user.target，这里也是在/lib下找到了：

直接一路盯紧Requires条目，追踪下去：

但是，到sysinit.target这里，Requires就断掉了，因为系统的初始化基本上已经结束了，但是并没看到任何网络服务，就连sshd都没被启动。

当时在这里卡了好久，然后突然想起这个固件应该还有一个VRP才对，尝试find了一下，结果就有了意外收获：

/mnt下挂载了一个名为squash的目录，里面有一套完整的类linux目录，不过bin,sbin这些都是空的，只有etc，lib这些目录里面存储了很多文件，最关键的就是那个change_to_vrp.sh的脚本，开头第一句注释就是chang iot to vrp，然后又连着执行了几十个insmod加载ko模块，显然是在进行从“debian”到“vrp”的切换。

我原本的预想是，这东西声称自己有两套系统，可能是两个内核，两套根文件系统，但下载的固件扫完只有一个内核，原以为是固件不完整，但这么一看，更像是两个OS共享同一个内核，通过挂载来进行访问，类似WSL和windows的关系，wsl把C盘，D盘“挂载”到自己的/mnt下；不过区别在于，WSL是有完整内核的，这里这个VRP是直接粗暴地把自己的内核模块植入进debian了。

在/mnt/squash下找*.wants目录，结果在etc下找到一个multi-user.target.wants：

而/mnt/squash/lib下也找到了跟wants完全匹配的service，并且几个软链接都直接指向/lib/systemd/system下的service，印证了之前的判断：vrp系统的启动很可能直接复用了debian的service甚至target路径。

（这里我想过另一种情况，即启动debian时，vrp挂载到mnt/squash下，启动vrp时，debian挂载到mnt下，但是vrp的/bin和/sbin的都为空，我想它很难作为独立的根文件系统启动，除非这个固件不全）

但CSDN上有说法称这个AR502H默认启动的是VRP系统，这里我不太确定，因为是跑在虚拟机上，手里也没有板子，肯定大量硬件缺失，qemu-system大概率跑不起来，所以暂时无法证明，只能猜测，在内核态末期可能会校验某个flag，根据flag判断是否需要执行chang_to_vrp.sh或者跟它有相近逻辑的指令，直接进入VRP系统

而之前的find . -name "vrp"时还在mpu目录下发现了一个名字就叫vrp的程序：

体积足足有168M，strings了一下，发现真有html和cgi的相关字符，所以，这东西可能是一个有虚拟路径，混杂了前端逻辑的守护进程，专门跑web服务。

先到这里，最近半个月可能没时间弄了，后面继续更新。