综上所述，为了在Wi- Fi上设置代码，我们需要：
1.从无线网络中读取要检测的存储区域。
2.使用反编译它。
3.写修复代码，用它修复内存中的固件，调用检测自定义例程的结构。
4.将这些结构、特定补丁代码、存根和用户定义的例程复制到无线网络。
5.在挂钩例程的帮助下，使用常规固件API调用该例程来执行补丁。驱动很少调用这个固件函数。这将确保我们可以安全地禁用中断处理和进程检测。
6.检测工具收集必要的运行时信息后，使用固件/驱动程序功能访问无线存储器，并从无线存储器复制结果。
值得注意的是，这种类型存在一些微体系结构()问题，因为我们新的BL调用覆盖了Wi-FiSoC上的指令。因此，在I/D-Cache缓存不一致的情况下，我们可能会丢失一些结果(有些调用可能不会执行，因为来自I-cache的旧的原始指令仍然有效)。我们怀疑原因是固件在初始化后锁定ARMCP15协处理器寄存器进行写入。因此，在Wi-FiSoC上刷新I-cache并不容易。还有一种技术是研究Wi-FiSoC内部的，就是静态固件插装。但是，它需要每次都重建无线固件，以应用新的分析负载。启动检测到的固件还需要重新启动设备。这里有几种类型的DBI工具可以提供帮助：
1.可以在函数参数中搜索签名的工具(如BSSID或MAC)；
2.可以收集关于调用栈信息的工具(这些信息可以帮助逆向工程或固件模糊测试)；
3.可以监控ThreadX块池状态的工具。
所有这些工具都为我们提供了代码处理框架的信息，因为我们可以用不同的客户端二进制文件定制DBI工具。在没有源代码和任何后向提示(如记录字符串、导出的函数名)的情况下，这是一大进步。在将这种类型的动态分析应用于运行的固件之后，我们可以知道哪些函数用于解析输入帧和参数，并将输入数据传递给这些函数。之后，可以使用许多类型的二进制分析和漏洞搜索技术。
第五，寻找漏洞
虽然我们在固件内存转储和Wi-FiSoC中采用了各种类型的二进制分析(包括静态和动态)，但是仍然很难搜索到漏洞。
5.1模糊测试
目前，似乎只能使用两种类型的模糊测试：
1.无线随机模糊测试；
2.仿真环境下固件的模糊测试。
第一种模糊测试可以直接在Wi-FiSoC上进行。一般可以利用处理器本身的功能包括JTAG、ARMETM或IntelProcessTracing技术来达到收集边缘覆盖的目的。但是这个过程也需要芯片本身的硬件支持和硬件黑客的一些知识储备，这样硬件调试功能才能在生产环境的设备中使用。这是一项非常重要的工程任务，盲目进行模糊测试是非常愚蠢的。接下来我们来试试第二种。第二种模糊测试依赖于固件模拟，因此在一些反馈驱动算法的帮助下，收集突变输入的边缘覆盖相对容易。这实际上是对无线设备的SMART模糊测试。这可能令人惊讶，但允许我们以这种方式进行模糊测试的工具已经被淘汰了。因此，我们可以使用一个混合了原来AFL模糊工具和独角兽CPU模拟器的工具，命名为afl-unicorn，最初是NathanVoss写的。我们可以查看相关文档了解它是如何工作的，包括混淆任意代码的方法和CGC二进制示例。因此，要使用afl-unicorn工具对Wi-Fi固件进行模糊测试，我们需要识别解析例程(例如，使用Wi-Fi DOCBI工具)，并编写一个模糊工具将MutatiedInput(Wi-Fi框架)输入到这些例程中。一般来说，模糊工具应该做到以下几点：
1.用独角兽的修改版映射必要的内存区域；
2.设置寄存器上下文；
3.读取更改后的输入文件，并将其映射到模拟器内存；
4.开始执行代码；
5.通过发送特定信号模拟固件崩溃。
这似乎是一种简单有效的技术，但仍有一些缺点。最值得注意的是对全局状态的依赖，这是在创建Wi-FiSoC内存转储时捕获的。这个状态可以包含一些保存的全局变量，这些变量可以组织模糊工具来访问一些执行路径。因为没有动态内存访问清理，所以很难找到并删除校验和验证码。此外，RTOS任务之间的通信无法实现，因此这也将阻止一些潜在的有趣的执行路径。然而，使用这种模糊测试技术，仍然有一些结果：
相关阅读
版权声明：内容来源于互联网和用户投稿 如有侵权请联系删除
标签： #查询最新动态链接超时