文章总结： 本文介绍了一个名为OSSSensor的开源工具，它利用AI技术辅助进行macOS漏洞研究。该工具将Apple的部分开源代码视为传感器信号，结合二进制分析和系统日志，通过AI代理自动处理信息过载问题，生成经过优先级排序的研究队列，以帮助研究人员更高效地识别潜在漏洞和系统变更。文章还讨论了该工作流程的架构、局限性（如成本高、AI可能产生幻觉）以及未来方向123。 综合评分： 85 文章分类： AI安全,二进制安全,逆向分析,渗透测试,应用安全

用AI提升macOS漏洞研究：一个开源工具与工作流程

幻泉之洲

2026年5月17日 12:31 北京

在小说阅读器读本章

去阅读

Datadog的Olivia Gallucci开发了一个叫OSS Sensor的开源工具，用于macOS漏洞研究。她把Apple的部分开源代码当作传感器信号，结合二进制分析和系统日志，用AI代理生成优先级研究队列。这套流程能大幅缩短从补丁发布到检测部署的周期，但她也坦承成本高、有幻觉，目前只适合独立小规模测试。

从手动到AI辅助：研究瓶颈怎么破

大家好，我是Olivia Gallucci，在Datadog搞安全研究。今天聊一个macOS漏洞研究的AI工作流程，顺便介绍我开源的OSS Sensor工具。

OSS Sensor能干这些事：基于Apple OSS差异、二进制特征和日志模板，生成一个按证据排好队的研究队列。它用自定义的规则打分，支持按规则分类。二进制和日志分析部分特意做得很轻量——没有集成LLM漏洞验证功能。它就是个分类和假设生成的辅助工具，不是自动挖洞的。

项目有两个版本：一个不带AI，一个带AI。不带AI的更精简，更容易适配你自己的工作流。我强烈推荐先用这个版本自己搭AI流程，尤其你想快速迭代或者灵活写增强功能的话。

这样就能根据你自己的设置来做个性化定制，而不是依赖我的配置。当然，关于AI API密钥即插即用的PR还在审核中。

为啥不直接做即插即用？因为我工作流程里有些手动干预步骤。而且我很快发现，某些配置根据使用情况会变得极其昂贵。老实说，我不确定新手会想要即插即用版本，尤其刚接触苹果系统的漏洞研究。

如果你想试试这个工具，有几个内置演示可以用。连上AI编码代理后，工具会概述执行步骤，展示开箱即用的评分和权衡功能。你可以在此基础上整合自己的AI工作流——工具设计简洁且模块化，几个提示词就能搞定。

这次演讲会讲AI怎么帮到我，以及我怎么调教AI让它更靠谱。要知道大约一年前，很多AI聊天机器人连macOS日志都不会查。

AI漏洞研究的两大核心：逆向工程和模糊测试

我会重点介绍AI漏洞研究的组件——逆向工程和模糊测试。逆向工程是通过二进制文件和运行时行为推断编译系统怎么工作的；模糊测试是自动生成并变异输入，靠崩溃或违反不变式来暴露缺陷。我的工作流就是自动化这些环节，因为它们最可靠。

首先，AI工作流把Apple的开源代码当成传感器。这里的传感器指任何能产生系统信号或状态变化的数据源，不需要你为它做解释。其次，工作流用AI代理把这个传感器转成我们的优先级队列：哪些变了？哪些跟安全相关？哪些需要逆向？哪些需要模糊测试？

简单说，agent就是能接收目标、选工具、运行步骤并生成结构化输出的系统。问题来了：苹果有巨大的安全攻击面，但只有部分是开源的。比如苹果有400多个开源库。

但这些发布内容不完整，很难手动跟进。我的时间就受限于精力。所以我的路线是：差异分析 → 假设验证 → 漏洞利用。关键技巧在于增强开源代码差异分析，再加上另外两种信号：二进制文件和操作系统日志。

正式深入前，先提一下房间里的大象——苹果的保密性。苹果实际开源的东西远超人们预期，比如XNU内核、核心库（libsystem、libC、libdispatch）以及一些长期存在的守护进程（launchd）。但他们没公开所有内容，有些组件缺失或部分可用，包括CoreFoundation、CFNetwork、iOS专用驱动、核心加密模块，还附带额外的再分发限制。这些源码包可能不完整或已过时——你会看到引用不存在文件的头文件，或者指令缺失。这对AI代理来说非常困惑。

关于这些限制和为啥这个工作流程重要，我推荐看我之前在BSides 312的演讲，那里讲了更手动版本的历史。

那么AI能干啥？苹果400多个开源库的信息过载，正是AI代理的用武之地。如果全靠我手动做代码库探查和临时差异比对，最终对风险的认知会非常局限。把这些记录工作自动化，我就能专注处理AI不擅长的部分，比如权限边界分析和漏洞可利用性评估。对威胁检测工程也很有帮助。

关键在于：理解变更的速度越快，就能越早部署检测方案并优先应对新型攻击手段。

即便代码不完整，它仍能指导我的研究。我和AI都把它当成一张地图。你或许没有完整版图，但这些地标是真实存在的。我和许多研究人员的做法是：以苹果开源代码为参考，同时研究专有二进制文件。比如拿launchd、syslogd或驱动的二进制，用现有日志或源码匹配已知函数、标注调用模式，逆向解析未知逻辑。代理机制很简单：这种混合方法虽然有效但无法扩展。代理能自动完成符号关联、字符串锚点追踪、源码上下文检索等重复工作，生成结构化摘要，从而大幅提升人工审查的效率和一致性。

即使符号表被剥离，程序结构结合字符串常量、系统调用特征，仍可逆向定位开源代码。以下四种工具反复出现：strings提取调试信息、格式字符串、文件路径、版本和项目信息；nm列出存在的符号名称，尤其适合未剥离符号表的二进制或框架；class dump获取私有框架和Objective-C方法等接口信息；苹果的分发清单用来交叉引用每个版本的组件。所有这些重复但依赖上下文的操作，我都交给代理当工具用。

我不需要模型编造事实，我需要它调用strings工具、解析输出并检索对应的源代码块，然后得出限定范围的结论，并附上观察结果的引用。之后我通常会深入进行二进制差异分析，比较补丁前后的二进制文件来识别变更。这是我超爱的案例：2016年，OSX逆向工程师用Diaphora工具对syslogd做10.11.2到10.11.3版本的差异比对，发现仅有一个函数被修改——分配计算从数值加4变成了数值乘4再加4。从漏洞利用角度看，这很像堆溢出缓解措施。附近还有个字符串显示“添加锁定会话，重新分配失败”，指向了源代码。这种精准分析就是补丁后漏洞被逆向的方式。因为这类修复通常需要应用到多个位置，如果相同代码在某些文件打了补丁而其他文件没打，未打补丁的文件可能仍然存在漏洞。组织越大越官僚，你最好相信他们会把同样的错误重复到相邻产品文件中。

现在想象一下完全相同的工作流，只不过由AI驱动，在每次Apple版本发布时持续运行。它吸收新的OS、OSS标签、压缩包以及分发清单，在功能和语义层面计算差异，然后根据安全相关性为变更打分——基于分配数学、边界检查、权限控制、XPC解析和IOKit外部方法表变更。它会关联二进制文件和字符串锚点，输出带风险评级的优先级队列，附上人工核验指引。在我独自做的渗透研究里，这套方案实现了效能倍增。当前测试只覆盖独立小型组件，受限于成本还没做完整OS测试。不过如果能扩展到系统级规模会非常理想。对企业用户来说，这将显著缩短工作周期，从苹果发布补丁到识别行为异常，加速监控策略调整和漏洞分级。若实现规模化，这将成为标准化的研究流程——你应该期望来自专业漏洞研究团队把平台变更跟踪作为常规操作，而不是某个用电脑随意构建内容的女士。

正因如此，我觉得这事值得公开讨论。它有助于保持漏洞可发现性，对初级工程师（比如我）特别友好。

架构揭秘：代理管道+检索器+工具箱

我现在效果最好的架构是这样的：采用代理管道方法，用一组协调的代理工具处理原始输入（差异文件、二进制、日志），输出基于证据的结果（排好的分类队列、假设和热点/遥测计划）。

首先用一个检索器——这是搜索嵌入信息的索引层，包括OSS代码、符号、注释和日志模板，返回与给定问题或对象最相关的上下文。然后用一个工具箱——精选的确定性分析器和系统命令，比如strings、otool、class dump、日志查询。代理调用它们来收集事实、生成证据，而不是瞎猜。最后由更多代理处理不同环节：逆向工程上下文分析、假设生成、方案规划和数据分析。我无法告诉你具体哪些AI模型和代理最有效，因为我主要沿用了最初选的那些。但稍后我会详细说明怎么量化评估。

我不会神化AI模型，而是把它看成资历尚浅的初级工程师——快速阅读、能按流程工作并生成结构化假设。我们可以通过逆向分析、代码追踪和模糊测试来验证这些假设。但要注意，每个步骤本身都可能出错。

它们彼此相互依赖，所以你的配置最好考虑到这一点，因为你可能用的是资源有限的付费个人计划。相比经典方法，本次演讲的重要补充是：我用Apple OSS做逆向分析时重点看日志。统一日志系统提供子系统与分类标签，可映射回组件、稳定的消息发布、辅助二进制和源码搜索的字符串，以及执行提示信息。在没有完整源代码的情况下重建数据流图。我把统一日志视为攻击面的切入点和代码路径，而不是教条。因为这些日志又嘈杂又庞大，我不总是知道怎么处理。但它们擅长告诉你哪些组件实际处理了输出或输入（比如子系统、类别加发送者镜像信息），而触发的错误路径可以揭示解析假设、类型期望和IPC协议。

这对目标选择来说是相当不错的投资回报率——工具设计及下一步模糊测试目标。AI代理通常可对日志执行三项边界明确的实用任务：首先提取日志行并定位字符串所在位置，通过二进制字符串定位基本块及调用者；接着检索这些调用者的相关开源代码（若存在），生成结构化摘要，包括输入参数、信任边界及解析过程；最后将该摘要输入模糊测试规划或检测工程，确定监控目标，识别攻击者可控参数以及可能的故障模式。

这一点也与开发概念验证(POC)相关，比如本地化的端点测试或检测。

所以当你的特权AI流程识别到新的不可信输入边界或新的特权XPC入口点时，可将其转化为遥测指标需求和关联规则。通常这就是把漏洞研究转化为防护覆盖的方法。过去我们只能手动干。

同样的思路也适用于早期的内核扩展。通过比对KX差异，研究人员发现了外部方法表的变化，展示了IOKit驱动中新增或修补的入口点。这个模糊测试规划器生成的不是漏洞利用代码（除非你刻意让它那么做），而是一套方案：首先枚举候选接口（系统调用处理程序、IOKit用户客户端、XPC服务、解析器），专注于攻击者可控输入跨越信任边界的入口点；然后生成最小化的测试框架，比如包含调用路径的测试驱动、权限要求与预期的输入形状，确保目标实际可达且可大规模复现；接着AI通过从字符串提取字典、从日志挖掘参数或基于观测流量自举来推荐种子策略，使覆盖率快速提升，而不是从零开始变异。

请注意，如果我提供的子集中没有该命令，你可以自行添加或连接AI搜索聊天机器人，让自动查找。但我不建议直接允许你的笔记本电脑随意运行任何程序或搜索任何内容而不加约束。

但如果你有测试用的MacBook等设备，尽管去试试看，效果会很不错。种子策略用于选择和生成初始的代表性输入集，能提升模糊测试覆盖率并引导变异指向高价值的代码路径。最后，AI定义了成功指标，比如崩溃分类、检测器信号和唯一的堆栈轨迹。

这样你就可以识别进展，最好把这些结果转化为可操作的研究。

局限性：成本、幻觉、信任问题

当前AI工作流程的不足之处在于，当你要求完整的漏洞利用链时，说实话我的研究水平还没达到能发现完整提权漏洞链以及完全绕过macOS安全机制的程度。我花了大量时间专门研究并测试操作系统的工作原理，这些实践经验本身也很有价值。但要注意，这些模型偶尔会虚构操作步骤，特别是当你接入AI聊天机器人时。所以我尽量保持高度约束——考虑到这些子系统的庞大性、我传输的信息量以及处理费用。

我设置约束条件包括漏洞类别预测和测试工具设计，这些是高价值输出，而人类负责漏洞可利用性评估。这种做法也能让大型AI模型（主要是我用的那些，运行良好）内置机制锁定用于攻击性研究。如果你和我一样不完全相信自己的第一直觉，验证你的想法是否合理会很有帮助。

关于如何利用高质量公共作品中的漏洞——比如Patrick有大量著作。我使用AI工具验证假设是否与既定技术和他发表的分析一致，以及我自己的笔记。这还没集成到OSS项目中，但我可能会添加，因为我经常做这些合理性验证。

此外，该肯定的地方要肯定。我特意将OSS Sensor授权为GPLV3协议，因为我从Patrick等人的GPLV3授权作品中受益匪浅，以及许多其他人的工作。保持代码开源共享能帮助他人以同样的方式构建和学习。

简而言之：即便是部分源代码也很有价值，结合二进制分析，你就能逆向苹果的子系统，且准确度惊人。但也存在限制：不完整的开源版本发布、代码混淆和授权问题。你需要一个设计上就合规的流程——通过本地索引和源码变更的谨慎处理，再加上溯源追踪功能，让你能解释每个结论的由来。

总结：学到了什么

我想传达的核心观点是：Apple的部分开源代码可以视为传感器数据流。虽然不是完整系统，但能持续提供变更信号。当你持续处理这些信号时，它们的价值会大幅提升。我展示的工作流将这些传感器数据转化为优先级研究队列，虽然使用AI代理，但遵循非常特定的理念：模型不是上帝，而是使用Juno Analyst的工具。工作通过确定性工具完成，模型负责整合证据、检索正确上下文并生成结构化输出，这使人类工作效率更高且更一致。

因此需要通过差异分析形成可验证的假设。你可以从源代码差异或二进制文件入手，分析有意义变更和潜在信任边界，然后将其转化为关于某类漏洞的可测试假设——大小计算问题、解析假设、策略控制及接口层面的变化。接着构建最小测试驱动确保路径可达且可复现，为模糊测试和验证做好准备。

关键在于仅靠开源差异分析是不够的。我们需要用另外两个信号来增强：二进制文件（反映实际发布内容）和系统日志（统一日志记录是个很好的投资回报支点，可以查看哪些组件实际处理了输入以及触发了哪些错误路径）。

Buzz规划器组件就是个例子，展示了如何保持实用性和有限性。它不生成漏洞利用代码，而是生成计划。它会告诉你哪些攻击面重要、如何快速触及它们、用最小化工具如何观察输入以使测试覆盖率快速提升、如何评估结果以便识别发现。重要的是，它承认了局限性。

开源版本并不完整，二进制文件可能不透明，模型可能会产生幻觉。这就是为什么一切都基于证据，设计上追踪并符合预先规划。

因此我本人在整个过程中暂停了。我使用过像ChatGPT的深度研究这样的工具，但考虑到成本限制，我需要手动审查，尤其是那些我可能无法理解的内容。虽然这些系统很优秀但会出现幻觉，再加上我可能并不总是清楚自己在说什么，所以这些人工检查是必不可少的。

最后，这不仅仅是一个攻击性研究的效率优化技巧。该流程能缩短本地化威胁检测的工程周期。当你能快速识别变更内容及行为与接口的变动时，就能更快地更新监控、优先级排序和分级处置，并将平台变动转化为检测覆盖率。这些正是我所关注的成果——让macOS漏洞研究更具扩展性、更易于教学且更具操作实用性。

后续方向与QA

关于后续发展方向，我还有更多内容要分享。我发布了一份名为《Ret to Read》的苹果安全通讯。毕业后，我大约每月或每两个月发布一次。非常感谢给我这次演讲的机会，希望大家喜欢。如果有问题请告诉我。

提问：你谈了很多关于作为初级分析师，因为成本和人工审查信任的问题，需要改变什么才能让你开始分配更大的任务、让它承担更多？只是回顾一下Dan的演讲。随着技术不断进步，我很幸运拥有大量测试设备。

我有大量测试用的Mac和iPad，为每类测试都准备了专用设备。因此我能委派某些普通人难以完成的工作。但细想之下，这些研究设备价值数万美元。我不禁思考：我在讨论技术普及性，但普通研究人员能否获得这些设备支持？他们负担得起吗？当我尝试缩减规模以便随时随地研究时，我发现做不到。当我开始查看令牌和成本限制时，伙计，输入整个操作系统子系统时费用会迅速飙升。所以我会说：直接给我一大笔钱。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《用AI提升macOS漏洞研究：一个开源工具与工作流程》