小众黑客会议 0x41con

会棍博主沉寂两月后重新上线。

上一次去蹭会是。之前有段时间差不多每个星期都换个国家玩，后来到了旅游旺季，听说全欧洲都在报复式出游。我感受到机场排队越发严重，懒得凑热闹，有段时间没敢坐飞机。

到了九月底又开始蠢蠢欲动，毕竟马上就《一觉睡到国庆节》了，重启会棍博主。

新冠沉寂三年后，第三届 0x41con 在希腊第二大城市塞萨洛尼基（Θεσσαλονίκη 或 Thessaloniki）召开。

0x41con 是一个颇具神秘感的小众技术会议，之前两届分别在罗马尼亚和荷兰。

0x41 这个数字本身无需过多的解读。我的理解是在做二进制安全研究的时候经常会随手构造一些输入，例如一长串 AAAAAAAAAAAA，对应的 ascii 编码就是一堆 0x4141414141。当程序触发崩溃的时候，通常就会在一些特定的寄存器看到这个数字。

所以当看到这一串这样的数字，要么是 base64 编码数据里填充了一堆 0，要么就是在调试二进制漏洞。也不是什么暗语。当然研究不同目标的人，有不同的兴奋点。假如是做浏览器 js 引擎漏洞研究的，可能就会对某些浮点数有 fetish。

这个会议的两位发起人分别是 iOS 安全研究社区很活跃的 argp 和 xerub。

xerub 来自罗马尼亚。他在 2018 年还来过上海，在 MOSEC 讲过一个关于 iBoot 的议题。

我没记错的话 _argp 来自希腊。最近的一篇署名演讲是 2019 年 CanSecWest 上对 iOS 沙箱和配置文件的逆向分析：

https://census-labs.com/media/sandbox-argp-csw2019-public.pdf

读者可能要奇怪了，我写了这么多铺垫，还没有开始进入发图片或者视频的环节，以证明我在会场到此一游？要不拾人牙慧，摘录一些议题的笔记也行。

从官网复制一段文字塞给 Google 翻译：

会场严格禁止拍照，所以题图是 MidJourney 画出来的。没想到吧？

小众会议还搞的很神秘，忍不住让人联想到库布里克的最后一部电影作品《大开眼戒》里的聚会——不不不，这是正经的技术会议。当然如果有像电影里那种神秘的聚会，请联系我～

不允许拍屏，大部分材料不会公开发布，意味着演讲者可以放飞自我，讲硬核的技术内容。在笔者心目中这个会议令人期待的指数仅次于。

虽然没有过多议题剧透，写一些不敏感的凑个数吧。

Johnathan Levin 这次准备了两个议题。第一天是关于 jtools 的更新和一些内核的新安全机制。

他说自己劝退 *OS 系统已经快三年了，除了一直在准备 Android 新书之外，对 Darwin 系统（也就是我们熟悉的 iOS / macOS 等）确实也感到有些疲倦。可是大佬的书 *OS Internals 系列是学习这几个系统安全机制的必备读物。我还在大学的时候就在看最老的那版 Mac OS X and iOS Internals: To the Apple's Core 1st Edition。大佬带头放弃治疗，就没资料可以看了啊……

Johnathan 经常会借参会的机会带他的书到现场，省去国际物流的麻烦。想找本人买书可以提前私信他预约。我本来对他的 Android 新书有些好奇，但觉得自己脑力有限，实在是没有精力再开新的坑了。想想还是算了。

有一篇关于 iOS 内核漏洞利用的议题 The First Dance（@f_roncari @jndok 和 @sferrini）将在数周后公布演讲材料，感兴趣的可以关注一下 kernel.rw。

此外一篇讲 LLVM 插桩无源码无符号二进制的议题，Coverage-guided binary fuzzing with revng and LLVM libFuzzer 有可能也会公开材料。

晚饭期间 Linus Henze 现场掏出手机演示了他的 fugu15 越狱，在搭载 iOS 15.4.1 的 iPhone 13 上跑了 Sileo。

由于这个版本从未发布过，第三方的插件还没有开始适配。这个八卦可以说，因为过几天在西班牙的 Objective by the Sea v5 会议上他将首次公开 fugu15 的技术细节。

我没拍照，无图无真相，权当我在吹牛吧。

想起另一件非常冷的笑话。前几个月我偶然听说一个关于各种车型的参数的网站 drivek.it，当时眼花看成 DriverKit，调侃了一下。

后者是 macOS 和 iPadOS 上新的编写设备驱动的接口，目的是减少第三方的内核扩展，而将设备驱动放在用户态运行，增加系统内核的稳定性和减少攻击面。

https://developer.apple.com/documentation/driverkit

然而新的代码更容易出现问题。Linus Henze 在 DriverKit 上刷了几个漏洞，并在 iOS 15 上实现了越狱。

Linus 看到我拿那个网站域名编段子之后，顺手把 driverk.it 域名买了下来。

技术人无聊的笑点……

下面开始游客照。

夜晚的海港吹着海风很闲适。

海边聚集了大量的餐馆和酒吧，非常热闹。

不过令我印象深刻的是这个城市的主路，建筑风格非常不“欧洲”。

甚至还出现了 LED 走马灯文字和灯箱，让我恍惚间有种回到祖国南部小城市的感觉。

题外话，更正一篇发了一年多的乌龙技术文章。

这两天在整理资料。为了满足考据癖重新分析了一些之前历史上出现过的案例，包括这篇去年发的 iOS Wifi 远程 0click 漏洞分析：

我发现我特么的写错了。

这篇文章讲的是 2021 年一个在网上引起热议的格式化字符串漏洞。手机只需要物理上接近恶意热点设备，就可以触发。文章的争议部分在于这个漏洞的可利用性到底如何。

其中提到我认为不可利用的一个理由是，runtime 的 lookUpImpOrForward -> checkIsKnownClass 会检查 isa 的有效性，是否满足如下三者之一^[1]：

类指针指向 dyld_shared_cache 的系统库的只读 data 段
类指针在全局变量 objc::allocatedClasses 里能找到
类指针指向可执行文件自身的只读 data 段

实际上 objc_msgSend 的利用并不需要走到 lookUpImpOrForward，而是直接利用方法缓存即可。因此在没有控制流完整性检查（如 PAC）的环境下，利用方式和之前针对任意地址 CFRelease 的案例^[2]大同小异。

关于方法缓存，展开说需要篇幅就太长了。有很多 iOS 开发者对这个细节进行过深入分析。

简单来说，在 NSLog 中使用 %@ 格式串，会将对应的参数当作 Objective-C 对象处理，首先发送一个 isProxy 消息，也就是等同于：

objc_msgSend(fakeobj, @selector(isProxy));

假设已经获得了随机化的地址偏移，算出来 isProxy 的地址，就可以在 fakeobj 上构造一个缓存结构，在 obj_msgSend 里实现任意地址跳转（即代码执行）。

ZecOps 通过特殊的设备让 objc_msgSend 的第一个参数完全可控，距离利用就还差：

找到一个内存位置，可以远程在可预测的地址上填入受控的数据（控制了 fakeobj 参数的地址，还差 fakeobj 的内容）
绕过 ASLR（用来获取 isProxy 这个 selector 的地址）

虽然以上两个条件尚不明确，但显然我之前关于 lookUpImpOrForward 的分析是错的……

[1]. 再说说之前的 iOS Wifi 漏洞
https://mp.weixin.qq.com/s?__biz=Mzk0NDE3MTkzNQ==&mid=2247483959&idx=1&sn=f7a23595fe77d4a34978ad6d1171f2fb

[2]. Attribution is hard — at least for Dock: A Safari sandbox escape & LPE
https://phoenhex.re/2019-05-26/attribution-is-hard-at-least-for-dock

[3]. Meet WiFiDemon – iOS WiFi RCE 0-Day Vulnerability, and a Zero-Click Vulnerability That Was Silently Patched
https://blog.zecops.com/research/meet-wifidemon-ios-wifi-rce-0-day-vulnerability-and-a-zero-click-vulnerability-that-was-silently-patched/