前言

书接上回，由于我们学校实验室里正好用的是小米AX9000这款路由器，因此我就选了这款设备挖，也就没有对固件仿真了。既有女朋友又努力上进的ZIKH26师傅与我这个摆烂人不同，在复现我这个洞的时候，想要研究一下小米路由器的仿真模拟。正好最近我也没啥事，于是也就一起看了看。

恰巧前几天也有师傅私信我关于小米路由器该如何仿真的问题，并且网上目前似乎还没有师傅分析过小米固件的仿真，因此我就写了此文放了出来（所以，我说FirmAE是对某些固件特制的学术玩具会不会被打，逃）。

除了一些特殊的设备，其实对于固件的仿真模拟，总结成一句话就是：IoT设备的仿真过程就是不断地改报错，只要与外设硬件无关，都是小问题。也就是说，主要是要有耐心。

这里依然以小米路由器AX9000为例，小米其他型号的路由器也都可以用如下的方案仿真。在本文的最后，会用我们仿真模拟的路由器环境验证CVE-2023-26315这个漏洞。

环境配置

小米路由器AX9000相对其他一些型号来说，仿真稍微复杂一些，因为小米AX9000的固件是AArch64el架构的，而网上似乎还没有公开的AArch64的内核与文件系统。因此，我们需要自己装一个AArch64的虚拟机，并从中extract提取出内核与磁盘镜像。可参考这篇文章中的步骤完成。

我本人比较懒，装AArch64虚拟机很耗时间和内存，所以这部分是ZIKH26师傅提取的内核与磁盘镜像，在此表示崇高的敬意。

关于网络环境配置的问题，这里就不再多说了。只简单提一句，qemu-system-aarch64启动后，可以用ip addr看到enp0s1网卡是DOWN的状态，且没有分配IP地址。

因此，我们需要手动分配一个IP地址（与网桥br0处于同一网段即可，qemu的enp0s1接口与宿主机的eth0接口通过虚拟网桥br0转发数据），然后再将enp0s1网卡给UP启用即可，命令如下：

完成后，enp0s1网卡的状态应该正常了，再检测下qemu虚拟机与宿主机能否互相正常通信：

下面，就正式开始仿真模拟了。

起手式

将固件解压后，首先将文件系统用scp传入qemu虚拟机，然后就是最经典的三行起手式：

好吧，这一步我竟然还截了一张图：

根据openwrt的内核初始化流程，按理说应该先启动/etc/preinit，其中会执行/sbin/init进行初始化，但是在这套固件仿真的时候，这样会导致qemu重启，所以我们首先先执行/sbin/init中最重要的/sbin/procd &，启动进程管理器即可。

启动httpd服务

下面就该启动httpd服务了，简单检索一下，发现有uhttpd，mihttpd，sysapihttpd。进一步查看一下配置文件（如/etc/sysapihttpd/sysapihttpd.conf），发现sysapihttpd其实就是nginx，监听了80端口，有了nginx自然就不需要再启动uhttpd了。而mihttpd中监听了8198端口，定义了一些文件上传下载的API，可以暂时先不启。

所以，只需要启动sysapihttpd，执行/etc/init.d/sysapihttpd start即可：

首先，报错缺失/var/lock/procd_sysapihttpd.lock这个文件，这个创建一下对应的目录和文件就行了。接着，会报错Failed to connect to ubus，很显然这里是用到了ubus总线通信，我们需要启动/sbin/ubusd &。但是，接下来又继续报错usock: No such file or directory，但是并没有给出缺失哪个文件，因此我们需要将ubusd拖进IDA定位一下报错点。

很容易定位到sub_20B0函数，我们执行的是ubusd，而不是它的软链接tbusd，因此v8会是路径/var/run/ubus.sock，接着其作为参数传入usock函数中，当usock函数的返回值错误时，就会走到perror("usock")报错。

显然我们缺少/var/run/ubus.sock这个文件，创建后ubusd即可正常启动，接着sysapihttpd服务也启动成功（这里缺失/dev/nvram芯片可以先不用管，因为后续没有用到相关操作，暂时不用hook）：

到这里，检查一下进程里相关程序都已经挂起，且netstat查看web端口也正常对外开放：

崩溃&排查

虽然这一切看上去没有任何问题，nmap也能扫到端口，但是我们访问IP就会报错，显示服务器没有传回任何数据。

此外，查看进程，可以发现sysapihttpd的主进程进程号没变，但是子进程的进程号却已经改变，这就说明当我们访问IP的时候，server崩溃了，所以子进程crash了，主进程作为守护进程又开了个新的子进程。

因此，我们可以用strace跟踪一下子进程的进程号，判断出现了什么问题导致sysapihttpd会crash的。这里直接在外面的qemu文件系统中用apt或者dpkg安装一下strace_arm64的deb包，然后再ssh开个窗口跟踪进程即可。先attach上去卡住，然后访问IP后，strace跟踪的结果如下：

可以看到最后是发生了段错误导致了crash的。我们需要解决的是上面的三个报错，前两个错误都是由于缺少/etc/TZ文件所导致的，这是一个和时区有关的配置文件，echo "WAUST-8WAUDT" > /etc/TZ创建一下即可。

对于后面getsockopt的报错，我们可以将/usr/sbin/sysapihttpd拖进IDA，定位一下getsockopt参数一致（主要关注第三个参数是0x50）的位置，可以找到sub_1EDAC和sub_27570两个函数。至于是哪个函数中getsockopt调用的位置才是关键，结合strace上下文，根据上面调用了accept4系统调用，可以确定sub_27570函数中getsockopt的位置才是调用点。

根据上面的代码，结合strace后面输出的log报错信息，可以得知这里是由于getsockopt发生了错误，从而重定向到了0.0.0.1:65535，导致了后续的崩溃。因此，最简单粗暴的办法就是绕过这个if分支，不执行其中的内容，即将CBZ给patch成相反的CBNZ即可：

将patch后的sysapihttpd程序按照如下的步骤更新至固件的文件系统中，并重启httpd服务：

然后，访问IP并重定向至/init.html，可以看到路由器初始化配置页面终于是成功出现了：

跳过初始化配置

然而，由于我们只启动了部分服务，以及有部分配置与硬件相关，所以毫无疑问按照路由器初始化配置页面中的流程进行配置的过程中一定会出现各种问题。当然，我们仿真模拟的环境并不需要完整的配置，只是为了验证或调试漏洞而已，所以我们也没必要折腾这部分，直接跳过就行了。

我们通过grep在固件文件系统中查找是在哪里重定向至/init.html的，很容易定位到/usr/lib/lua/luci/view/web/sysauth.htm文件：

其中，相关代码如下：

这里最简单粗暴的办法当然就是将这几行都注释掉，这样虽然的确可以跳过初始化配置，但是在之后漏洞验证的时候会出点小问题，留到后文再说。

我们这里还是更优雅地想办法去满足这个if判断的条件，使之不重定向至/init.html。根据这里调用的函数，很容易定位到如下代码的调用关系（这里的源码来自于小米路由器4 Pro 稳定版，这个版本的Lua源码没有编译，小米各个型号路由器的Lua部分变化不大，源码当然比反编译出来的伪代码好看很多）：

很容易弄清这里的逻辑，只需要按照如下命令设置uci配置项，标记为已初始化即可：

uci set设置后，再次访问IP，即可绕过初始化配置，跳转至登录页面：

设置登录密码

由于我们跳过了初始化配置阶段，并没有设置路由器后台的登录密码，且我们需要验证的CVE-2023-26315是一个授权认证后的漏洞，因此我们需要设置登录密码以登录进后台拿到token的值（当然，上文说过有些型号的设备固件中Lua是没有编译的源码，因此也可以拿这部分源码把相关API改成未授权的，然后用固件里自带的/usr/bin/luac编译一下替换即可，但这样确实太暴力了）。

上篇文章提过，身份校验的过程在/usr/lib/lua/luci/dispatcher.lua的jsonauth函数中，其中调用了checkUser函数根据从POST报文中获取的username，password和nonce（现时）字段进行身份验证。

在/usr/lib/lua/xiaoqiang/util/XQSecureUtil.lua的checkUser函数中，首先获取了系统uci配置项中存储的密码，这里的XQPreference.get函数在本文的上一节中已经给出，可分析出此处的配置项为account.common.(用户名)。接着，需要POST报文中传入的现时字段nonce与系统中uci存储的password的值拼接后进行sha1哈希的结果等于POST报文中传入的密码字段。

因此，接下来，我们需要确定POST报文中传入的密码和用户名字段是什么。很显然，POST请求报文中的密码字段不可能是明文的形式，不然随便拦截一下就寄了。故而，一定会有相关的JavaScript代码对用户提交的密码进行加密（哈希）后再进行传输。所以，可以直接在浏览器登录页面中，查看一下相关的web代码：

可以看出，报文中的用户名字段固定就是admin，而密码字段是通过oldPwd()函数加密后的结果。这里的oldPwd()函数将用户提交的密码明文与一个固定的key值（a2ffa5c9be07488bbb04a3a47d3c5f6a）拼接后，进行sha1哈希，再将结果继续与现时nonce拼接后，再sha1哈希一次，作为POST请求报文中的密码字段。

结合上述分析，我们需要将account.common.admin这个uci配置项设置为sha1(登录密码+key)，比如说登录密码设置为winmt，那么这个值就是sha1(winmta2ffa5c9be07488bbb04a3a47d3c5f6a)=b264db0fca361ef8eca919fa28e70d7a57d4c2db。

可通过如下命令set设置uci的配置项：

设置好account.common.admin这个uci配置项后，用设定的密码winmt即可成功登录入路由器后台：

此时，token值为789c292990be8ca7d36947145aaea700。

一个小插曲

在“跳过初始化配置”一节中，提到过：如果将sysauth.htm中重定向的if分支都注释掉的话，在后面进行漏洞验证的时候会出现一些问题。具体来说，是当访问/api/xqdatacenter/request这个API的时候，会出现503报错。

下面来分析一下这个问题的成因。

在/usr/lib/lua/luci/controller/api/xqdatacenter.lua中，对于/api/xqdatacenter/request这个entry{}没有设置第五个参数与权限有关的flag位：

具体在/usr/lib/lua/luci/dispatcher.lua文件中，可以看到entry{}的相关定义：

同样是在/usr/lib/lua/luci/dispatcher.lua文件中，其内的dispatch函数中对API作了最顶层的权限校验（sysauth_authenticator内的函数等各种模式是在其中被调用做进一步验证的）。在dispatch函数中，有一段如下代码：

其中，_noinitAccessAllowed函数的代码如下：

综上，也就是说只有getInitInfo()函数的返回值为true或flag位为0x08，才能绕过这个_noinitAccessAllowed的校验，不然就会报503错误。

这里的getInitInfo()函数我们已经不陌生了，在“跳过初始化配置”一节中出现过，也就是xiaoqiang.common.INITTED这个uci配置项。这样也就解释了为什么在处理sysauth.htm中重定向的if分支时，还是最好设置一下相关uci配置项。当然，直接找一份xqdatacenter.lua的源码，在对应entry{}中加上flag位0x08，再用固件自带的luac编译后替换一下也是可以的。

验证漏洞

接下来，我们完成本次仿真模拟的最终目的：验证CVE-2023-26315这个漏洞。根据我上篇文章中的分析，想要完成此漏洞的验证，还需要启动datacenter以及plugincenter，命令如下：

启动后，可能会有一些报错，但并不影响，netstat查看9090和9091端口正常即可：

最后，跑一遍exp即可成功拿到shell，漏洞验证完成：

完结撒花，Are You OK？