1. 这篇文章真正要解决的问题最近后台一直有读者问同一个问题AI 都这么强了能不能直接拿过来干逆向能不能一键脱掉 VMP甚至有人把问题问得更直接是不是以后做二进制安全不需要人看汇编了全部交给 AI 就行了我的判断先说在前面AI 目前不能“一键干掉 VMP”但 AI 在辅助逆向和辅助脱壳这件事上确实把门槛拉低了很多。它真正降低的是“从零开始面对一个未知壳程序”时的排查成本。过去你需要手动翻各种特征、反复试断点、在 OD 和 x64dbg 里来回切现在可以把大量“读代码、找规律、猜意图”的工作丢给 AI再由人来复核和收尾。这篇文章会把一次完整的 AI 辅助逆向脱壳实验拆开讲从环境准备、任务设计、Prompt 写法到 AI 输出结果之后如何人工核验再到哪些环节 AI 容易翻车。读完之后你会得到一个能直接复用的 AI 辅助逆向工作流而不是一个假的“自动脱壳脚本”。需要先声明一个前提下面所有的脱壳、逆向、dump、修复导入表操作都在隔离虚拟机中进行测试样本是自编写或已获授权使用的教学样本。请记住没有授权就去逆向别人的软件在多数法域下都可能构成违规职业安全和法律风险远比技术风险高得多。这也是全文所有实操步骤的第一原则。2. VMP、加壳与脱壳的基础概念2.1 VMP 到底做了什么VMP即 VMProtect是一款商业级软件保护工具。它和普通压缩壳的区别在于普通壳如 UPX只是把程序压缩一下运行时再解压回内存核心代码逻辑并没有变VMP 则会把选中的代码块“虚拟化”翻译成一套自定义字节码然后在运行时用内置的虚拟机解释器逐条执行。你可以把它理解为把原来的汇编程序翻译成了一种只有它自己懂的“外星语言”。调试器看到的不是原来的指令而是一个不停在解释执行的虚拟机主循环每个 VM handler 都在处理自己的字节码。这种保护方式的直接后果是静态分析变成了一场灾难动态调试也容易陷入海量的虚拟指令流。2.2 壳层、OEP 与 IAT脱壳的本质是让程序在运行时自己完成解密、解压、还原代码的过程等到它把原始代码恢复到内存后再把它从内存中抓出来并修复成可独立运行的 PE 文件。几个关键术语需要先对齐OEP / EntryPoint原始程序的真实入口点。壳在运行完解密逻辑后会把控制权交给 OEP。找到 OEP 是脱壳第一步。IAT导入地址表。程序调用外部 API 时需要通过这张表。壳在运行时会动态重建 IAT脱壳后必须修复否则程序一运行就崩。Dump把当前进程内存中的镜像抓出来保存成文件。Dump 出来的文件通常不能直接运行因为 IAT、重定位等可能还是断的。VM 区段被虚拟化的代码区域。VMP 会把原始指令替换成字节码并生成一个或多个 VM 区段。能不能还原取决于你要不要恢复这些虚拟化代码。2.3 AI 在哪个环节介入如果把脱壳流程拆成“识别壳特征 → 静态侦察 → 动态调试 → 找 OEP → Dump → 修复 IAT → 还原代码”AI 真正能发挥作用的环节是前面几个和后面几个尤其是壳特征识别喂给它 PE 头、区段名、导入表特征它能很快告诉你可能是什么壳。静态代码理解把反汇编片段丢给它它能帮你解释这段代码在干嘛甚至给出等价的高级语言逻辑。调试脚本生成让 AI 生成 x64dbg 脚本、Frida 脚本、Python 分析脚本比自己查 API 快很多。IAT 修复辅助让它根据导入表和调用点信息生成修复建议或脚本。但最核心的“找 VM 入口、还原 handler、对抗反调试”这些细活AI 目前仍然相当依赖人的引导。它更像一个经验丰富但必须被盯着的实习生而不是一个全自动的老师傅。3. 环境准备与前置条件AI 辅助逆向脱壳不等于你不用搭环境。相反环境越干净AI 的输出越容易验证否则你根本分不清问题是样本本身的、AI 幻觉的还是环境干扰的。3.1 隔离环境强烈建议使用 VMware 或 VirtualBox 创建一个独立的 Windows 虚拟机专门用于脱壳实验。原因有三样本可能在脱壳过程中触发反调试、反虚拟机或恶意行为隔离环境能把风险挡住。VMProtect 这类壳对调试器敏感真实桌面环境里各种残留驱动会让现象难以复现。快照功能可以让你随时回滚反复尝试不同的断点和 dump 策略。虚拟机的系统版本、位数要和目标程序匹配。如果样本是 32 位就准备 32 位 Windows如果是 64 位就准备 64 位。3.2 基础工具链下面这套工具组合是逆向脱壳的常规配置建议提前装好并确认版本兼容工具用途说明x64dbg / x32dbg动态调试目前 Windows 平台最主流的调试器IDA Pro / Ghidra静态分析Ghidra 免费适合预算有限的场景Scylla / ImportRECDump 与 IAT 修复脱壳后的标准修复工具PEiD / Detect It Easy查壳用于第一步识别壳特征Python 3 pefile脚本辅助写自定义分析脚本时很有用Frida动态插桩适合 hook API辅助分析运行时行为这些工具的具体版本建议以实际系统为准本文重点演示通用思路不绑定某个特定版本。如果你在自己的环境里装不上某个插件优先检查位数和系统版本是否匹配。3.3 测试样本选择教学环境里不要一上来就拿真实商业软件做实验。更稳妥的路径是用自己写的小程序编译后套上 VMProtect 试用版生成一个“已知底牌”的样本。用网上公开的 CrackMe、CTF 逆向题、恶意分析训练样本。这些样本通常已经获得作者或社区授权专门用来练习逆向。这是因为脱壳工作必须要有“对错标准”。自己编译的样本你清楚 OEP 应该在哪IAT 应该包含哪些函数VM 区的行为是什么。脱完壳后一对比就知道 AI 辅助方案有没有成功。如果一开始就拿未知样本你连结果对错都无法判断。3.4 授权和日志建议在实验开始前写一份简单的 README 记录样本来源、授权情况、实验日期、测试环境、目标行为。这不只是合规需要也是复现实验的基础。AI 辅助逆向最大的风险不是能力不够而是输出不可复现——如果你不记录清楚 Prompt 和上下文同一个问题换个窗口再问AI 给你的方案可能完全不同。4. 让 AI 独立分析样本的完整流程接下来进入核心部分。我把一次典型的“AI 辅助脱壳”流程拆成四个阶段。每个阶段都包含为什么要这样做、给 AI 的 Prompt、AI 可能给出的回答、以及你必须做的人工核验。4.1 第一步让 AI 做静态侦察拿到样本后先别急着丢进调试器。先用 Detekt It Easy 或 pefile 看基本信息然后把关键信息交给 AI。给 AI 的 Prompt 可以这样写你是一名 Windows 二进制安全分析师。我拿到了一个疑似加壳的可执行文件需要你帮我做初步分析。 样本信息如下 - 文件大小xxx KB - 区段列表[.text, .vmp0, .vmp1, .rdata, .data] - 导入表仅包含 LoadLibraryA、GetProcAddress、VirtualAlloc - 熵值.text 区段熵为 7.91.vmp0 区段熵为 7.98 - 文件编译时间戳2023-xx-xx 请回答 1. 根据区段名和导入表特征判断可能加的是什么壳。 2. 下一步应该优先做静态分析还是直接动态调试。 3. 在调试这个样本时你建议从哪个环节入手寻找 OEP。AI 通常会给出类似这样的判断区段名带vmp且导入表被压缩成最少功能项高度符合 VMProtect 的特征建议直接用 x64dbg 动态调试因为在壳早期就把导入表恢复完静态分析收益很低寻找 OEP 优先采用“内存断点法”或“栈平衡法”。这里第一道人工核验点就出现了AI 说的是否符合常识如果 AI 说“用静态分析直接还原字节码就能一步到位”那基本可以判定它在编。因为 VMProtect 对虚拟化代码的还原目前没有任何公开的一键工具能保证完整恢复。一个靠谱的 AI 回答一定会建议动态调试 脱壳修复。值得提醒的是不要把 AI 给出的“90% 可能是 VMProtect”直接当成结论。你还需要打开 Detect It Easy 人工确认一下。AI 的价值是帮你列出思考路径而不是替代工具本身的检测结果。4.2 第二步让 AI 设计动态调试方案拿到初步判断后下一步是让 AI 生成一套可行的调试思路。这是 AI 最有用的环节之一因为它能把“脱壳的多种常见方案”整理得非常清楚。给 AI 的 Prompt我正在用 x64dbg 调试一个疑似 VMProtect 壳的 32 位程序。 我需要你帮我设计一个寻找 OEP 的调试流程。 要求 1. 说明每一步的操作目的。 2. 说明每一步应该观察哪些关键点。 3. 给出一个条件断点的设置思路。 4. 告诉我如何判断是否快要到达 OEP。 5. 如果程序有反调试应该怎么处理。 请以分步骤的方式输出。一个合格的 AI 回答会覆盖以下核心思路首选“内存断点法”在VirtualAlloc或VirtualProtect上下断点观察壳在什么时候申请新的可执行内存这通常是解密代码的阶段。其次用“栈平衡法”在壳代码末尾常见jmp到 OEP 之前堆栈指针会有一次明显的调整。可以用条件断点持续监控esp。最后用“硬件断点”对可疑代码区段下硬件执行断点避免被软件断点检测轻松发现。你需要做的是把这些思路落到 x64dbg 的操作里。比如 AI 说“在 VirtualAlloc 上下断点”你就设置断点等程序断下后再一行一行观察汇编。这一个环节最考验人的能力也最容易暴露 AI 的局限。AI 能给你一个漂亮的流程但它看不到你屏幕上真实的寄存器值。如果断点没有命中AI 不会主动告诉你“可能是反调试检测到了调试器”它只会等你继续提问。4.3 第三步让 AI 协助分析 VM 入口与 handler如果样本只是普通压缩壳走到第二步基本就能找到 OEP 完成脱壳。但如果样本是 VMP 虚拟化过的你还要面对“被虚拟化的那部分代码”。这是整个实验里最有趣的环节。我给 AI 输入了一段反汇编片段的简化示例让它分析这段代码想实现什么。下面是一个模拟输出我给出的反汇编片段示意 push ebp mov ebp, esp push edi xor edi, edi mov ecx, [ebp8] cmp ecx, 0 jz short loc_401023 add edi, ecx mov eax, [ebp0xC] add eax, edi ... AI 回答 这段代码看起来是一个简单的求和函数。它接收两个参数 第一个参数是循环次数或数组长度第二个参数是数据区指针。 xor edi, edi 是将累加器清零后面在循环里对每个元素做累加。在这个环节AI 的代码理解能力非常强它能把常见的汇编模式直接翻译成 C 语言逻辑。但请注意VMP 虚拟化后的代码不会给你这么优雅的汇编片段它都是千篇一律的 VM 主循环mov al, [esi] inc esi jmp [eax*4 vm_dispatcher]真正还原 handler 的时候AI 会呈现出明显的“局部理解强、全局还原弱”的特点。它适合做的是“把一段 handler 的含义解释出来”而不是“自动把所有 handler 全部还原成原始函数”。这一点在实测中非常重要。4.4 第四步让 AI 生成 Dump 与修复方案当你到达 OEP 后最后一个核心步骤是从内存中 Dump 程序并修复 IAT。这一步可以用 x64dbg 配合 Scylla 完成也可以让 AI 帮你生成完整的操作清单或脚本。给 AI 的 Prompt我已在 x64dbg 中停在疑似 OEP 的位置寄存器状态如下 EAX0x00401000EIP0x00401000当前代码是标准的编译器入口。 我打算用 Scylla 插件做 Dump 和 IAT 修复。 请告诉我 1. 在 Scylla 中应该选择哪个进程attach 到哪个地址。 2. IAT 搜索的起始地址如何确定。 3. 修复时如何选择“重建导入表”选项。 4. 修复后如何验证新程序能正常运行。AI 的回答会指向一个正确的操作顺序attach 到当前进程 → 填写 OEP 地址 → 点击 IAT Autosearch → 如果结果异常手动检查第一个调用点 → Get Imports → Fix Dump。最后用脱壳后的文件替换原文件跑一次看是否能正常启动。Dump 和修复 IAT 是最不能出错的环节。如果 IAT 修复失败程序通常表现为“运行后立刻崩溃”或“点击按钮时无响应”。这时候一定要把 Dump 前的内存状态和 Scylla 扫描到的导入函数列表截图让 AI 根据具体错误排查。5. 可复用的 AI 辅助脱壳工具箱为了让整套流程可以沉淀到日常工作中我把比较通用的辅助脚本和 Prompt 模板整理成了一份工具箱。你可以直接保存下来下次做脱壳实验时按需使用。5.1 通用 Prompt 模板你是一名 Windows 二进制安全与逆向分析专家。我会给你一段反汇编代码、PE 头信息或调试日志请你 1. 解释代码的功能尽量用 C 语言伪代码表示。 2. 指出其中可疑的点例如反调试、自校验、混淆特征。 3. 如果这是加壳程序说明当前处于壳的哪个阶段。 4. 给出下一步的调试建议不要泛泛而谈。 5. 如果有不确定的地方直接说不确定不要编造寄存器或地址。 以下是我要分析的输入 [在这里粘贴代码 / 输出 / 描述]这个模板的核心是“让 AI 明确边界”。如果你不限定AI 很容易在细节缺失的情况下脑补出一个看似合理的答案。要求它“不确定就直说”能显著降低幻觉几率。5.2 基于 pefile 的静态侦察脚本这个脚本适合在动态调试前快速查看样本的区段和熵值给 AI 提供基础信息。文件路径为pe_scan.py。import pefile import math import sys def entropy(data: bytes) - float: if not data: return 0.0 freq [0] * 256 for b in data: freq[b] 1 ent 0.0 length len(data) for f in freq: if f 0: p f / length ent - p * math.log2(p) return ent def main(path: str) - None: pe pefile.PE(path, fast_loadTrue) print( 基本信息 ) print(镜像基址: 0x%X % pe.OPTIONAL_HEADER.ImageBase) print(入口点: 0x%X % pe.OPTIONAL_HEADER.AddressOfEntryPoint) print(\n 区段信息 ) for sec in pe.sections: name sec.Name.rstrip(b\x00).decode(utf-8, ignore) size sec.Misc_VirtualSize raw_size len(sec.get_data()) ent entropy(sec.get_data()[:raw_size] if raw_size else b) print(f{name:10s} 虚拟大小: {size:#10x} 熵值: {ent:.2f}) print(\n 导入表(前10项) ) pe.parse_data_directories(directories[pefile.DIRECTORY_ENTRY[IMAGE_DIRECTORY_ENTRY_IMPORT]]) if hasattr(pe, DIRECTORY_ENTRY_IMPORT): for entry in pe.DIRECTORY_ENTRY_IMPORT[:10]: dll entry.dll.decode(utf-8, ignore) funcs [imp.name.decode(utf-8, ignore) if imp.name else ford_{imp.ordinal} for imp in entry.imports[:5]] print(f{dll}: {, .join(funcs)}) else: print(未发现导入表通常是壳压缩后的特征。) pe.close() if __name__ __main__: if len(sys.argv) ! 2: print(用法: python pe_scan.py file_path) sys.exit(1) main(sys.argv[1])运行方式python pe_scan.py test_vmp.exe如果输出区段名里有vmp、.vmp0且导入表只有LoadLibraryA、GetProcAddress等少量函数基本可以判断该程序被 VMProtect 处理过。5.3 x64dbg 条件断点脚本示例在 x64dbg 中你可以在命令栏执行脚本。下面这个脚本给VirtualAlloc设下断点每次断下后自动输出当前申请的地址和大小适合观察壳是否在内部分配可执行内存。// 文件x64dbg 命令栏脚本 bp VirtualAlloc Loop: run log EAX0x{EAX:X} size0x{EDX:X} type0x{ECX:X} // 手动观察 EAX 是否为可执行内存地址 jmp Loop这里要注意VirtualAlloc的断点会被循环频繁触发所以更适合结合条件判断。如果要自动化一点可以在 x64dbg 的脚本引擎里加上次数限制比如只断前 20 次。这个脚本的意义不是直接找到 OEP而是帮你快速定位壳申请内存的时机。5.4 Scylla 修复 IAT 的检查清单Scylla 的操作虽然图形化但每个选项背后都有讲究。下面是给 AI 复核时也会同步使用的检查清单步骤操作判断标准1附加到脱壳目标进程进程列表中选对 PID2填写 OEP 地址地址必须是在调试器中确认过的真实入口点3IAT Autosearch扫描到的函数数量合理不是 0 也不是异常大4Get Imports导入的 DLL 都是正常系统 DLL没有明显缺失5Fix Dump生成修复后的文件6运行验证修复后的程序能独立启动调用关键 API 不崩溃如果第 3 步扫描出的导入表为空通常不是 Scylla 的问题而是你之前的断点没有停到正确位置。先回头看 OEP 是否准确再考虑 IAT 修复。6. 运行结果与效果验证6.1 如何判断脱壳成功脱壳不是“Dump 出来一个文件”就算成功。真正的判断标准是修复后的程序在不依赖原壳的情况下能正常启动并执行与原始程序一致的功能。建议按这个顺序验证打开脱壳后的文件对照原始样本的入口点地址是否合理。用 Detect It Easy 再次检测壳特征是否已经消失。双击运行脱壳后的程序观察是否报错。用 Process Monitor 或 Wireshark 观察程序行为是否与原程序一致。在调试器里加载脱壳后的程序确认导入函数能正确解析。6.2 预期输出以自编写样本为例脱壳成功后的典型输出如下原始样本区段 .text .rdata .data 脱壳后区段 .text .rdata .data 检测工具结果 未检测到已知壳特征。此时程序能够以独立文件形式运行不再依赖 VMProtect 的运行时环境。这个过程就是在做“壳层还原”但虚拟化的业务代码还没有被完全翻译回原始汇编运行时逻辑已经暴露出来了。6.3 失败时的第一排查方向如果脱壳后的文件一运行就崩溃不要马上怀疑 Scylla 或 AI 的方案先按以下顺序排查看错误类型。如果是“无法定位程序输入点”说明 IAT 修复有缺口重点回看导入表。看崩溃地址。如果崩溃地址落在壳区段说明 OEP 判断偏早还没有到程序真正入口。看调试器日志。确认在 Dump 前是否被反调试机制带偏了路径。这一节给一个最实用的判断脱壳最常见的失败原因不是工具不会用而是 OEP 找错了。如果你找的“OEP”比真实入口早了几十行Dump 出来的文件运行到一半就会崩。AI 能帮你理解汇编但最终确认 OEP 时你必须自己盯着寄存器、栈和内存状态来做最终判断。7. 常见问题与排查思路问题现象可能原因排查方式解决方案AI 给出大量寄存器/地址但调试器里对不上AI 根据不完整上下文脑补了细节要求 AI 区分“分析”和“猜测”核实每个地址回贴真实寄存器值追加提问“哪些是推测”VirtualAlloc 断点永远不命中反调试提前检测到调试器检查 IsDebuggerPresent、NtQueryInformationProcess换用硬件断点或先 patch 反调试分支Scylla 扫描 IAT 结果为空OEP 没有停准或 IAT 在壳内尚未恢复完成回到调试器用内存断点法重新定位 OEP重新执行脱壳流程不要跳过找 OEP脱壳后程序无法启动提示缺少 DLL导入表修复不完整用 Scylla 对比原始导入表手工补导入项或用原始程序做对照AI 说“可以一键还原 VMP 代码”AI 幻觉不存在成熟的通用方案要求 AI 给出具体工具名和原理立即修正预期VMP 虚拟化代码还原仍然高度依赖人工调试中程序自动退出检测到 VM 环境或调试痕迹查看调试器日志和程序退出码尝试隐藏调试器或在非虚拟化环境测试这张表格是我觉得全文里最值得收藏的部分。因为 AI 辅助逆向的核心问题很集中不是 AI 不会答而是你很难判断 AI 在哪个环节开始胡编。最常见的翻车点就是地址和寄存器值。预防方法很简单在 Prompt 中反复强调“如果缺少上下文就明确说缺少上下文不要推测”。如果 AI 给了完整分析但你发现它使用了你没有提供过的地址那大概率是在编。8. AI 不能做什么VM 业务还原与对抗加固AI 在脱壳流程中能大幅提效但在几个方向上仍然明显乏力这是本次实验给出的最诚实结论。第一VMP handler 的完整还原仍然做不到。AI 能解释单个 VM handler 的语义但当几百个 handler 组成一个复杂的字节码解释器时AI 很难在全局尺度上完成自动化还原。原因是它没有真正的程序执行模型无法像人一样“运行一遍原始逻辑再验证还原结果是否等价”。这需要形式化验证级别的工具支撑目前公开方案还远未成熟。第二反调试和反虚拟机对抗需要人工设计策略。AI 可以给你列出常见的反调试 API但面对一个精心设计的 VMP 加固程序它生成的对策往往是通用模板不能针对真实样本做动态调整。你仍然需要自己在调试器里观察哪条分支被反调试逻辑命中然后决定 patch 还是绕过。第三自校验和代码完整性保护是 AI 的盲区。很多加固程序会对自己做哈希校验脱壳后文件一旦被改动就会自动进入错误分支。AI 很难在未经动态验证的情况下判断这个校验点在 Dump 后是否还会触发。你需要通过静态分析和动态监控双重定位校验逻辑再决定是保留还是 patch。第四AI 没有“合规意识”和“安全边界”概念。你让它分析一段代码它会照做但如果目标程序属于未经授权的商业软件技术上的“能”和法律上的“能”是完全两回事。在二进制安全领域判断一个样本是否允许分析永远是人来做这个决定。更稳妥的判断是AI 是一个强大的“逆向分析副驾驶”而不是“自动驾驶”。它擅长缩小范围、解释逻辑、生成脚本、整理思路但它不擅长带着你从零到一、从模糊到精确地完成一次高难度脱壳。任何声称 AI 已经完全取代人工逆向的说法目前都站不住脚。9. 最佳实践与工程建议如果要把 AI 辅助逆向脱壳真正用到日常工作和学习中下面几条工程建议值得坚持。第一永远在隔离环境里做脱壳实验。这不是一句口号。即使自编写的样本也可能在加壳后产生意想不到的行为。虚拟机快照是你回退到“刚刚开始调试”状态的最快手段。每完成一个关键探索节点比如找到 OEP、定位 IAT就拍一个快照能省下大量重跑时间。第二任何 AI 输出都要落到可验证的事实上。不要让 AI 直接给你一个“最终结论”而是把它的回答拆分成可验证的断言一条条在调试器里确认。例如它说“这个函数的功能是加密字符串”你就应该找到它的调用点、参数来源和返回值使用位置。验证不通过就继续追问。第三把脱壳报告当成代码一样管理。记录样本哈希、环境版本、Prompt 文本、AI 输出摘要、人工修改点、Dump 前后对比。这样两周后回看时你还能复现当时结论。第四团队里要有一个负责“纠偏 AI ”的人。如果你们小组所有成员都依赖同一个 AI 模型来分析样本很容易出现“把 AI 幻觉当成共识”的集体偏差。正确做法是让一个人专职复核 AI 输出另一个人从调试器侧验证两人交叉确认后再继续。第五不要把脱壳成功当成安全分析完成。脱壳只是拿到了可读的二进制真正有安全价值的分析是脱壳之后的还原业务逻辑、定位漏洞点、理解攻击面。很多时候严重漏洞藏在壳下面的那几行逻辑里而不是壳本身。所以脱壳完成后请把报告重心放到“这个程序在做什么”而不是“我用什么工具脱的壳”。10. 总结与下一步方向这篇文章围绕“AI 能否干掉 VMP”这个问题做了一次完整的实验复盘和技术拆解。核心结论是AI 不能一键干掉 VMP但它能明显降低逆向脱壳的学习和排查成本。它会读汇编、会写脚本、会整理思路但找 OEP、确认 IAT、判断反调试分支这些关键节点仍然需要人来拍板。如果你打算沿着这个方向继续深入建议按下面这条路径走先用自己编译的程序套不同加壳工具把“找 OEP → Dump → 修复 IAT”这个基础流程跑通。再用公开 CTF 逆向题练习重点感受“在没有原始符号的情况下如何靠行为特征推断代码功能”。最后研究 VMProtect 的虚拟化原理从字节码格式、handler 分派表开始理解为什么完整还原如此困难。二进制安全是一片非常吃经验的领域AI 的到来并没有抹平经验的差距反而放大了“会用 AI”和“只会问 AI”的人之间的差距。能独立验证 AI 结论的人才是真正能独立做逆向的人。给自己一个目标下一次拿到带壳样本先让 AI 帮你把地图画好然后自己一步一步走过去。这样积累的经验才是 AI 替代不了的东西。 AI辅助逆向脱壳实战：VMP不再是不可逾越的壁垒
1. 这篇文章真正要解决的问题最近后台一直有读者问同一个问题AI 都这么强了能不能直接拿过来干逆向能不能一键脱掉 VMP甚至有人把问题问得更直接是不是以后做二进制安全不需要人看汇编了全部交给 AI 就行了我的判断先说在前面AI 目前不能“一键干掉 VMP”但 AI 在辅助逆向和辅助脱壳这件事上确实把门槛拉低了很多。它真正降低的是“从零开始面对一个未知壳程序”时的排查成本。过去你需要手动翻各种特征、反复试断点、在 OD 和 x64dbg 里来回切现在可以把大量“读代码、找规律、猜意图”的工作丢给 AI再由人来复核和收尾。这篇文章会把一次完整的 AI 辅助逆向脱壳实验拆开讲从环境准备、任务设计、Prompt 写法到 AI 输出结果之后如何人工核验再到哪些环节 AI 容易翻车。读完之后你会得到一个能直接复用的 AI 辅助逆向工作流而不是一个假的“自动脱壳脚本”。需要先声明一个前提下面所有的脱壳、逆向、dump、修复导入表操作都在隔离虚拟机中进行测试样本是自编写或已获授权使用的教学样本。请记住没有授权就去逆向别人的软件在多数法域下都可能构成违规职业安全和法律风险远比技术风险高得多。这也是全文所有实操步骤的第一原则。2. VMP、加壳与脱壳的基础概念2.1 VMP 到底做了什么VMP即 VMProtect是一款商业级软件保护工具。它和普通压缩壳的区别在于普通壳如 UPX只是把程序压缩一下运行时再解压回内存核心代码逻辑并没有变VMP 则会把选中的代码块“虚拟化”翻译成一套自定义字节码然后在运行时用内置的虚拟机解释器逐条执行。你可以把它理解为把原来的汇编程序翻译成了一种只有它自己懂的“外星语言”。调试器看到的不是原来的指令而是一个不停在解释执行的虚拟机主循环每个 VM handler 都在处理自己的字节码。这种保护方式的直接后果是静态分析变成了一场灾难动态调试也容易陷入海量的虚拟指令流。2.2 壳层、OEP 与 IAT脱壳的本质是让程序在运行时自己完成解密、解压、还原代码的过程等到它把原始代码恢复到内存后再把它从内存中抓出来并修复成可独立运行的 PE 文件。几个关键术语需要先对齐OEP / EntryPoint原始程序的真实入口点。壳在运行完解密逻辑后会把控制权交给 OEP。找到 OEP 是脱壳第一步。IAT导入地址表。程序调用外部 API 时需要通过这张表。壳在运行时会动态重建 IAT脱壳后必须修复否则程序一运行就崩。Dump把当前进程内存中的镜像抓出来保存成文件。Dump 出来的文件通常不能直接运行因为 IAT、重定位等可能还是断的。VM 区段被虚拟化的代码区域。VMP 会把原始指令替换成字节码并生成一个或多个 VM 区段。能不能还原取决于你要不要恢复这些虚拟化代码。2.3 AI 在哪个环节介入如果把脱壳流程拆成“识别壳特征 → 静态侦察 → 动态调试 → 找 OEP → Dump → 修复 IAT → 还原代码”AI 真正能发挥作用的环节是前面几个和后面几个尤其是壳特征识别喂给它 PE 头、区段名、导入表特征它能很快告诉你可能是什么壳。静态代码理解把反汇编片段丢给它它能帮你解释这段代码在干嘛甚至给出等价的高级语言逻辑。调试脚本生成让 AI 生成 x64dbg 脚本、Frida 脚本、Python 分析脚本比自己查 API 快很多。IAT 修复辅助让它根据导入表和调用点信息生成修复建议或脚本。但最核心的“找 VM 入口、还原 handler、对抗反调试”这些细活AI 目前仍然相当依赖人的引导。它更像一个经验丰富但必须被盯着的实习生而不是一个全自动的老师傅。3. 环境准备与前置条件AI 辅助逆向脱壳不等于你不用搭环境。相反环境越干净AI 的输出越容易验证否则你根本分不清问题是样本本身的、AI 幻觉的还是环境干扰的。3.1 隔离环境强烈建议使用 VMware 或 VirtualBox 创建一个独立的 Windows 虚拟机专门用于脱壳实验。原因有三样本可能在脱壳过程中触发反调试、反虚拟机或恶意行为隔离环境能把风险挡住。VMProtect 这类壳对调试器敏感真实桌面环境里各种残留驱动会让现象难以复现。快照功能可以让你随时回滚反复尝试不同的断点和 dump 策略。虚拟机的系统版本、位数要和目标程序匹配。如果样本是 32 位就准备 32 位 Windows如果是 64 位就准备 64 位。3.2 基础工具链下面这套工具组合是逆向脱壳的常规配置建议提前装好并确认版本兼容工具用途说明x64dbg / x32dbg动态调试目前 Windows 平台最主流的调试器IDA Pro / Ghidra静态分析Ghidra 免费适合预算有限的场景Scylla / ImportRECDump 与 IAT 修复脱壳后的标准修复工具PEiD / Detect It Easy查壳用于第一步识别壳特征Python 3 pefile脚本辅助写自定义分析脚本时很有用Frida动态插桩适合 hook API辅助分析运行时行为这些工具的具体版本建议以实际系统为准本文重点演示通用思路不绑定某个特定版本。如果你在自己的环境里装不上某个插件优先检查位数和系统版本是否匹配。3.3 测试样本选择教学环境里不要一上来就拿真实商业软件做实验。更稳妥的路径是用自己写的小程序编译后套上 VMProtect 试用版生成一个“已知底牌”的样本。用网上公开的 CrackMe、CTF 逆向题、恶意分析训练样本。这些样本通常已经获得作者或社区授权专门用来练习逆向。这是因为脱壳工作必须要有“对错标准”。自己编译的样本你清楚 OEP 应该在哪IAT 应该包含哪些函数VM 区的行为是什么。脱完壳后一对比就知道 AI 辅助方案有没有成功。如果一开始就拿未知样本你连结果对错都无法判断。3.4 授权和日志建议在实验开始前写一份简单的 README 记录样本来源、授权情况、实验日期、测试环境、目标行为。这不只是合规需要也是复现实验的基础。AI 辅助逆向最大的风险不是能力不够而是输出不可复现——如果你不记录清楚 Prompt 和上下文同一个问题换个窗口再问AI 给你的方案可能完全不同。4. 让 AI 独立分析样本的完整流程接下来进入核心部分。我把一次典型的“AI 辅助脱壳”流程拆成四个阶段。每个阶段都包含为什么要这样做、给 AI 的 Prompt、AI 可能给出的回答、以及你必须做的人工核验。4.1 第一步让 AI 做静态侦察拿到样本后先别急着丢进调试器。先用 Detekt It Easy 或 pefile 看基本信息然后把关键信息交给 AI。给 AI 的 Prompt 可以这样写你是一名 Windows 二进制安全分析师。我拿到了一个疑似加壳的可执行文件需要你帮我做初步分析。 样本信息如下 - 文件大小xxx KB - 区段列表[.text, .vmp0, .vmp1, .rdata, .data] - 导入表仅包含 LoadLibraryA、GetProcAddress、VirtualAlloc - 熵值.text 区段熵为 7.91.vmp0 区段熵为 7.98 - 文件编译时间戳2023-xx-xx 请回答 1. 根据区段名和导入表特征判断可能加的是什么壳。 2. 下一步应该优先做静态分析还是直接动态调试。 3. 在调试这个样本时你建议从哪个环节入手寻找 OEP。AI 通常会给出类似这样的判断区段名带vmp且导入表被压缩成最少功能项高度符合 VMProtect 的特征建议直接用 x64dbg 动态调试因为在壳早期就把导入表恢复完静态分析收益很低寻找 OEP 优先采用“内存断点法”或“栈平衡法”。这里第一道人工核验点就出现了AI 说的是否符合常识如果 AI 说“用静态分析直接还原字节码就能一步到位”那基本可以判定它在编。因为 VMProtect 对虚拟化代码的还原目前没有任何公开的一键工具能保证完整恢复。一个靠谱的 AI 回答一定会建议动态调试 脱壳修复。值得提醒的是不要把 AI 给出的“90% 可能是 VMProtect”直接当成结论。你还需要打开 Detect It Easy 人工确认一下。AI 的价值是帮你列出思考路径而不是替代工具本身的检测结果。4.2 第二步让 AI 设计动态调试方案拿到初步判断后下一步是让 AI 生成一套可行的调试思路。这是 AI 最有用的环节之一因为它能把“脱壳的多种常见方案”整理得非常清楚。给 AI 的 Prompt我正在用 x64dbg 调试一个疑似 VMProtect 壳的 32 位程序。 我需要你帮我设计一个寻找 OEP 的调试流程。 要求 1. 说明每一步的操作目的。 2. 说明每一步应该观察哪些关键点。 3. 给出一个条件断点的设置思路。 4. 告诉我如何判断是否快要到达 OEP。 5. 如果程序有反调试应该怎么处理。 请以分步骤的方式输出。一个合格的 AI 回答会覆盖以下核心思路首选“内存断点法”在VirtualAlloc或VirtualProtect上下断点观察壳在什么时候申请新的可执行内存这通常是解密代码的阶段。其次用“栈平衡法”在壳代码末尾常见jmp到 OEP 之前堆栈指针会有一次明显的调整。可以用条件断点持续监控esp。最后用“硬件断点”对可疑代码区段下硬件执行断点避免被软件断点检测轻松发现。你需要做的是把这些思路落到 x64dbg 的操作里。比如 AI 说“在 VirtualAlloc 上下断点”你就设置断点等程序断下后再一行一行观察汇编。这一个环节最考验人的能力也最容易暴露 AI 的局限。AI 能给你一个漂亮的流程但它看不到你屏幕上真实的寄存器值。如果断点没有命中AI 不会主动告诉你“可能是反调试检测到了调试器”它只会等你继续提问。4.3 第三步让 AI 协助分析 VM 入口与 handler如果样本只是普通压缩壳走到第二步基本就能找到 OEP 完成脱壳。但如果样本是 VMP 虚拟化过的你还要面对“被虚拟化的那部分代码”。这是整个实验里最有趣的环节。我给 AI 输入了一段反汇编片段的简化示例让它分析这段代码想实现什么。下面是一个模拟输出我给出的反汇编片段示意 push ebp mov ebp, esp push edi xor edi, edi mov ecx, [ebp8] cmp ecx, 0 jz short loc_401023 add edi, ecx mov eax, [ebp0xC] add eax, edi ... AI 回答 这段代码看起来是一个简单的求和函数。它接收两个参数 第一个参数是循环次数或数组长度第二个参数是数据区指针。 xor edi, edi 是将累加器清零后面在循环里对每个元素做累加。在这个环节AI 的代码理解能力非常强它能把常见的汇编模式直接翻译成 C 语言逻辑。但请注意VMP 虚拟化后的代码不会给你这么优雅的汇编片段它都是千篇一律的 VM 主循环mov al, [esi] inc esi jmp [eax*4 vm_dispatcher]真正还原 handler 的时候AI 会呈现出明显的“局部理解强、全局还原弱”的特点。它适合做的是“把一段 handler 的含义解释出来”而不是“自动把所有 handler 全部还原成原始函数”。这一点在实测中非常重要。4.4 第四步让 AI 生成 Dump 与修复方案当你到达 OEP 后最后一个核心步骤是从内存中 Dump 程序并修复 IAT。这一步可以用 x64dbg 配合 Scylla 完成也可以让 AI 帮你生成完整的操作清单或脚本。给 AI 的 Prompt我已在 x64dbg 中停在疑似 OEP 的位置寄存器状态如下 EAX0x00401000EIP0x00401000当前代码是标准的编译器入口。 我打算用 Scylla 插件做 Dump 和 IAT 修复。 请告诉我 1. 在 Scylla 中应该选择哪个进程attach 到哪个地址。 2. IAT 搜索的起始地址如何确定。 3. 修复时如何选择“重建导入表”选项。 4. 修复后如何验证新程序能正常运行。AI 的回答会指向一个正确的操作顺序attach 到当前进程 → 填写 OEP 地址 → 点击 IAT Autosearch → 如果结果异常手动检查第一个调用点 → Get Imports → Fix Dump。最后用脱壳后的文件替换原文件跑一次看是否能正常启动。Dump 和修复 IAT 是最不能出错的环节。如果 IAT 修复失败程序通常表现为“运行后立刻崩溃”或“点击按钮时无响应”。这时候一定要把 Dump 前的内存状态和 Scylla 扫描到的导入函数列表截图让 AI 根据具体错误排查。5. 可复用的 AI 辅助脱壳工具箱为了让整套流程可以沉淀到日常工作中我把比较通用的辅助脚本和 Prompt 模板整理成了一份工具箱。你可以直接保存下来下次做脱壳实验时按需使用。5.1 通用 Prompt 模板你是一名 Windows 二进制安全与逆向分析专家。我会给你一段反汇编代码、PE 头信息或调试日志请你 1. 解释代码的功能尽量用 C 语言伪代码表示。 2. 指出其中可疑的点例如反调试、自校验、混淆特征。 3. 如果这是加壳程序说明当前处于壳的哪个阶段。 4. 给出下一步的调试建议不要泛泛而谈。 5. 如果有不确定的地方直接说不确定不要编造寄存器或地址。 以下是我要分析的输入 [在这里粘贴代码 / 输出 / 描述]这个模板的核心是“让 AI 明确边界”。如果你不限定AI 很容易在细节缺失的情况下脑补出一个看似合理的答案。要求它“不确定就直说”能显著降低幻觉几率。5.2 基于 pefile 的静态侦察脚本这个脚本适合在动态调试前快速查看样本的区段和熵值给 AI 提供基础信息。文件路径为pe_scan.py。import pefile import math import sys def entropy(data: bytes) - float: if not data: return 0.0 freq [0] * 256 for b in data: freq[b] 1 ent 0.0 length len(data) for f in freq: if f 0: p f / length ent - p * math.log2(p) return ent def main(path: str) - None: pe pefile.PE(path, fast_loadTrue) print( 基本信息 ) print(镜像基址: 0x%X % pe.OPTIONAL_HEADER.ImageBase) print(入口点: 0x%X % pe.OPTIONAL_HEADER.AddressOfEntryPoint) print(\n 区段信息 ) for sec in pe.sections: name sec.Name.rstrip(b\x00).decode(utf-8, ignore) size sec.Misc_VirtualSize raw_size len(sec.get_data()) ent entropy(sec.get_data()[:raw_size] if raw_size else b) print(f{name:10s} 虚拟大小: {size:#10x} 熵值: {ent:.2f}) print(\n 导入表(前10项) ) pe.parse_data_directories(directories[pefile.DIRECTORY_ENTRY[IMAGE_DIRECTORY_ENTRY_IMPORT]]) if hasattr(pe, DIRECTORY_ENTRY_IMPORT): for entry in pe.DIRECTORY_ENTRY_IMPORT[:10]: dll entry.dll.decode(utf-8, ignore) funcs [imp.name.decode(utf-8, ignore) if imp.name else ford_{imp.ordinal} for imp in entry.imports[:5]] print(f{dll}: {, .join(funcs)}) else: print(未发现导入表通常是壳压缩后的特征。) pe.close() if __name__ __main__: if len(sys.argv) ! 2: print(用法: python pe_scan.py file_path) sys.exit(1) main(sys.argv[1])运行方式python pe_scan.py test_vmp.exe如果输出区段名里有vmp、.vmp0且导入表只有LoadLibraryA、GetProcAddress等少量函数基本可以判断该程序被 VMProtect 处理过。5.3 x64dbg 条件断点脚本示例在 x64dbg 中你可以在命令栏执行脚本。下面这个脚本给VirtualAlloc设下断点每次断下后自动输出当前申请的地址和大小适合观察壳是否在内部分配可执行内存。// 文件x64dbg 命令栏脚本 bp VirtualAlloc Loop: run log EAX0x{EAX:X} size0x{EDX:X} type0x{ECX:X} // 手动观察 EAX 是否为可执行内存地址 jmp Loop这里要注意VirtualAlloc的断点会被循环频繁触发所以更适合结合条件判断。如果要自动化一点可以在 x64dbg 的脚本引擎里加上次数限制比如只断前 20 次。这个脚本的意义不是直接找到 OEP而是帮你快速定位壳申请内存的时机。5.4 Scylla 修复 IAT 的检查清单Scylla 的操作虽然图形化但每个选项背后都有讲究。下面是给 AI 复核时也会同步使用的检查清单步骤操作判断标准1附加到脱壳目标进程进程列表中选对 PID2填写 OEP 地址地址必须是在调试器中确认过的真实入口点3IAT Autosearch扫描到的函数数量合理不是 0 也不是异常大4Get Imports导入的 DLL 都是正常系统 DLL没有明显缺失5Fix Dump生成修复后的文件6运行验证修复后的程序能独立启动调用关键 API 不崩溃如果第 3 步扫描出的导入表为空通常不是 Scylla 的问题而是你之前的断点没有停到正确位置。先回头看 OEP 是否准确再考虑 IAT 修复。6. 运行结果与效果验证6.1 如何判断脱壳成功脱壳不是“Dump 出来一个文件”就算成功。真正的判断标准是修复后的程序在不依赖原壳的情况下能正常启动并执行与原始程序一致的功能。建议按这个顺序验证打开脱壳后的文件对照原始样本的入口点地址是否合理。用 Detect It Easy 再次检测壳特征是否已经消失。双击运行脱壳后的程序观察是否报错。用 Process Monitor 或 Wireshark 观察程序行为是否与原程序一致。在调试器里加载脱壳后的程序确认导入函数能正确解析。6.2 预期输出以自编写样本为例脱壳成功后的典型输出如下原始样本区段 .text .rdata .data 脱壳后区段 .text .rdata .data 检测工具结果 未检测到已知壳特征。此时程序能够以独立文件形式运行不再依赖 VMProtect 的运行时环境。这个过程就是在做“壳层还原”但虚拟化的业务代码还没有被完全翻译回原始汇编运行时逻辑已经暴露出来了。6.3 失败时的第一排查方向如果脱壳后的文件一运行就崩溃不要马上怀疑 Scylla 或 AI 的方案先按以下顺序排查看错误类型。如果是“无法定位程序输入点”说明 IAT 修复有缺口重点回看导入表。看崩溃地址。如果崩溃地址落在壳区段说明 OEP 判断偏早还没有到程序真正入口。看调试器日志。确认在 Dump 前是否被反调试机制带偏了路径。这一节给一个最实用的判断脱壳最常见的失败原因不是工具不会用而是 OEP 找错了。如果你找的“OEP”比真实入口早了几十行Dump 出来的文件运行到一半就会崩。AI 能帮你理解汇编但最终确认 OEP 时你必须自己盯着寄存器、栈和内存状态来做最终判断。7. 常见问题与排查思路问题现象可能原因排查方式解决方案AI 给出大量寄存器/地址但调试器里对不上AI 根据不完整上下文脑补了细节要求 AI 区分“分析”和“猜测”核实每个地址回贴真实寄存器值追加提问“哪些是推测”VirtualAlloc 断点永远不命中反调试提前检测到调试器检查 IsDebuggerPresent、NtQueryInformationProcess换用硬件断点或先 patch 反调试分支Scylla 扫描 IAT 结果为空OEP 没有停准或 IAT 在壳内尚未恢复完成回到调试器用内存断点法重新定位 OEP重新执行脱壳流程不要跳过找 OEP脱壳后程序无法启动提示缺少 DLL导入表修复不完整用 Scylla 对比原始导入表手工补导入项或用原始程序做对照AI 说“可以一键还原 VMP 代码”AI 幻觉不存在成熟的通用方案要求 AI 给出具体工具名和原理立即修正预期VMP 虚拟化代码还原仍然高度依赖人工调试中程序自动退出检测到 VM 环境或调试痕迹查看调试器日志和程序退出码尝试隐藏调试器或在非虚拟化环境测试这张表格是我觉得全文里最值得收藏的部分。因为 AI 辅助逆向的核心问题很集中不是 AI 不会答而是你很难判断 AI 在哪个环节开始胡编。最常见的翻车点就是地址和寄存器值。预防方法很简单在 Prompt 中反复强调“如果缺少上下文就明确说缺少上下文不要推测”。如果 AI 给了完整分析但你发现它使用了你没有提供过的地址那大概率是在编。8. AI 不能做什么VM 业务还原与对抗加固AI 在脱壳流程中能大幅提效但在几个方向上仍然明显乏力这是本次实验给出的最诚实结论。第一VMP handler 的完整还原仍然做不到。AI 能解释单个 VM handler 的语义但当几百个 handler 组成一个复杂的字节码解释器时AI 很难在全局尺度上完成自动化还原。原因是它没有真正的程序执行模型无法像人一样“运行一遍原始逻辑再验证还原结果是否等价”。这需要形式化验证级别的工具支撑目前公开方案还远未成熟。第二反调试和反虚拟机对抗需要人工设计策略。AI 可以给你列出常见的反调试 API但面对一个精心设计的 VMP 加固程序它生成的对策往往是通用模板不能针对真实样本做动态调整。你仍然需要自己在调试器里观察哪条分支被反调试逻辑命中然后决定 patch 还是绕过。第三自校验和代码完整性保护是 AI 的盲区。很多加固程序会对自己做哈希校验脱壳后文件一旦被改动就会自动进入错误分支。AI 很难在未经动态验证的情况下判断这个校验点在 Dump 后是否还会触发。你需要通过静态分析和动态监控双重定位校验逻辑再决定是保留还是 patch。第四AI 没有“合规意识”和“安全边界”概念。你让它分析一段代码它会照做但如果目标程序属于未经授权的商业软件技术上的“能”和法律上的“能”是完全两回事。在二进制安全领域判断一个样本是否允许分析永远是人来做这个决定。更稳妥的判断是AI 是一个强大的“逆向分析副驾驶”而不是“自动驾驶”。它擅长缩小范围、解释逻辑、生成脚本、整理思路但它不擅长带着你从零到一、从模糊到精确地完成一次高难度脱壳。任何声称 AI 已经完全取代人工逆向的说法目前都站不住脚。9. 最佳实践与工程建议如果要把 AI 辅助逆向脱壳真正用到日常工作和学习中下面几条工程建议值得坚持。第一永远在隔离环境里做脱壳实验。这不是一句口号。即使自编写的样本也可能在加壳后产生意想不到的行为。虚拟机快照是你回退到“刚刚开始调试”状态的最快手段。每完成一个关键探索节点比如找到 OEP、定位 IAT就拍一个快照能省下大量重跑时间。第二任何 AI 输出都要落到可验证的事实上。不要让 AI 直接给你一个“最终结论”而是把它的回答拆分成可验证的断言一条条在调试器里确认。例如它说“这个函数的功能是加密字符串”你就应该找到它的调用点、参数来源和返回值使用位置。验证不通过就继续追问。第三把脱壳报告当成代码一样管理。记录样本哈希、环境版本、Prompt 文本、AI 输出摘要、人工修改点、Dump 前后对比。这样两周后回看时你还能复现当时结论。第四团队里要有一个负责“纠偏 AI ”的人。如果你们小组所有成员都依赖同一个 AI 模型来分析样本很容易出现“把 AI 幻觉当成共识”的集体偏差。正确做法是让一个人专职复核 AI 输出另一个人从调试器侧验证两人交叉确认后再继续。第五不要把脱壳成功当成安全分析完成。脱壳只是拿到了可读的二进制真正有安全价值的分析是脱壳之后的还原业务逻辑、定位漏洞点、理解攻击面。很多时候严重漏洞藏在壳下面的那几行逻辑里而不是壳本身。所以脱壳完成后请把报告重心放到“这个程序在做什么”而不是“我用什么工具脱的壳”。10. 总结与下一步方向这篇文章围绕“AI 能否干掉 VMP”这个问题做了一次完整的实验复盘和技术拆解。核心结论是AI 不能一键干掉 VMP但它能明显降低逆向脱壳的学习和排查成本。它会读汇编、会写脚本、会整理思路但找 OEP、确认 IAT、判断反调试分支这些关键节点仍然需要人来拍板。如果你打算沿着这个方向继续深入建议按下面这条路径走先用自己编译的程序套不同加壳工具把“找 OEP → Dump → 修复 IAT”这个基础流程跑通。再用公开 CTF 逆向题练习重点感受“在没有原始符号的情况下如何靠行为特征推断代码功能”。最后研究 VMProtect 的虚拟化原理从字节码格式、handler 分派表开始理解为什么完整还原如此困难。二进制安全是一片非常吃经验的领域AI 的到来并没有抹平经验的差距反而放大了“会用 AI”和“只会问 AI”的人之间的差距。能独立验证 AI 结论的人才是真正能独立做逆向的人。给自己一个目标下一次拿到带壳样本先让 AI 帮你把地图画好然后自己一步一步走过去。这样积累的经验才是 AI 替代不了的东西。