前面写了 3 篇有关如何攻击 Wi-Fi 可用性的 post，于是这里也来简单的介绍一下自己所想的一个非常简单的、用于保护 Wi-Fi 可用性的思路。现实生活中的情况总是复杂的，不过个人认为下面这个思路在理论上来看是成立的（也或许实践中早有公司应用），没有过多的问题，当然这也有它自身的局限性，似乎还没有一个足够完美的方案（如果有的话，业界应该早就推广开了）。
我们已经提到过三种攻击，分别是 Deauthentication Flood，Beacon Flood 和 Authentication Flood，这三种攻击都需要攻击者发送数量非常多的包才行。于是我们也可以反过来利用这一点。
Continue reading One simple means to defend Wi-Fi availability
这是另一个 IEEE 802.11 攻击的方法，算上前面两篇
就收集齐了 IEEE 802.11 中最简单的三种可用性攻击。这三种方法不涉及任何密码学的东西，仅仅需要靠近受害者的网络范围，然后嗅探到几个包就可以开始攻击，并且足以让被攻击的人完全用不了无线网络。
这篇 post 中所描述的 Authentication Flood 与第一个 Deauthentication Flood 相对应。Deauthentication Flood 是强制让一个 AP 上、已经建立 association 的 STA 断开，从而达到目的。而Authentication Flood 则是通过伪造一大堆请求认证的包（其实还有 Association Flood，与这篇 post 中的方法相似），来塞满 AP 中的 Authentication / Association table，这样，真正的用户只能等到这个表有空 entry 的时候才能和 AP 建立连接了。
Continue reading IEEE 802.11 Denial-of-Service: Authentication Flood
这是另一种 802.11 攻击，或者说扰乱更合适。攻击者发出无数个 Beacon 帧，这些 Beacon 帧既可以是和你的 AP 拥有相同的 SSID，也可以是攻击者自定的 SSID，或者就是一些随机字符串，取决于攻击的目的和实际环境。
使用 WPA / WPA2 能让你的数据有更好的安全保障，但是攻击者可以利用基于802.11设计上的缺陷来对你进行拒绝服务攻击，也就是 deauthentication 攻击。攻击者首先需要知道你的 Wi-Fi 的 MAC 地址，然后伪装成你的身份给 AP (或者说路由器) 发送 deauthencation 包。这样一来，AP 在收到了来自“你”的 deauthencation 包之后，就会断开和你的连接。虽然仅仅是用这种方法并不能窃取到你的数据（结合其他方法有可能能破解 AP 的密码，但是不在本文的讨论范围之内），并且这个方法的目的也不是要窃听数据，而是让你连不上自家的 AP。如此一来，你也不得不拿出网线。而且不管你使用什么加密方式、密码强度有多高，甚至隐藏你的 SSID （毕竟隐藏 SSID 正如字面意义上的，它只是藏了 SSID，并不是隐藏了你和 AP 之间的数据包）都不行。
在 802.11 - 2012 标准 8.2.4.1.3 Type and Subtype fields 下面，列举了所有有效的 MAC 帧的 type 与 subtype 的组合，这里我们关注的 deauthentication 是 type 为 management 的帧。
| Type valueb3 b2 | Typedescription | Subtype valueb7 b6 b5 b4 | Subtype description |
|---|---|---|---|
| 00 | Management | ... | ... |
| 00 | Management | 1100 | Deauthentication |
| 00 | Management | ... | ... |
Continue reading IEEE 802.11 Denial-of-Service: Deauthentication Attack
昨天写的 codesign --remove-signature 的 bug 解决 一文中，在最末尾猜测了可能是 LLVM 的 LTO （link time optimaliztion）的问题，然后今天把 LLVM 的头文件下下来了，打开了 LTO 支持，发现也是可行的。这个就让人摸不着头脑了。不过上面提到的解决方法是没问题的。
如果想要打开 LLVM 的 LTO 支持的话，可以去 LLVM 的官网下载 Pre-built Binaries。比如现在的 LLVM Release 是 4.0.0，那么就下载Clang for Mac OS X。然后加上对应的编译选项 -I/PATH/TO/YOUR/clang+llvm-4.0.0-x86_64-apple-darwin/include（指定头文件搜索 clang+llvm-4.0.0-x86_64-apple-darwin/include 目录）
所以我们什么都不用改，只需要把 Apple 开源的 cctools 中的 codesign_allocate 重新编译一下，问题就神奇的解决了。
不过 codesign_allocate 中的确是存在一处无符号整数溢出的问题，只不过几乎没有影响。
听说在 macOS 上使用自带的 codesign 来移除应用程序签名的话，会使得 MachO 文件变得不正常，于是就花了点时间来看看 codesign 相关的源代码。虽然有第三方的工具，自己也可以通过简单粗暴的改 MachO 文件来解决，但是探究问题具体出在哪里也很有趣。那么这里将以 Reeder 为例子（其实存在感不强233）讲述。
同样的，在前面我也列出目录，你可以直接跳到解决方案的部分。
本来是想研究如何“简单”阻止 insert_dylib 注入的，但是好像并没有简单的方法，不过发现了一些 dyld 的东西，虽然目前来看似乎没有太大的意义，可是能拿到的东西肯定不是 dyld 想让应用拿到的。这篇 post 中的方法在 macOS 10.12.4 和 iOS 10.3.2 (14F5089a) 中均测试可行。
关于 iOS / macOS 中 dyld 如何初始化一个 MachO 的运行这里就不详细说了，在网上能找到这方面的一些资料。概要流程引用如下：
- 从 kernel 留下的原始调用栈引导和启动自己
- 将程序依赖的动态链接库递归加载进内存，当然这里有缓存机制
- non-lazy 符号立即 link 到可执行文件，lazy 的存表里
- Runs static initializers for the executable
- 找到可执行文件的 main 函数，准备参数并调用
- 程序执行中负责绑定 lazy 符号、提供 runtime dynamic loading services、提供调试器接口
- 程序main函数 return 后执行 static terminator
- 某些场景下 main 函数结束后调 libSystem 的 _exit 函数
那么在这篇 post 中，我们关注点是 2 和 4，并且主要在 4 上。
在看雪论坛上看到了某软件防篡改分析，不过我看到的时候那篇帖子已经删掉了内容。在写这篇 post 的时候发现有人贴上了原始的文章，某软件防篡改分析。
一开始自己在做绕过的时候，只是大概猜到有防注入的措施，但是没有细研究，而是选择了另一个方式，同样实现了 dylib 的注入，并且不需要修改主程序。
