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

彻底覆写了Windows系统,换成了Fedora44,然后突然发现Fedora45马上就出了...

根据日志内容,定位到了一个处理报文相关的函数,对其中比较易懂的部分进行了必要的变量名还原和结构体修复:

QQ20261009-143106.png

QQ20261009-143120.png

QQ20261009-143135.png

QQ20261009-143149.png

可以看出这是一段构造,在构造一段request请求,并且会分为GET和POST两种方法;但我要找的是处理接收报文的函数。

不过,应用层协议往往是事件驱动模型,所以合理推测,这里在构造请求报文,属于发生事件后的前半部分,那响应报文的接收和处理应该就发生在这个函数的前半段或者它的调用者当中。

花了一些时间,理清了整个函数的结构:

while循环
{
    switch(handle_method)
    {
    case 0: 确定某个指针是否存在,存在就令handle_method为1,否则为7
    case 1: 通过getaddrinfo进行dns查询
    case 2: 请求报文构造
    case 3:
    case 4:
    case 5:
    case 6:
    }
}

该函数的参数是一个结构体指针,而handle_method是该结构体的一个字段。

case为1的伪代码:

QQ20261009-212428.png

QQ20261009-210136.png

可以看出这是通过getaddrinfo来进行地址结构体转换。

首先,需要确定这个程序在目前的运行路径下是否会执行到这一步,所以可以在整个函数开头下断点,看存储handle_method的寄存器X20存储的值:

QQ20261009-215256.png

QQ20261009-215312.png

QQ20261009-220137.png

QQ20261009-220206.png

QQ20261009-220222.png

观察到这个值变了五次,0->1->2->4->6,随后开始循环。

现在我们确定handle_method == 1是可达逻辑,并且对目前的历经路径有一个大概的印象:

该客户端令handle_method = 1,内部已经提前硬编码了IP - 110.43.0.83,调用getaddrinfo,把110.43.0.83:433这个地址转成addrinfo结构体的格式,接着令handle_method = 2,进行httpdns查询。

先对case1的每个错误判断下一次断点,确定它全程正常,就可以把它忽略掉去看case2了。

评论