用 Malcat 对 LLM 进行恶意软件分流与静态脱壳基准测试

一些背景

为什么？

我刚开始编程时，写的第一个程序（用的是 Turbo Basic，没错）是一个 对话代理：一个简单的文本循环，里面大约有 50 个 if-else 分支。它感觉鲜活而神奇，从那以后我就一直对人工聊天程序保持着浓厚的兴趣。快进 30 年到现在：随着近期大语言模型的进步，我多少又找回了 9 岁时那种兴奋和敬畏的感觉。

所以你可以轻易想象，自从 Malcat 的 MCP 服务器 发布以来，我 大量地玩起了 LLM，分析各种各样的恶意文件，既是为了工作，也是为了乐趣。而我至今仍对实时观察 LLM 着迷，看着它们关联 Malcat 的检测结果、追踪有趣字符串的引用、反编译函数，整个过程就像活了一样。为了让整个流程更加顺畅，我开发了一个 恶意软件分流流水线，大致长这样：

整套东西运行得非常好，但有一个问题一直困扰着我：我应该在流水线里用哪个模型？所有模型都不错（尤其是和我第一个 BASIC 程序相比 :)，但我想知道哪一个 最适合恶意软件分析，并且最好是 相对便宜的那个。当然，业内有各种指标（每 token 成本、参数数量）和基准（SWE、HumanEval 等）。但它们并不能说明全部情况，而且也不总是适用于 恶意软件分析（这类任务输入 token 量很大，还需要一些事实背景知识）。

所以我想到的显而易见的方案就是 把它们拉出来比试一番，看看哪个模型能赢。换句话说，来一场老式的 骑士比武大会:) 最后还能站着的模型，将获得在我流水线中工作的光荣资格。而且既然这次测试的结果或许对其他人和其他场景也有参考价值，我决定把结果发表在这里。

注：不要指望这是一份非常严谨的科学基准测试。这只是我针对自己的使用场景测试了一批 LLM 而已。

TL;DR: 如果你赶时间，可以直接跳到分流基准测试的结果 这里 和静态脱壳基准测试的结果 这里，或者直接阅读 我的结论。

规则 📜

每一场比武都需要一套规则。否则就只是群殴而已。因此，以下是我们这场比赛的规则：

1. In Malcat we trust（我们信赖 Malcat）：
   模型只能访问 Malcat 的 MCP 服务器。
2. 不可压缩：
   我们想发挥模型的原始能力，因此会屏蔽掉 OpenCode 或 Codex 中可能存在的一些功能，比如上下文压缩。
3. 须有过目不忘之能：
   我们需要大的上下文窗口，因为反汇编 / C 代码列表 非常庞大。所以上下文窗口小于 1M tokens 的模型不得入场。就像玩过山车的身高要求一样。
4. 不可妄言：
   出现幻觉将被倒扣分。
5. 简洁为要：
   模型会有一个总的 token 上限。一旦达到上限，它们会收到最后一条消息，要求输出结果。为什么要设上限？嗯，我又不是印钞机。而且也没人愿意等好几个小时才看到一份分流报告。
6. 须竭尽全力：
   如果分析因为某些原因失败了（例如可能是 OpenRouter 的问题），模型还有（仅此一次的）第二次机会。

比赛将分为两个不同的项目：

• 分流赛
  ：精心挑选了 2 个干净样本、1 个 PUA 样本和 6 个恶意样本，覆盖从 PE 恶意软件到恶意 office 文档，包括 .NET 和 Golang。LLM 的任务是撰写一份简单的分流报告并 为其结论提供证据。模型将从以下几个方面进行评估：
• 最终判定
  （7 分）：这里我们不仅评判结果，也评估证据的相关性
• 提取的 IOC
  （5 分）：这里我们想看看 LLM 挖得有多深
• 耗时
  （4 分）：在 5 分钟以内，每减少 1 分钟得 1 分
• 成本
  （4 分）：0€ 得 4 分，0.25€ 得 3 分 ⋯⋯ 直到 1€ 及以上：0 分
• token 上限
  ：500k
• 静态脱壳赛
  ：在这里，LLM 的任务是 仅使用 Malcat及其变换功能，对 5 个精心挑选、带有有趣壳链的恶意软件样本进行静态脱壳。这里的目标是评估模型理解代码、定位异常以及调用复杂工具的能力。评分规则如下：
• 提取的载荷数
  （12 分）：成功提取了多少个载荷。当载荷已被找到，并且 / 或者解密参数已被逆向出来，即便最终没有取得最终载荷，我们也可能给予部分得分。
• 耗时
  （4 分）：在 5 分钟以内，每减少 1 分钟得 1 分
• 成本
  （4 分）：0€ 得 4 分，0.50€ 得 3 分 ⋯⋯ 直到 2€ 及以上：0 分
• token 上限
  ：800k

我完全清楚这套评分是带有主观性的。它对应的是我 个人对模型的期望，你的期望也许完全不同。分数会被拆解成各个组成部分，所以你大可以使用自己的权重！

武器 ⚔️

这并不是一项让 LLM 直接处理原始文件的基准测试，也不是对各种恶意软件分析平台的中立比较。对于每个样本，每个模型都可以访问（且仅能访问）通过 MCP 服务器暴露的 Malcat，并使用相同的分析功能集。为了可复现性，下面列出了 MCP server 向每个模型暴露的内容：

文件格式解析：

模型可以解析 60+ 种文件格式并访问其结构、符号和元数据

文件提取：

模型可以对大多数归档、程序和安装包类型 切分并提取子文件

代码分析：

模型可以访问重建的 CFG，并能够 反汇编和反编译函数、跟随（间接）引用、调用者 / 被调用者等

数据分析：

模型可以访问 提取的字符串列表（按得分排序，因此最重要的字符串会优先呈现），并可以查询文件中的 熵值

模式匹配：

Malcat 会扫描超过 400k 个常量、2.5k 条 YARA 签名和 200+ 种异常。模型可以访问扫描结果，更重要的是，可以访问 模式命中位置

Kesakode 查询：

每次分析都会以一次 在线 Kesakode 查询 开始。这会将每个函数标记为 clean、library、malware 或 unknown，在实践中对模型帮助很大

Malcat 变换：

模型可以对文件的任何部分应用一系列数据变换（CyberChef 风格），可在 80 多种可用算法中进行选择

内置脱壳器：

Malcat 提供了若干 专用脱壳器，例如 Donut 脱壳器或 UPX 脱壳器。这在第二个挑战中应该会派上用场。

模型 无法执行 shell 命令、运行 Python 脚本或进行网络搜索。在实践中，这意味着当模型成功时，结果通常来自 Malcat 暴露了正确的产物，以及模型选择检视了正确的内容这两者的结合。当模型失败时，原因可能是推理失败、模型工具使用不当，或者 Malcat 没有暴露正确的信息，或者暴露得不够清晰。

参赛选手 🦾

下面是将要测试的模型列表。如需了解更多信息，可以参考它们在 OpenRouter models page 上的描述：

我原本还想测试其他一些模型，但要么它们的上下文窗口太小，要么它们屏蔽了输出（说的就是你 nova-premier-v1），要么它们在测试期间的可用性太不稳定（比如那个出色的 deepseek-v4-flash，我猜是太受欢迎的受害者）。

分流大赛

让我们从第一个挑战开始：为 9 个精心挑选的二进制文件撰写分流报告。我认为这个功能对 SOC 团队会非常有用：在几分钟内你就能获得一份第二意见，这对每个人都很有价值。提示词大致如下所示（为了清晰起见，我省略了针对特定文件类型的指引列表）：

You are tasked to analyse a file using Malcat MCP. Your main goal is to decide if the file is malicious or clean. The result of your analysis shall take the form of a textual report.Analysis workflow-----------------Analysing a file is usually done as follows:* First, gather some high-level info about the sample, such as any framework or compiler used* List virtual and carved files* Look at the matching YARA rules, anomalies, constants* Look at the most interesting strings.* Inspect a couple of interesting functions* To complete your analysis, you may follow back the references of the most pertinent strings / constants and analyse the code referencing themPrograms may be like Russian dolls and include several sub-files/resources. If it makes sense, you may analyse said sub-files and apply the same workflow.Some file types require a specific approach: <omitted>Report generation-----------------Using this information, write a small report assessing if the file is malicious or not and its main behavior. It shall be formatted as follows:1. Generic info about the file (type, metadata, frameworks used, interesting notes)2. Inferred behavior: explain the main content/goal/behavior of the file3. Sub-files: list the sub-files that were pertinent for the analysis and some info about them.4. IOCs: any extracted IOCs5. Key detections: list all the elements that you think point towards malware6. Counter arguments: list the arguments that tell you that the file may be clean, or in the case of malware, list the possible shortcomings of your key detections7. Final verdict, with a confidence score.The report shall have the following headings: Summary, Key detections/IOCs, Evidence, Verdict.

这将测试 LLM 在文件及其子文件（如果有的话）中 浏览的能力、关联不同元素的能力，同时也测试其关于恶意软件的 知识。正如你将在下文看到的，结果相当令人印象深刻，即便考虑到为这项挑战设定的相对较低的 token 上限：500k tokens。

如果你想自己判断，我会尽量附上一些报告的链接（至少是最好的那些）

二进制 #1: Zig 下载器

样本：

9da5191c78e49b46e479cdfe20004a9d76ccc4a545deeb83e3c07f83db9cf736 (VT, Bazaar)

类型：

恶意x64 PE 二进制文件

描述：

一个签名的 Zig 下载器（参见 basic report）

作为第一个测试，我们从一个容易识别的样本开始。这是一个非常直白的 Zig 下载器，带有几个反虚拟机技巧，与我们在之前的博客文章中已经分析过的类似。由于模型 可以访问 Kesakode 在线查询，剩下需要分析的非干净字符串和函数非常少。唯一的陷阱是证书。它当然是无效的，但 Malcat 并不验证证书（是的，这在 TODO 列表上），因此模型必须忽略这个伪影。

在 IOC 部分，识别出 Zig 并提取 URL 和文件名可以获得额外分数。在判定部分，得分将根据判定结论、行为分析以及每个识别出的反沙箱技术来给出。

那么让我们看看参赛者们的表现：

感谢 Claude掏空了我的钱包，@#！除此之外，正如预期的那样，大多数模型在第一个测试中表现良好。

二进制 #2: Busybox

样本：

a344eab689251264b208fabbbf23c7d12e652e9b372957af916446142398c382 (VT)

类型：

干净Armv7 ELF 二进制文件

描述：

Armv7 busybox shell（参见 basic report）

我可以想象 BusyBox 对某些模型来说可能会有问题。它包含了一点点各种东西：磁盘访问、网络访问、一个 HTTP 服务器，甚至还有一个高熵缓冲区。由于它是一个干净的文件，得分将按以下方式给出：

• IOC：识别 BusyBox、其版本和端口可得分
• 判定：每个指向干净的证据可得分，每个描述的行为也可得分

那么让我们看看哪个模型会栽在这上面：

我不确定我是否非常公平，因为我猜某些模型认为既然判定是 干净，就不需要提供行为分析了。无论如何，规则就是规则。

请注意，DeepSeek的时间可能受到了 DeepSeek当前历史最高需求的影响

二进制 #3: Excel 宏

样本：

00189ae30ede41db97df3adb41e962c6d08534ca421cf30147b23d1cd46f2228 (VT, Malshare)

类型：

恶意Excel 文档

描述：

一个非常直白的 Excel 下载器。下载通过 Excel 宏完成，URL 经过轻度混淆（参见 basic report）

这个样本是一个非常简单的下载器，任何人在 2 秒内都能将其识别为恶意（嗯，前提是你用对了工具）。模型唯一要做的就是打开 Workbook流，并调用 Malcat 的反编译工具以获取 Excel 公式。URL 经过轻度混淆（见下文），如果模型能够对其反混淆，就能拿到全部 5 个 IOC 分数。

下载代码也被混淆了。如果检索到了 API 名称，则会在判定中获得额外加分。

不出所料，对大多数模型来说这就是小菜一碟。我有点惊讶 Claude 调用了错误的工具，但最终它把所有事情都答对了，所以我就睁一只眼闭一只眼。

请注意，DeepSeek的时间可能受到了 DeepSeek当前历史最高需求的影响

二进制 #4: SFX CAB 到 AutoIT

样本：

6b08010bf6a5148ea64abdea3edfac0ed11a27137def1f8f6e6c7a996870a8e8 (VT, Bazaar)

类型：

恶意自解压（CAB）PE

描述：

一个自解压 CAB 文件，会释放若干文件。Crap.aac是（被混淆的）启动批处理脚本，它会将释放的文件重组为一个有效的 AutoIT 可执行文件并运行（参见 basic report）

借助这个样本，我们把难度大幅提升。首先，模型必须从自解压 CAB 中读取 POSTRUNPROGRAM资源，并忽略 PE stub 的其余部分。这应当为进入 CAB 归档提供一个入口点。然后它需要打开 CAB 归档、定位批处理脚本、对其反混淆，并获取重组 AutoIT 文件的正确命令。说实话，我并不期望任何模型能在仅 500k tokens 内做到这一点。但这将对它们的工具调用能力构成考验。

如果链条中的所有技术和文件名都被识别出来（CAB SFX、AutoIT 和批处理脚本），我会给满分的 IOC 分数。判定方面，当然有对判定结论的分数，但也会对文件重组算法（以及，虽然我不敢相信会出现）对最终重组出的 AutoIT 脚本的分析给分。

对我们的 LLM 来说，这绝对是更难啃的硬骨头。没有任何模型能（或者甚至尝试）重组出 AutoIT 文件。这可能是因为我们没有暴露批处理相关的工具，但即便如此，模型本可以给出一些方向性的提示。不过要给 ChatGPT点赞，它是唯一注意到 AAC 文件被拼接在一起的模型，而且其撰写的报告也是最有用的，差距明显。

Claude和 DeepSeek无法完成批处理部分的分析，并在报告生成环节卡住了。我从日志中可以看到它们大部分构件都答对了，但之后惨遭翻车。这可能是我的问题，因为缺少了压缩机制。

二进制 #5: Tor 节点

样本：

6b866c187a0dee2fb751a8990d50dc1ed83f68e025720081e4d8e27097067dc8 (VT)

类型：

干净PE 程序

描述：

Tor 程序（参见 basic report）

这个样本的难点在于其体积：9 MB，以及 Tor 本身的不良声誉。当然，还有大量的加密代码。本轮的 IOC 分数将授予能够识别出 Tor 的模型。判定分数则根据决策、行为来给分，如果模型指出 Tor 的存在 可能是感染迹象，还可额外获得 1 分。

对大多数模型而言这是一个简单的判定；说实话，所有报告之间差异不大。也许这道题太简单了。至于 Nova 2 Lite，我在想，如果我们每次都取它判定结果的反面，它作为检测器会有多好用 ;)

请注意，DeepSeek的耗时可能受到了 DeepSeek当前历史最高需求量的影响

二进制 #6: Rust 释放器

样本：

3c47eccd8fc8d9a9ce087c5ff5f9dce08d5dd15123b84a44301ca98b6a4f797d (VT)

类型：

恶意Rust PE 程序

描述：

一个 Rust 释放器，它包含一个巨大的 base64 字符串，该字符串进一步与 0x83 进行 XOR 运算，解密后得到一个 MZ 文件（参见 basic report）

这个样本也应该相对容易分流，但由于它分为两个阶段，所以还有一些额外的深度。如果模型能够识别出持久化机制（注册表键和释放路径），并检测出这是 Rust 程序（Malcat 已经做到了，所以相当容易），就会给出 IOC 分数。判定分数将奖励论据的相关性以及追溯到释放链的终点。请注意一个难点：由于 Rust 处理字符串的方式以及字符串缺少终止符，Malcat 必须依靠启发式方法来恢复可用的字符串。在这个案例中，base64 字符串的尺寸太短，这对模型来说应该会比较困难！

请注意，DeepSeek的耗时可能受到了 DeepSeek当前历史最高需求量的影响

这里没有任何模型能够追溯到感染链的终点，这有点令人失望。尽管如此，大多数模型都正确识别出了解密算法或载荷位置，这已经相当有用了。

二进制 #7: 代码释放器

样本：

0dc710737c12ea1c1215fbd39e00347649fff1fb0e512287c86873f66a9f0a35 (VT, Bazaar)

类型：

恶意PE 程序

描述：

一个来自 .text 节的释放器，存在大量但相当微妙的异常点（参见 basic report）

这个样本可能有点棘手，因为它的生成方式比较特殊。我猜测攻击者使用了一个（已签名的）干净应用程序作为母体，然后在其中打补丁植入了一个恶意释放器。此外，代码节经过了混淆，但混淆方式相当隐蔽。更糟糕的是，加密的载荷只有中等熵值。因此，这里可疑的并不是某个大张旗鼓的痕迹，而恰恰是某些痕迹的 缺失：

• text 节中，释放器代码与加密载荷之间存在一个 600 KB 的空洞
• data 节中没有任何被引用的字符串
• 资源节末尾存在一个 4 KB 的空隙（我猜版本信息被打了补丁）
• 导入表显得不太合理
• 资源语言很奇怪

让我们看看模型们能否看穿这些表象。

发现异常之处可获得 IOC 分数。给出正确判定、定位载荷、识别其解密算法以及论据的相关性可获得判定分数。我会特别关注那些引用混淆现象作为论据的回答。

请注意，DeepSeek的耗时可能受到了 DeepSeek当前史无前例需求高峰的影响

模型们在识别该文件中的异常之处方面都表现得相当不错。大多数模型都发现了代码混淆、不合常理的 API、资源和证书。我有点失望的是，没有任何模型能够提取出第二阶段载荷，不过我想这可能还需要更多的 token 才能完成。

二进制 #8: 被打补丁的下载器

样本：

1fd921159de8ccf3c33c7ad3d52a4186c2695b858435e8e327c4d95a8d1b048a (VT, VirusShare)

类型：

恶意PE 下载器

描述：

一个很可能用于侧加载（side-load）的 DLL，仅有少数几个函数被打了补丁（参见 basic report）

这个样本有点棘手，即使对人类分析师而言也是如此。如果你在那里稍微仓促一些，可能只会看到一个看似正常的服务 DLL。诚然，唯一的 export 名称看起来有点奇怪，但其余部分看起来都很合法。这里的恶意软件作者算是有点小聪明：这是一个下载器，只有少数几个恶意函数被埋藏在一个本来干净的二进制文件中。无需定位载荷，也别无他物。更糟糕的是，恶意入口点并不是 export 本身，而是 被某个export 调用的一个函数。最后，虽然下载 URL 是明文的，但它并没有被直接引用（仅通过其第二个字符引用）。所幸的是，Malcat 的常量数据库在这里提供了 相当有力的证据：5 个与下载相关的 API 哈希。这对于大多数模型来说应当足以触发一些警示。

发现 URL、哈希值以及指出 export 名称可获得 IOC 分数。给出正确判定、描述其行为（包括 AES 加密）以及论据的相关性可获得判定分数。

请注意，DeepSeek的耗时可能受到了 DeepSeek当前史无前例需求高峰的影响

这个文件的结果让我感到惊喜。只有 Minimax M1做出了错误判定。当然，Malcat 在这里帮了大忙，提供了许多有用的线索，但模型们的表现依然值得肯定。

二进制 #9: UPX 加壳的 vksaver

样本：

161ee3cc94b683d301f99f64e7ec1106767b6fc3ebb0b08bef7e22e9096998f5 (VT, MalShare)

类型：

PUAUPX 加壳的 PE

描述：

一个 UPX 加壳的 VKontakt PUA 程序（参见 basic report 以及 report for the UPX-unpacked binary）

对于最后一个样本，我挖出了一个相当棘手的干净文件：一个老旧的 UPX 加壳 VKontakt 浏览器"扩展"，它会（在用户选择加入之后）安装捆绑的应用程序。一旦 UPX 脱壳完成（Malcat 内置了 UPX 脱壳器），该程序可能会从 .rdata向磁盘转储一个大型的 XOR 加密缓冲区并运行它、篡改浏览器配置，并包含告知用户如何提升权限的图片。说实话，在时间压力下我也会犯错。实际上我确实犯过：这是我在 Avira 时期的 一个老旧误报（FP），被我带回家进行进一步分析。我并没有具体地误判这个文件，但它曾被我的一条启发式规则检出，所以错误依然发生了。那么让我们来看看我们的模型如何处理它！

对于这个案例，我只接受 PUA（潜在不受欢迎应用）的判定。

IOC 分数将根据识别出应用程序、持久化机制以及释放文件的名称来评定。判定分数则根据正确的结论、对行为的描述（包括解密算法以及捆绑安装的"选择加入"性质）以及论据的相关性来评定。

大多数模型的表现都相当令人印象深刻。甚至有四个模型成功找到了 token 来还原解密算法！

请注意，DeepSeek的耗时可能受到了 DeepSeek当前史无前例需求量的影响

总结

在审阅了 90 份（！）AI 生成的报告并以我能做到的最客观方式进行评分之后，我必须承认 我深感钦佩。大多数（严肃的）模型成功地对我的 9 个样本进行了分类，并在 合理的时间和金钱成本下产出了 有用的报告。诚然，Malcat 为这些模型提供了大量有用的线索（尤其是 Kesakode 的函数标注功能），这无疑让它们的任务变得更轻松，但即便如此，它们仍然交付了成果。

如果能用其他 MCP 服务器重做这个基准测试，看看模型在信息更少、工具更少的情况下表现如何，会很有意思

无论如何，在分流基准测试的最后，得出了以下分数。首先我们来看原始分数，即 模型的表现究竟如何：

我们可以看到，有 4 个模型在这项基准测试中占据主导地位：GPT 5.5、Opus 4.7、DeepSeek 4 Pro以及一个我在此次测试前从未听说过的模型：Mimo 2.5 Pro。最好的报告（至少在我看来，这是主观意见）由 GPT 5.5撰写。GPT 是一个相对 啰嗦的模型，这在此次基准测试中反而是个优势。虽然其他 3 个模型的报告与 GPT 同样出色，但 GPT 始终 给出了更多证据，这对于恶意软件分流非常有价值，因为它为人类分析师提供了 更多可供核实报告的线索，从而最终带来 更多信心。

注：在本章所有图表中，DeepSeek和 Claude的平均分计算都忽略了测试 #4，因为我无法 100% 确定那里是模型本身的问题。

但是，如果你负担不起 API 费用，那么再强的原始性能又有什么用呢？如果我们综合考虑我在本章开头列出的 其他标准（时间和成本），就会得到下面的评级：

现在我们看到了不同的画面。我们可以看到，中国模型在性价比方面远超美国模型。我 尤其对Mimo 2.5 Pro印象深刻，它仅以一小部分的价格就给出了非常优秀的结果（几乎与 GPT/Claude 模型不相上下）。DeepSeek V4的表现也相当不错，但因其相当长的推理时间而被扣分（这可能只是暂时性的问题，因为其 Flash 模型最近获得了不少关注）。

最后，如果你想做出决策，这里有一张以两个维度为轴的图表，将模型的原始性能与每次分析的平均成本进行对比绘制：

Anthropic 的定价策略到底是怎么回事？要知道，Claude 每 token 的价格本应与 ChatGPT 相当，然而我们看到的却是这样。

针对我自己的特定使用场景，我的结论是：我会在我的流水线中纳入以下两个模型：

• Mimo 2.5 Pro
  作为默认选项，因为它对这项任务来说 完全够用，而且在 性价比方面无可匹敌
• GPT 5.5
  作为可选的 拼尽全力模式，适用于不计成本、追求 最佳报告的场合

静态脱壳大赛

生成分流报告确实是一个非常有用的应用场景，但在我看来，它并不能让我们精确地比较各个 LLM 模型，原因如下：

• 评分环节本质上是 主观的：你必须信任我对结果做出正确的判断
• 总结对 LLM 来说太轻而易举，并没有真正把它们推向极限

正因如此，我设计了第二项挑战：仅使用 Malcat 的 MCP server对 5 个恶意软件样本进行 静态脱壳。我知道这个基准测试有点儿戏：如果你想引爆并脱壳样本，有更好的方法。把样本送到沙箱（比如出色的 Joe Sandbox，这是我个人的最爱），下载内存或 PE dump，搞定收工。当然沙箱也有自身的不足（反 xxx 技术、速度较慢、价格昂贵、可能遗漏部分产物），但用 LLM 静态脱壳样本，虽然是个非常有趣的用例，却并不是花费 token 的最佳方式。我通常只有 在样本无法在 VM 中引爆以及 / 或者内存中找不到可用 dump 的时候，才会走这条路。

可以确定的是，这项挑战 会把所有模型都推向极限。事实上，它需要以下能力：

• 模型必须 判断样本是否被加壳
• 模型必须 定位加壳的载荷
• 模型必须 逆向出解密算法
• 模型必须 将算法翻译为 Malcat 的 transforms

显然比第一个基准测试更难，尽管 Malcat 这次也会再次给它们提供帮助。

注：与第一项挑战一样，模型 无法使用 Malcat 之外的任何工具（即没有 Bash 也没有 Python），这可能会有些受限。但这是有原因的：我不知道你怎么想，反正我可不希望让模型在无人监督的情况下分析恶意软件时执行任意代码 :)

每个模型收到的 prompt 如下所示：

Your goal is to decide whether the sample likely embeds a packed and/or encrypted payload, and if it does, recover that payload using static analysis and Malcat transforms. If that payload is itself packed/encrypted, recurse.Start by assessing whether the current file appears packed or encrypted:- inspect entropy and entropy-based anomalies- look for high-entropy regions, overlays, abnormal sections, packed-code signatures, encrypted blobs, or virtual/carved files- compare entropy evidence against strings, constants, section names, imports, and obvious packer signaturesIf there is no credible evidence of a packed or encrypted embedded payload, stop early. Produce a short report explaining why no unpacking was attempted.If there is credible evidence of packing or encryption, try to recover the unpacking/decryption logic:- identify the encrypted/compressed payload location, size, and format- locate the code that reads, decodes, decrypts, decompresses, or copies the payload- recover the algorithm and parameters when possible- recover keys, IVs, XOR constants, rolling-key logic, compression settings, or transform chains- use back-references from constants, strings, suspicious buffers, entropy regions, and API calls to find the relevant codeWhen you understand the transform, use Malcat transforms to unpack or decrypt the payload. Prefer precise transforms over broad guesses. If several stages are present, unpack them step by step and analyse the resulting file after each important stage.After producing an unpacked file, briefly verify that it is plausible:- check whether entropy decreased or structure became recognizable- check file type, headers, sections, imports, scripts, strings, or other high-level indicators- do not perform a deep behavioral analysis unless it is needed to validate that unpacking workedIf the algorithm or key cannot be recovered statically, say so and include the strongest evidence you found.Analyse the unpacked file to see if you need to recurse. If it is not packed: abort, otherwise, unpack the new file.

我不知道你怎么想，反正我相当好奇我们的模型能否胜任这项任务。那就让我们开始吧！

脱壳 #1

样本：

674f19126e6dcf0ebb2bf9944841c4cd43195f73b006d51826c7c4252a7e2122 (VT, Bazaar)

类型：

.NET dropper

描述：

.NET string -> base64 -> 3des -> 404 Keylogger（参见 basic report）

作为首个脱壳挑战，我选择了一个 相对简单的样本。一个 .NET dropper 内嵌了一个大型 base64 字符串，并经过 3DES 解密。这里唯一的微妙之处在于：3DES 的密钥和 IV 并非在与解密相同的控制流路径中生成，因为解密是在异步任务中进行的。因此模型必须将两者关联起来，老实说这还相当容易。

我预期所有模型至少都能定位到载荷，这要归功于 Malcat 的 HugeStringBase64异常检测！

对大多数模型来说，第一项挑战不过是小菜一碟。.NET 相对容易分析，结果也印证了这一点。特别表扬 Gemini 3.1 Pro，它仅用 243k tokens 和 93s 就完成了样本脱壳！

脱壳 #2

样本：

a64e4bbea5983eefb772b8b467504f6242c913e98a8c7fa9a6fd6e4b9a3631de (VT, Bazaar)

类型：

Golang PE

描述：

一个简单的单级 rdata dropper，加密方式：add 0xc4 + reverse -> Remus（参见 basic report）

第二个脱壳挑战同样相当简单：一个 Golang 恶意软件从其 rdata 段中释放出一个加密的 Remus 实例。我之所以说它简单，主要是因为：

• Malcat 通过其 BigBufferNoXrefMediumToHighEntropy异常检测直接指向了载荷
• 得益于 Kesakode，需要分析的未知代码并不多
• 解密算法非常简单

无论如何，让我们来看看结果。请注意，与后续所有挑战一样，我也会为部分成果给分（例如定位到载荷或逆出解密算法）。

好吧，我有点失望。我本以为这是个简单的题目。只有 Opus 4.7给出了完美的结果。GPT 5.5也得到了一个 dump，但它的载荷偏移有点偏（提前了 32 字节）。我不太清楚为什么会这样（别忘了 Malcat 的 MCP 也允许模型反汇编并 反编译函数，没有借口）。由于载荷在最后会被 reverse，这意味着我们丢失了 MZ 头的开头部分，可惜了！

最后，Mimo 2.5 Pro完美地逆出了解密算法，但却无法构建出正确的 transform chain（不知怎么搞混了 VA、EA 和偏移）。至于其他所有模型：可耻！

脱壳 #3

样本：

fa755134d9c9796b2f58fd61aeb0ef12121da6afaa1943f05334d332992cdff5 (VT, Bazaar)

类型：

Golang PE

描述：

Golang rdata -> AES -> Donut SC -> ValleyRAT（参见 basic report）

在这第三个挑战中我们仍停留在 Golang 领域，但难度略有提升。简单的 XOR 现在被替换为 ECB 模式下的 AES 解密，并由此引出第二阶段：一个 Donut 加载器。脱壳 Donut 加载器后，我们得到最终的恶意软件：ValleyRAT。值得注意的是，Malcat 原生内置了 Donut 脱壳器，因此在这一部分模型只需调用名称恰如其分的 unpack_donut工具即可。

那么让我们看看我们的模型这次是否表现得更好！

这个恶意软件总体上被分析得相当不错。

脱壳 #4

样本：

4109d17d439e425d24e9d11956adcc63ff8e24ccfffe21dd8c5431fe969d2783 (VT, Bazaar)

类型：

PowerShell 脚本

描述：

PowerShell -> Base64 -> Gzip -> PowerShell -> Base64 -> Xor35 -> Cobalt Strike

不知道你怎么想，反正我已经厌倦二进制文件了，那就换个口味分析一个小脚本吧。这里我们有一个三阶段加载器：

• 第一阶段是一个 PowerShell 脚本，它会对一个长字符串进行 base64 解码并 gunzip 解压
• 第二阶段是另一个 PowerShell 脚本，它会对一个长字符串进行 base64 解码并 XOR 解密
• 第三阶段是一个 Cobalt Strike beacon

相对简单，但有个陷阱。Malcat 并不太适合分析文本文件。模型能够读取文本文件的内容并调用 Malcat 的 transforms，但仅此而已：没有异常检测，没有分析，也没有 Kesakode。它们基本上只能自力更生！那么让我们看看它们在这种条件下表现如何：

除了 GPT 5.5和 Opus 4.7之外，大多数模型在处理这个样本时都遇到了问题。其中两个抱怨上下文大小，声称第一阶段的载荷无法装入它们的内存（Gemini 3.1 Pro和 Qwen 3.6+）。但在我看来，这只是暴露了它们策略上的错误。对于这种大型混淆脚本，它们 不应该把整个脚本加载到上下文窗口中；那种做法根本就是错的。相反，它们应该像处理任何二进制文件那样加载它，每次只读取少量文本。

脱壳 #5

样本：

ee0f0f2f089ee0594da5750bb4e342c34d703ea045ed80c3b73c81d2f3de8bd4 (VT, Bazaar)

类型：

MSI installer

描述：

MSI -> CAB -> NSIS -> License.txt（混淆的 pyc）-> hex decode -> XOR -> reverse -> b64 -> zlib -> PowerShell -> AES -> 一些我已经记不清的 .NET 玩意儿（参见 basic report）

对于最后一个脱壳挑战，我特意挑了一个有难度的 ^^ 这是一条非常长的链：一个 MSI installer，其中包含一个 NSIS installer（还有一个小巧的 start.exe.NET 启动器）。该 NSIS installer 打包了一个诱饵安装程序、一份完整的 Python 发行版（其中的 python.exe被重命名过），以及几个名为 License.txt和 License1.txt的 混淆过的.PYC文件。Python 字节码中嵌入了一个巨大的 hex 编码字符串，解密后会得到一段 PowerShell 脚本，再由它注入一个 .NET 恶意软件——说实话，关于它我已经全忘光了。

在 仅仅 800k tokens的限制下，这对我们的模型来说会很艰难。如果它们能识别出 License*.txt文件，我就已经会感到惊艳了 :D 如果它们能走到 PowerShell 这一步，我会给满分。

注：Malcat 目前（尚未）内置 Python 反编译器，因此模型必须 RE Python 字节码。而且大多数 Python 反编译器对这个样本都会失败。

这个样本确实把 LLM 们都搞糊涂了！老实说，可能也有我提示词的问题，因为其中一些模型以为需要解密 NSIS overlay，而其实只要像打开 Malcat 中任何其他虚拟文件那样打开它就行了。无论如何，Claude 表现得很出色，差一点就走到 PowerShell 那一步。它只是没能搞清楚 XOR 的取值，但除此之外整条解密链都摸得很准，相当漂亮！

总结

静态脱壳环节对我们的模型来说显然是更大的挑战。这在分数上也体现得非常明显。Opus 4.7是其中毫无悬念的赢家，尽管说实话，仅凭 5 个样本很难下定论。另外有两个模型在该用例中表现优秀：GPT 5.5和 Mimo 2.5 Pro：

与第一个基准测试相比，这里有意思的一点是该组中的第一名 Opus 4.7与第四名 Qwen 3.6+之间的差距：Claude 的得分几乎是后者的两倍！那些在分流任务中"够用"的模型，在这些以逆向工程为核心的任务上就力不从心了。如果把其他指标也纳入考量，差距会变得没那么清晰，因为 Claude 的 极高成本是一个明显的拖累——其费用是 GPT 5.5分析的 三倍，是 Mimo 2.5 Pro的 6 倍：

这个结论在下图中得到了进一步印证：

我学到了什么

总体而言，分流基准测试的结果让我印象深刻。在 2026 年，LLM 确实能给恶意软件分流 带来很大的价值，甚至已经达到可以在专业场景中作为 第二意见使用的程度。而对于偏重逆向工程的任务（例如我们的静态脱壳基准测试），我的感受则更为复杂：LLM 还远不是自主的分析师。不过借助合适的工具，它们已经可以通过提供良好的线索来节省大量时间。

至于模型的选择，有些结果在意料之中，比如 GPT和 Claude表现优秀但价格昂贵；但 Mimo 2.5 Pro的实力却让我大吃一惊——在跑这个基准之前，我对这个模型一无所知。它不仅表现几乎可与 GPT和 Opus媲美，价格还便宜 4 到 6 倍！向这个相对新生模型背后的工程师们致敬！

我还学到一点：所宣传的每 token 价格只是故事的一部分。最终成本在很大程度上取决于模型为推理在内部消耗了多少 tokens，以及它使用工具的效率有多高。例如，Opus 4.7和 GPT 5.5在纸面上看起来价格相近，但在本基准中 Opus 4.7的成本至少要贵一倍。

最后，如果要根据本基准做选择，我会：

• 将 Mimo 2.5 Pro用于任何需要规模化的场景
• 将 GPT 5.5用于真正重要的分流报告
• 如果不计成本，将 Opus 4.7用于偏重逆向工程的任务；否则用 GPT 5.5或 Mimo 2.5 Pro

不过，benchmark 还没有结束！我还想探索一些更快的模型，例如 DeepSeek V4 Flash、Mimo V2 Flash，或更轻量的模型，例如 NVIDIA 的 Nemotron 3。作为开发者，我也想试试其他 MCP servers，看看这些好成绩有多少来自 Malcat，又有多少来自模型自身的推理能力。但这就留到以后的文章里再说吧！

与此同时，我也邀请你自己来做基准测试。你可以使用 Malcat's MCP server 亲自测试一下。如果你想把 Malcat 接入自己的流水线，欢迎随时 联系我们，我们将很乐意提供协助。

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。