之前在空间里看见过同学发咕咕机的分享,那时还是第一代咕咕机,然后这几周在 @DIYgod 那边也看到了咕咕机,于是就入了一个来玩玩w
看着非常有趣的咕咕机,然后想自己在这上面折腾点啥东西,于是就有了这个 WordPress 插件,它可以将站点的评论打印到咕咕机上www
之前在空间里看见过同学发咕咕机的分享,那时还是第一代咕咕机,然后这几周在 @DIYgod 那边也看到了咕咕机,于是就入了一个来玩玩w
看着非常有趣的咕咕机,然后想自己在这上面折腾点啥东西,于是就有了这个 WordPress 插件,它可以将站点的评论打印到咕咕机上www
前面提到的方法都需要发送大量的数据包,而这篇 post 中的方法仅需要嗅探再加上少量的包就可以实现对使用 WPA / WPA 2 的用户进行攻击,使受害者无法连接上 AP。这种方法即 RSN IE Poisoning。
Continue reading IEEE 802.11 Denial-of-Service: RSN IE Poisoning
前面写了 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 的注入,并且不需要修改主程序。