wifi芯片研究

Author： Crystal

2018/1/5

0x00：细节研究

细节一

ASLR和DEP

首先研究wifi芯片漏洞作为突破口，是因为手机对主应用处理器做的保护已经比较难实现攻击了

细节二

由于对电源的考虑导致设备设计人员选择应用 FullMAC WiFi 实现方式，这样 WiFi 芯片是自行负责处理 PHY，MAC 和 MLME ，并自行传输准备好的内核驱动程序数据包，这也就是说 WiFi 芯片是会自行处理可能被攻击者控制的数据输入。

在选择攻击面的考虑时，还有一个因素影响了我们的选择。在博通芯片上进行测试的时候，我们欣喜地发现，它不受 ASLR 保护，而整个 RAM 都有 RWX 许可——这意味着我们可以在内存中的任何地方进行读，写和运行代码的操作！==但是在 Shannon 、联发科技、以及高通的基带中存在 DEP 机制的保护，所以相对而言，更难进行漏洞利用。 ==

这一点结合之前的研究难点来看，我们需要处理的部分是找到wifi芯片向内核驱动程序传输数据包的过程，以及传输完后怎么在内核驱动中执行。这一点来看，确实需要wifi内核驱动相关的知识。

细节三

在不算特别详尽的研究中，我们发现以下智能手机的型号使用的是博通的 WiFi 芯片：

部分三星 Galaxy 系列的 S3 至 S8
所有三星 Notes 3，Nexus 5, 6, 6X 和 6P
所有 iPhones  5 之后的型号

芯片的型号则是从 BCM4339 到 BCM4361型号。

芯片固件的逆向工程和调试相对简单，因为每次芯片重制后的主 OS 都将未加密的固件二进制程序加载到芯片的 RAM 中，由此，只是通过手机系统的简单搜索就足以定位博通固件的地址。但如果在 Linux 内核上，这样的路径通常会在配置的变量 BCMDHD_FW_PATH 中定义。

我们之后又发现了另一件让人高兴的事情，固件上并不会对完整性进行检验，==也就是说攻击者可以轻松地对原始固件进行修改，添加 hook 进行打印输出调试或者其他行为修改，甚至修改内核来调用我们自己的固件。我们在研究的过程中就经常地放置 hook 并观察系统的行为（更有趣的是系统的不正常行为）。 ==

这一块，调试wifi驱动，最简单方式。给一点建议。开发驱动着手有可能会走很多弯路。

细节四

这个系统的奇怪之处在于，大部分代码都是在 ROM 上运行的，大小为 900 k。而后续的更新都是存放在 RAM 中的，也占 900 k 的大小。在执行更新或修复的时候，在 RAM 中会有一个附加的 thunk 表，然后在执行的特点位置进行调用这个表。如果有错误需要进行修复，则可以对 thunk 表进行重定向指向新代码。

这个问题之前在问题单里也有提出，然后这次可以根据这个思路，再分析一下RAM固件。

细节五

将 BCM43xx 视为 WiFi 片上系统（SoC）应该是正确的，因为这里有两个不同的芯片在处理包数据。主处理器 Cortex-R4 在将收到的包数据交给 Linux 内核之前，会先处理 MAC 和 MLME 层的数据==；但使用专有博通处理器架构的单独芯片则可处理 802.11 PHY 层。==SoC的另一个组件是应用处理器的接口：早期的博通芯片使用的是较慢的 SDIO 连接，而 BCM4358及更高版本使用的 PCIe。

这部分的话我们研究的是BCM4358

最有用的资源则是 VMG-1312 的源代码，VMG-1312 也是使用博通芯片组的路由器，虽然这个产品早已被人们遗忘。尽管之前的 brcmsmac 驱动中包含博通开源使用在 Linux 上的代码，但在 VMG-1312 中居然包含有博通专有的闭源代码，可以看到代码上标注了 “这是博通未公开的专有源代码” 警示信息。显而易见，这是博通代码不小心混在 VMG-1312 源码中错误公开了！

这些泄露的代码片段包含我们在固件 blob 中找到的大部分功能。但这部分还是有些过时，没有包含最新的 802.11协议的相关处理方法。但我们找到的这部分对于此次研究已经非常有用，主要的数据包处理功能并没有发生大的变化。我们==通过将源代码与固件进行比对，能够快速地获取数据包处理代码部分的整体概念，==帮助我们寻找到值得关注的代码区域，并将关注点移到下一个阶段上——如何找到合适可用的漏洞。

这部分需要关注的是在研究固件的基础上把数据包处理流程梳理出来。

0x01：细节研究

细节五：数据包处理流程

先找到固件中的漏洞位置，如下代码所示，有几个关键的数据帧标志类型。根据数据帧的类型在 VMG-1312 的源代码定位到处理这部分数据包的代码。

frame_type = *(unsigned __int16 *)(arg + 8);  // arg->frame_type
  cfg = *(_DWORD *)(arg + 4);                   // arg->bsscfg
  v4 = wlc;
  ie = *(_DWORD *)(arg + 0xC);                  // arg->ie
  current_wmm_ie = *(_BYTE **)(cfg + 0x354);    // cfg->current_wmm_ie
  if ( frame_type == 0x20 )                     // FC_REASSOC_REQ = 0x20 重新关联请求帧
    goto LABEL_9;
  if ( frame_type <= 0x20 )
  {
    if ( *(_WORD *)(arg + 8) )
    {
      if ( frame_type != 0x10 )                 // FC_ASSOC_RESP  = 0x10  //关联帧 
        return 0;
      goto LABEL_15;
    }
    ...
    ...
    ...
    if ( frame_type != 0x30 )                     // FC_REASSOC_RESP = 0x30 重新关联响应帧
  {
    if ( frame_type == 0x80 )                   // FC_BEACON = 0x80 信标帧
    {
      v16 = **(_DWORD **)(*(_DWORD *)arg + 0x1C);
      if ( *(_DWORD *)(*(_DWORD *)wlc + 0x34) )
      ...
      ...
      ...

总共定位到两处位置一处应该是发送数据包的过程在 1）首先发送探测请求帧

细节四：thunk表问题

应该是thunk技术的传名调用。

root

google nexus 6p 7.0 root 参考：链接：http://bbs.gfan.com/android-8330379-1-1.html

0x00：细节研究

0x01：细节研究

猜你喜欢