分类目录归档:Hack Space

Protection against Message Forward in Objective-C

A Brief Review


Runtime is one of the powerful features of Objective-C, it provides us the ability to add/replace a method of some class, retrieve/set the implementation of a specified method, and even add a class in runtime.

However, just like the sunlight shines not only on the good guys, but also on the bad ones. There are some tools in iOS Jailbreak community which take the advantage of Objective-C's runtime feature, to be specific, the ability of message forward. Within this feature, they can log the calling sequence of the methods in the application for further exploitation. And it's not that hard to inject such tools into your application, since there are many ways such as DYLD_INSERT_LIBRARIES or modifying the MachO load commands, and they got some sets of tools like iOSOpenDev, and the new replacement of iOSOpenDev, MonkeyDev by @AloneMonkey.

And there're at least 2 tools which can log the calling sequence of the methods,

Hooked via forwardInvocation
Hooked via forwardInvocation

继续阅读Protection against Message Forward in Objective-C

iOS保护应用安全,拒绝forwardInvocation (╯°□°)╯︵ ┻━┻

在 iOS 逆向工程的论坛上看到了如何勾住一个类所有方法的帖子,然后基本都是用 Objective-C 里的 forwardInvocation: 来做的,例如

Hooked via forwardInvocation
Hooked via forwardInvocation

于是这里做了一个检测自己的类是否被这样给 hook 了的方法。

继续阅读iOS保护应用安全,拒绝forwardInvocation (╯°□°)╯︵ ┻━┻

玩玩咕咕机——将 WordPress 站点的评论打印到咕咕机上w

之前在空间里看见过同学发咕咕机的分享,那时还是第一代咕咕机,然后这几周在 @DIYgod 那边也看到了咕咕机,于是就入了一个来玩玩w

看着非常有趣的咕咕机,然后想自己在这上面折腾点啥东西,于是就有了这个 WordPress 插件,它可以将站点的评论打印到咕咕机上www

第一条打印出来的评论w
第一条打印出来的评论w

继续阅读玩玩咕咕机——将 WordPress 站点的评论打印到咕咕机上w

One simple means to defend Wi-Fi availability

前面写了 3 篇有关如何攻击 Wi-Fi 可用性的 post,于是这里也来简单的介绍一下自己所想的一个非常简单的、用于保护 Wi-Fi 可用性的思路。现实生活中的情况总是复杂的,不过个人认为下面这个思路在理论上来看是成立的(也或许实践中早有公司应用),没有过多的问题,当然这也有它自身的局限性,似乎还没有一个足够完美的方案(如果有的话,业界应该早就推广开了)。

我们已经提到过三种攻击,分别是 Deauthentication FloodBeacon FloodAuthentication Flood,这三种攻击都需要攻击者发送数量非常多的包才行。于是我们也可以反过来利用这一点。

FSPL From 2412 MHz to 2472 MHz
FSPL From 2412 MHz to 2472 MHz

继续阅读One simple means to defend Wi-Fi availability

IEEE 802.11 Denial-of-Service: Authentication Flood

这是另一个 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 建立连接了。

Authentication Flood
Authentication Flood

继续阅读IEEE 802.11 Denial-of-Service: Authentication Flood

IEEE 802.11 Denial-of-Service: Deauthentication Attack

使用 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 ... ...
Captured deauthentication packet
Captured deauthentication packet

继续阅读IEEE 802.11 Denial-of-Service: Deauthentication Attack

codesign_allocate 的 bug 依旧是个谜

昨天写的 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 目录)

codesign_allocate compiled with LTO support
codesign_allocate compiled with LTO support

所以我们什么都不用改,只需要把 Apple 开源的 cctools 中的 codesign_allocate 重新编译一下,问题就神奇的解决了。

不过 codesign_allocate 中的确是存在一处无符号整数溢出的问题,只不过几乎没有影响。

继续阅读codesign_allocate 的 bug 依旧是个谜

codesign --remove-signature 的 bug 解决

听说在 macOS 上使用自带的 codesign 来移除应用程序签名的话,会使得 MachO 文件变得不正常,于是就花了点时间来看看 codesign 相关的源代码。虽然有第三方的工具,自己也可以通过简单粗暴的改 MachO 文件来解决,但是探究问题具体出在哪里也很有趣。那么这里将以 Reeder 为例子(其实存在感不强233)讲述。

Malformed MachO After Removed Signature
Malformed MachO After Removed Signature

同样的,在前面我也列出目录,你可以直接跳到解决方案的部分。

继续阅读codesign --remove-signature 的 bug 解决