
不少刚接触逆向的读者会先被“分析一个样本”这件事的路径吓到拿到一个 Windows 可执行文件先查壳再拖进 IDA、Ghidra看导入表、找字符串、跟交叉引用在调试器里跑几个来回可能一天下来只定位到一两个关键函数。再碰到 Unity 游戏还得先分辨是 Mono 还是 IL2CPP再决定用 dnSpy 还是 Il2CppDumper。整个过程不是不能做而是非常消耗体力。AI 进来之后很多人以为它能“一键破解”“自动绕过校验”这其实是误解。真正适合 AI 干的是把逆向里那几个最费时间的环节接过去整理文件信息、解释反编译代码、标记可疑 API、生成阶段性报告。换句话说AI 不能替你按 F9但它能让你少看很多无关代码。这篇文章会讨论怎么把大模型接入以 PE 文件、Unity 游戏、UEUnreal Engine二进制为对象的逆向工作流并给出一套可复用的“先本地结构化提取再交给 AI 总结”的工程思路。文中包含三个能直接落地的方向PE 文件一键 AI 分析脚本、Unity 反编译后的代码总结、Ghidra 插件对接大模型自动生成函数注释。所有示例都围绕安全研究、CTF、恶意样本分析和已授权测试展开不涉及绕过授权或攻击性操作。1. 这篇文章真正要解决的问题传统逆向的门槛高是因为要把大量“阅读理解”工作压在人的身上。面对一个加了壳的 PE 文件你要先识别壳的类型找到入口点判断哪些代码是外壳解压逻辑哪些是程序真实逻辑面对一个 Unity 游戏你要从几千个类里找到真正处理协议、校验、加解密的那几个面对 UE 二进制你还要对抗 C 编译器生成的符号信息和函数内联。这些工作里真正需要“人脑判断”的部分其实不多反倒是“浏览—筛选—总结—记录”占了绝大多数时间。AI 接入的价值正好落在这部分。它擅长两件事第一把格式化的元数据整理成一段有条理的结论第二把伪代码或反编译源码翻译成人类能快速理解的功能描述。只要我们在调用模型之前先把二进制转换成结构化的中间表示AI 就能稳定地发挥“高级助理”作用而不是空泛地生成没有依据的猜测。我的判断是AI 辅助逆向工作流解决的不是“能不能分析”的问题而是“单位时间内能分析多少函数、能多快形成可验证假设”的问题。对新手来说它压缩了大量挫败感对老手来说它把重复劳动交给脚本和模型自己专注在真正需要经验判断的决策上。读这篇文章你能得到一个完整的工作流框架三个能直接跑的示例代码以及一套避开常见坑的经验清单。你不用先把逆向学完再去试 AI反而可以借 AI 的总结更快理解一个陌生样本。2. PE、Unity、UE 逆向的核心概念与适用场景2.1 Windows PE 逆向在分析什么PE 是 Portable Executable 的缩写指 Windows 平台上可执行文件的格式包括 exe、dll、sys 等。逆向一个 PE 文件本质上是在回答几个问题这个程序是做什么的它依赖哪些系统 API它有没有加壳或混淆关键的逻辑函数在哪里PE 文件内部有明确的结构DOS 头、NT 头、节区表和多个数据目录。实际分析中导入表尤其重要因为它会暴露程序调用了哪些系统函数。比如一个普通工具突然导入了VirtualAlloc、WriteProcessMemory、CreateRemoteThread就非常可疑。AI 很适合做这类“特征归纳”给它一批导入函数和节区权限它能帮你判断潜在意图并建议下一步往哪个方向跟。2.2 Unity 逆向的两种形态Unity 游戏逆向要区分两种打包方式。第一种是 Mono 模式。游戏业务逻辑以 IL 中间语言形式存在核心文件是Managed/Assembly-CSharp.dll。用 dnSpy 或 ILSpy 可以直接反编译回接近源码的 C#分析难度相对低。这种情况下AI 的价值在于快速浏览大量方法你从上千个类里抽出疑似处理登录、支付、签名、校验的类和方法让模型逐段说明用途。第二种是 IL2CPP 模式。Unity 会把 C# 代码转换成 C 再编译成原生二进制因此看不到原始的 Assembly-CSharp.dll关键信息被移到global-metadata.dat里。实际工作流通常先用 Il2CppDumper 一类工具恢复符号和类结构再在 IDA 或 Ghidra 里配合分析。AI 的角色从“直接读 C# 代码”变成“解释还原后的 C 伪代码、辅助分析字符串和函数调用链”。2.3 UEUnreal Engine逆向的差异UEUnreal Engine游戏以 C 为主业务逻辑很多编译在原生二进制里同时又有大量资源和蓝图逻辑打包在 .pak、.ucas 等资产文件中。逆向 UE 二进制时重点是 UObject 系统、GObjects 全局对象表、UFunction 以及各类反射信息。资源层面常用 FModel 等工具查看资产内容逻辑层面则要在 IDA/Ghidra 中分析对应函数。UE 逆向对 AI 的依赖点很实际C 伪代码比 C# 更难读函数数量更多靠人逐个看成本极高。让 AI 先解释一段伪代码的用途再根据函数名、字符串引用判断该不该继续往下跟是一条比较高效的路。下面第七章的 Ghidra 插件思路就适用于这个场景。分析对象关键技术文件逆向重心常见工具Windows PEEXE / DLL / SYS导入表、加壳、关键 API 调用DIE、IDA、x64dbg、pefileUnity MonoAssembly-CSharp.dllC# 业务逻辑、协议、加解密dnSpy、ILSpyUnity IL2CPPglobal-metadata.dat符号还原、字符串、函数链Il2CppDumper、IDA、GhidraUnreal Engine.pak / .ucas、主程序二进制UObject、蓝图节点、C 函数FModel、IDA、Ghidra3. 把 AI 放进逆向工作流的整体思路3.1 传统流程的三个成本传统逆向流程有三个不容易被量化、却又真实存在的成本。一是信息碎片化样本信息分散在导入表、字符串、反汇编窗口、调试器寄存器里人需要在多个工具之间来回切换二是上下文切换刚看完一个函数又得跳去查另一个交叉引用大脑的临时记忆很容易被撑满三是经验依赖老手能根据经验快速跳过无关代码新手则会在一个无关函数上浪费很长时间。这三个成本有一个共同点它们都是“认知负担”而不是“判断难度”。AI 的文本理解能力正好适合处理这种负担。前提是我们要把分散的信息整理成结构化格式交给模型而不是让模型自己去分析二进制。3.2 新的三层工作流我推荐把 AI 辅助逆向拆成三层。第一层是信息收集层用脚本或工具完成文件格式解析、字符串提取、节区权限扫描、反编译等确定性操作。这一层不需要 AI结果必须是稳定、可复现的。第二层是 AI 分析层把第一层的输出整理成 JSON 或 Markdown配合合适的提示词发送给模型让它总结可疑点、解释代码语义、生成报告。第三层是人工决策层工程师审查 AI 输出确认哪些结论可以采纳哪些需要进一步动态调试。这个三层结构的核心原则是永远不要让模型直接读取原始二进制也不要让模型替你做最终判断。AI 给出的是“分析建议”不是“实验结论”。顺着这个原则我们可以把逆向工作流做成一个半自动化的 CLI一键完成“提取—分析—报告”。4. 环境准备与前置条件4.1 Python 环境与依赖下面的示例主要用 Python 3建议提前建好虚拟环境避免污染系统 Python。需要安装的库不多pefile用来解析 PE 文件requests用来调用大模型接口。如果你的模型服务使用 OpenAI 兼容的 Chat Completions 协议代码会很简单。python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate pip install pefile requests不建议把 API Key 写死在代码里。把它放进环境变量脚本启动时自动读取这样既能保护密钥也方便切换不同的模型服务。export LLM_API_URLhttps://your-llm-endpoint/v1/chat/completions export LLM_API_KEYyour-api-key export LLM_MODELyour-model-name如果你分析的样本比较敏感尤其是真实恶意软件建议优先使用本地或私有化部署的模型。外部模型服务会记录你上传的内容直接上传原始样本或完整反编译代码存在泄露风险。稳妥的做法是先在本地提取摘要或脱敏后的关键信息再决定要不要提交给外部模型。4.2 反编译与调试工具PE 分析用pefile就能完成文件结构层面的解析真正深入时还需要 IDA、Ghidra、x64dbg 这类工具。Unity Mono 分析推荐 ILSpy它提供ilspycmd命令行工具方便脚本批量反编译。IL2CPP 场景需要 Il2CppDumper 一类符号还原工具。UE 二进制分析通常直接使用 Ghidra 或 IDAGhidra 好处是能写 Python 脚本容易和 AI 接口做集成。这些工具的版本更新频繁本文不绑定具体版本号。你只要保证能用命令行或脚本调用就行核心思路是通用的。4.3 大模型 API 准备示例代码统一采用兼容 OpenAI Chat Completions 协议的接口这是目前大多数模型服务的通用标准。只需要准备三个信息服务地址、API Key、模型名称。如果模型上下文长度有限可以先把分析对象拆小再分段提交。5. 完整示例一PE 文件一键 AI 分析脚本5.1 脚本设计思路这个脚本想解决一个具体场景你收到一个疑似恶意的 exe想先快速了解它是什么、有没有危险 API、该往哪个方向深入。传统做法是打开 PEiD 或 DIE 看壳再手动翻导入表很慢。脚本的做法是先用pefile解析 PE 结构提取机器类型、节区权限、导入表、文件哈希把结果转成 JSON再把 JSON 交给模型生成分析报告。这样做有两个好处。第一输入给模型的是精简后的结构化信息不会因为二进制过大导致上下文超限第二每一步处理都有本地记录模型给出的结论可以被追溯和复核。5.2 完整代码#!/usr/bin/env python3 # 文件路径scripts/pe_ai_analyzer.py import os import sys import json import hashlib import pefile import requests def sha256_of_file(path): h hashlib.sha256() with open(path, rb) as f: for chunk in iter(lambda: f.read(4096), b): h.update(chunk) return h.hexdigest() def extract_pe_info(path): pe pefile.PE(path, fast_loadFalse) info {} info[machine] hex(pe.FILE_HEADER.Machine) info[timestamp] pe.FILE_HEADER.TimeDateStamp info[sections] [] for sec in pe.sections: name sec.Name.rstrip(b\x00).decode(errorsreplace) chars sec.Characteristics info[sections].append({ name: name, virtual_size: hex(sec.Misc_VirtualSize), raw_size: hex(sec.SizeOfRawData), executable: bool(chars 0x20000000), writable: bool(chars 0x80000000), }) info[imports] {} if hasattr(pe, DIRECTORY_ENTRY_IMPORT): for entry in pe.DIRECTORY_ENTRY_IMPORT: dll entry.dll.decode(errorsreplace) funcs [] for imp in entry.imports: if imp.name: funcs.append(imp.name.decode(errorsreplace)) info[imports][dll] funcs[:50] pe.close() return info def call_llm(system_prompt, user_content): url os.environ.get(LLM_API_URL) key os.environ.get(LLM_API_KEY) model os.environ.get(LLM_MODEL) headers { Authorization: fBearer {key}, Content-Type: application/json, } payload { model: model, messages: [ {role: system, content: system_prompt}, {role: user, content: user_content}, ], temperature: 0.2, } resp requests.post(url, jsonpayload, headersheaders, timeout180) resp.raise_for_status() return resp.json()[choices][0][message][content] def main(): if len(sys.argv) ! 2: print(fUsage: {sys.argv[0]} sample.exe) sys.exit(1) path sys.argv[1] info extract_pe_info(path) file_hash sha256_of_file(path) user_content json.dumps({ file_hash: file_hash, file_size: os.path.getsize(path), pe_info: info, }, ensure_asciiFalse, indent2) system_prompt ( 你是一名经验丰富的安全分析工程师。请根据用户提供的 PE 文件元数据 分析该文件可能的类型、可疑点、重要导入函数的用途并给出下一步分析建议。 请使用 Markdown 小标题输出不要过度猜测对不确定的内容明确标注不确定。 ) report call_llm(system_prompt, user_content) print( AI 分析报告 ) print(report) if __name__ __main__: main()5.3 运行与验证python scripts/pe_ai_analyzer.py samples/demo.exe如果脚本正常输出一份包含文件哈希、节区分析、导入表分析、可疑点判断和下一步建议的 Markdown 报告说明整条链路已经跑通。常见失败点是模型服务地址或 API Key 配置错误此时先检查环境变量是否能被脚本读到。另一个可能出现的问题是该文件根本不是合法 PEpefile会抛出异常这种情况先用 DIE 或file命令确认文件类型。6. 完整示例二Unity 反编译 AI 逻辑总结6.1 Unity Mono 场景拿到一个 Unity Mono 打包的游戏目录核心文件是Managed/Assembly-CSharp.dll。先用 ILSpy 的命令行工具反编译到本地源码目录。ilspycmd -p -o output_src Assembly-CSharp.dll参数-p表示按项目结构输出-o指定输出目录。反编译完成后你会得到大量.cs文件。此时不急着让 AI 分析全部代码而是先按关键词过滤login、sign、pay、token、encrypt、decrypt、verify、check。这些类和方法往往是分析协议和加密逻辑的入口。下面这个脚本会扫描指定源码目录下所有.cs文件把包含这些关键词的代码片段提取出来交给 AI 生成说明。#!/usr/bin/env python3 # 文件路径scripts/unity_ai_analyzer.py import os import sys import requests def list_cs_files(root): for dirpath, _, filenames in os.walk(root): for fn in filenames: if fn.endswith(.cs): yield os.path.join(dirpath, fn) def extract_suspicious_methods(cs_file_path, keywords, context_lines15): with open(cs_file_path, encodingutf-8, errorsignore) as f: lines f.readlines() results [] for idx, line in enumerate(lines): if any(k.lower() in line.lower() for k in keywords): start max(0, idx - context_lines) end min(len(lines), idx context_lines) snippet .join(lines[start:end]) results.append((idx 1, snippet)) return results def call_llm(system_prompt, user_content): url os.environ.get(LLM_API_URL) key os.environ.get(LLM_API_KEY) model os.environ.get(LLM_MODEL) headers { Authorization: fBearer {key}, Content-Type: application/json, } payload { model: model, messages: [ {role: system, content: system_prompt}, {role: user, content: user_content}, ], temperature: 0.2, } resp requests.post(url, jsonpayload, headersheaders, timeout180) resp.raise_for_status() return resp.json()[choices][0][message][content] def main(): if len(sys.argv) ! 2: print(fUsage: {sys.argv[0]} cs_source_dir) sys.exit(1) root sys.argv[1] keywords [login, sign, token, pay, encrypt, decrypt, verify, check] snippets [] for cs_file in list_cs_files(root): matches extract_suspicious_methods(cs_file, keywords) for line_no, snippet in matches: snippets.append(f### {os.path.relpath(cs_file, root)}:{line_no}\n{snippet}) if not snippets: print(未找到包含相关关键词的代码片段) sys.exit(0) user_content \n\n.join(snippets[:50]) system_prompt ( 你是一名 Unity 游戏安全分析工程师。以下是从反编译源码中提取的代码片段 它们可能涉及登录、签名、支付、加解密或校验逻辑。请逐段解释其用途 标注可疑点并说明是否需要进一步分析。 ) analysis call_llm(system_prompt, user_content) print( Unity 代码分析 ) print(analysis) if __name__ __main__: main()运行命令python scripts/unity_ai_analyzer.py output_src这个脚本会把匹配到的代码按文件路径和行号列出来模型分析时可以直接引用位置信息方便你回头去源码里核对。这里真正容易踩坑的地方是Unity 的类名和方法名可能已经被混淆过关键词过滤会漏掉很多关键逻辑。遇到混淆严重的样本可以先用工具记录原始名称和混淆名称的映射关系再让 AI 结合调用关系分析而不是单纯依赖命名。6.2 IL2CPP 场景如果游戏是 IL2CPP 打包脚本化反编译 C# 这条路走不通。常规做法是用 Il2CppDumper 还原global-metadata.dat里的类结构和方法地址得到dump.cs、script.json等中间文件。之后把这些结构化信息交给 AI让模型辅助分析字符串、方法名和函数签名之间的关联。这一阶段比 Mono 场景依赖更多工具知识建议先用 PE 脚本和 Mono 脚本把整体工作流跑通再进入 IL2CPP 的专项练习。7. 完整示例三UE 二进制分析与 Ghidra 插件对接大模型7.1 Ghidra 脚本对接大模型UE 二进制分析经常要面对大量 C 伪代码。手动逐段阅读效率很低让 AI 先给函数“翻译”一遍再决定是否深入是更实际的方案。Ghidra 提供了基于 Jython 的脚本接口可以直接在当前反编译窗口里获取函数伪代码然后调用大模型生成中文注释。下面这个脚本会在 Ghidra 的 Script Manager 中运行获取当前地址所在函数的伪代码调用模型生成注释并把结果打印出来。注意Ghidra 的 Jython 环境不一定包含requests你需要把模块加入 Ghidra 的类路径或者把网络调用替换成基于java.net.HttpURLConnection的实现。这里以requests为例便于阅读。# category Analysis # 文件路径ghidra_scripts/llm_function_comment.py import os import requests from ghidra.app.decompiler import DecompInterface def get_current_function(): return getFunctionContaining(currentAddress) def decompile_function(function): if function is None: return ifc DecompInterface() ifc.openProgram(currentProgram) results ifc.decompileFunction(function, 30, monitor) if results.decompileCompleted(): return results.getDecompiledFunction().getC() return def call_llm(user_content): url os.environ.get(LLM_API_URL) key os.environ.get(LLM_API_KEY) model os.environ.get(LLM_MODEL) headers { Authorization: fBearer {key}, Content-Type: application/json, } payload { model: model, messages: [ { role: system, content: 你是 Ghidra 逆向插件。请用中文解释以下伪代码的用途 并指出潜在风险点例如缓冲区溢出、认证绕过、硬编码密钥等。 如果信息不足请直接说明。, }, {role: user, content: user_content}, ], temperature: 0.2, } resp requests.post(url, jsonpayload, headersheaders, timeout120) resp.raise_for_status() return resp.json()[choices][0][message][content] function get_current_function() code decompile_function(function) if code.strip(): comment call_llm(code) print(\n AI 注释 ) print(comment) if function: function.setComment(comment) else: print(当前地址没有可反编译的函数)这段脚本的价值不在于复杂而在于把“看伪代码”这个高频动作半自动化。你可以把鼠标停在任意一个可疑函数上运行脚本立刻得到一份初步解读。对于 UE 二进制这个方法尤其适合先筛选大量普通函数只把真正关键的函数留给人来深入分析。7.2 对 UE 二进制的适配说明UE 引擎里的函数名经常带项目前缀例如UMyActor::DoSomething。Ghidra 如果没有还原符号函数名可能只是FUN_140123456。这种情况下AI 单看伪代码容易瞎猜。建议先结合字符串引用、FName 信息、以及 FModel 导出的资产结构把上下文一起喂给模型。输入越具体AI 结论越接近真实逻辑。这个原则对所有三类目标都成立。8. 常见问题与排查方法AI 接入逆向工作流不是零门槛常见问题主要集中在联网调用、输入长度、模型幻觉和工具链兼容性上。问题现象可能原因排查方式解决方案AI 请求超时服务响应慢或 prompt 过长检查模型服务状态缩短输入内容分块提交增加 timeout 时间API 返回 401/403API Key 无效或地址错误用 curl 单独测试接口重新配置环境变量模型结论明显错误输入信息不足或模型幻觉对照本地 PE/反编译结果检查输入补充导入表、字符串、调用关系要求模型标注置信度pefile 解析失败文件不是合法 PE 或已损坏用 DIE 或 file 检查文件类型确认样本类型后再跑脚本Unity 反编译后无有效源码游戏实际是 IL2CPP检查是否包含 Assembly-CSharp.dll切换到 Il2CppDumper 流程上下文长度超限函数过大或片段过多查看模型上下文窗口限制截取关键片段先做摘要再聚合API Key 泄露代码里硬编码密钥检查 git 历史和环境变量配置立即轮换密钥改用环境变量还有一个经常被忽略的问题模型可能“一本正经地胡说八道”。比如在分析伪代码时模型会根据函数名猜一个看似合理的用途但实际逻辑完全不同。解决办法是要求模型明确区分“从代码能确定的”和“推测的”并且把原始代码片段连同 AI 结论保存下来便于复核。9. 最佳实践与工程建议第一输入必须结构化。无论分析 PE、Unity 还是 UE都先用本地工具把二进制转换成 JSON、Markdown、CSV 这类中间格式再交给模型。不要试图让模型“直接看二进制”也不要一次性塞入几十万行反编译代码。第二输出必须可追溯。每次调用模型时把输入摘要、prompt、模型输出、原始文件哈希一起保存。当 AI 结论被证明有误时你能快速定位是哪一步出了问题也能用历史数据优化提示词。第三把“风险操作”留给人。AI 可以提示“这段代码可能绕过认证”但不能替用户确认绕过是否可行。涉及实际漏洞利用、破解、绕过校验的验证必须由具备权限的分析人员在受控环境中人工完成并遵守相关法律法规。第四敏感样本优先走本地模型。分析真实恶意软件时反编译代码本身就是敏感数据。如果条件允许优先使用本地部署的开源模型必须使用外部 API 时先对输入做最小化处理剔除文件名、路径、个人信息等无关内容。第五控制成本。大模型按 token 计费每次都把整段伪代码发过去不划算。可以先让模型做“一句话函数摘要”再对可能有价值的高危函数做二次详细分析。两阶段分析能明显压缩成本同时保留可读性。第六把工作流固化成一个 CLI 或 Makefile。当你有 20 个样本要分析时手工逐个调用脚本会非常痛苦。把 PE 解析、Unity 反编译、AI 请求这些步骤封装成统一命令只传一个样本路径重复分析就能一键完成。10. 总结与后续学习方向这篇文章的核心判断是AI 接入逆向工作流不能替代人的判断但能大幅减少“读代码、写总结、找可疑点”的重复劳动。真正高效的做法不是把二进制直接丢给模型而是先本地结构化提取再把中间结果交给模型分析最后由人来做关键决策。建议你的下一步实践很具体找一个有授权的测试样本先跑通 PE 一键分析脚本看 AI 报告能不能帮助你快速形成初步判断再找一个 Unity 演示项目反编译后让 AI 总结某个方法的作用最后在 Ghidra 中对一个 C 函数运行注释脚本。三个场景都跑一遍你就会理解哪些环节适合 AI哪些环节还离不开人的经验。后续可以深入的方向包括把多个工具链串成 AI Agent自动完成查壳、解析、反编译、分析、报告全流程用 RAG 方式建设样本分析知识库让模型能引用历史分析结论针对常见的加密算法、反调试技巧做模型提示词优化甚至用微调方式让模型更适应特定引擎的反编译代码风格。还有一个重要提醒分析任何样本前先确认自己有合法授权。技术能力越强边界意识越要清晰。把一个样本真正跑通比收藏十篇教程更有价值。