Apple Cuts Mac Bounty Payouts, Driving Researchers to Exploit Brokers

苹果大幅削减Mac漏洞赏金，促使研究人员转向漏洞经纪商 苹果大幅削减macOS漏洞赏金并推行严苛的漏洞提交分类审查，正促使独立研究人员放弃协调披露机制，转而将内核漏洞直接出售给私人漏洞经纪商。 Josh Stroschein与Datadog安全工程师Olivia Gallucci深入探讨了macOS内核机制，将苹果面向对象的IOKit驱动程序框架与传统Linux驱动程序进行了对比。他们剖析了内核驱动程序中虚函数表（Vtable）劫持和释放后使用（UAF）漏洞的工作原理，随后分析了指针身份验证码（PAC）以及通过kalloc_type进行类型化内存分配等现代缓解措施。随后，对话转向威胁趋势，探讨了尽管恶意软件缺乏复杂的混淆技术，但加密货币财富如何刺激了蓬勃发展的macOS信息窃取程序市场。最后，他们讨论了PAC崩溃监控的遥测优势、AI在分析庞大代码库中的作用，以及导致研究人员放弃苹果官方赏金计划而转向第三方漏洞经纪商的巨大收益差距。 与Linux纯C语言内核不同，macOS严重依赖IOKit这一面向对象的C++驱动程序框架；历史上，在偏移量为零处篡改多态Vtable可实现完整的内核执行劫持。 (0:30) 苹果已通过现代芯片级防御措施瓦解了传统的Vtable劫持，主要包括指针身份验证码（带有加密加盐机制的PAC-IA和PAC-DA）以及通过kalloc_type实现的类型化堆桶隔离。 (10:00) macOS威胁态势目前由轻量且通常未加壳的加密货币信息窃取程序主导，这些程序完全绕过了内核漏洞利用，转而采用如ClickFix等社会工程诱饵。 (22:15) 苹果在2025年10月对漏洞赏金架构进行的调整，将单个macOS漏洞奖励大幅削减至约3,000美元，促使研究人员投向美国第三方经纪商，后者为Mac漏洞提供3万至5万美元，为iOS完整利用链提供高达1,300万美元的报酬。 (45:00)

Security researcher Olivia Gallucci explains how Apple's hardware-enforced mitigations like Pointer Authentication Codes (PAC) have reshaped macOS kernel exploitation into telemetry generation, even as a surge in simple, user-space infostealers and skewed bug bounty economics alter the broader threat landscape. Kernel Architecture and C++ Vtable Hijacking (0:30) Gallucci refutes the notion that macOS functions identically to Linux under the hood, pointing to the structural divergence in driver management. While the standard Linux kernel relies on traditional C, macOS uses IOKit, an object-oriented device driver framework written in a restricted subset of C++. Although stripped down to lower bug density, IOKit remains reliant on polymorphism, where dynamic runtime dispatch relies on virtual method tables (Vtables). In classes lacking a primary base class, the pointer to the virtual table (`vptr`) sits at offset zero of the object, creating a target where corrupting the first machine word redirects indirect branches to execute code at full kernel privilege. Exploitation traditionally relies on three primitives: temporal memory corruption such as use-after-free (UAF), out-of-bounds writes, and heap shaping. Canonical examples include Brandon Azad's 2016 exploit against `OSUnserializeBinary`, which leveraged a malicious serialized dictionary and heap grooming to hijack `virtual retain`, and RET2's 2021 Intel Graphics exploit, which used an out-of-bounds write to redirect `taggedRetain`. Both demonstrated how stale or manipulated references allowed attackers to direct execution straight into forged Vtables. Silicon Defenses, PAC, and Telemetry Generation (10:00) Modern Apple hardware neutralizes classic Vtable hijacking through Pointer Authentication Codes (PAC) alongside allocator hardening via `kalloc_type`. PAC cryptographically signs pointers, applying instruction-address (`PAC-IA`) signatures to Vtable function targets and data-address (`PAC-DA`) signatures combined with cryptographic salts to Vtable pointers. If an attacker tampers with a pointer or lacks the valid execution context, the signature validation fails, immediately halting execution. Simultaneously, `kalloc_type` isolates heap allocations into typed buckets, preventing attackers from populating freed C++ object slots with generic sprayed buffers. From a defensive engineering perspective, Gallucci notes that PAC transforms silent exploits into loud, detectable telemetry. Failed authentication triggers an `EXC_BAD_ACCESS` error with the `KERN_INVALID_ADDRESS` subtype or forces a kernel panic. By tapping into the native Endpoint Security (ES) subsystem and clustering events over narrow time windows—such as correlating crashes with `IOKitOpen` calls, `task_for_pid` lookups, or `mprotect` permission modifications—defenders can reliably identify active intrusion attempts. Documentation Deficits and AI Research Acceleration (20:00) Independent vulnerability research on macOS is constrained by sparse official documentation. Gallucci notes that while ARM provides comprehensive architectural documentation for mechanisms like PAC, Apple's public engineering notes lack granularity. This deficit directly impacts large language models, causing them to hallucinate Linux constructs like `systemd` instead of Apple's `launchd` and fail to locate core macOS log directories. Despite these hurdles, Gallucci explains that modern AI tooling dramatically accelerates security audits by allowing researchers to parse vast amounts of code. By combining AI analysis across more than 400 open-source Apple repositories with patch-diffing strategies, researchers can exploit Apple's corporate engineering silos. Because engineering teams frequently patch a security vulnerability in one specific file without checking neighboring modules, auditing recent security diffs consistently exposes unpatched, identical flaw patterns elsewhere in the codebase. Infostealers, Consumer Hygiene, and Gray Markets (22:15) In user space, threat activity has seen a dramatic rise in macOS infostealers driven by the overlap of macOS users and cryptocurrency assets. Rather than relying on complex kernel exploits, these threats rely on simple social engineering lures, such as fake updates or rogue repositories, to extract browser cookies, passwords, and wallet credentials. Disassembled in tools like Binary Ninja, these binaries are rarely packed or heavily obfuscated. While Apple's built-in defenses provide standard baseline protection, native safeguards against tactics like 'ClickFix' remain minimal, leading defenders to rely on third-party monitoring utilities like Patrick Wardle's Objective-See suite. At the same time, shifting financial incentives complicate platform defense. In October 2025, Apple slashed macOS bug bounty payouts from roughly $30,000 down to as low as $3,000, while raising maximum iOS full-chain payouts to $2 million. In contrast, US third-party exploit brokerages offer between $30,000 and $50,000 for single macOS vulnerabilities and upwards of $13 million for iOS chains. Compounded by lengthy review times and triage friction within official vendor channels, these economics have normalized the choice among researchers to sell critical discoveries to third-party clearinghouses. While Apple's hardware-level protections have significantly raised the technical bar against kernel memory corruption, defensive maturity across the ecosystem remains uneven. Bridging this gap is hindered by persistent documentation shortages, corporate bug bounty cuts that drive researchers toward external brokers, and commercial EDR solutions that continue to treat macOS telemetry as a secondary priority.

Datadog 安全工程师 Olivia Gallucci 指出，macOS 威胁态势正经历结构性分化：底层内核攻击因指针验证码（PAC）和类型隔离分配等硬件级防御而成本极高，但上层用户态却因加密货币利益驱动，涌现出大量依赖社会工程且结构简陋的信息窃取恶意软件。 IOKit 架构与虚表劫持机制 (0:30) 针对将 macOS 简单等同于 Linux 的误解，Gallucci 指出两者的核心差异在于硬件驱动模型。Linux 内核完全基于传统 C 语言构建，而 macOS 则深度依赖面向对象的 IOKit 框架。IOKit 采用 Apple 剪裁过的受限 C++ 子集以缩小攻击面，但其底层的多态性机制仍高度依赖虚方法表（Vtable）。在 Itanium C++ ABI 模型下，无主基类的动态对象在偏移量 0 处存储虚表指针（vptr），若攻击者能篡改该位置，随后的虚方法调用即可在内核最高特权级别下劫持执行流。 历史上经典的内核利用依赖于释放后引用（UAF）、越界写入（OOB）与堆塑形技术。例如 Brandon Azad 在 2016 年针对 OSUnserializeBinary 的经典漏洞利用中，通过恶意序列化字典构造悬挂指针，结合堆喷射引诱内核调用 retain 方法以实现提权；RET2 团队在 2021 年的 Intel 显卡驱动利用中，则利用越界写覆盖 OSArray 条目并劫持 taggedRetain 调用。此类底层攻击手段高度专属于 Mac 体系，迫使研究人员必须投入专门精力掌握 C++ 内核对象的内存布局。 PAC 签名与类型堆隔离防御体系 (10:00) 针对传统虚表劫持，Apple 部署了两大核心防护：指针验证码（PAC）与强化内存分配器 kalloc_type。在 ARM PAC 架构下，Apple 将指令地址（IA）签名应用于虚表函数指针，将数据地址（DA）签名应用于虚表指针本身。虚表指针签名结合了存储基地址与混淆类名哈希的加密盐值，使得攻击者无法再通过将内存清零或伪造指针来完成利用；任何未经授权的篡改都会在验证期导致系统直接中断（Abort）。同时，kalloc_type 依据具体数据结构类型而非仅按大小对内核堆进行桶化隔离，彻底破坏了攻击者用通用受控缓冲区覆盖已释放对象的堆喷射路径。 从防御工程视角来看，PAC 的关键价值在于将静默的内核利用转化为高保真的崩溃遥测信号。当攻击触发签名校验失败时，系统会生成内核崩溃并抛出带有 KERN_INVALID_ADDRESS 子类型的 EXC_BAD_ACCESS 错误。企业防御者无法仅靠单一崩溃报警，但可以通过 macOS 原生的 Endpoint Security（ES）框架收集遥测，将 PAC 崩溃与短时间内的异常事件聚类关联，例如特定进程调用 IOKitOpen 通信、利用 task_for_pid 获取任务端口、执行 setuid 提权或发生异常的 mprotect 内存保护转换，从而准确判定入侵。 加密货币诱发的信息窃取软件热潮 (22:15) 与日益艰难的底层内核利用形成鲜明对比的是，面向 macOS 用户态的信息窃取木马（Infostealer）在过去一至两年呈现爆发态势。Gallucci 解释称，这类威胁通常完全绕过复杂的底层漏洞利用，转而依赖社会工程学手段。其爆发的核心推手在于加密货币的高价值回报：持有大量加密资产的个人以及使用企业配备 Mac 笔记本的员工构成了极为丰厚的攻击目标。包括朝鲜（DPRK）国家背景团伙在内的黑客组织，正利用这些工具搜刮数字钱包密钥、浏览器 Cookie、存储密码及企业机密文档。 在二进制特征上，macOS 窃密木马大多未经过第三方加壳，混淆程度极低，安全人员使用 Binary Ninja 等反汇编工具便能直接阅读其逻辑。由于攻击者仅凭虚假软件更新、恶意 GitHub 仓库及搜索引擎投毒等手法就能轻松得手并将数据外传，目前几乎没有动力增加复杂的混淆层。此外，部分黑客组织位于独联体（CIS）国家，利用当地执法盲区甚至在大学公开举办 CTF 竞赛与接受采访。尽管针对普通用户有 Objective-See 提供的系列开源防护工具，但如 Ferdous Saljooki 在 MacDevOps 会议上的研究所揭示，macOS 原生防护机制在防御 ClickFix 等社会工程攻击方面仍然相对薄弱。 文档短缺、AI 辅助与漏洞悬赏失衡 (45:00) macOS 安全研究长期受到文档严重匮乏的阻碍，Apple 较少公开发布详尽的底层系统架构细节，迫使研究人员高度依赖 ARM 官方规范推导系统行为。这种长期的公开数据短缺导致大型语言模型在处理 macOS 知识时频繁产生幻觉，例如在分析系统日志路径时给出错误指引，或将 Apple 原生的 launchd 混淆为 Linux 下的 systemd。然而，在解析海量复杂源码方面，现代 AI 工具正显著降低门槛：Gallucci 通过 AI 辅助脚本分析了 400 多个 Apple 开源仓库，快速定位到 IOKit 的研究切入点。研究人员还广泛沿用 Patrick Wardle 推荐的方法，通过比对 Apple 最新补丁在孤立代码中的修复痕迹，顺藤摸瓜寻找跨模块未修复的同类漏洞。 在研究成果变现层面，Apple 官方悬赏与第三方漏洞中介之间存在巨大的经济差距。Gallucci 指出，Apple 在 2025 年 10 月调整悬赏结构，虽然将 iOS 完整漏洞链的最高奖金提至 200 万美元，却将 macOS 单个漏洞奖励从以往的约 30,000 美元断崖式削减至 3,000 美元左右。相比之下，美国本土的第三方中间商针对 macOS 漏洞开出 30,000 至 50,000 美元，iOS 完整漏洞链在灰市收购价更高达 1,300 万美元。加之官方审核流程漫长、重复提交风险以及审核人员沟通成本高昂，将高价值漏洞出售给第三方中介在安全社区中已从道德争议转变为普遍的经济抉择。 macOS 平台安全正处于双轨发展：底层硬件防御在 PAC 和内存标记等技术推进下筑起了极高的内核壁垒，但商业端点检测系统仍落后于硬件进化；与此同时，上层针对加密资产的低技术门槛木马泛滥，结合厂商漏洞悬赏激励失衡，使得生态防护的薄弱环节持续暴露在用户交互与灰市交易之中。

## Background 本期播客由 Josh Stroschein 主持并发布于 RSS/Web 平台（发布时间为 2026 年 8 月 26 日），邀请了前苹果安全工程师、现 Datadog 安全研究员 Olivia Gallucci 担任嘉宾。节目围绕 macOS 底层安全机制展开，深入剖析了 macOS 与 Linux 的内核差异、IOKit 框架下的虚表劫持（Vtable Hijacking）与 UAF 漏洞利用，并探讨了现代硬件防御 PAC 与新型窃密木马的威胁态势。 ## TL;DR 节目首先破除了“Mac 底层就是 Linux”的迷思，详细拆解了 macOS 特有的 IOKit C++ 面向对象驱动架构以及经典的虚表劫持漏洞利用手法。随后，Olivia 重点剖析了苹果如何借助硬件级指针认证码（PAC）与 kalloc_type 类型隔离堆终结传统内核攻击，并解释了 PAC 拦截如何将无感提权转化为高价值的内核崩溃遥测信号。对话还涵盖了当前 macOS 信息窃取木马“不加壳、靠社工敛财”的反常生态，并深入探讨了苹果官方漏洞悬赏缩水导致研究成果流向第三方经纪商的行业现实。 ## Atmosphere & style 整场对话在轻松随和的极客交谈与硬核严肃的底层逆向解析之间自如切换。Josh 与 Olivia 的互动充满技术共鸣，既有对早年逆向资料匮乏与大模型“胡言乱语”的幽默吐槽，也有面对内核汇编与硬件加密机制时的严谨拆解。听众能真切感受到一位年轻独立研究员在文档壁垒森严的苹果生态中硬磕内核的执着，以及在面对漏洞审核官僚化与悬赏倒挂时的坦率与现实感。 ## Bulletin - `00:00` macOS 内核驱动基于 IOKit 专用受限 C++ 框架，与纯 C 语言编写的 Linux 存在本质差异，多态动态调用机制使其在历史上频遭 Vtable 虚表劫持攻击。 - `10:00` 苹果通过硬件级指针认证码（PAC）密码学签名与类型隔离堆（kalloc_type）组合拳，几乎终结了基于堆喷射与覆写偏移量 0 虚指针的传统内核提权路径。 - `22:15` macOS 近期爆发的信息窃取木马（InfoStealer）主要受加密资产暴利驱动，绝大多数样本未加壳且无混淆，单纯依靠社会工程学直取钱包与凭证。 - `44:30` 苹果官方漏洞悬赏机制调整导致 macOS 漏洞收益大幅缩水（降至约 3,000 美元），与第三方经纪商高达数万美元的报价形成巨大倒挂，迫使成果流向外部市场。 ## Key takeaways - `00:00` macOS 与 Linux 架构有本质差异，其驱动核心 IOKit 采用受限 C++ 框架编写，引入了由面向对象多态与虚表分派构成的专有攻击面。 - `05:00` 传统内核 Vtable 劫持主要依赖释放后使用（UAF）或越界写配合堆喷射，通过覆盖偏移量 0 的虚表指针并诱发 taggedRetain 等虚函数完成执行流劫持。 - `10:00` 苹果采用 PAC 机制对函数指针（PAC-IA）及结合基类虚表哈希的虚表指针（PAC-DA）进行签名校验，篡改即刻触发系统终止（Abort）。 - `10:00` kalloc_type 堆分配器改按具体数据结构类型划分隔离内存桶，彻底破坏了攻击者利用通用数据缓冲区精准占位被释放对象的条件。 - `16:03` macOS 官方底层安全细节文档严重匮乏，独立研究员往往需要借助全彩且规范的 ARM 官方规范文档来推导苹果硬件安全机制。 - `20:00` 大语言模型在 macOS 底层领域存在严重幻觉，经常编造路径或将 macOS 的 launchd 机制与 Linux 的 systemd 混淆。 - `22:15` 席卷 macOS 的信息窃取木马不需要高深内核利用链，因其核心目标是企业和办公设备中高价值的加密货币钱包资产与浏览器凭证。 - `25:00` 反常的是，当前的 macOS 窃密木马大多不采用加壳与混淆技术，逆向人员可在反汇编器中直视明文逻辑，黑客依托独联体等避风港规避打击。 - `30:00` PAC 拦截虽未完全杜绝绕过，但将原本隐蔽的内核提权转化为高噪音的 EXC_BAD_ACCESS（KERN_INVALID_ADDRESS）崩溃遥测。 - `32:46` Endpoint Security（ES）框架支持监控约 140 种底层事件，结合 iokit_open、task_for_pid 和 mprotect 的聚类分析是捕捉提权利用的关键。 - `35:00` 老款 Intel Mac 缺乏 Apple Silicon 的深度定制硬件安全特性与 PAC 体系，原生系统日志与现代遥测能力存在显著断代差距。 - `37:25` 主流商业 EDR 对 macOS 内核底层防护适配不足，未来硬件防御正向 A19/M5 的内存完整性强制机制与虚拟机监控器辅助校验演进。 - `40:00` 苹果内部部门林立且代码库庞大，结合 AI 检索官方安全更新补丁周边的邻近代码，已成为高效定位同类未修漏洞的核心挖掘手段。 - `44:30` 苹果大幅削减 macOS 漏洞官方悬赏，与高出数倍甚至十倍的合规第三方漏洞经纪商报价形成严重倒挂，严重影响白帽提交意愿。 - `48:30` 官方审查团队的沟通成本、排队碰撞风险以及对 PoC 标志位（如 TCC Flag）的理解脱节，进一步挫伤了研究者的社区贡献热情。 ## Detailed walkthrough ### `00:00` macOS 底层驱动与 Linux 的本质差异 Josh Stroschein 开场介绍了本期嘉宾 Olivia Gallucci。Olivia 现任 Datadog 安全工程师，专注于 macOS 内部机制和检测工程，此前曾在苹果公司工作，并发表了大量高水平的独立安全研究。针对外界常常流传的“Mac 本质上就是 Linux”这一论调，Olivia 表达了明确的反对态度，她指出虽然两个系统共享部分命令行工具，但绝不能等同于相同的操作系统。Olivia 强调：“Just because some of the Linux commands also work on Mac, it does not mean they're the same operating system.” 在更底层的内核与驱动架构上，macOS 与采用传统纯 C 语言编写内核的 Linux 有着天壤之别。macOS 内核采用名为 IOKit 的专用框架来管理硬件驱动，其核心特性在于它是一个主要由 C++ 类构建的面向对象框架。因为这种架构引入了庞大的 C++ 攻击面，安全研究员必须深入理解如何操纵 C++ 对象及其内存损坏漏洞。然而，很多研究人员并不愿意投入时间去攻坚这种特定且专属于 Mac 的技术环境。为了收紧攻击面，苹果在 IOKit 中使用的是一种严格受限的 C++ 子集，剔除了普通 C++ 中大量复杂的库导入与高级语言特性，正如苹果对其引导过程所做的极简化精简一样，力求将潜在漏洞控制在极小范围内。 - Linux 内核传统上几乎全盘基于 C 语言开发。 - macOS 内核驱动框架为 IOKit，基于受限的 C++ 面向对象架构实现。 - 苹果通过裁剪 C++ 特性与精简启动引导流程来收缩内核层面的漏洞暴露面。 --- ### `05:00` C++ 多态、虚表劫持与经典内核利用案例 在受限的 C++ 环境中，虚方法多态机制依然是核心。C++ 的普通静态方法在编译期就已固化，而多态方法依赖运行时的虚方法表（Vtable）动态解析。虚表本质上是一个存储函数指针的地址目录，指示程序如何调度执行。Olivia 以老旧的 Itanium C++ ABI 为例说明：当一个动态类没有主基类时，其虚表指针（Vtable Pointer / `vptr`）位于偏移量 0（Offset 0）处。这意味着攻击者只要能控制一个多态对象的第一个机器字，接下来的虚方法调用就会变成攻击者完全可控的动态分派，从而劫持执行流并跳转至恶意 Payload。而在内核空间中，这类利用直接以内核特权级别运行，危害极大。 ```mermaid flowchart TD accTitle: C++ Vtable Hijacking Process accDescr: Diagram showing how an attacker replaces a freed object with fake data containing a forged Vtable pointer to hijack kernel execution flow. subgraph MemoryManipulation ["内存布局操纵"] A["释放合法 C++ 对象"] -->|"产生悬挂指针"| B["保留陈旧引用 (UAF)"] B --> C["堆喷射与堆塑形<br/>(Heap Spraying)"] C --> D["在原内存地址写入受控伪造数据"] end subgraph HijackDispatch ["执行流劫持"] D --> E["偏移量 0 覆盖伪造虚表指针 (Vtable)"] E --> F["内核触发虚函数调用<br/>(如 taggedRetain)"] F --> G["解引用伪造虚表，跳转至攻击者 Shellcode"] end ``` Olivia 解释了实现内核对象劫持的三种核心原语：时间性内存破坏（如 Use-After-Free，UAF）、直接覆写（如越界写 Out-of-Bounds Write）以及堆塑形（Heap Shaping）。在典型的 UAF 场景中，攻击者先释放一个对象但保留其陈旧引用（Stale Reference），随后通过堆喷射（Heap Spraying）将精心构造的伪造数据精准分配到该对象原有的内存槽中，并用伪造的虚表指针覆盖其首个机器字；一旦内核对该残留引用触发虚函数调用，就会立刻跳转执行攻击者的内核代码。 针对该领域的经典实战漏洞，Olivia 详细剖析了两个基石级案例： 1. **Brandon Azad 的 2016 年经典利用**：利用了内核函数 `OSUnserializeBinary`（负责解析用户态传入的二进制序列化数据并反序列化为内核 C++ 对象）。通过构造特制的序列化字典制造悬挂指针，完成受控替换后，触发 `virtual retain` 虚方法分派，从而跳转至伪造虚表。 2. **RET2 于 2021 年公开的 Intel 显卡驱动漏洞**：利用越界写（OOB Write）破坏 `OSArray` 条目，使其指向伪造的 C++ 对象。当内核执行 `taggedRetain` 时即完成劫持。Olivia 强调，`taggedRetain` 是 macOS 内核中负责生命周期管理的带标签引用计数虚方法，频繁解引用对象的虚表，因此成为攻击者劫持执行流的极佳跳板。 - 现代 macOS 漏洞挖掘难度激增，需要深厚的技术积淀、强大的专属 AI 模型支持或充足的测试资金，否则极易直接使测试机崩溃宕机。 - `OSUnserializeBinary` 核心职责是将用户态序列化对象图（Object Graphs）转换为内核功能性 C++ 类实例。 - `taggedRetain` 是 macOS 内核对象生命周期维护的关键虚函数，是劫持分派调用链路的高频目标。 ### `10:00` PAC 与 kalloc_type：终结传统 Vtable 劫持的双重防御 在讨论了 CVE-2016-1828（针对反序列化二进制的漏洞）以及 CVE-2021-3735 等历史漏洞后，Josh Stroschein 指出了此类对象问题的核心本质：当一个内核对象在内存中被过早释放，而系统中仍然残留对其的悬空引用（Dangling Reference）时，攻击者便能够利用堆风水（Heap Grooming）精细布局内存，夺取控制权，并诱导系统通过虚函数表（Vtable）发起调用。面对这种极难从根本上消除的攻击链，Josh 询问苹果到底采取了哪些手段来提升利用门槛，这些举措是否真正奏效。Olivia Gallucci 明确回答：“是的，它们在很大程度上是非常有效的。”她指出，以往攻击者能够轻易覆写这些指针，但苹果引入的两项核心机制彻底颠覆了传统的攻击面：基于硬件的指针身份验证码（PAC, Pointer Authentication Codes）以及名为 `kalloc_type`（音频中发音为 chaotic type）的加固内存分配机制。 ```mermaid flowchart TD accTitle: 苹果内核防御机制对比 accDescr: 展示指针身份验证码 PAC 与类型隔离堆 kalloc_type 如何分别化解 Vtable 劫持与堆占位攻击。 subgraph Defense_PAC["PAC 机制 (指针签名)"] direction TB PAC_IA["PAC-IA (指令地址): 签名虚函数指针"] PAC_DA["PAC-DA (数据地址): 签名虚表指针 (使用名称 Hash 加盐)"] PAC_Check{"指针运行/返回校验"} PAC_IA --> PAC_Check PAC_DA --> PAC_Check PAC_Check -- 签名失效 --> Sys_Abort["系统立即终止 (Abort)"] end subgraph Defense_Kalloc["kalloc_type 机制 (类型隔离堆)"] direction TB Alloc_Req["内核对象分配请求"] Type_Sort["按特定数据结构类型分类 (非单一大小)"] Dedicated_Bucket["隔离内存桶 (Isolated Buckets)"] Alloc_Req --> Type_Sort --> Dedicated_Bucket Generic_Buffer["通用数据缓冲区 (攻击 Payload)"] -.->|无法覆盖/隔离落区不同| Dedicated_Bucket end ``` Olivia 深入拆解了 PAC 在 ARM 架构下的运行语义。PAC 彻底瓦解了传统的 Vtable 劫持，因为它能够对 C++ 虚函数表项和指针进行密码学签名。在 ARM 的 PAC 架构中，“IA” 代表指令地址（Instruction Address），“DA” 代表数据地址（Data Address）。苹果对虚函数表内部的函数指针采用 PAC-IA 语义，而对指向虚表的指针本身（Vtable Pointers）则采用 PAC-DA 语义。具体实现中，虚表指针使用 DA 密钥，同时结合存储地址以及经过混淆的基类虚表名称（mangled base Vtable name）的哈希值作为加密盐（Cryptographic Salt）。“总的来说，这意味着攻击者不能像过去那样通过将所有内容置零来伪造虚指针；它现在必须在正确的上下文中进行验证，否则系统就会终止。” 与此同时，内核堆分配器引入的 `kalloc_type` 则从内存布局层面切断了替换途径。它改变了以往单纯按照对象大小（Size-based）分配内存的逻辑，而是严格按照具体的数据结构类型（Data Structure Type）进行归类。这使得相同的内核数据结构被强制存放在专用的隔离内存桶中。正因为这种严格的类型隔离，攻击者再也无法用一段通用的受控数据缓冲区精准地替换某个被释放的复杂 C++ 对象；曾经能够稳定碰撞覆盖的占位分配，现在会直接落入完全不同的分配器区域，或者直接触发区域检查失败（Zone Checks）。 - **涉及的历史漏洞编号**：CVE-2016-1828、CVE-2021-3735。 - **PAC 签名分类**：函数指针使用 PAC-IA（指令地址绑定）；虚表指针使用 PAC-DA（数据地址绑定，结合虚表混淆名称哈希）。 - **防御协同效应**：`kalloc_type` 阻止了同尺寸对象的任意类型混淆与占位，而 PAC 则保证了即使指针被非法篡改也无法顺利执行。 --- ### `13:02` PAC 动态校验流程与绕过探索的现实难度 Josh 追问指针签名的具体工作机理，尤其好奇校验到底是在哪一时间节点触发的，并推测协议本身是否可能存在某些校验空隙或盲区。Olivia 坦言，许多人下意识会将这种认证与常见的“Web 认证”类比，但这完全是两码事；最直观的方式其实是去查阅图解。在底层控制流中，虚表包含了大量的表项与目标地址。在动态运行期间，每个指针都会绑定特定的签名或者 PAC 代码与对应地址。 当代码开始执行时，PAC 不仅在初始调用时核验指针是否合法，还会确保整个调用链条与上下文保持完整。“PAC 不仅在开始准备运行时进行检查，它还在最后进行检查，以此确认在这个过程中是否有任何东西被修改过。”只要检测到数据被篡改，系统就会判定检查失败并立即中止运行（Abort）。Olivia 提到，尽管针对 PAC 的绕过技术是存在的——她自己也曾专门撰写过长篇博文梳理各种 PAC 绕过思路——但在底层内核环境里寻找此类缝隙异常艰难。“对于我来说，在取得实质性突破之前，我通常得在电脑前硬坐上好几个月。” 针对类型隔离机制，Josh 联想到了 Windows 平台上的 Control Flow Guard（CFG），认为两者在防御设计上有着深厚的架构血缘。基于他对早期堆喷射（Heap Spraying）技术的理解，以往攻击者依赖的是大面积无差别地喷洒内存以赌中相同内存块，而现在面对按类型细分的隔离桶（Isolated Buckets），即使成功触发了某个脆弱对象的悬空引用并尝试诱导虚函数遍历，攻击负载也根本无法跨越隔离区域写入，最终只会引发访问违规（Access Violation）或指针异常而导致系统崩溃。 --- ### `16:03` 文档稀缺性与苹果安全研究的独立之路 当被问及这些机制是苹果独创还是 ARM 生态的标准演进时，Olivia 表示自己无法百分之百断言苹果与 ARM 的界限，因为她在学习和研究过程中，核心的参考依据几乎全来自 ARM 官方发布的文档。ARM 提供了极为详尽、全彩印刷的 PDF 技术白皮书，逐步剖析了各项特性的底层规范。相比之下，苹果自身的公开文档极为匮乏，“苹果并没有像我希望的那样把所有细节都记录下来，以供我们学习这些内容；因此，去了解 ARM 是如何实现的，为我提供了足够的信息，让我能够推敲出自己在研究 macOS 内核及其机制时所面对的到底是什么。” Josh 顺势对比了微软生态：尽管微软的 MSDN 以及《Windows Internals》等经典著作通常也只是停留在满足驱动开发者的浅层水平，漏洞研究员依然需要自行填补大量空白，但 Windows 的研究资料和工具链显然要庞大得多。Olivia 强烈赞同这一观点，指出苹果研究生态的门槛远高于 Windows。两人深入探讨了为何历史上针对 macOS 的底层安全研究长期处于冷清状态。Olivia 直言，这与职业发展路径紧密挂钩：安全从业者通常需要顺应企业雇主的需求，而在美国，全职从事漏洞挖掘的岗位大多集中在政府承包商或特定第三方机构中，个人很难在保留自由度的同时获得优厚的待遇。 正因如此，Olivia 选择了做一名独立安全研究员，并将自己的研究成果公开发布到网络上。她回忆起刚涉足该领域时曾遭遇普遍的劝阻：“很多人劝我不要进入这个领域，他们说：‘你根本找不到工作的，谁在乎 macOS 安全？’”这种情况一直持续到近期针对 Mac 平台的窃密木马（Infostealers）大规模爆发，业界才猛然醒悟： > “直到窃密木马开始蔓延，人们才惊呼：‘天哪，Olivia 一直是对的，Mac 上的确到处都是恶意软件，我们必须深入研究它的安全性了。’如果不是因为窃密木马的兴起，我可能根本无法以此为生。” 在谈话的尾声，她向在 macOS 研究领域拓荒的先行者们致敬，特别是 Amit Singh（《Mac OS X Internals》作者）和 Patrick Wardle，正是他们付出了巨大的心血公开分享研究资料，才为后来的安全社区铺平了道路。 ### `20:00` 学习资源、逆向工程与大语言模型在 macOS 领域的幻觉盲区 在谈及 macOS 逆向工程与内核学习路径时，Olivia Gallucci 表示，多亏了 Patrick Wardle 等先驱者的无私分享与文档建设，使得这一领域的知识变得更加触手可及。Josh Stroschein 对此深有共鸣，他回忆起自己约 15 年前刚踏入逆向工程（RE）领域的情形，当时不仅 Windows 逆向不像现在这样文档齐备，很多技术细节甚至比现在的 Mac 内部机制还要匮乏，安全从业者不得不艰难摸索，安全会议在当年的知识传递中扮演了至关重要的角色。 当前大语言模型（LLM）的广泛使用暴露出一个底层短板：凡是在公开研究和数据上未被充分覆盖的细分领域，LLM 的表现往往非常糟糕。针对 Windows 内核与逆向已有海量的文档和论坛语料库，而 macOS 内部机制显然存在巨大的数据真空。Olivia 分享了一个极为直观的实际案例：在去年 3 月左右，她做技术展示时发现，当时的 ChatGPT 连 macOS 的系统日志应该去哪里寻找都无法准确回答。更荒谬的是，许多 LLM 至今仍会将 macOS 与 Linux 彻底搞混，例如尝试在 macOS 上寻找 `systemd`；事实上 Apple 采用的是自身由来已久的 `launchd` 及其启动自动化框架（甚至有传闻称 `systemd` 某种程度上借鉴了 `launchd` 的设计）。Josh 也补充道，这种由于底层资料稀缺而引发的模型幻觉，在 Windows 的时间旅行调试（Time Travel Debugging, TTD）领域同样存在：虽然该功能内建于 WinDbg 中，但微软公开文档的完整度参差不齐，一旦让 LLM 生成查询或构建数据模型，模型就会编造出完全错误的路径。 - Olivia Gallucci 强调：“ChatGPT could not tell you where to find logs on macOS. Not only that, some LLMs to this date will get confused with things like systemd and all that... it's just because it's not there, it doesn't exist on Mac.” - 资料匮乏与数据不平衡直接导致 LLM 在处理专有底层技术（如 macOS `launchd` 机制、WinDbg 时间旅行调试）时频频产生严重幻觉。 --- ### `22:15` 加密货币盗窃狂潮：macOS 信息窃取木马（InfoStealer）的爆发 Josh 将话题转向近一两年在社交网络和威胁态势中激增的 macOS 恶意软件——信息窃取木马（InfoStealer），并好奇为何在几乎没有传统漏洞利用的情况下，这类恶意程序会如此野蛮生长。Olivia 解读称，macOS 上的信息窃取木马通常不需要任何“硬核”的漏洞利用链（Hardcore Exploitation），其爆发的核心驱动力是纯粹的经济利益，即加密货币（Cryptocurrency）。 ```mermaid flowchart TD accTitle: macOS InfoStealer Attack Path accDescr: 攻击者利用社工诱导下载后窃取密钥、凭证并打包回传给 C2 的执行流程 subgraph INGRESS["诱导阶段"] A["社工诱导交付<br/>(SEO Poisoning / 假开源项目)"] --> B["用户自主下载并执行"] end subgraph STEAL["凭证与资产收割"] B --> C["加密货币钱包资产<br/>(Crypto Wallets)"] B --> D["浏览器 Cookie 与账密<br/>(Session Tokens / Passwords)"] B --> E["办公电子表格与敏感数据<br/>(DPRK 组织针对性采集)"] end subgraph EGRESS["数据回传与变现"] C & D & E --> F["外传至外部 IP / C2 域名"] F --> G["独联体 (CIS) 避风港变现"] end ``` Olivia 提到，业内一个令人无奈的事实是：在 Mac 上配置并使用加密货币钱包的用户群体，与企业办公设备的用户存在极大的重叠。黑客迅速意识到，既然 macOS 上的安全防御在过去一两年内鲜少有人深究，他们完全不需要编写复杂的驱动利用，只需编写一段功能极简、逻辑干净（甚至像用 AI “vibe-coded” 随意拼凑出来）的代码，通过钓鱼或社会工程学诱骗用户点击运行，就能顺藤摸瓜将本地钱包里的资产洗劫一空。 随着朝鲜（DPRK）等 APT 团伙及网络犯罪分子的涌入，信息窃取木马的目标除了加密货币，也逐渐扩展到抓取本地表格和敏感文档。更离奇的是，该生态下的黑客群体甚至形成了一种几乎“公开且友善”的社区氛围：黑客们大方接受公开采访，部分黑客甚至在大学校园里操办起 CTF 比赛。Olivia 和 Josh 指出，这在很大程度上是因为这批开发者大多盘踞在独立国家联合体（CIS）范围内；只要其恶意软件在地理上规避独联体成员国，便不会招致当地执法机关的抓捕，从而在庇护下肆无忌惮地开发分发。 - Olivia Gallucci 总结恶意软件开发者的逻辑：“And so they realized they're like, if we can just get someone to download this through social engineering, we can get everything we want.” - 针对 macOS 的窃密木马极度依赖社会工程学，规避了代价高昂的零日漏洞利用，主要通过 SEO 投毒、假冒开源项目和虚假下载站等手段直扑高价值的个人加密资产。 --- ### `25:00` 特征反常：未加壳、无混淆与基础防御建议 在剖析 macOS 信息窃取木马的技术特征时，Josh 询问其代码结构是否像 Windows 窃密木马那样千篇一律地“收集数据、发给外部 IP、结束退出”。Olivia 指出，macOS 窃密木马目前存在一个极其特殊、甚至与常规恶意软件相反的特征：**绝大多数样本既不加壳，也不做代码混淆**。在苹果生态中，正常的开发者使用 Xcode 打包软件时，系统会自动完成打包、代码签名以及公证流程。若在 macOS 上检测到第三方壳工具（Packer），本身就是极其扎眼的异常行为。因此，许多攻击者干脆连混淆都懒得做，逆向分析人员直接把 Mach-O 文件拖进 Binary Ninja，其明文逻辑和控制流一览无余；对于攻击者而言，只要能拿到钱，恶意软件是否裸奔完全无所谓。Josh 猜测，随着未来 LLM 被广泛用于自动化分析，这类攻击者迟早也会被迫进入加壳与控制流平坦化（Control Flow Flattening）等复杂的对抗周期。 ```mermaid flowchart LR accTitle: macOS Normal vs Suspicious Binary Characteristics accDescr: 对比正常 Xcode 构建管线与当前窃密木马的二进制特征 subgraph NORMAL["合法分发流程"] direction TB N1["Xcode 源码构建"] --> N2["Apple 原生打包 & 签名"] N2 --> N3["Gatekeeper & 官方公证"] end subgraph MALWARE["当前窃密木马特征"] direction TB M1["极简裸奔代码"] --> M2["无第三方加壳 / 无混淆"] M2 --> M3["依赖社工绕过 Gatekeeper 直接敛财"] end ``` 谈及个人日常防御与数字卫生习惯，Josh 提到自己的痛点：家中有多台 Mac 电脑，如果给不懂技术的孩子或家人装上类似 KnockKnock 的监控或防火墙工具，一旦工具拦截了 Gmail 等正常服务，自己就会瞬间沦为全天候家庭 IT 客服。Olivia 认为，普通用户目前主要还是仰赖 Apple 自带的防御体系以及良好的操作卫生习惯（即提防各类点击欺诈与钓鱼下载）。她提及安全研究员 Ferdos Saljuki 最近在 MacDevOps 会议上对 macOS 原生“点击修复”（Click-Fix）防护机制进行的逆向分析，结果表明系统底层的防护手段其实仍然比较有限，社会工程学仍是黑客突破系统的绝对主力。 若要追求进阶可见性，Olivia 极其推崇 Patrick Wardle 及其创办的 Objective-See 基金会开发的一系列开源工具： - **物理与窃密监控类工具**：例如在屏幕唤醒打开瞬间自动调用摄像头拍照取证，以防物理接触渗透； - **传感器提示状态**：Patrick 早期的工具曾专门用于监控并保持状态灯常亮以防偷窥，如今 Apple 已将类似的麦克风/摄像头调用指示直接内建在 macOS 与 iOS 的系统级设计中； - **系统状态检视**：如 KnockKnock 等轻量级持久化与自启动项枚举工具。 在完成对上层恶意软件态势的梳理后，二人迅速将对话焦点进行“180度大转弯”，重返底层防御工程，准备深入探讨指针身份验证（PAC）以及 Apple 在 macOS 中布置的各类底层现代缓解机制与绕过手法。 - Olivia Gallucci 强调 macOS 窃密木马的裸奔状态：“It's usually not packed, and then it's usually not obfuscated in any way... you open it in Binary Ninja and you're like, 'Okay, I know what's going on,' and they don't care, they're like, 'We got what we want, so fine.'” - Olivia Gallucci 对家庭与个人安全的实用建议：“If you want good security tools for... like a little bit of extra knowledge, Patrick Wardle's and Objective-See's tools are really where it's at.” ### `30:00` 绕过 PAC 的攻防博弈与内核崩溃遥测 谈到指针认证码（Pointer Authentication Codes, PAC）的绕过方式，Olivia Gallucci 表示攻击者有非常多的途径去规避它。她在自己的个人博客（oliviaglucci.com）上专门写过一篇文章，总结了大约十种绕过 PAC 的不同方法，内容主要涵盖逆向工程、编译器技术以及 Apple 平台安全性。Josh 顺势询问了她的博客地址并打趣道，主页上有很多她和朋友或家人的日常合照，Olivia 笑着说确实经常有人觉得反差很大：“在我和我妈的合影旁边，居然赫然写着讨论内核漏洞利用和底层 Bootloader 安全的技术长文。”包括 Project Zero 以及 Medium 上的各路安全研究员，也都发表过各种极具创意的 PAC 绕过策略。 然而从蓝队防御的角度来看，这些硬件和系统层级的保护反而带来了极大的检测优势。防御者最乐于见到的就是攻击失败，因为“失败意味着制造噪音”，一旦制造噪音，问题就转变成了遥测数据的捕获与分析。Olivia 指出：“That said, failed kernel exploitation is still telemetry.” 得益于 PAC 的拦截，原本能悄无声息实现的权限提升（Silent Privilege Escalation）极易触发失败，进而抛出 `EXC_BAD_ACCESS` 错误甚至引发内核崩溃（Kernel Panic）。在崩溃日志中，PAC 校验失败最典型的报错表现为子类型为 `KERN_INVALID_ADDRESS` 的 `EXC_BAD_ACCESS`。虽然普通场景下企业很少将全量本地崩溃遥测上传到云端，但当一台机器出现异常时，本地的深层遥测数据便成了极其宝贵的线索。 ```mermaid flowchart TD accTitle: PAC 拦截与内核遥测生成流程 accDescr: 展示了攻击者尝试内核漏洞利用时，如何被 PAC 拦截并生成 EXC_BAD_ACCESS 崩溃日志与遥测信号。 subgraph Exploit["攻击行为"] A["恶意进程执行内核提权"] --> B["劫持虚函数表 / 篡改指针"] end subgraph Defense["Apple PAC 校验"] B --> C{"PAC 签名校验"} C -- "指针被篡改" --> D["硬件触发故障拦截"] end subgraph Signals["防御遥测信号"] D --> E["EXC_BAD_ACCESS<br/>(KERN_INVALID_ADDRESS)"] D --> F["内核崩溃 (Kernel Panic)"] E --> G["本地 Endpoint Security 遥测日志"] F --> G end ``` - PAC 使得内核攻击从“无感知提权”转变为“高噪音崩溃”，为防御方提供了捕获攻击前兆的可能。 - 崩溃日志中排查 PAC 攻击特征的关键标识是 `EXC_BAD_ACCESS` 与子类型代码 `KERN_INVALID_ADDRESS`。 --- ### `32:46` Endpoint Security (ES) API 与关联检测模式 Josh 询问 Apple 是如何记录和提供这些底层行为数据的。Olivia 解释道，macOS 提供了底层的 Endpoint Security（ES）框架和 API，允许安全工具实时监控操作系统内核中发生的各色事件。当分析由攻击引发的内核崩溃和错误时，一种成熟的本地检测模式是“聚类关联分析（Clustering）”，因为防御者通常不能针对单次孤立的崩溃就草率报警，而必须结合时间窗口内的多维异常行为进行研判。 利用 ES 进行监测也面临巨大挑战。首先是极其庞大的数据吞吐量：只要在终端中运行内置的 `eslogger` 工具，仅仅记录一秒钟，Mac 就会瞬间产生大约 100 个独一无二的事件日志。Apple 在 Endpoint Security 中提供了大约 140 种不同类型的底层事件。为了精准捕捉漏洞利用链条，Olivia 强调有几类特定事件需要重点关联监控： 1. `iokit_open`：当用户空间进程尝试与某个 IOKit 内核驱动打开通信通道时触发； 2. 进程任务端口获取（`get_task`），尤其是通过 `task_for_pid` 获取其他进程控制权的动作，这是典型的后渗透（Post-Exploitation）行为信号； 3. 内存保护属性变更（如调用 `mprotect` 等函数）以及特权级别变化（如 `setuid`）与异常的进程 `exec` 行为。 如果在一台机器上同时观测到 PAC 类型的指针崩溃，且在极短的时间窗口内伴随可疑的驱动 User Client 活动、非法的 Task Port 抓取以及异常的内存保护修改，防御者对该系统遭受实际攻击的判断置信度就会瞬间拉满。 - 仅运行 `eslogger` 采集 1 秒钟，系统即可吐出多达约 100 条各不相同的事件记录。 - Apple Endpoint Security 涵盖了约 140 种系统事件类型，需重点结合 IOKit 打开、`task_for_pid` 提权与 `mprotect` 内存修改进行聚类关联。 --- ### `35:00` 分析工具推荐与 Intel/Apple Silicon 的分水岭 在被问及有什么好用的工具来查询、收集和聚合这些底层的 ES 遥测时，Olivia 直言系统自带的命令行工具 `eslogger` 虽然是开箱即用的，但对于分析人员非常不友好：“In my opinion, is kind of hard to use because it's all like text-based and all that. And for me, I have to look at text all day, so it's just a lot.” 她强烈推崇由 Brandon Dalton 开发的开源 GUI 工具 **Mac Monitor**。Dalton 去年在 Objective by the Sea (OBTS) 安全峰会上现场发布了 Mac Monitor 2.0 版本，赢得了满堂喝彩。该工具不仅能够图形化展示事件统计信息，还会用色彩丰富的图表清晰绘制不同时间段内被处理的事件类型，并支持灵活排序与过滤，极大地减轻了逆向与检测人员的负担。 随后，Josh 提出了一个疑问：这些现代的防护机制和遥测技术是否同样适用于老的 Intel 架构 Mac？他表示自己的老款 Intel Mac 目前仍然能收到系统更新，但不确定其底层安全能力是否与当前讨论的技术一致。Olivia 坦言：“If I was to guess, I would say no.” 她补充解释，在 Apple 推出 Endpoint Security API 之前，macOS 的系统日志和审计机制在业界以极其难以处理和混乱而“臭名昭著”。此外，她笑着调侃自己的职业经历：“This is maybe this should be put as a disclaimer at the beginning, but I started my career after ARM and the M1s and all that were put out, so my experience with Intel Macs is non-existent.” 许多现代硬件强化的安全特性完全是伴随 Apple Silicon 架构从底层深度定制而来的。 - 推荐分析工具：Brandon Dalton 开源的 **Mac Monitor**（发布于 OBTS 峰会），支持直观的图表化统计、日志分类过滤与高亮展示。 - 历史架构差异：老款 Intel Mac 缺少 Apple Silicon 特有的硬件级安全扩展与深层 PAC 体系，且 Endpoint Security 框架推出时间相对较晚。 --- ### `37:25` macOS EDR 行业现状与硬件安全未来演进 针对当前遥测数据的落地应用，Josh 提出在算力充足、存储廉价且大语言模型（LLM）擅长理解半结构化数据的今天，企业是否已经广泛采用了这些深度遥测手段。Olivia 给出了一个出人意料的客观现实：“It's really nobody to be honest.” 她分析指出，除了极个别专注 Mac 生态的初创 EDR 厂商（例如由少数前 macOS 专属安全工程师打造的 **Foreon**）在真正深挖 Apple 底层日志和安全防护机制外，市面上绝大多数主流企业级 EDR 在开发时根本没有真正考虑 macOS 的内部机制。常规 EDR 的 Mac 研发团队往往规模很小，其产品主要是套用 Apple 原生策略、记录简单的失败日志或根据文件哈希比对已知恶意软件，对于深度的内核防护、内存异常以及隐蔽的硬件级遥测几乎缺乏检测能力。 谈及 Mac 安全体系的未来走向，Olivia 坦承预测未来并不是自己的强项，她有时和在 Apple 内部工作的朋友交流技术推论时，大家也往往持有不同见解。但她对 Apple 正在推进的硬件级创新感到由衷兴奋。她列举了当前学术界和 Apple 最新硬件架构的发展动向： - Apple 在 A19 以及 M5 这一代芯片体系中引入了全新的内存完整性强制机制（Memory Integrity Enforcement）； - 学术研究与底层架构设计中正积极探讨“虚拟机监控器辅助的虚指针完整性校验（Hypervisor-assisted virtual pointer integrity checks）”和“金丝雀虚函数表监控（Canary Vtable monitoring）”等前沿方案； - 学界广泛支持利用来宾机外部（Out-of-guest）内核对象监控技术来构建下一代的完整性防御模型。 Olivia 总结认为，Apple 在硬件架构和内存防御层面的自主推进已经构筑了极高的防御壁垒，而未来最令人期待的，恰恰是第三方安全生态与工具链将如何跟进并充分驾驭这些先进的硬件防护。 - 绝大多数商用 EDR 并未针对 macOS 深度优化，普遍局限于文件 Hash 查杀与外层合规，仅有如 Foreon 等少数垂直初创公司在深挖内核级 ES 遥测。 - 前沿硬件安全技术正向 A19 / M5 芯片的内存完整性强制机制（Memory Integrity Enforcement）演进，并伴随 Hypervisor 辅助的指针校验与 Canary 虚函数表监控等学术防御方案。 ### `40:00` AI 工具助力漏洞挖掘与苹果生态的补丁审计思路 在苹果 macOS 与内核安全领域，研究门槛历来居高不下。Olivia Gallucci 提到，像 IOKit、历史 ABI 演进等底层细节，官方文档长期极度匮乏，这也是她花费大量心力撰写记录的原因。虽然业内有 Csaba Fitzl、Mickey Jin 等长年深耕的顶级研究员，但近期每周都有不少“全新面孔”提交并公布各类漏洞。Josh Stroschein 提问，这究竟是由于大语言模型（LLM）赋能了漏洞研究（VR），还是因为这块过去被低估的领域迎来了研究热潮。Olivia 认为，对苹果产品的关注与执念始终存在，毕竟像 WWDC 等活动凝聚了一批狂热技术拥趸，而且“能够宣称自己黑掉了苹果（I hacked Apple），这对个人声誉与虚荣心来说是极大的鼓舞”。 AI 的普及彻底改变了漏洞挖掘的工作流。即便 Olivia 已在安全领域摸索了四五年，面对苹果 400 多个开源代码仓库的庞大体量，以往很难逐一啃透；正是借助 AI 进行数据处理、模式提取与代码快速定位，她才能迅速切入自己陌生的 IOKit 及其驱动程序领域，并催生了当前的研究项目。Josh 也深有同感地补充道，他在面对体量庞大的 LLVM 项目代码库时也有类似经历——AI 能够帮研究者剥离烦琐的语法细节与代码样板，快速锁定核心关注点。 谈及如何切入苹果产品挖掘漏洞，Olivia 指出苹果以往多采用“基于隐匿的安全”（Security through Obscurity），直到近期推出 Apple Security 博客等才有所改善。她采纳了知名 macOS 安全研究员 Patrick Wardle 在播客中的宝贵建议：**紧盯官方发布的最新补丁**。因为像苹果这样组织架构庞大、部门林立且相互割裂（Siloed）的公司，同一套脆弱代码往往会散落在邻近的文件或模块中；修补了一处，周边极大概率依然潜藏着未被修复的同类漏洞。 > Olivia Gallucci 强调：“当面对像苹果这样官僚化、充斥着部门壁垒（silos）的大公司时，邻近代码或相邻文件存在相同脆弱代码的概率极高，而且鉴于各部门之间的割裂程度，苹果漏修这些漏洞的概率也同样极高。” ```mermaid flowchart TD accTitle: 补丁对比漏洞挖掘与 AI 加速流 accDescr: 描述研究员如何利用 AI 和补丁对比在苹果代码库中定位漏洞的逻辑流程。 subgraph S1["情报与补丁输入"] P["Apple 官方安全更新补丁"] R["400+ 开源代码仓库"] end subgraph S2["AI 分析与范围收敛"] AI["AI 辅助代码分析 / 数据检索"] F["快速缩小审计范围 / 定位关联代码路径"] end subgraph S3["漏洞定位与利用"] V["发现未被同步修复的同类代码缺陷"] E["构建 PoC / 跨驱动利用"] end P --> AI R --> AI AI --> F F --> V V --> E ``` --- ### `44:30` 苹果赏金缩水与第三方漏洞经纪商（Broker）的悬殊现实 谈到行业经济利益与漏洞悬赏（Bug Bounty）时，Olivia 透露了苹果近年来悬赏策略的重大转变。2025 年 10 月前后，苹果调整了 macOS 的奖励标准。尽管针对 iOS 完整利用链（Full-chain exploit）的赏金上限从 100 万美元提高到了约 200 万美元，但 macOS 端的报酬却大幅缩水——过去能拿到约 30,000 美元的漏洞，如今可能被直接砍到仅剩 3,000 美元左右。与此同时，美国本土存在大量合法的第三方漏洞经纪商（Brokerage/Clearinghouse），其开出的收购价格往往高出一个数量级。 两者的悬殊差距直接影响了研究者的变现选择：花三到六个月打磨出的成果，提交给苹果官方可能只有 3,000 美元，但出售给合法的第三方机构却能进账 30,000 至 50,000 美元；在移动端利用链方面，苹果给出最高 200 万美元，而某些第三方厂商的标准市价已达到 1,300 万美元左右。过去，将漏洞出售给第三方中介机构在白帽社区中常被视为一件不光彩的事，但如今这种现象已司空见惯。 - **macOS 基础漏洞回报倒挂**：官方悬赏降至约 $3,000，而合规第三方经纪商可开出 $30,000 – $50,000。 - **高危全链悬赏估值鸿沟**：针对高端攻击链，苹果官方最高提供约 $2,000,000，而黑市与第三方经纪市场行情高达 $13,000,000。 - **职业化抉择**：正如 Josh 所指出的，漏洞研究既是热爱也是职业，从业者必须实现时间和智力成本的最大化；官方定价与市场公允价值的脱节，迫使更多顶级成果流向外部市场。 > Olivia Gallucci 谈到研究者的经济考量时指出：“苹果给出的那 3,000 美元根本无法改变你的生活，但 50,000 美元却能让你有能力供孩子去读私立学校。” --- ### `48:30` 官方审查机制的摩擦、TCC 案例与研发安全脱节 除了赏金微薄，官方流程中的沟通摩擦与人为误判也让研究员苦不堪言。Olivia 解释说，提交给官方后不仅需要漫长的等待与修补周期，在此之前研究员不得公开成果；而且中途很可能遭遇“撞洞”（已有人在排队前提交）而分文未获。甚至在技术验证过程中，审核人员的专业度往往无法匹配漏洞深度。她举了一个典型案例：macOS 的 TCC（Transparency, Consent, and Control，透明度、同意和控制）保护数据库中有一个专门用于漏洞悬赏验证的标识位（Flag），如果攻击者能够突破边界篡改该标记，即证明利用链成立。然而，她的一位朋友提交了针对 TCC 的漏洞后，苹果审查人员却回应称“你仅仅是改动了一个 Flag，这起不到任何破坏作用”，完全忽视了该 Flag 的存在初衷本就是为了提供安全证明。 Josh 随后分享了自己在 Web 安全漏洞挖掘中遭遇的荒谬遭遇。他曾耗费数小时在一个 Web 应用中找到了跨站脚本（XSS）漏洞并提交了详尽的 PoC 复现报告，对方却以“无法复现且不构成安全威胁”为由关闭了工单，甚至反扣了他的平台声誉积分（Reputational points），这次恶劣体验让他彻底退出了该漏洞众测项目。他感慨道，业界普遍存在安全工程思维（Secure coding mindset）与单纯开发思维（Development mindset）脱节的问题，缺乏安全把控的系统往往漏洞百出，而僵化的审核机制则在不断劝退有热情的年轻研究员。 在节目尾声，Josh 对 Olivia 分享的底层知识与社区贡献表示了诚挚感谢。Olivia 则呼吁大家关注她的开源项目： > Olivia Gallucci 总结道：“你可以访问 oliviagallucci.com 关注我的工作，我把所有东西都开源了，并努力让所有成果公开且尽可能通俗易懂。” ## Notable quotes > `00:00` Just because some of the Linux commands also work on Mac, it does not mean they're the same operating system. — Olivia Gallucci > `30:00` That said, failed kernel exploitation is still telemetry. — Olivia Gallucci > `40:00` 当面对像苹果这样官僚化、充斥着部门壁垒（silos）的大公司时，邻近代码或相邻文件存在相同脆弱代码的概率极高，而且鉴于各部门之间的割裂程度，苹果漏修这些漏洞的概率也同样极高。 — Olivia Gallucci > `44:30` 苹果给出的那 3,000 美元根本无法改变你的生活，但 50,000 美元却能让你有能力供孩子去读私立学校。 — Olivia Gallucci > `22:15` And so they realized they're like, if we can just get someone to download this through social engineering, we can get everything we want. — Olivia Gallucci > `20:00` ChatGPT could not tell you where to find logs on macOS. Not only that, some LLMs to this date will get confused with things like systemd and all that... it's just because it's not there, it doesn't exist on Mac. — Olivia Gallucci ## Mentioned Josh Stroschein, Olivia Gallucci, Datadog, Apple, Linux, IOKit, Brandon Azad, RET2, Intel, ARM, Control Flow Guard (CFG), Microsoft, MSDN, Windows Internals, Amit Singh, Mac OS X Internals, Patrick Wardle, ChatGPT, WinDbg, Binary Ninja, Objective-See, KnockKnock, Ferdos Saljuki, Project Zero, Brandon Dalton, Mac Monitor, Foreon, Csaba Fitzl, Mickey Jin, LLVM ## Video description In this episode, we're joined by security researcher Olivia Gallucci to explore macOS low-level security, kernel exploitation, and macOS threat trends. We break down how macOS internals differ from Linux—focusing on IOKit, C++ dynamic class resolution, and Vtable hijacking in kernel drivers. Olivia explains the mechanics behind use-after-free (UAF) vulnerabilities, heap shaping, and legacy kernel exploits, as well as modern Apple hardware and OS defenses like Pointer Authentication Codes (PAC... [Source](https://www.buzzsprout.com/2414128/episodes/19693963-ep28-macos-security-internals-kernel-exploitation-pac-defenses-and-the-rise-of-macos-infostealers-with-olivia-gallucci.mp3)

[0:00] Olivia Gallucci: Just because some of the Linux commands also work on Mac, it does not mean they're the same operating system. [30:00] Olivia Gallucci: That said, failed kernel exploitation is still telemetry. [40:00] Olivia Gallucci: 当面对像苹果这样官僚化、充斥着部门壁垒（silos）的大公司时，邻近代码或相邻文件存在相同脆弱代码的概率极高，而且鉴于各部门之间的割裂程度，苹果漏修这些漏洞的概率也同样极高。 [44:30] Olivia Gallucci: 苹果给出的那 3,000 美元根本无法改变你的生活，但 50,000 美元却能让你有能力供孩子去读私立学校。 [22:15] Olivia Gallucci: And so they realized they're like, if we can just get someone to download this through social engineering, we can get everything we want. [20:00] Olivia Gallucci: ChatGPT could not tell you where to find logs on macOS. Not only that, some LLMs to this date will get confused with things like systemd and all that... it's just because it's not there, it doesn't exist on Mac.

[40:00] Patrick Wardle: One of the best ways to actually find bugs in Apple's products is to look at what the recent patches are and then go target those patches. [35:00] Olivia Gallucci: It's very clear that most EDRs are not developed with Mac in mind, and their Mac teams appear to be quite small, and the scope of what they're currently doing doesn't often support things like kernel protections and flagging weird, obscure things.

[0:00] And as a result, this malware is just like blown up in its success and popularity to a point where like the infostealer community is almost friendly in a way. Like they've done like public interviews, like some of them have ran like CT apps at like universities and stuff. While macOS was once considered a footnote in mainstream malware research, the rapid rise of Mac-focused infostealers and evolving kernel defenses have turned Apple security into a critical frontier in cybersecurity today. Thank you. Welcome back to Behind the Binary. I'm Josh Stroschein. Joining me today is Olivia Gallucci. Olivia currently serves as a security engineer at Datadog, focusing on macOS internals and detection engineering. With previous work at places like Apple and her prolific independent research, she brings a deep practical perspective to Apple platform mechanics and defense. In this episode, we dive into how macOS driver architecture works under the hood, C++ memory corruption in IOKit, modern mitigations like PAC, and the current Mac threat landscape. Here is my conversation with Olivia. Joining me today is Olivia, and we're here to talk about Mac security and some of the research that you've done recently, particularly with some kernel-level exploits and just, I think, security internals with Mac in general. This is an area that I probably have a basic understanding conceptually, but I've never dug into how Macs actually work. So maybe What makes Apple different? Maybe some would argue that they're Mac is just Linux. So where do the differences lie? Okay, so I would not argue that Mac is just Linux. I hear that argument all the time and my question to people who say that is just because some of the commands were Some of the Linux commands also work on Mac. It does not mean they're the same operating system. So yeah, I'd say when it comes to lower level stuff, I'd say the biggest structural difference is how macOS handles its hardware drivers. The macOS kernel uses a specialized framework called IOKit. And what makes IOKit unique is that it's an object-oriented framework composed primarily of C++ classes. And because there's this massive attack surface C++. Researchers have to understand how to manipulate C++ objects and exploit vulnerabilities there. And it's just, it's very specific to Mac. And I think a lot of people don't always want to take the time to research something that can only really help them in one way. very specific environment. That would be different. So if we look at like a Linux kernel, that's all traditionally C? Yes. So IOKit, C++, you said it's a restrictive type of C++. What do you mean by that? Oh, yeah. So it's restricted in that a lot, like when you're writing in normal C and when you have, or normal C++, you have all these different features, all these different methods and things you can import and all of that. and really limited the functionality so that, less, exploits, less vulnerabilities can take place. It's kind of similar to what Apple also did with like their boot process as well. They made it as small and compact as possible. So the amount of vulnerabilities that could possibly take place is a lot more limited than if you just, you know, wrote this big chunky, you know, bootloader and all of that. But we're still dealing with traditional C++. So we have all of the object oriented design principles that are at play there, Thank you. where... In particular, where your research has found vulnerabilities or weaknesses in their design? Exactly. So there's a couple of things here. So in C++, you have those regular static methods, and those are rigid and hard-coded at compile time. But C++ also, as you said, relies on polymorphism, which is the ability for different objects to share the same interface while having specific behaviors to execute until the program's actually running, C++ uses virtual methods that are resolved dynamically. And to keep track of this, the program uses a virtual method table or Vtable, which is essentially a hidden directory of memory address addresses like function pointers that tells the program exactly where to route that execution. When the program runs, it uses this Vtable as a directory to find that exact location of the code it needs to execute next. And for our purposes, using like an older Itanium C++ ABI as an explanatory model, if a dynamic class is no primary base class, its virtual table pointer is placed at offset zero. This means if an attacker can control the first machine word of a polymorphic object, the very net virtual call is automatically. [5:00] on edge of becoming an attacker-controlled dispatch. They can hijack that lookup process and redirect the execution flow to their own malicious code or payload. - Okay, right, and we're in kernel, so it's even more damaging because then I would imagine that the code that they're executing is at the same, now is at kernel privilege level. So there's quite a bit of damage that they can do. - 100%. When it comes to, I guess, so the idea is then the attacker needs to corrupt these objects in order to take over the flow. Can you maybe walk us through what that process looks like? I guess the number of things that come to mind here is one, Where do you even start? How do you even start... researching vulnerable kernel drivers on a Mac. What does it look like to have your workflow? And where do you look for objects? What kind of drivers are you targeting or where do you even begin with this process all right well there's two questions there so there's the how does this work and then how do you begin so in terms of how does this work there are three main exploit primitives here so there's temporal memory corruption like use after direct overwrites like out-of-bounds writes, and heap shaping. In the use-after-free scenario, the attacker frees an object but keeps a stale reference to it. They then use heap shaping, which is like spraying controlled replacement allocations, to place fake data exactly where that dead object used to be. They then overwrite that object's first word with a fake V table pointer, and when the kernel inevitably triggers a virtual call on that stale reference, it table and jumps to the attacker's code. So that's how that works. And then how do you start? Starting is a little bit challenging, because there's only really like a couple of like good examples in my opinion that have sustained the test of time. And the reason for this is because one most of the examples are older and two Apple has implemented so many new memory protections that this like class becomes very difficult to even act on if you're an individual. It requires a lot of time, a lot of previous knowledge or very good AI models if you have access to those, and oftentimes a lot of funding in case you're, you know, breaking things on the machine. If you'd like, I could probably go into some of like the older exploits and how those ones work, but in terms of newer ones, they're few and far between. Well, I guess I'd be curious to hear a little bit more about some that would help kind of build the stage for, because I think something we'll talk about then is, you know, like what has Apple done? Modern defenses, hardening of these objects and everything else that they're doing, where does that stand out compared to their competitors? Because it seems like, I guess I don't follow vulnerabilities as much as maybe a VR person would, but it still seems like. There's a number of UAF and other memory corruption bugs that just get you know, discovered every year. Yeah. And yeah, there's usually like one or two like crazy ones that like, Yeah. So, For context in this space with the IO kit and all of that, There was Brandon Azad's 2016 exploit. And this is kind of the canonical example of that use after free pattern that I discussed before. He used a crafted serialized dictionary in OS unserialized binary. This is a macOS kernel function, which is responsible for like parsing and converting binary formatted serialized data, which would be things like dictionaries or object graphs sent from user space back into functional C++ objects within the kernel. But what he did was he crafted a serialized dictionary and OS and serialized binary to leave a dangling pointer, then reallocated it with controlled content and then triggered a virtual retain, which was just another function call in that area of code was working with called through to that forged table. That's one very famous example. The reason why I like his work is that he wrote about it publicly and the way that he words it is like very simple to understand. So I always like to shout out his work there. There was also an out of bounds, right flavor with... This was... This was RET2 and this was in 2021. They had an Intel graphics exploit and here they used an out of bounds right to corrupt an OS array entry. So it pointed to a fake C++ object which hijacked the flow during that virtual tagged retain. So for reference, This tag retain I keep mentioning, this is a virtual reference counting method in the Mac OS kernel that do references an object's virtual method table to manage its lifetime. This makes it a really great target for attackers looking to hijack execution flow as a result. And those were CDE's? [10:00] 2016, 18, 28. for the unserialized binary just to get them on record here and then because we have notes too um cve 2021 3735 is that yeah - Yeah, okay. - Exactly those, yes. - Okay, and so those, so I guess, what's the core problem? with these objects and if they're if they're They're sitting in memory and you can get an object to be freed before it should be freed so that there's a reference still to it, then you can groom memory... to take control and then get that object to call through the virtual function table. I mean, it seems like a hard problem to fix. What has Apple done? to make this more difficult and have they been effective with it? Yes, they largely have been effective. And so one, like you said, that's exactly why, you know, overwriting these pointers is a problem. And the protections Apple put in place was something known as pointer authentication codes, and then a memory feature called chaotic type. So this was a these were a huge change for attackers. So PAC fundamentally disrupts traditional Vtable hijacking because it cryptographically signs C++ Vtable entries and pointers. So the vulnerabilities I just discussed probably wouldn't have been able to occur. Now, it might be a little bit helpful for me to give some more information up front before explaining all this. So there's PAC, so Pointer Authentication within ARM's PAC architecture. Here, that IA component stands for instruction address and that DA component stands for data address. Apple uses PAC IA, symantics for Vtable function pointers and packet DA, semantics, for Vtable pointers. Specifically, you know, Vtable pointers will use the DA key with the storage address and then a hash of the mangled base Vtable name as a cryptographic sol. Overall, altogether, this means that an attacker can't just forge a virtual pointer by setting everything to zero like it has in the past. It now has to authenticate in the right context or else the system aborts. On the other hand, there's that chaotic type chaotic type. is a hardened kernel memory allocator that categorizes allocations by their specific data structure type rather than just their size. So it forces identical data structures into a dedicated isolated memory bucket. Because of this type isolation, attackers can't reliably swap complexed complex C++ objects with a generic data buffer. These replacement allocations that, you know, used to collide reliably now land in completely different allocator regions or fail zone checks. I guess, can you maybe explain a little bit more about how the pointer signing works? works um like when does the authentication take place and does that i'm curious because i immediately think well maybe there's like gaps of or spots in the authentication protocol that would leave it susceptible um i don't know if that's feasible to do in a podcast but what do you think Yeah, so... I think most people are probably thinking about like authentication in terms of like web authentication and stuff. Unfortunately, I don't think that is necessarily the best approach to go about this. I think honestly like like googling a picture and being like what does pack authentication looks like will probably be the easiest. But I think I can do an okay job explaining it. So when you start off with your with your control flow, right? You're gonna have all you know, this information in the V-tapes. They're going to have all these slots with all these addresses and all that stuff. And so when, you know, Everything gets compiled. When everything starts running at dynamic runtime, everything's going to have a specific signature or a specific pack and a specific pack code with an address. From there, it then executes. And let's say... It executes. in a way that it wasn't supposed to something got hijacked well It doesn't really matter because PAC not only checks it at the beginning when it, you know, says, hey, let's start running this. It also checks it at the end to say, hey. was anything modified in this process? So, If something was modified, what happens is PAC just aborts. The system will just abort. And so it will say, hey, it failed one of these two checks. And as a result, it it. is pretty secure. There are things, there are pointer authentication bypasses. I have a whole blog post on that on like the different ways you can think about how you can bypass pack. But like, generally speaking, when it comes to lower level stuff and the [15:00] Curdle and all that like it. It takes a a long time. You're going to be, at least for me, I'm going to be sitting there for a couple months before, uh, you know, anything happens. Okay. Yeah, I was just looking. It reminds me of control flow guard to a certain degree as well. And it sounds like maybe they have some architectural kinship and how the authentication and I don't know who borrowed from what, but that sounds pretty effective. And the heap allocation as well. So I guess my... understanding of heap spraying and stuff is many, many years old, but... It sounds like then instead of just indiscriminately allocating memory and hoping that it lands in the same region. Now we're dealing with isolated buckets. And so if you have a vulnerable object, and you then try to groom memory you're probably going to hit this isolation. And so even if you can somehow manage to exploit the object that is get the function pointer to traverse the virtual function table, you're not going to be able to land across those memory regions. And I'm guessing some sort of access violation or something would occur. or you just wouldn't even know what memories. Yeah, okay. Okay. Well, that's pretty. Is that unique? Is this unique to Apple then? Or is this just a kind of a broader arm implementation that Apple has adopted? I wish I could tell you. I wish I could tell you. I'm assuming it... ARM has at least something similar, because in the process of me learning about this, one of the main sources of documentation I use is ARM's docs. They have like these beautiful full color PDFs where they document each of these things. And even though Apple's design and arms design is separate. You know, Apple isn't documenting everything as much as I would like to be able to learn about these things. And so learning about how Arm is... Doing it gives me enough information to try to figure out what I'm looking at when I'm looking at macOS internals and its mechanics. Yeah. Do you find with like working with Apple, researching Apple that it's similar to I don't know how much experience you have with Windows. Microsoft has their MSDN, their Microsoft Development Network, and there's a variety of of textbooks out there, the system internals and Windows internals. I mean, there's a lot of great resources that have filled in the gaps. But even Microsoft documentation usually is... is pretty shallow, right? It's enough to make a developer, you know, to help a developer write code and write kernel drivers. But for a researcher looking for security problems, it's, you have to fill in a lot of the gaps. Have you found that to be the experience with Apple. then it sounds maybe like you have it. Absolutely. Probably more so, I'm guessing, just because it's... There's, well, I don't know, maybe you can also comment on the state of research is certainly not as as prolific as Windows just due to the nature of where Apple, I mean, I think the market shares certainly changed and grown in Apple's favor. But it just maybe isn't as if I'm going to do research and I know Windows is, global everywhere, not as confident about Apple. Is that still more or less a true assessment or perspective? Yes. Yes. And I think that's actually why the state of research has historically been so poor, because like if you want to have a career, right, you're probably going to want what businesses want. And that's actually one of the reasons why I don't do vulnerability research as my day job to pay for vulnerability research careers in the US. You know, you're either going with government or third party developers, like if you want, you know. health insurance and such. in order to do those types of roles. So one, you got to be really good. But two, it's like, you're not, you're sacrificing, you know, the amount of pay by not being an individual. And what I realized is I was like, Hey, due to all of this, you know, I want to be independent, I want to put my work online, I want to do all of that. And at the same time, I can benefit everyone because there's so few people. I mean, there's more people today, but there's so few people told me not to go into this area. They were like, you're not going to have a job. Who cares? And all of that. And it was only until infosealers came around where people were like, yeah, Olivia was right all along. There's malware on the backs. We need to look into the security and all of that. And so if it wasn't for infosealers, I probably wouldn't have a career. so has, but leave his last name is pronounced, Singh, Amit Singh, Patrick Wardle especially. All of these people put a lot of effort into making their work. [20:00] accessible, especially Patrick Wordle. And as a result, I've had it a lot easier than them in terms of learning. Yeah, I would echo my getting into RE stuff years ago. Even 15 years ago, it was not as well documented, probably more so than maybe Mac internals right now, but a similar experience. You really had to hunt for knowledge. I mean, conferences were a big part of the knowledge sharing, they played a crucial role there. I've even found to this day with LLMs that areas that are just underrepresented, underserved in terms of research, naturally don't feed into LLMs as well either. And so now that we have, I would say, a pretty rich source of RE documentation on Windows internals, I would imagine there's still a gap with aiding LLMs and the Mac worlds. I actually have a great example of that too. and I called out in some of my presentations around, so I guess it's around almost two years, a year or so ago. So March of last year, so not two years, but ChatGPT could not tell you where to find logs on Mac OS Not only that uh some llms to this date will get confused with things like system d and all that so like apple uses launch d and like the whole like launch automation framework like not system d and i think system d was actually inspired by launch d if i'm not mistaken i'm pretty sure i read that on like reddit so it's maybe someone backtracked there but um it's kind of interesting because like i'll have chats with some people and they're like oh why can't i find like my system d or whatever it's just because it's not it's not there it doesn't exist on mac so oh wow yeah that is interesting and it just conflates and confuses and hallucinates and sends you down the wrong path um yeah yeah that's interesting i i've experienced that with uh time travel debugging that's an area that as a yes it's baked into WinDebug, you know, in a sense. And it's, you know, Microsoft has some documentation out there, but it's a little hit and miss in terms of completeness and what you're looking for. And it seems to lend itself to more hallucinations than when asking for assistance from an LLM and crafting queries and kind of working with the data models You mentioned InfoSteelers I think I kind of curious if maybe we just could detour down that road a little bit I don know the current state of Mac malware but it does seem like over the last year or two at least anecdotally social media feeds a lot more info stealer Mac malware What caused the rise? Do you have any particular theories on what caused the rise of those to become so prevalent and what made them effective? I assume that they were after the same information that Windows info stealers are, passwords and browser session cookies and just the normal stuff that they can steal. Yeah. So typically there isn't any like, I guess what you say, like hardcore exploitation involved. There has been cases of that, though, where they'll find like really cool vulnerabilities and stuff. When it comes to info stealers on Mac, they really blew up because of cryptocurrency. There's a really heavy, and I'm a little sad to even share this, but apparently there's a pretty big overlap in user bases of people who have crypto setups on their Mac. And so as a result, so they have that crypto and it's on their Mac and it's on an enterprise machine and all that So it super easy to just take that money and get those that information And so now infosealers will also include things like trying to get spreadsheets and all that like the DPRK infosealers and all that. But cryptocurrency was the main one. And what was super interesting was that because so few people were even focusing on Mac security, like a year or two ago, just making these, like, if you look at InfoSealer malware, it's very simple. It's often very clean. Some of it's, you know, vibe coded and all of that, but like, it's functionality is quite simple. And so they realized they're like, if we can just get someone to download this through social engineering, we can get everything we want. And as a result, this malware is just like blown up in its success and popularity to to a point where the InfoSealer community is almost friendly in a way. Like they've done public interviews, some of them have ran CTFs at universities and stuff. Really? So yeah, admittedly, this usually happens and it's called the Commonwealth of Independent States. It's like an allegiance with Russia where they don't arrest these malware developers and stuff, but they be chilling over there. [25:00] Yeah. Well, and that would explain maybe why a lot of them are geographically excluding the CIS countries, probably, to stay on the good side of these, I don't know what you would call that, benefits or perks of operating out of those regions. that isn't. And I suppose that's kind of true, maybe on the Windows side of the world, too, because Office documents have waned out of popularity for a number of reasons. And I'm GitHub projects and SEO poisoning and that kind of stuff is where a lot of it's coming from. Is there anything else that's noticeable about or notable about a Mac Steeler? Or is it just... Thank you. straightforward code steal information to some external ip domain and call it a day Yeah. Oh, here's another thing that's very unique to them. They usually don't use any sort of third party packers. I've written about this. Mac OS, like when you ship your app to Xcode and all that, they like pack and sign and all this stuff, your software for you. So... This malware is often not packed. It's not to say that third party packers don't like exist on Apple ever. But like if you see a software that's packed, that's usually a hint. that it's suspicious because uh you know apple has its own uh packing software so that's that's one of the the call outs it's usually not packed and then it's usually not obfuscated in any way we're now beginning to see obfuscation being used but it's normally you know you open it and binary ninja and you're like okay i know it's okay going on and they don't care they're they're like we got what we want so fine yeah but it's yeah i mean i would imagine um yeah i wonder if they're going you. especially with LLMs now to augment analysis if they're going to go through the rapid evolution of introducing obfuscations. And we've got to go through the packer phase again and then go through control flow flattening and all the different stuff that we've seen on Windows for years. And, you know, when you look at a Mac, too, I have several floating around my house. And every once in a while, when the kids start using them, I think, hmm. They're not as informed as I am about how to use a computer safely. I still make mistakes. I wonder if I should do something different with a Mac. Do you have any suggestions for that or does it just come down to basic cyber hygiene like i don't run antivirus do i really need antivirus i know patrick wortle has a handful of um utilities. I think I grabbed, what is it? the firewall app knock knock or something and i have that running on my mac now but as soon as i throw that at somebody, I'll put that on somebody else's laptop and it starts blocking Gmail and other things. It's just going to make my day miserable because I'll become IT support in the house. Yeah. So I will say that those are the tools I was going to mention. I would say Apple generally does a pretty good job. And so as a result, it's mainly just like general hygiene. There are certain things that like I'm a little sus about when it comes to Apple. I can't remember his name, but he recently did a presentation. Let me find him. At Mac DevOps, where he reverse engineered macOS's native click fix protections. I just want to make sure I pronounce it correctly. Ferdos Saljuki. Apologies if I mispronounced his name, but he reverse engineered macOS's click fix protections and it was really like there isn't all that. that many and Yeah, so it was super cool on what he did. So there isn't that many protections there. But with most things, it's like, It's just social engineering and that's the main way in. If you want good security tools for... like a little bit of extra knowledge. Patrick Wordle's and Objective-C's tools are really where it's at. I remember one of his tools was like something that would like take a picture, like the minute it, like you open up the, the screen. So you can see if like someone's trying to like get in or sneak into your, your Mac and things like that. There's also certain features that Patrick had where it would like keep a light illuminated. But I think, Mac and iOS is now included that in their default builds, so... It's just there by default now. So we're going to do a hard, what would you say, 180, 190 degree turn back to the detection engineering and kind of talking about going back to the point authentication and some of the modern mitigations that Apple has done. implemented in the Mac OS. I guess so a couple things that I think stem from here. One are, are there workarounds or attackers who says getting harder and harder. So it sounds like these things are not a hundred percent, but they're difficult to get past anything that you're aware of as a [30:00] of ways for getting around it? - Yeah, so there are a ton of different ways to get around pack. I have a blog post that it's just like, I think it's like 10 different ways where you can like, What's your blog? Let's make sure we get that in there. I'll add it in the show description as well. It's just my name. It's just oliviaglucci.com. everything's on like reverse engineering compilers, Apple security. And sometimes I think people get thrown a little bit off because every time I post something, it will be like a picture with me and my friends or like with me and my mom or something. And people are like, Oh, like, great to talk about like Colonel exploits with like you and your mom. Like, okay. Okay. I see a picture right now of it must be you and your mom, uh, the level bootloader security. Yep. And then the other ones, me and my boyfriend with boot, Yeah. Okay. I'll make sure to get this in the, in the show description. So everyone can check out the blog. But yeah, so there's tons of different ways to do that. Lots of different creative stuff, like Project Zero has it, a bunch of people in Medium have it. And so there's all sorts of different ways. And what's interesting with like the detection engineering and all of that is... when you have pack and all these protections And these predictions are good. That means failures are common. And that's kind of what us is like defenders want, because if there's if they're failing, they're making noise and then it becomes a problem of tracking telemetry. That said, failed kernel exploitation is still telemetry. And because of PAC, instead of silent privilege escalation, the exploit's likely to fail and generate something known as an exec bad access. This is a type of error and then also kernel panics. And if you look at crash logs, a PAC failure commonly appears as exec bad access with the subtype current invalid address. And so there's all these different endpoint security logs, as well as different types your telemetry and you can see whether or not something's occurring from a local standpoint. This isn't generally stuff you would send to the cloud, but if there's something you're worried about on your machine, you would look at the localized telemetry. Yeah, okay, so we're... We're saying that there's a program or there's a driver or something on the systems, somebody's likely attempting to abuse it. And because the vulnerability exists, but the failure is because the protection actually kicked in from the operating system and blocked it. And now you're getting telemetry about that. So you have some insight into maybe adversarial action as well as vulnerable drivers on the system. How does Apple log that? What is the I guess, what is the format that they use? Kind of. So there's, it's, it's called endpoint security or yes. Endpoint security is, is an API that allows you to like see what's going on on the machine. And When you have like these errors, like these kernel panics and all that, the mature local detection pattern is clustering because you don't want to alert on just one crash unless you know exactly what you're monitoring. So you'll use endpoint security to monitor all these different types of events. Now, there's two problems with this. So first, when you log with ESLogger, so if you type in your terminal ESLogger, if you log for around one second, you'll have around 100 unique events. and distinct logs that have occurred on your Mac. So there's a lot of bulk there. Apple has around, I think it's like 140 or something. It's like some crazy amount of different types of logs that show up in endpoint security. And the ones that I personally look for in like the situations we discussed before would be Iokit open, which these fire when processes open a communications channel with an Iokit driver. There's also get task events, specifically task for PID retrievals, which make task port acquisition a post exploitation signal. And then there's memory like monitoring a memory transitions with like m protect and other memory functions as well as privilege changes like set UID or Exact behavior and what you can do is you can correlate a pack style crash on a host that's also showing Suspicious user client activity so task port grabs and anomalous memory protection changes in a short time window or Just like your confidence level for other things that are happening on the machine, you can kind of say, "Hey, you know, something is going wrong here. This isn't great." and your confidence in what's happening rises pretty quickly at that point. That sounds like an incredibly rich source of information. API, so it's just available. You have to have something to query and harvest and aggregate. Any good packages that do that? or utilities or software that you utilize or would recommend? Yes. So there's ES Logger, which is on the machine itself, [35:00] It's installed by default. This is in my opinion, is kind of hard to use because it's all like text-based and all that. And for me, I have to look at text all day, so it's just a lot. I like this tool by Brandon Dalton. It's called Mac Monitor. It is beautiful. It's open source. He released version two last year live at OBTS. It was super cool. Massive round of applause was great. And this tool will show you like the statistics they're the logs on your machine too. So it will show you which types of events have been processed during this time and it will graph them out for you and it lets you sort them and analyze them in a way that's pretty with different colors and all of that. So it becomes a lot easier to analyze events. at a in a short amount of time. Maybe this should be obvious, but I'm assuming there's... same protection, same telemetry for the old Intel Macs, did her as Apple... abandon. I'm still receiving updates on my Intel Mac, but I don't know what's all baked into the security of it compared to what we've been discussing. If I was to guess... No. Because endpoint security, I think, was only around a couple years ago. If I was to guess, I would say no. macOS logging was actually notoriously difficult until... endpoint security came out. And the other thing is, this is maybe this should be put as a disclaimer at the beginning, but I started my career after. arm and the M1s and all that were... Put out so my experience with Intel max is non-existent Yeah, I know I date myself whenever I say that okay, well that I mean that sounds like a great a Again, we're in this age now of... I don't know if compute is cheap, but it is plentiful. Storage is certainly plentiful. I think LLMs are helping to... take large unstructured or at least somewhat structured data sets and make more sense of it. So it would seem like we're finally poised to really take advantage of all that information for organizations that can. Do you have any insight into who's actually utilizing this? Is this becoming standard in enterprise setups or... power users are still the only ones really digging into it. it's really nobody to be honest. I use it because I know how to use it. There's an EDR company called Foreon. They're a Mac specific EDR startup. And they're really the only people that I have seen doing like advanced stuff with Apple's logs and Apple security protections and all of that. Most EDRs I know. And so for the record, I think EDRs have a place in you know, an organization and all of that. But besides for Forion, most EDRs that will just enforce like Apple's native protections, like they'll just like force it on the machine and log it when things don't occur. They'll also say like, hey, you know, I noticed you have this file with this hash, this is a malware, like all those things are important. And all that, but it's very clear that most EDRs are not developed with Mac in mind. And their Mac teams appear to be quite of what they're currently doing doesn't often support things like kernel protections and, and, and flagging weird, obscure things. The only one I've seen is a Foreon and it's because they have two or a couple of macOS only engineers working on it. Thank you. Where do you see the future state of Mac security? No, it's all good. Most of the time I would... Yeah. I will predict things like with some of my friends even work at Apple. I'll be like, yeah, I think this is going to happen. And they're like, I don't know. And so it's I would say I'm I'm usually pretty bad at predicting where things are going to go. But I am very easy to excite when it comes to the things that Apple is developing. So a couple of things we didn't cover was like Apple introduced memory integrity enforcement on A19 and M5 class silicon. And in the academic and architectural space, there are proposal for like hypervisor assisted virtual pointer integrity checks and canary V table monitoring and all that. the shelf macOS endpoint features yet. Academic literature, you know, heavily supports, you know, out of guess kernel object monitoring to like enforce this integrity model moving forward. And... like random random papers I just sat down to read I don't I don't read too many papers but when someone else reads them and then sends them to me I'm like oh I'll check it out and so there's things like that that I've seen and then the protections I think Apple has been super great with has been like the hardware and the memory and all that and that ends up protecting the system a lot where I'm really excited to see is what third-party [40:00] The researchers can do, especially vulnerability research groups that either get caught doing things sus or, you know, independent researchers who are able to use AI to do you know, more in depth work because at present, one of the reasons why I've documented these things with like IOKIT and the historical ABIs and how it affected Max and all that is because one, the documentation isn't really there. And so I'm still kind of working my way up to like, the modern Mac and all the things that are going on within it. And those things take a lot of time. So the amount of researchers that I even see that are consistently getting vulnerabilities, like it's hard. There's Chaba Fitzel, there's Mickey Jin, there's some people who've been around for for ages, but a lot of the people I see are like random new people. Like every week getting put out of saying, hey, they found this, they found that. And I'm really excited to see the patterns of those people to see if any of them, you know, make it big and consistent and, you know, open source their work. Do you think that's... Is it LLM-enabled research that's getting more folks into the space or just more interest in an area that maybe has been underserved? And, I mean, if I had to pick an area right now, say I'm going to start another career doing VR, I'd want to pick an area where I would think is ripe with vulnerabilities to maximize my time and effort. And maybe at the end of that, the payout. I do think there's always been an interest in Apple stuff. the WWDC and all that, people, So there's a subgroup of people that are very, very obsessed with Apple products, and I think there's always that interest there. And to be able to say, you know, I hacked Apple, I think that's a big ego booster. You know, like that's pretty cool. Mm-hmm. So I definitely think there's an intro there. AI has enabled so many people who haven't focused in this for as long to, you know, learn more. And that includes me. Even though I've been in this space four or five years at this point, It was only until I downloaded Apple's like 400 plus open source repos and all that and started doing data processing and all of that was I able to say, hey, I want to look into this space. I want to look into this space. And like that, that was one of the ways that this project came about, because I was like, hey, I don't know much about Iokit and Iokit drivers. because I was able to narrow down what I was looking at faster. So I think AI, I think that's happened. And I also think, because Apple's security model has always been security through obscurity up until very recently when they when they were announced the Apple security blog and all that and I would agree with you. One of the best ways to actually find bugs in Apple's products is to look at what the recent patches are and then go target those patches. Because when a bureaucratic company like Apple, when they have all these silos and all that, the chances that neighboring code or neighboring files have the same code that is, you know, vulnerable, the chances that you'd be able to find that are quite high. And the chances that Apple didn't fix it are also quite high because of how siloed it is. And so I got that advice from Patrick Wardle in another podcast. And he was like, yeah, I just look at what the patches are. And then I go look there. And that's what I started doing. So Thank you. Yeah, that seems like a really great place to start. And to me, it makes a lot of sense because you see that play out over a lot of vulnerabilities in the past where a patch comes out, it addresses maybe one problem or not even addresses it well. And if you started looking there, that would just open opportunities and related code paths and just a great place with AI. And it seems like a great... I feel like I've had a similar experience with the LLVM project. That's something that has this massive code base that I probably wouldn't have wanted to take on at this point in my life, but AI has made it a lot easier to do research and narrow down the parts of it that I'm particularly interested in and not have to get lost in syntax and code patterns and all of the stuff that comes with a massive code base that's online. Is there Anything else that we should discuss or that you think is worth... kind of rounding out the episode on. Yeah, you mentioned earlier about like bug bounties and things around, uh, It was October of last year. October 2025 is when Apple changed their... payouts for Mac OS. And now the third party vulnerability research space for Apple has always been higher than what Apple's offering. I think at present, they changed it to [45:00] from 1 million to I think $2 million for a full chain iOS exploit, but things that used to be like $30,000 for Mac are now like $3,000 and all of that. And so there's many like third party brokerages and stuff in the US that you can try to you know, sell your work to and all of that. And, many people I know go that route now because That general question of like, oh, what's this going to be used for? It's left open to it's in the US and then you get a lot more money. and I think one of the things Apple really needs to consider is... how difficult they've made it for people focusing on Macs to want to submit to their program. I think that's something there because it You know, you spent, you know, three, six months working on something and then you get like 3K for it when you could get like 30 to 50K from somewhere else. Right. It's like legitimate in the US, like you're not like selling it to some like other country or whatever. So there's things like that. And then also with iPhone research, iPhone research, you know, I haven't done much of it, but it's historically been very difficult. And, and, when Apple's offering a maximum of 2 million, and then there's other companies where the standard's like 13 million, if you sell to them, you know, it's kind of difficult to be like, ah... Like, And so most people I know are almost favoring third-party firms now, which I think is really interesting because in the past, I think that would – really was something to be ashamed of. It's just become so... so common now. Yeah, you know, I just assumed that Apple has a bug bounty. It seems like every major tech company and a lot of places have them. So it's interesting to hear the breakdown in the pricing. It's been a while since I've gone and looked at any sort of what do exploits sell for, and that seems to be... like a concerning disparity between what markets I would imagine a, you know, brokerage or clearinghouse, whatever, you know that's representative representative of market value and if the company that arguably should be the ones... wanting to receive that information firsthand in order to fix it and disclose it properly rather than the potential for it to be sold to a nation state or some wherever to get abused. I think they'd want to be on top of that, so that does seem a bit a bit concerning and certainly would force or cause... I mean, yeah, you don't do this kind of work, especially for a company like Apple for free. I mean, yes, you're passionate and there's a lot of people that just really like to share knowledge and do the research, but It's either than a hobby or it's... you know, it's a career. And if it's a career, makes sense to maximize the time that you're spending on it. A hundred percent. And the money that Apple's giving out, like that 3K or whatever, like that's not going to make or break your life. But like $50,000, like you could, you could send your kids to private school with that money, you know, and if you're finding something with multiple exploits, like a, you know, five chain to seven chain, and you're, you're making millions of dollars at that point. And these third party companies, like these third party brokers, like they'll DM you online. considered us. They're super... And, you know, not that Apple is... you know, unfriendly or they're, I'm not, I don't want to say their bug bounty program isn't, is unfriendly in any way. It's just that like, You have to wait a really long time. They have to fix it. And then only then can you talk about it. You might you may or may not get paid because they you don't know where you are in the process of if other people found those vulnerabilities. You always know that payout is going to be less than what you could have gotten otherwise. And. it introduces a lot more human error. For example, transparency, consent, and control, that's a protection database on macOS. There's a specific flag in there that's meant to show that if you got access to it, if you found a vulnerability and you got access to it, you can just change that little flag. I had a friend who submitted a vulnerability to Apple and they were like, you know, all you did was change this flag, this does nothing, when the whole point of the flag was for bug bounty in the first place to show that you could change it. And so you kind of have these interactions and you hear about these interactions in the community, you're like, gosh, darn it. Like, it's so much easier to go this other route. Like, you know, so if someone from Apple is listening to this, this is what you're this is what the. the new grads who want money are thinking about these days. I had kind of a similar experience. I did a bug bounty. It's been a while. I tried one, spent hours hacking away on this web app. I found some cross site scripting. I thought, okay, this isn't the most devastating, but this is certainly an issue. And as we talked about earlier, it's like, if there's a bug here, there's definitely bugs in other parts of this application submitted the application or submitted the writeup. [50:00] gave proof of concept, all that stuff. I got told that it wasn't an issue. It wasn't reproducible. And then they dinged my reputational points for it. And I was just like, you know what? Forget this. I'm done. And I walked away from that program and I've never gone back because it was such an irritating experience. Yeah, I'm sorry to hear that, but can't say I'm surprised. Yeah, I thought, man, what a great way to make a little extra cash, you know, like go hack on web apps. So people were making bank on web apps there for quite a while. Maybe they still are, but it's just easy. It's a different mindset. I've encountered this multiple times over my career. There's a security, like a secure coding mindset, and there's just a development mindset. And the two don't necessarily play together. And it's just been, you can see when an application has been developed without anyone advocating for security principles or practices. It just seems to be quite apparent. Well, at this point, then, I'll just say thank you for your time and really appreciate your sharing your knowledge, your insight, your experience with all of the research you're doing with me, with the community, the community at large. I'll give you last words. Yeah, thank you so much for having me. I really appreciate it. Again, my name is Olivia Gallucci, and you can follow my work at oliviagallucci.com. That's where I post everything. I make everything open source and try to make all my work public and as easy to understand as possible. And that's all for this episode of Behind the Binary. Thanks so much for tuning in. If you enjoyed the show, please consider subscribing and leaving a review. It really helps us to reach new listeners. Until then, stay curious and keep exploring.