AI 能不能替代人工完成 VMP 样本的逆向和脱壳这是很多做二进制安全、游戏安全、软件安全、CTF 的人在 2025 年反复问的问题。VMP 全称 VMProtect是一种常见的代码虚拟化保护方案它会把原本的 x86 指令翻译成自定义字节码程序运行时再由虚拟机解释器逐条还原执行所以静态分析和动态调试都比普通加壳程序困难得多。我给一个只有简单比较逻辑的 C 程序加上 VMP 保护再把识别保护、定位 OEP、动态调试、内存转储、还原核心校验函数这五个任务全部交给大模型独立完成。实测结果和预期差别很大AI 在思路、术语、工具选择上很在行但一旦涉及真实内存地址、脚本语法和 VM 指令还原就会频繁给出“看起来专业但其实不可用”的答案。这篇文章会把实验流程、结果、原因以及能落地的人机协作方式写清楚也会强调安全边界所有分析只针对自行编写的 CTF 测试程序或已获授权的样本。1. VMP 为什么难逆向先搞清楚 AI 面临的对手是什么1.1 VMP 的“虚拟化”到底做了什么很多刚接触二进制安全的读者会把 VMP 当成普通壳以为像 UPX 一样能直接脱掉。实际上 VMP 一般有两层功能第一层是保护原有导入表和入口点第二层是把关键代码块转换成自定义字节码并在运行时通过解释器执行。通俗理解是原来程序里是一段人能看懂的 x86 汇编VMP 把它“翻译”成了一种只有 VMP 自己认识的中间语言程序每次运行时都要靠 VMP 的 handler 解释这段中间语言才能恢复原始行为。从逆向角度看最棘手的问题不是“多了一个壳”而是“函数本体不见了”。你看到的反汇编可能变成一堆 handler 分支每个 handler 负责取指令、解码、执行、更新虚拟机上下文。不同的 VMP 版本、不同保护选项、甚至每次加壳时的随机化都会让字节码和 handler 布局发生变化。这种特性决定了脱壳不能简单套用一个通用脚本。VMP 也不只是单纯混淆控制流它还会打乱栈结构、抹平 API 调用特征、插入垃圾指令、将系统调用包装成自定义 thunk。这些手段叠加后静态分析工具输出的一整段伪代码可能完全不可读。这也是为什么许多 CTF 选手遇到 VMP 会直接选择用动态调试加内存转储的方式先找到原始代码被还原的位置再抓取内存镜像分析。1.2 大模型在二进制逆向里的能力边界大模型在逆向领域有两个天然优势。第一训练语料里包含大量汇编、反编译、加壳原理、CTF writeup所以它能说出“VMProtect 的特征是什么”“Scylla 是干嘛的”“为什么要在内存断点后 dump”这类知识。第二它能快速把一段杂乱的反汇编总结成人类能理解的自然语言减少搜索文档的时间。但大模型也有一个致命问题它本身不执行代码也没有实时读取调试器上下文的能力。你给它一段反汇编文本它能做模式匹配你问它“这个地址的指令到底是什么”它只能靠上下文猜测。更麻烦的是在缺少客观验证的情况下大模型会生成“看起来合理但实际不存在的地址、函数名和脚本”。这不是它故意撒谎而是语言模型的本质就是在做概率预测下一个 token 大概率是这样但这不等于当前二进制里真的存在 0x401000 这个有效代码地址。所以在这次实验里我刻意区分了“知识问答”和“真实工程任务”。前者可以用来检验 AI 的理论储备后者才是判断 AI 是否“真能干 VMP”的关键。1.3 实验目标和合规边界本文讨论的逆向分析只用于三类场景自己编写并加壳的测试程序、CTF 官方题目、已获得授权或属于自己业务范围的安全研究样本。不要在未授权的商业软件、游戏客户端或第三方 App 上复现同样操作这是安全研究的基本红线。实验目标也很明确构造一个包含check_flag校验函数的 C 程序使用 VMP 保护后让 AI 独立完成从样本识别到还原校验逻辑的全过程最终找出正确 flag。整个实验在隔离虚拟机里进行样本文件只保存在实验目录不联网运行。这样既保留了 VMP 的真实难度又不会涉及任何违规操作。2. 实验环境搭建样本、工具与模型2.1 准备一个带 VMP 保护的 CTF 类测试程序我没有直接拿网上找的加壳样本而是自己写了一个只包含字符串比较和简单计算的小程序。程序逻辑是读取用户输入调用check_flag函数校验如果结果等于 0 就输出“Correct”否则输出“Wrong”。核心代码如下#include stdio.h #include string.h int check_flag(const char *input) { char key[] CTF{VMP_AI_2025}; if (strlen(input) ! strlen(key)) return -1; for (int i 0; i strlen(key); i) { if (input[i] ! key[i]) return -1; } return 0; } int main(int argc, char *argv[]) { char buf[64] {0}; printf(Enter flag: ); if (scanf(%63s, buf) ! 1) return 1; if (check_flag(buf) 0) { printf(Correct\n); } else { printf(Wrong\n); } return 0; }编译成 32 位 Release 版本后使用 VMP 的试用版对check_flag函数做虚拟化保护其他部分保持默认。这样程序就是一个合法的测试样本目标是从加壳后的二进制里分析出key字符串和校验逻辑。如果你手头没有 VMP 授权也可以用开源的 OLLVM 或自定义虚拟机指令模拟类似效果。本文为了贴近真实场景选择使用 VMP 保护选项中的“虚拟化”和“内存保护”这也是 VMP 被称为难啃对象的主要原因。2.2 逆向工具链清单针对 VMP 样本常用的工具并不是某一个“万能脱壳机”而是一套组合工具用途使用阶段Detect It EasyDIE检测编译器特征、加壳类型、入口点段特征第一步静态识别PEiD / Exeinfo PE辅助查看区段名和入口点特征交叉验证x64dbg / x32dbg动态调试、下断点、观察内存、转储进程核心调试阶段Scylla抓取导入表、修复 IAT、dump 进程镜像内存转储阶段Ghidra / IDA静态反编译、分析还原后的代码逻辑还原阶段Process Hacker查看进程模块、内存保护属性辅助动态分析Python 脚本批量提取字节码、处理日志、生成算法脚本自动化辅助需要注意VMP 分析经常需要 32 位调试器因为许多 VMP 保护样例都是 32 位程序。如果你的样本是 64 位对应的调试器换成 x64dbg工具原理相同但命令和插件需要适配。2.3 选择 AI 接入方式API、网页端还是本地模型大模型接入方式会影响实验的效率和可复现性。我这次实验同时使用了三种方式做对比目的是看不同上下文长度和交互方式对分析结果的影响。接入方式优点缺点适合场景网页聊天无需写代码适合问答无法批量测试上下文容易被聊天记录污染快速问概念、问思路OpenAI 兼容 API可脚本化、可保存每次输入输出需要开发少量代码成本和限额需要关注批量评测、自动记录实验过程本地部署模型数据不离开实验环境隐私好小参数模型能力有限大参数模型对硬件要求高对数据隔离有要求的项目在后续任务中我优先使用 API 方式因为可以准确控制每次输入的内容并能把 AI 的完整输出保存到日志文件里。这样得到的“实测结果”不是聊天记录而是可重复检查的实验数据。2.4 实验前检查清单在开始给 AI 布置任务之前建议先确认以下内容虚拟机是否做了干净快照防止样本运行异常后需要回滚。样本文件是否计算了 MD5 或 SHA256确保不同阶段分析的是同一个文件。调试器插件是否正常加载x64dbg 的 Scylla 插件是否可用。AI 提示词模板是否保存方便多轮实验对照。每轮 AI 输出是否写入独立日志文件防止结果丢失。实验目录是否关闭网络避免样本产生外联行为。这些检查不是形式主义。VMP 样本在调试过程中可能触发反调试、反虚拟机、异常分支跳转如果没有快照和日志一次操作失误就可能让整个实验前功尽弃。3. 怎么给 AI 布置逆向任务Prompt 设计和评分标准3.1 把“脱壳”拆成可验证的子任务很多人在让 AI 分析 VMP 时直接问“怎么脱这个壳”这是一个非常模糊的问题。AI 只能给出泛泛而谈的流程无法真正解决问题。更合理的做法是把脱壳和逆向拆成多个可验证的子任务让 AI 对每个子任务给出具体输出再由人工或工具验证。我采用的子任务划分如下编号子任务输入材料期望输出1识别保护类型DIE 报告、区段表、入口点指令判断是什么壳、什么保护选项2分析 OEP 思路入口点汇编、ESP 定律相关线索给出定位原始入口点的方法3生成调试脚本x64dbg 支持的命令描述可运行或接近可运行的断点/脚本4内存转储与 IAT 修复转储说明、模块基址、进程内存信息给出 dump 和 IAT 修复步骤5还原核心校验逻辑转储后反汇编、Ghidra 伪代码解释算法思路、给出核心比较逻辑每个子任务都要有明确“完成标准”。比如任务 3 的完成标准是“x64dbg 能正确执行脚本并且不报语法错误”任务 5 是“能从还原后的代码里找到 key 常量”。没有完成标准AI 输出一大堆文字很难判断它是否真的做对了。3.2 给 AI 的输入材料与 Prompt 模板给 AI 的材料越结构化输出质量越高。我使用的 Prompt 模板大致如下你是一名 Windows 二进制安全逆向工程师现在需要处理一个 CTF 训练样本。 该样本使用 VMProtect 保护目标是分析 check_flag 函数的逻辑并找到 flag。 这是 Detect It Easy 的输出 [粘贴 DIE 报告文本] 这是入口点前几条指令 [粘贴 x32dbg 中入口点反汇编] 请完成以下任务 1. 判断最可能的保护类型和选项 2. 给出定位原始 OEP 的具体步骤 3. 提供一份 x32dbg 脚本脚本需要在遇到内存断点后暂停并输出当前寄存器值。 要求 - 不要给出绕过授权或破解商业软件的操作 - 每一步给出预期输出 - 如果不确定请直接说不确定不要编造地址。这样写的好处是限制了 AI 的回答范围并明确要求它“不要编造地址”。不过实测发现即使加了这句话AI 在具体给地址时仍然可能出错因此后续还需要人工核对。3.3 判定标准不能只看答案要看为什么和可执行性AI 的“答案”不能只用“对错”来评价因为逆向过程是动态的。我采用了四个维度评分知识正确性概念判断是否符合主流工具和 VMP 原理。可执行性给出的命令、脚本、地址是否真的能在实验环境中运行。可解释性答案是否说明了原因能否帮助我理解下一步为什么这样做。人工干预量从 AI 输出到最终结果需要多少轮人工修正。这四个维度中可执行性最容易被忽略。有些 AI 输出看起来很有条理但把脚本粘贴进 x32dbg 会发现命令名写错或者地址指向了数据段。这就是典型的“知识正确但工程不可用”。4. 实测记录AI 在 5 个子任务上的表现4.1 任务一识别保护类型与壳特征这一轮我先把 DIE 检测报告和入口点反汇编贴给 AI。AI 很快给出了结论特征符合 VMProtect区段名通常是.vmp0、.vmp1入口点附近会出现push大立即数、call跳转到 handler 等特征。它还提醒我入口点看到的指令并不是原始程序代码而是 VMP 的启动 stub真正的主函数入口需要继续向下找。这个任务的输出质量很高知识正确性基本满分。原因是识别壳类型属于常见问题训练语料足够多AI 不需要精确知道当前样本的地址只需要根据文本特征做判断。人工干预量很小只补充了一个 DIE 扫描结果截图。4.2 任务二定位 OEP 与导入表修复思路第二个任务开始出现偏差。AI 给出的方案是“在入口点后找一个大跳转或者使用 ESP 定律在栈指针改变处下硬件断点然后单步跟踪到原始入口”。这个思路本身是正确的也是手工脱壳常用的路线。问题出在它给了一个具体地址0x401000并说“这通常是原始入口”。但实际上我的样本在加壳后入口点是 0x001F1000 附近0x401000 只是数据段的一部分。AI 看到反汇编里有push 0x401000就推测那里可能是 OEP却没有验证这条指令是立即数还是有效地址。人工改成了“在第一个ret指令处下断点通过栈回溯找返回地址”这才进入下一步。这个任务暴露了 AI 的最大弱点它能把方法论讲清楚但无法把方法论应用到“当前这个具体二进制”上。4.3 任务三生成动态调试脚本我要求 AI 生成一段 x32dbg 脚本功能是遇到内存断点后暂停并输出寄存器。AI 给出了类似下面的内容bp 0x001F2000 run log hit breakpoint ? eax这段脚本表面上像个调试命令序列但 x32dbg 中并不支持? eax这样的寄存器查看命令。正确写法是使用r eax或在寄存器窗口直接查看。AI 之所以写错是因为它把 x64dbg 和 Windbg 的表达式语法混在一起了。随后我让 AI 改用RegisterCommand它又开始编造自定义命令。最后这段脚本只能在人工修改后运行。这是典型的“可解释性高、可执行性低”。4.4 任务四内存转储与导入表修复任务四要求 AI 给出内存转储和 IAT 修复流程。AI 的回答在概念层面是合格的先用调试器找到进程主模块基址在配置好内存断点后运行等待原始代码被还原再用 Scylla 选择进程并抓取 IAT最后 dump 整个镜像。它还解释了为什么要在VirtualProtect或VirtualAlloc返回的缓冲区上留意可执行内存段。但它随后生成了一段用 Python 调用 Scylla 的伪代码里面引用了一个不存在的scylla.dll接口导致脚本无法运行。真实环境里 Scylla 通常以 x64dbg 插件形式使用而不是直接 Python 调用。如果只看 AI 的“思路”你会觉得它已经很接近但照着代码做完全走不通。这个任务给我的判断是AI 适合写分析计划不适合直接生成依赖具体插件接口的调用代码。4.5 任务五还原核心算法并给出 flag最后一个任务是把转储后的check_flag函数还原出来。在 VMP 虚拟化保护下Ghidra 反编译输出的代码是一堆 handler 分支关键比较逻辑完全隐藏在 VM 字节码里。AI 看到反编译结果后先是正确识别出主程序里存在printf、scanf调用并大致勾勒出用户输入流向但一旦进入 handler 层它就失去了方向。我尝试把一段 handler 的字节码贴给 AI问它“这段字节码是否在比较两个字符串”。AI 的回答是“可能是在做长度比较也可能是计算校验和需要更多上下文”。即使我提供了多个 handler 分支它也只能总结出“这个 VM 用了栈机和寄存器两种模式”无法还原出key常量。最终key是我通过动态调试在内存中直接找到字符串常量后确认的。这个任务再次说明面对 VMP 的私有指令集和每次加壳都会变化的 handler大模型几乎没有先验知识可以直接套用。4.6 综合结果表子任务AI 知识正确性输出可执行性人工干预程度最终判断识别保护类型高高低AI 可独立完成定位 OEP 思路高中中思路可用地址需人工核生成调试脚本中低高需要人工逐行修正内存转储与 IAT 修复高低高框架可用代码不可用还原核心算法低低极高无法独立完成所谓“离谱”主要体现在认知反差上AI 对外部知识和通用流程理解得很好但一旦进入真实二进制地址、真实插件接口、真实 VM handler 的世界就会变成高分低能。离“AI 独立干掉 VMP”这个目标还有很长的距离。5. 为什么“AI 独立干掉 VMP”不现实根据实测反推原因5.1 VMP 的虚拟指令集是“每个样本私有的”传统加壳就像给一本书换了一个封面打开封面后内容还是原来的文字VMP 则更像把书本内容翻译成了一种私密语言而且每本书的私密语言规则都不一样。VMProtect 在加壳时会生成一套与当前样本绑定的字节码解释器不同的保护选项、不同的编译器版本、甚至不同加壳参数都会影响 handler 布局。大模型本质上是基于概率的文本生成器。它擅长处理语料中出现过的模式但 VMP 的 handler 属于“每个样本都可能不同”的领域模型很难从前面的对话中推断出当前 handler 的具体语义。所以当任务从“识别壳类型”切换到“理解 VM 字节码”时AI 能力会断崖式下跌。5.2 大模型会产生“幻觉地址”和“伪代码”在一次实验中我让 AI 帮忙确认某条jmp指令的跳转目标它非常肯定地写了一个地址。后来我在 x32dbg 里查看该地址对应的是一段包含大量 0x00 的数据区域。这个现象不是偶发而是大模型在缺少当前进程上下文时的必然表现它无法访问调试器内存只能靠“猜”。更隐蔽的是“伪代码幻觉”。AI 生成的反编译伪代码可能结构完整包含if、while、memcmp等元素但这些元素并不一定来自真实代码可能是从其他样本中学来的模板。在 VMP 场景下伪代码看起来越合理越是需要警惕。5.3 上下文长度和分析深度互相矛盾完整分析一个 VMP 样本需要同时看到入口点反汇编、handler 的指令流、内存转储信息、导入表修复结果。这些数据加起来很容易超过当前大模型的上下文窗口限制。一旦上下文被截断AI 就会丢失前面已经确定的事实开始基于不完整信息做推断。有经验的逆向工程师会不断缩小分析范围先定位关键函数再只看该函数涉及的内存段。但 AI 不擅长自己决定“该忽略什么”它往往把所有信息都当成同等重要的内容导致后续判断被无关数据干扰。5.4 缺少可复现的验证闭环人工逆向是一个“假设-验证-修正”的循环。调试器每执行一条指令你就能看到真实结果进而修正下一步分析方向。AI 目前没有这种闭环能力。它可以提出一个假设但无法自己运行程序、查看修改后的内存、判断差异点在哪里。这也是为什么本文标题里的“实测结果太离谱”并不是夸张。真正离谱的不是 AI 一无是处而是它能在知识问答里像专家在实际执行时又像只会纸上谈兵的新手。只有当工具链补齐“AI 生成操作并自动执行-采集结果-回填给 AI”的循环后AI 在 VMP 领域的独立性才可能显著提升。6. 落地可用的 AI 辅助逆向工作流6.1 推荐人机分工AI 出方案工具出事实人工做决策根据本次实测我认为现阶段最合理的使用方式是AI 负责概念解释、方案梳理、反汇编摘要、脚本框架生成、代码注释生成。工具负责提供准确的地址、内存内容、断点命中位置、导入表信息。人工负责验证 AI 输出、修正错误地址、处理 VM handler、做最终安全判断。在这种分工下AI 的价值不是替代分析者而是减少搜索资料和写重复脚本的时间。比如让 AI 解释一段 Ghidra 反编译代码的逻辑它能快速帮我找到可疑的strlen和循环比较但真正决定“这个循环为什么存在”的仍然需要回到反汇编和动态调试结果上。6.2 一组可复制的具体工作流步骤第一步先用 DIE 和 PEiD 识别样本类型把检测报告保存为文本。第二步把报告和入口点前 20 条指令交给 AI请它列出保护选项、可尝试的调试策略以及可能遇到的反调试机制。第三步在虚拟机里打开 x32dbg根据 AI 建议设置断点但每个地址都用调试器实际确认一遍。第四步命中关键断点后把寄存器和内存区域复制到文本文件再贴给 AI请它解释这段状态与原始函数的关系。第五步使用 Ghidra 对 dump 后的镜像做反编译把相关函数伪代码片段分段交给 AI请它注释关键分支。第六步人工复核 AI 注释把正确结论写进分析报告把错误结论单独标红防止污染后续分析。这套工作流在 CTF 比赛和授权安全测试里都可以使用。核心原则是AI 做的每一步都必须有工具日志或调试器截图作为证据。6.3 学习环境与真实项目环境的差异在 CTF 或学习环境中可以容忍 AI 输出大量无用内容和错误地址因为目标是学习过程本身。但在真实安全项目比如恶意软件分析、自研客户端保护评估里日志需要可追溯、结论需要可复现AI 输出的“灵感”只能作为参考不能直接写进报告。维度学习/CTF 环境真实授权安全项目样本来源官方题目/自编程序客户提供或业务自有必须有授权AI 输出要求能启发思路即可必须可验证、可追溯环境隔离普通虚拟机即可隔离网络、专用分析机、禁止外联结果留存个人笔记需要完整报告、样本哈希、截图、时间线错误容忍度高低这里还要强调在真实项目里不要因为 AI 说了“这一步安全”就跳过风险确认。涉及敏感数据、真实用户环境或生产系统时必须由有经验的工程师做最终决策。7. 常见问题排查AI 输出不可用时怎么处理7.1 现象与排查对照表问题现象可能原因检查方式处理建议AI 给出的 OEP 地址无效地址幻觉模型没有真实内存数据在 x32dbg 中goto该地址查看是否是指令用调试器找到实际跳转目标再回填给 AIAI 生成的脚本报语法错误混用了 x64dbg、Windbg、Python 语法查看 x64dbg 命令帮助逐行执行先让 AI 用help command确认语法AI 对同一段反汇编给出矛盾解释上下文过长或被无关数据干扰把反汇编裁剪到关键函数范围分段提问每次只问一个分支AI 无法理解 VM handler当前样本的 VM 指令集未出现在训练语料中人工先定位 handler 入口和分派逻辑让 AI 总结已还原的 handler 规则而不是直接猜字节码AI 生成的结果与调试器不一致模型根据“常见样本”推断不是根据当前样本对比调试器日志和 AI 引用地址为 AI 提供精确寄存器值、内存值并要求它引用样本运行后虚拟机卡死触发了 VMP 反虚拟机或反调试检查是否缺少调试器插件、是否有硬件断点残留恢复快照关闭网络使用更稳妥的断点方式脱壳后的程序无法运行dump 的镜像 IAT 未修复完整用 Scylla 重新抓 IAT检查无效指针在原始 OEP 处 dump并在目标进程中修复7.2 一条从报错到解决的排查链路当 AI 给出的结论无法复现时不要反复让 AI“再猜一次”。正确做法是回到原始数据。第一步先确认样本本身没变。重新计算哈希如果哈希不同说明当前调试环境已经偏离初始样本需要回滚快照。第二步确认 AI 输入的材料是否准确。我遇到过把 DIE 报告贴错版本导致 AI 一直分析其他样本的情况。把输入文件重新检查一遍往往能发现低级错误。第三步把 AI 输出的地址、命令、脚本逐项与调试器对照。用 x32dbg 的goto跳转到地址用help查看命令语法用 watch 窗口查看寄存器是否真的等于 AI 说的值。第四步如果仍然无法解决把问题分成更小的子问题。与其问“如何脱 VMP”不如问“入口点这条push指令的目标地址是多少”“这个call在 handler 中可能起到什么作用”。第五步所有结论在写进分析报告前至少要有一次调试器截图或日志支持。没有证据的 AI 结论只能作为待验证假设。7.3 怎么防止 AI 输出污染你的分析结论在分析过程中AI 很容易产生“说服力很强的错误结论”。要防止污染最简单的方法是给 AI 的输出打标签哪些是知识问答、哪些是待验证脚本、哪些是已经通过调试器确认的事实。我自己在实验时会用一个临时目录保存三类文件ai_raw/保存每轮 AI 原始输出不在原文件上修改。ai_verified/保存已经人工验证过的结论和代码。analysis_notes/保存自己的调试记录和证据截图。这样做有两个好处一是可以追溯 AI 在哪个环节产生了错误结论二是避免把 AI 输出直接当成“已确认事实”写入最终报告。8. 最佳实践与后续学习路径8.1 用 AI 学二进制逆向的正确姿势如果你是 CTF 新手或刚接触二进制安全不要一开始就把样本丢给 AI 要答案。正确做法是自己先尝试分析把困惑点记录下来再让 AI 解释原理。比如我实验里的check_flag函数如果你自己先看汇编版本再对比 VMP 版本就能直观理解虚拟化保护对代码形态的改变。AI 更适合当“陪练”而不是“代打”。你可以让 AI 出题让它给你一个简单程序并说明保护思路然后自己尝试分析最后让 AI 检查你的分析过程。这种方式既保留了学习价值又能利用 AI 加快知识获取速度。8.2 可复用的实验检查清单每次做 VMP 或类似加壳样本分析时建议对照以下清单样本是否来自可信来源是否已获得授权。虚拟机快照是否已创建。样本哈希是否已记录。DIE、PEiD、x32dbg、Scylla 是否都可用。AI 提示词模板是否保存输入材料是否完整。是否关闭网络或限制外联。是否计划好了分析完成后的清理步骤。AI 的关键结论是否已经被调试器验证。是否有最终报告和证据附件。这个清单不复杂但能避免大多数常见事故。尤其是“样本来源”和“授权”这两项应该放在第一位。8.3 从 VMP 出发可以继续研究的方向如果 VMP 分析让你对二进制安全产生了兴趣可以按以下路径扩展先掌握 PE 文件结构、加载过程和导入表机制。再练习 UPX、ASPack 等传统壳的脱壳理解 OEP 定位方法。接着学习 OLLVM 的控制流平坦化理解编译器级混淆。然后尝试 VMP 的 handler 识别和字节码解码记录每个 handler 的行为。扩展到移动端加固分析比如 Android 的 Dex 加固和 So 库的混淆。最后结合 Frida、unidbg 等动态插桩工具做更自动化的分析。AI 在每一层都能提供辅助但真正提升能力的还是你亲手定位过断点、修复过导入表、还原过 VM handler 之后的经验积累。回到开头的问题AI 真能干掉 VMP 吗从本次实测来看答案是“不能”。至少现在不能独立完成。但 AI 已经能显著提升分析效率让一个熟悉逆向原理的人用更少时间完成样本分类、方案设计和脚本初稿。VMP 这类保护技术会继续演进AI 也会继续演进最终胜出的不是单纯依赖某一方的人而是能把 AI 方案、工具事实和人工判断紧密结合的分析者。