文章总结： 研究人员开发了PatchDiff-AI系统，使用大语言模型(LLM)进行Windows补丁漏洞的自动化分析。该系统采用多智能体架构，包括Windows内部机制智能体、逆向工程智能体和漏洞研究智能体，能够自动识别已修补漏洞的根本原因并生成详细报告。测试结果显示，系统能在88.6%的情况下正确识别可执行文件，83.9%的情况下找到易受攻击函数，71.4%的情况下找出正确根本原因。文章通过四个案例研究展示了系统的优势和局限性，包括成功分析NTFS漏洞和生成概念验证代码的能力。系统成本约为每份报告0.14美元，为安全团队提供了快速分析漏洞的实用工具，可用于防御和攻击目的。 综合评分： 88 文章分类： AI安全,漏洞分析,二进制安全,安全工具,自动化
LLM 驱动的 Windows 补丁漏洞自动化分析
Maor Dahan
securitainment
2025年12月17日 14:56 中国香港
执行摘要
- 在本研究中，我们探索了使用大语言模型 (LLM) 来查找已修补漏洞的根本原因。
- 我们开发了一个名为 PatchDiff-AI 的多智能体系统，能够自主分析 Patch Tuesday 漏洞的根本原因并生成详细报告。
- 这种分析可以帮助安全团队几乎即时地分析漏洞，无论是用于防御还是攻击目的。
- 通过使用多种策略，我们成功地将系统调优至超过 80% 的成功率，实现了完全自动化的报告生成,包括攻击向量分析和触发流程。
Patch Tuesday → Exploit Wednesday
Microsoft 的常规更新周期以 Patch Tuesday 为核心——每月第二个星期二，公司会发布一份完整的 CVE 列表及其相应修复。这些修复以 Microsoft Standalone Update (MSU) 文件格式发布，通过修补或替换核心系统文件来应用更新。
Patch Tuesday 之后通常会出现所谓的 “Exploit Wednesday”,攻击者会竞相发掘 Microsoft 已创建补丁的漏洞。通过对更新后的二进制文件执行二进制差分，攻击者可以快速定位潜在的安全问题，并在组织广泛部署补丁之前尝试利用这些漏洞。
以类似方式，防御者通常也会赶紧分析这些补丁，以了解漏洞的根本原因，从而创建检测和缓解措施。
补丁差分的现状
如今，补丁差分是一个繁琐的过程。要成功识别易受攻击的代码片段，研究人员需要：
- 识别怀疑包含漏洞的文件
- 执行二进制差分以识别更改
- 从其他常规代码更新中隔离与安全相关的更改
- 分析可疑部分并理解根本原因
- 动态检查调用流程以找到潜在的触发途径
- 评估补丁修复的完整性
这些步骤有时可能需要数周时间，而每月同时发布的大量漏洞进一步加剧了这个问题。
我们着手寻找一种更好的方法——一种能够让研究人员快速分析已修补漏洞并理解其根本原因的方法。
使用 LLM 进行补丁差分分析
大语言模型 (LLM) 可以基于其训练数据和用户输入，统计地生成合理且准确的信息。但存在一些局限性，包括有限的上下文窗口 (影响其能处理的数据量和运营成本) 以及臭名昭著的模型幻觉。
多年来，关于 LLM 对安全领域漏洞评估的贡献 的论文已经发表了许多。如今，LLM 在分析闭源软件时似乎仍有困难，但在开源和 Web 漏洞方面表现要好得多，其中共同点是存在人类可读代码。
OpenAI 的 Aardvark 和 Claude Code 安全审查器 仍然依赖于可读的源代码。另一方面，Google Project Zero 的 Big Sleep 旨在发现零日漏洞。这两种方法都没有将二进制文件作为闭源进行分析。
介绍 PatchDiff-AI
我们的研究采用了一种不同的方法，使用 LLM 进行安全补丁的根本原因分析 (RCA)。我们的理论 (似乎已得到验证) 是，二进制 “差分” 提供的额外上下文将显著增强 LLM 理解复杂低级代码的能力。
为完成此任务，我们开发了一个多智能体系统,可自动分析特定平台的 Microsoft Knowledge Base (KB) 更新 (图 1)。我们称之为 PatchDiff-AI。
图 1: 我们的多智能体系统 PatchDiff-AI 示意图
PatchDiff-AI 定义
-
Windows 内部机制智能体
— 该智能体使用检索增强生成 (RAG) 管道，后端是一个包含 Windows 二进制文件及其功能元数据的向量存储。这使智能体能够显著缩小分析范围，专注于最相关的组件。
-
逆向工程智能体
— 该智能体使用先进的逆向工程工具来分析和差分相关文件。它会将找到的产物附加到整体上下文中供其他智能体使用。
-
漏洞研究智能体
— 该智能体协调分析，收集上下文中存在的所有产物和其他信息，并生成一致的报告。
GitHub 仓库： https://github.com/akamai/patchdiff-ai
方法论
由于上下文窗口限制和幻觉问题，尽可能有效地使用 LLM 时，提供相关且简洁的上下文至关重要，从而在隔离易受攻击代码组件的任务中保持高准确性，同时降低运营成本。
分而治之
我们实现中的一个关键细节是将分析划分为几个更小且聚焦的任务，最终作为智能体运行：
- 检索有关 CVE 的信息以创建配置文件
- 下载相关更新并对基础版本文件应用增量
- 创建 Windows 内部机制 AI 智能体，使用漏洞元数据隔离相关文件
- 创建逆向工程 AI 智能体，可以：
- 反汇编并应用符号，然后导出它们用于二进制差分
- 关联二进制文件并识别更改和调用流程
- 精确定位易受攻击的代码块
- 创建漏洞研究 AI 智能体，遍历可能的漏洞路径以交叉关联并找到最佳可能结果
这种划分的主要优势之一是，它允许我们为每种任务类型使用特定模型;OpenAI o4-mini 在文件元数据丰富化方面表现出色，而 OpenAI o3 则用于对可疑易受攻击代码的最终深度分析。
为任务选择合适的模型有双重好处 — 首先是准确性，其次是成本。
上下文丰富化
LLM 是 “记住” 大量信息的机器。使用提示调用 LLM 将调整其在提示上下文中提供最相关信息。
我们能够向 LLM 提供的关于已修补漏洞的每一条信息都将有助于生成更准确的响应，并增加定位易受攻击代码的机会。然而，关于漏洞的模糊信息将导致结果不佳 (如果有的话)。
在分析过程中使用漏洞元数据丰富上下文被证明至关重要。为实现这种丰富化，我们向 LLM 提供了 KB 描述、系统文件描述和二进制差分数据。这种方法使我们能够缩小需要分析的更改数量，从而减少上下文长度和与 LLM 的迭代次数。
结果
为了评估我们的框架，我们检查了模型正确定位以下内容的能力：
- 与 CVE 对应的易受攻击可执行文件
- 可执行文件内的易受攻击函数
- 漏洞的根本原因并正确解释
基于这些参数，我们分析了 Windows 11 24H2 最近三次 Patch Tuesday 发布。在运行我们的工具并生成自动化报告后，我们手动检查了选定的结果，并确定了最终模型响应的准确性。
在优化上下文并调整不同任务的各种模型后，我们最终实现了以下结果：
- 在 88.6% 的情况下识别出针对相关 CVE 进行修补的正确可执行文件
- 在 83.9% 的情况下找到正确的易受攻击函数
- 在 71.4% 的情况下找出漏洞的正确根本原因
如果我们排除因上下文不足导致的报告生成失败 — 例如静态分析工具崩溃或无法应用增量补丁 — 我们可以估计模型在给定正确代码块时的成功率。在这种情况下，当在上下文中提供正确代码块时，LLM 成功率约为 96% (图 2)。
图 2: CVE 选定报告的评估结果
来一份 CVE 报告，摇匀，不要搅拌
因此，我们遇到了几个有趣的用例，我们想要分享并深入研究。每个用例都具有相同的报告结构：
- 构成报告的 CVE 详细信息
- RCA — 报告的核心
- 补丁前后的代码片段
- 如何触发漏洞的自顶向下概述
- 补丁的突出描述
- 可以利用该漏洞的攻击向量
- 对漏洞影响的清晰、详细说明
此外，每份报告的最后一部分都试图挑战补丁的有效性，并审查其可能的绕过方法。
案例研究
在以下四个案例研究中，我们将探讨几个有趣的案例，突出显示我们的框架在哪些方面表现出色、在哪些方面遇到困难，以及在哪些方面完全失败。
案例 #1: 挂载并攻破
我们分析的漏洞之一是 CVE-2025-24991,根据 Microsoft Security Response Center (MSRC) 的说法，这是一个 “Windows NTFS 中的越界读取允许授权攻击者在本地泄露信息” 漏洞。另一条信息来自 FAQ，其中指出，”攻击者可以欺骗易受攻击系统上的本地用户挂载特制的 VHD，然后触发该漏洞。“
现在，该漏洞显然与 NTFS 组件相关，这明确意味着涉及 ntfs.sys。
另一个线索是该漏洞通过挂载 VHD 文件触发。手动分析补丁可能至少需要数小时 — 但使用 PatchDiff-AI工具将其缩短至几分钟。当没有明显路径来识别根本原因时，我们的工具同样有效，就像这个案例一样，这一事实进一步放大了这一点。
在这种情况下，系统声称在 KB5053598 更新中对文件所做的 17 个最相关更改中找到了根本原因。完整报告可以在我们的 GitHub 仓库中找到，我们的评估过程如下。
首先，我们的工具输出相关组件，确实是 ntfs.sys,以及相关函数 ReadRestartTable()。它还输出了关于该逻辑设计功能的简短说明 (图 3)。
Microsoft Windows NTFS driver (ntfs.sys)
Affected routines: ReadRestartTable() and its consumer
InitializeRestartState().
参考 3: ntfs.sys 函数逻辑说明
接下来，我们将漏洞类别关联到 CWE 索引，在本例中为 CWE-125: Out-of-bounds Read。这将帮助我们了解 LLM 在撰写此报告时正在寻找什么漏洞。
参考 4 是我们工具 RCA 的实际输出。它清楚地概述了出了什么问题，并精确地指出了问题所在。
ReadRestartTable() processes a restart area that was previously
retrieved from the NTFS transaction log (LFS). The function first
validates the outer log record with NtfsCheckLogRecord(), then calls
NtfsCheckRestartTable() to validate the embedded restart table.
Buggy offset computation (pre-patch)
1. v9 = *(QWORD *)(a4 + 72) // ptr to restart area
2. offset_to_tbl = *(WORD *)(v9 + 4) // value comes from log
3. NtfsCheckRestartTable(v9 + offset_to_tbl, size, cookie)
The code trusts the 16-bit field at offset +4 of the restart area to
locate the first restart table. If an attacker supplies a crafted
restart record in which this field is smaller than the actual header
size, NtfsCheckRestartTable() will be invoked on a memory range that
starts inside the header instead of at the real table. Because the
size argument (derived from *(DWORD *)(a4 + 64)) is unchanged, the
routine reads past the caller-supplied buffer, disclosing adjacent
kernel memory.
Additional consequence: the return value (pointer returned to the
caller) is likewise computed from this untrusted field, so callers
such as InitializeRestartState() may later copy the out-of-bounds data
into pageable pool that is accessible to user mode via other
interfaces.
Patched behaviour
The patch discards the header-supplied offset. Instead it derives the
correct header length from the number of client entries:
hdr_len = (clients <= 1) ? 40 : (8 * clients + 32);
NtfsCheckRestartTable(v10 + hdr_len, ...);
If the validation fails, execution now jumps to new corruption
handling code that raises STATUS_DISK_CORRUPT_ERROR before any out-of-
bounds access can occur.
参考 4: PatchDiff-AI 的 RCA 输出
使用 IDA 和 BinDiff 检查这些发现显示，这确实是正确的位置。我们知道这一点，因为 Microsoft 使用功能标志来选择退出漏洞修复;这样，在出现意外行为的情况下可以将其恢复 (图 5)。
图 5: Microsoft 功能标志 (绿色块)、修复路径 (蓝色块) 和易受攻击路径 (红色块)
在报告中，我们可以找到函数易受攻击部分的反编译代码片段,并审查易受攻击的代码 (参考 6)。
```c
// pre-patch (simplified)
WORD offset = *(WORD *)(RestartArea + 4);
if (!NtfsCheckRestartTable(RestartArea + offset,
Total - offset, Cookie))
NtfsRaiseStatus(...);
// post-patch
WORD clients = *(WORD *)(RestartArea + 14);
ULONG hdrLen = (clients <= 1) ? 40 : (8 * clients + 32);
if (!NtfsCheckRestartTable(RestartArea + hdrLen,
Total - *(WORD *)(RestartArea + 4),
Cookie))
NtfsRaiseStatus(...);
*参考 6: 函数易受攻击部分的反编译代码*
报告的一个亮点是**自顶向下触发**部分。在此部分中，LLM 建议触发漏洞时必须采取的可能步骤 (如适用),甚至提出实际利用细节 (图 7)。
- User mounts or accesses a volume containing a malicious $LogFile.
- NtfsMountVolume() → NtfsRestartVolume() → InitializeRestartState().
- InitializeRestartState() reads the first restart area and calls ReadRestartTable().
- ReadRestartTable() uses the untrusted 16-bit offset to pass an out-of-range buffer to NtfsCheckRestartTable(), which performs the actual out-of-bounds memory read.
- The leaked data is later copied back into attacker-controlled disk structures or user-mapped memory, allowing disclosure.
*参考 7: LLM 对如何利用该函数的建议*
**当结合后续提示时，我们的工具进一步分析反编译的代码并发现更多信息，甚至可以建议最小概念验证 (PoC)**。
另一个有用的见解可以在**攻击向量**部分找到，它提供了漏洞利用的高层视图。它让我们了解漏洞的范围以及攻击者需要什么来利用它 (图 8)。
Local attacker crafts an NTFS image (or directly edits $LogFile on an existing volume) so that the Restart Area field at offset +4 contains an undersized value. Mounting or otherwise activating the volume on a vulnerable system triggers the OOB read in kernel context.
*参考 8: LLM 输出的攻击向量部分*
其余部分提供了对补丁本身及其对系统的安全影响的更一般描述。然而，在最后一部分，我们要求 LLM 尝试挑战补丁，看看是否有可能快速找出修复中的另一个漏洞。在这种情况下，它评估补丁是完整的："*所有错误路径现在在任何潜在越界访问之前引发。*"
### 案例 #2: 当星星对齐时
对于专注于检测或缓解的团队来说，针对自动生成的 IDA 数据库和 BinDiff 输出评估报告是有价值的，通常也是足够的。然而，我们的方法更进一步 — 还可以被证明对攻击目的有用，因为在某些情况下，系统可以超越分析，实际生成可工作的漏洞利用。
例如，**CVE-2025-32713**,这是一个在 2025 年 6 月更新 (KB5060842) 中修补的漏洞，被描述为："*Windows Common Log File System Driver 中的基于堆的缓冲区溢出允许授权攻击者在本地提升权限*。" 在大约两分钟内，我们的工具生成了一份报告，将问题追溯到 `CClfsLogFcbPhysical::ReadLogBlock()`。
此时，有两种方法来应对利用的挑战：
1. 手动逆向该函数及其调用者，直到用户模式调用
2. 让 LLM 为我们完成并自主编写 PoC
然而，正如通常情况一样，还有第三种选择：混合方法。让 LLM 完成逆向工程的繁重工作，而您确定间接代码流并解析二进制逻辑部分之间的复杂连接。这将使 LLM 产生更好的结果。
使用这种实践，我们在短短几个小时内就实现了蓝屏死机 (BSOD) 漏洞利用 (图 9)。
*参考 9: CVE-2025-32713 PoC 执行期间的 BSOD*
理解漏洞触发流程的旅程始于评估 RCA 部分中描述的建议易受攻击代码。在意识到补丁试图修复安全缺陷后，我们将调用流程分析到输入/输出控制 (IOCTL) `0x80076832`。
在寻找用户模式对应项时，我们找到了两个候选者，因为 `clfsw32.dll`导出函数 `ReadLogRecord`,该函数具有调用此 IOCTL 的直接路径 (图 10)。
*图 10: 调用流程图，从用户模式的导出方法开始一直到内核驱动程序 (使用 IOCTL 调用)*
在每一步，我们都评估了 LLM 如何帮助逆向和分析逻辑，考虑到它接受了部分此类知识的训练。图 11 显示了它如何解决 `v4`的条件要求，即我们提供的缓冲区大小。
*图 11: 使用 LLM 分析验证检查*
尽管我们目睹了 LLM 能够发现的一些出色观察结果，但也有一些情况下结果具有误导性。回到 CVE-2025-32713，在其一个响应中，我们的报告包含图 12 所示的引用。
“crafts the log header so that the page size (v48) exceeds the supplied buffer” “`
参考 12: LLM 的误导性结果输出
这个响应相当令人困惑，最终使我们偏离了理解如何触发易受攻击代码的方向。事实上，它引导我们进入了一条完全无关的研究路径 (我们尝试操纵已经有缓解措施的 .blf文件结构)。我们后来创建了具有不同物理和逻辑每扇区字节数的虚拟磁盘，并通过调试分析了它们的行为。
可以公平地说，LLM 处理了大部分工作，但需要经验丰富的研究人员的密切监督。LLM 是辅助人类的工具，只要辅助提供正确。
模型偶尔会偏离到非生产性方向，人类指导对于保持其在正轨上至关重要。话虽如此，结果不言自明:LLM 正确识别了易受攻击的代码，准确追踪了调用流程，并解释了 v27的错误赋值如何导致 CcCopyRead()中的溢出。
案例 #3: 大海捞针
在某些情况下，您需要谨慎对待 LLM 输出。幻觉不是 LLM 的唯一风险;各种 LLM 界面 (例如，”ChatGPT 可能会犯错误。检查重要信息。”) 中反复强调了这一点。
这里也适用同样的谨慎，尽管系统试图验证其输入和输出，并检查多条路径以识别根本原因。有时几乎不可能，因为条件太宽泛和模糊。
让我们以 5 月 KB5058411 更新中的 CVE-2025-29974为例。MSRC 关于该漏洞的信息页面指出，”Windows Kernel 中的整数下溢 (环绕或回绕) 允许未经授权的攻击者通过相邻网络泄露信息“,这可能有些模糊。
接下来，我们看到 MSRC 页面提到攻击者必须在附近;也就是说，攻击者必须在接收无线电传输的范围内。这显然是在讨论信息的气隙渗透。然而，不清楚的是如何渗透，或者通过什么硬件。这种缺失的上下文降低了获得有效报告 (如果有的话) 的机会。
关于 CVE-2025-29974，我们执行了我们的工具并收到了一份关于两个未命名函数的报告：sub_1408E6D3C和 sub_1408FAD58。为方便起见，我们将它们称为 primary()和 secondary()。图 13 是这些函数的 BinDiff 视图，很容易看出它们非常不同……如果你问我的话，太不同了。
图 13: 使用 PatchDiff-AI 自动创建的更改 BinDiff 视图
经过仔细检查，我们可以将正确的 primary函数识别为 sub_1408E7738,这是一个完全不同的方法，位于不同的地址。造成这种混淆的主要原因是，通过此更新对 ntoskrnl.exe进行了高度修改。共有 3,791 个函数被修改，这导致找到正确的前后配对的概率急剧下降。
此案例报告提供的置信度水平为 0.2，表明报告定位到正确漏洞的置信度为 20%。这个置信度水平以及大量代码块修改，与较差的结果相对应。
案例 #4: 过于易受攻击
在某些情况下，组件有多个由更新解决的漏洞。这并不罕见，因为单个逻辑缺陷可能包含不同类别的漏洞链。
如果我们看一下 KB5055523 (2025 年 4 月) 更新，我们可以找到一组漏洞，分别命名为 CVE-2025-24058、CVE-2025-24060、CVE-2025-24062、CVE-2025-24073 和 CVE-2025-24074 (图 14)。它们都与桌面窗口管理器 (DWM) 相关，并且都是 “CWE-20: 输入验证不当” 的结果，这使得它们对模型来说难以区分和模糊。
图 14: 2025 年 4 月更新漏洞的部分列表
使用 LLM 存在权衡。它们的共同点是成本因素。即使所需上下文不一致，LLM 也会尝试在一次迭代中完成任务。要获得更准确的结果，我们必须通过启发式方法评估结果，并优化上下文，以便它可以创建更好的变异。
我们使用 2025 年 4 月更新漏洞的报告 来评估此类用例的结果。通过比较根本原因和附加信息，我们能够理解多个漏洞如何通过其分析影响 LLM (表)。
| CVE | 主要错误函数 | 漏洞类别 | 根本原因 |
| — | — | — | — |
| CVE-2025-24074 | COcclusionContext::PreSubgraph CDDisplaySwapChain::PresentMPO CLegacySwapChain::Present | 由输入验证不当导致的基于堆的内存损坏 / 动态数组增长期间的整数溢出 (CWE-20，导致 CWE-787)。 | 相同的 PreSubgraph 整数环绕触发遮挡信息缓冲区溢出 |
| CVE-2025-24073 | COcclusionContext::PreSubgraph | 基于堆的缓冲区溢出 / 由输入验证不当导致的整数溢出 (CWE-20，导致内存损坏) | 相同的 PreSubgraph 整数环绕触发遮挡信息缓冲区溢出 |
| CVE-2025-24060 | COcclusionContext::PreSubgraph COverlayContext::ComputeOverlayConfiguration | 输入/边界验证不当导致越界堆写入 | 相同的 PreSubgraph 整数环绕触发遮挡信息缓冲区溢出和另一个溢出 |
| CVE-2025-24058 (dwmcorei.dll) | CLocalAppRenderTarget::EnsureRenderSurface | 释放后使用 / 类型混淆，由于将释放的对象 指针作为隐式 this 指针传递 (CWE-416,CWE-843) | 释放的 CD3DDevice 指针重用为 CDeviceManager this |
| CVE-2025-24058 (dwmcore.dll) | CLegacyRenderTarget::CollectOverlayCandidates COverlayContext::ComputeOverlayConfiguration | 基于堆的缓冲区溢出，由于对调用者提供的列表长度的输入验证不当 (CWE-20，导致 CWE-122) | 使用 CollectOverlayCandidates 的堆溢出 |
| CVE-2025-24062 | CCompositionSurfaceBitmap::AddOcclusionInformation CSurfaceBrush::AddOcclusionInformation | 指针截断 / 输入验证不当导致释放后使用 / 权限提升 (CWE-20，与 CWE-704 相关) | 参数扩展为 __int64;添加了 IsOverlayCandidateCollectionEnabled() |
通过 LLM 确定的多个漏洞及其 RCA
该表仅是报告内容的反映。对 2025 年 4 月更新漏洞的评估发现了 CVE-2025-24074、CVE-2025-24073 和 CVE-2025-24060 的重复。这三个都引用了相同的函数，只有细微的更改或添加。
CVE-2025-24058 (dwmcore.dll) 似乎与 CVE-2025-24060 对 ComputeOverlayConfiguration的考虑重叠。然而，CVE-2025-24058 (dwmcorei.dll) 和 CVE-2025-24062 似乎解决了完全不同的根本原因。
由于 LLM 不是确定性系统，即使输入相同，输出也可能有所不同。我们可以观察到输入上下文的变化，无论多么轻微，都会影响 LLM 的输出并导致两份不同的报告。
价格标签
PatchDiff-AI 基于监督式多智能体架构，使用不同的 LLM 模型，以在保持高准确性的同时降低成本。使用 OpenAI 模型生成一份报告的成本细分导致最高成本为 1.43 美元。
实际上，我们从 3 月、4 月和 5 月更新中生成了 131 份报告，仅针对 Windows 11 24H2 x64 进行过滤。平均成本约为每份报告 0.14 美元。考虑到每天 (如果不是每小时) 需要应对多少漏洞，这些成本在规模化时可能很大。
当启用完全自主功能时，例如 Windows 内部机制和漏洞研究智能体中的扩展优化，价格计算可以设定上限;但是，由于系统的非确定性性质，它不能有平均值。
结论
在网络安全领域使用 AI，特别是 LLM 的未来是光明的。LLM 可以轻松地将一个非常复杂但有方法的过程转变为简单的工作流程，并且可以集成到各种安全团队的管道中。
我们的研究表明，漏洞的完全自动化 RCA 不仅是可能的，而且是实用的 — 具有有意义的准确性和合理的成本。
通过将问题分解为微任务，并将其调整为结合 Windows 内部机制推理、逆向工程工作流程和特定漏洞分析的专业化多智能体架构，我们使 LLM 能够克服其传统限制。这种实践 (以及 PatchDiff-AI 配套工具) 也可以推广到其他产品和平台。
使用我们的系统，安全团队可以创建全面的检测，有效缓解漏洞，并为其系统创建渗透和回归测试。此外，我们的系统可以帮助缩短触发已知漏洞的过程，从而在易受攻击的共享代码库中实现进一步的研究和变体发现。
Patch Wednesday Root Cause Analysis with LLMs
免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。
查看原文：《LLM 驱动的 Windows 补丁漏洞自动化分析》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论