小米IoT私有协议的漏洞挖掘尝试(八)

无符号的程序,还是尽量从日志下手。*

gdbserver的效果不太理想,哪怕是一台qemu-system虚拟机,也完全不支持硬件watch调试。

我又传了一个静态编译的strace进去,同样收效甚微。

最后还是靠着观察日志,终于找到了这个状态机的收发函数。下面是较为完善的状态机:

while循环
{
    switch(handle_method)
    {
    case 0: 确定某个指针是否存在,存在就令handle_method为1,否则为7
    case 1: httpc_connecting
    case 2: httpc_req_head_sending
    case 3: httpc_req_body_sending
    case 4: httpc_resp_head_recving
    case 5: httpc_resp_body_recving
    case 6: httpc_disconnecting
    }
}

对http_connecting进行处理:

QQ20261017-094017.png

观察到它主要根据field20这一int类型的变量来决定是否走tls_open,所以dbg在此下断点:

QQ20261017-094007.png

然后直接把这个x0寄存器改成1,观察它内部发生变化的几个变量:

QQ20261017-095314.png

QQ20261017-095351.png

QQ20261017-095416.png

结果发现,field18这个变量被赋值了一个指针,位于rodata区域,IDA里跳转过去,发现正好是之前研究过的那份证书。

但是tls_open内部是一个比现在这个http处理更为复杂的状态机,并且几乎没有任何日志字符串可供提示,逆向会花费更多的精力,不过还是可以依靠它恢复一些结构体。

评论