nft指令快要忘光了，今天用之前又现复习了一小时。

发现我一直在给同一个结构体改名字，在http_resp_frame_helper和http_req_frame_helper之间游移不定，但其实应该还是前者更合理一些。

目前已知的是，当它开始第一次连接时，它会先走httpc_connecting，然后走httpc_req_head_sending和httpc_req_body_sending发一个get请求，随即进入httpc_resp_head_recving,并根据某字段进入了一个分支，在该分支下，如果收到的请求行是“HTTP/1.1 200 OK”，它就先用httpc_disconnecting把连接关掉，关起门来判断读取的报文和目前的缓冲区指针哪个大，然后根据结果去判断继续读还是File done。

但关键问题在于，它具体是如何解析的，是由某结构体里的函数指针所指向的函数进行处理的，正常走根本抓不到：

恢复结构体彻底陷入了瓶颈，所以我不得不尝试脱离纯粹的静态分析，抓一些除了400响应码以外的其他报文。

这时候之前搭建的局域网就派上用场了。

虽然它是硬编码了ip,但事实上，如果我通过ARP广播进行欺骗，伪装成一台网关，让它把报文发到这个网关，并且利用nft修改转发规则，就可以让明文的http流量经过攻击机，并到达除了小米云以外的服务器，这时我就可以用那台服务器起一个http服务，自己伪造响应报文观察它的反应。

使用一台kali虚拟机来完成这一过程：

首先启动bettercap中间人工具，通过probe和show证明两台虚拟机之间相互可达。
，随后设置为双工模式，开始发起ARP广播。

在小米设备的虚拟机上通过ip neigh查看ARP的缓存情况，发现192.168.122.1（网关）的Mac地址已经和192.168.122.251（kali）一样，证明ARP欺骗生效。

用nft建立一个表，分别在prerouting钩子挂一个dnat链，在postrouting钩子挂一个snat链，前者负责把受攻击设备的数据包的dst改成个人服务器的ip,以此保证路径被篡改；后者负责把数据包的src改成kali自己的ip,负责保证回来的报文可以正常根据NAT规则表返回。

成功劫持：

随后我在自己的服务器上开了一个python的http.server：

成功了，不过返回去的是404 Not Found,所以有必要放一个get请求的同名文件，看看能否返回200。