这节公开课02想聊的不是某个逆向工具怎么用而是AI逆向工程师必须想清楚的一件事AI的边界在哪里。这里说的边界有三层授权实验的边界、证据留存的边界、发布规范的边界。很多朋友一听说AI能辅助逆向就急着拿Ghidra、Frida、Wireshark去分析目标甚至想用AI自动猜接口、批量解析加密参数、逆向别人的App。先说结论AI可以帮你读代码、翻译伪代码、找相似实现、梳理调用关系但它不能替你判断这个实验是否被授权不能保证你的证据链有效更不能让你把未修复的漏洞细节直接公开。这篇文章适合正在做二进制安全、游戏安全、软件安全、网络安全方向学习的人也适合打CTF的选手。你不需要很强的机器学习背景只需要平时会做逆向分析并且打算把分析结果写成报告或写进博客。真正能拉开差距的不是谁用的模型更多而是谁在动手前就想清楚了“能不能做、怎么留痕、公开到什么程度”。下面按实际落地的顺序拆一遍。1. 先分清AI逆向工程师的能力边界1.1 AI在逆向里到底能做什么AI辅助逆向目前最实用的能力集中在几类把反汇编或反编译出来的伪代码翻译成更容易懂的语言。给函数、变量、常量做自动重命名和注释。梳理调用关系定位核心逻辑。识别已知算法、已知库函数、相似代码片段。辅助分析JS逆向、安卓逆向、封包中的数据结构和参数来源。生成分析脚本、解密脚本、解包脚本的骨架。这些能力是实打实的。特别是遇到一个几千行的反编译结果时AI能把主流程大致讲清楚帮人节省大量时间。比如在安卓逆向里AI可以辅助定位某个字符串的引用路径在JS逆向里AI可以根据加密参数出现的位置猜测可能是哪类算法在封包分析里AI可以把PCAP中的数据流按协议整理成初步摘要。这些都适合作为第一轮分析参考。1.2 AI不能替代判断和授权AI的边界在于它不能替你回答“这次测试是否被授权”不能帮你判断“这个漏洞能不能公开”也不能保证它给出的结论一定正确。模型输出的是“看起来合理的文本”不是经过验证的事实。常见做法是让AI解释一段可疑代码AI给出的解释可能很流畅但函数地址、变量名、调用关系都有可能是错的。尤其在反编译结果不完整、符号被混淆、编译器优化过的情况下AI会出现幻觉。它可能把A函数的作用描述得像B函数也可能凭空补出一个不存在的协议字段。所以AI结论只能作为假设必须回到实际环境中验证。判断标准很简单AI说出的每一个关键结论能不能在调试器、抓包结果、日志或实际运行里复现。能复现才算初步成立不能复现就标记为推测不要写进正式报告。1.3 动手前先回答三个问题在打开工具之前建议先过一遍边界清单分析目标是谁有没有授权目标是我自己的程序、企业内部授权系统、CTF平台还是来源不明的App样本数据从哪里来是否合规是自己抓的包、平台提供的题目还是第三方泄露的数据分析结果准备给谁看只写内部报告、提交漏洞平台还是发公开博客只要有一个问题不清晰就先停下来。边界判断应该优先于技术判断。AI可以加快分析速度但没办法把“没有授权”变成“有授权”。2. 授权实验动手之前先解决能不能测2.1 授权范围要落到具体字段授权实验不是一句“我有授权”就行而是要明确范围。最基础的授权信息至少包括目标资产域名、IP、App包名、系统版本、业务范围。授权期限开始时间和结束时间。允许的手段是否允许主动扫描、抓包、逆向、动态调试、压力测试。数据范围可以访问哪些数据哪些数据不能碰。联系人授权方和测试方各自的负责人。紧急停止条件发现越权、生产故障、异常波动时怎么中止。只有把这些问题写清楚“授权实验”才具备可操作性。否则后续所有分析过程都可能被质疑。2.2 新手优先做自建靶场和CTF对于正在学习二进制安全、CTF、封包技术的朋友我建议优先在可控环境中练手。CTF比赛平台、自建虚拟机、官方提供的靶场环境都是合法场景。想复现某个已知漏洞比如Log4j相关漏洞也应该在隔离的靶场里做而不是拿线上系统验证。自建环境的好处是可以在授权范围内自由分析可以随便抓包、打断点、改参数不会影响到别人。很多朋友问我为什么学了逆向还是不敢动手不是技术不行是没有一个可以放心乱来的环境。CTF、靶场、虚拟机和测试样本就是用来解决这个问题的。2.3 授权失效的常见情况我见过不少边界问题不是一开始就没授权而是授权范围在实际操作中悄悄被扩大。比如授权书写的是测试某个Web域名结果顺着接口去逆向了移动端App。授权范围是预发布环境测试人员顺手把生产环境的登录接口也测了。口头说“你都可以测”但没有书面授权出了问题无法证明。授权时间已经到期系统里还挂着抓包代理。这些情况都属于越界。更稳妥的方式是每测一个新目标先确认是否在授权范围内每次扩大测试面先补充授权记录整个实验过程中保留授权文档副本。2.4 授权文档建议字段可以把授权文档做成一个简单表格至少包含字段内容示例目标资产api.example.com、com.example.app授权期限2025-03-01 至 2025-03-31允许手段逆向分析、抓包、动态调试、本地验证禁止行为生产环境压测、数据导出、未授权横向移动授权方联系人王工 / 邮箱 / 电话测试方联系人李工 / 邮箱 / 电话紧急停止方式发送邮件并电话确认这个表格不复杂但能避免大量后续纠纷。尤其是做游戏安全、软件安全相关项目时授权范围决定了你能不能碰客户端、能不能分析服务端协议、能不能把样本带出公司。3. 证据留存分析过程要能复现和追溯3.1 为什么证据比结论更重要做逆向分析结论只是一句话证据才是让人信服的部分。无论写内部报告还是提交到漏洞平台核心都是“证据能不能支撑结论”。如果你说某个App的封包参数是依赖服务器时间生成的但没有抓包时间、没有请求响应截图、没有脚本运行记录别人很难复核。AI辅助分析后这一条更重要。因为AI输出有随机性同一个提示词在不同模型、不同版本下可能给出不同答案。如果不记录当时用了什么提示词、哪个模型版本、哪些关键输出结论就无法复现。3.2 至少留下这七类证据我在实际项目中通常留以下几类内容不一定全要但核心不能少样本文件哈希对原始APK、DEX、JS文件、PCAP文件计算SHA256保证文件没有被改动过。文件来源记录样本从哪里下载、谁提供、什么时候获得。工具版本表IDA、Ghidra、Frida、Wireshark、Burp Suite、Python版本尽量写清楚。关键命令记录包括解包命令、抓包命令、动态调试命令。日志和会话记录终端输出、运行日志、抓包记录。截图和录屏关键调用链、入参出参、断点位置。AI交互记录提示词、模型名称、版本、时间和生成的主要结论。这些证据不需要全部展示在公开文章里但在分析过程中要留存方便复盘和补充报告。3.3 留存的顺序和方法建议用一个独立工作目录按任务和时间创建子目录。比如task_20250310_appx/ ├── 01_samples/ # 原始样本和哈希 ├── 02_tools/ # 工具版本说明 ├── 03_logs/ # 终端日志和抓包文件 ├── 04_ai/ # AI提示词和输出记录 ├── 05_screenshots/ # 截图和录屏 ├── 06_report/ # 最终报告 └── README.md # 任务信息每次执行关键操作前先记录当前时间和环境状态。抓包时开一个总会话并把PCAP按任务编号命名。执行动态调试时保存断点、寄存器、调用栈截图。不要等到分析结束再去补记录补出来的记录基本不可信。3.4 AI辅助分析时怎么留痕使用AI辅助时建议单独建一个文件记录每个问题。格式可以参考## 问题这个函数是否负责AES解密 - 模型某平台某模型V3 - 时间2025-03-10 10:23 - 输入代码片段关键函数反编译内容 - AI回答是疑似AES-CBC模式 - 人工验证已用调试器确认密钥长度和分组大小 - 结论成立关键点在于“人工验证”这一列。AI给出的判断必须标清楚“是否已验证”。如果只是AI推测就写“未验证”不要放进最终结论。证据链完整的意思是别人拿着你的记录能理解你当时为什么相信这个结论以及你怎么验证的。4. 发布规范报告和公开内容哪些能写4.1 内部报告与公开博客要分开“分析出来了”和“能写进博客”是两件事。内部报告可以写完整技术细节包括复现步骤、受影响范围、关键代码片段公开博客则要收敛很多不能公开未修复漏洞的完整利用方法不能直接分享从真实目标抓到的敏感样本不能提供完整可运行的攻击载荷。很多平台规则也要求先负责任披露再讨论技术细节。也就是说如果漏洞还没有修复公开分析很容易造成风险。哪怕修复了也要在公开时做脱敏处理。4.2 CTF的writeup怎么写CTF比赛中的writeup相对自由但也不是什么都能写。要遵守赛事规则不能直接把flag明文放出来也不要把别人的解题脚本完整抄一遍。更稳妥的写法是说明题目类型和考察点。讲思路从哪里入手怎么找到关键函数。给关键步骤如何定位加密入口、如何还原逻辑、如何构造输入。给部分代码或伪代码但省略可直接复制利用的完整脚本。如果你用了AI工具解题也要看比赛规则。有些比赛允许AI辅助有些明确禁止。就算允许也建议在writeup里说明哪一步用了AI、AI提供了什么帮助、自己做了哪些验证。4.3 公开内容的脱敏处理写公开文章时下面这些信息必须处理真实域名、IP、端口替换为example.com或xxx.xxx.x.x。真实账号、令牌、密钥、手机号、邮箱全部打码。敏感样本的完整二进制不要直接放链接只保留哈希和文件类型。能直接用于绕过检测、窃取数据、控制系统的完整代码片段尽量拆散或省略关键参数。涉及真实业务的数据哪怕不敏感也要谨慎。判断标准只有一个一个陌生读者看完这篇公开文章能不能直接拿它去打一个未授权的真实目标。如果答案是“能”说明公开得太多了。4.4 发布前检查清单我每次发安全类文章前会过一遍分析目标是否授权是否属于我可公开讨论的范围。是否包含未修复漏洞的完整利用路径。是否包含可识别的个人、公司、平台信息。是否包含可直接运行的完整Payload。是否违反CTF赛事规则、平台规则或合作协议。是否刻意夸大了影响比如把理论风险写成实际攻击成功。只要有一项不通过就先不发或者把内容砍到安全范围。发布规范不是限制分享而是保护读者、也保护自己。5. 实战流程从授权实验到证据留存的完整链路5.1 环境准备能复现的环境才是好环境拿到一个分析任务后我会先在隔离环境里搭建分析环境。如果是逆向了APK准备一台模拟器或测试机如果是分析JS和抓包准备独立浏览器配置和抓包代理如果是二进制逆向用虚拟机跑分析和调试工具。隔离环境的好处是分析过程中的崩溃、异常行为、恶意样本不会影响主系统。环境搭建完成后做一个快照。这样后续每一步都能回滚。同时记录环境信息操作系统、Python版本、Java版本、目标APK版本、工具版本。这些信息会被写进证据目录。5.2 任务信息记录分析开始前先写一个说明文件记录任务编号。目标名称和版本。授权依据。开始时间。分析人。预期目标比如“分析登录接口的加密参数生成逻辑”。这一步看起来多余但对后续写报告非常有用。很多分析做到一半发现走偏靠任务说明可以把思路拉回来。5.3 静态分析、动态分析、AI辅助怎么配合我常用的顺序是先静态分析计算哈希查看文件类型读取字符串用Ghidra或IDA打开看整体结构。让AI先读一遍核心函数生成一个初步说明。这个说明只当参考。根据AI的初步结论定位关键入口比如登录函数、加密函数、协议组装函数。再用动态分析验证运行程序、抓包、下断点、查看内存和寄存器。把静态结论和动态行为做对比不一致的地方重点排查。举个例子在分析一个封包协议时AI可能说某个字段是时间戳。你不能直接信要抓取多个请求看这个字段是否随时间变化、是否符合时间戳格式。如果三组请求都能对上再写“推测为时间戳”并在报告中标注验证方法。5.4 验证和复现关键结论至少要能复现一次。复现不是简单重跑同一个脚本而是换一种方式验证。比如动态调试器里看到的数值是否和抓包一致。修改时间后协议字段是否跟着变化。换一台设备或另一个账号结论是否仍然成立。AI生成的解密脚本是否真的能解出预期格式。如果复现失败不要因为“AI是这么说的”就保留结论。要判断是输入数据问题、工具问题还是分析思路本身错了。无法复现的内容一律标记为“未确认”不能写进最终结论。5.5 报告结构建议最终报告可以按这个结构组织任务背景和目标。授权范围和限制。环境与工具版本。分析过程和证据。关键结论。复现步骤。风险等级和建议。附录证据文件链接、AI交互记录、脚本哈希。复现步骤要写得足够详细但如果是内部报告要控制分发范围。公开版本则需要脱敏并按前面说的发布规范处理。5.6 任务完成后的清理分析完成后不要立刻删除所有临时文件。先把证据归档再处理工作目录。原始样本建议保留一段时间方便后续复核。临时脚本如果只对当前任务有效可以只保留哈希和关键片段不保留完整可运行版本。涉及敏感数据的文件按保密要求单独加密保存。清理的目的不是销毁证据而是避免无关人员在工作目录里看到完整分析材料。6. 常见问题与边界判断6.1 在CTF里用AI算不算违规取决于比赛规则。有的CTF允许使用AI辅助有的明确禁止还有的只允许在特定题目中使用。进场前先读规则。如果规则没有写最稳妥的做法是先问主办方或者默认不使用AI生成直接答案。就算比赛允许AI也建议记录AI使用过程。因为在复现writeup时裁判可能要求你解释“这一步是怎么想到的”。有记录代表你对自己的分析过程是清楚的没有记录很难说清是AI的功劳还是你验证的结果。6.2 抓包和分析别人的App算不算问题关键在授权。自己开发的App、企业授权的测试项目、CTF平台提供的样本这些场景可以正常分析。未授权抓包、逆向别人的商业软件、绕开客户端限制则可能涉及违规。尤其是拿到一个来源不明的APK不建议直接解包分析并公开因为你无法确认样本是否被篡改也无法确认是否有授权。更稳妥的方法是先确认来源。如果是公司项目看合同或授权书是否覆盖如果是学习目的优先选用公开样机或靶场。不要因为“很多人都在做”就觉得没问题。6.3 公开writeup的边界到底在哪里公开writeup可以写思路不建议写完整的直接可用Payload。可以把关键函数作用讲清楚但对核心绕过点做模糊化处理。比如分析一个加密算法可以说明算法类型、密钥如何定位、校验失败的判断方式但不要把完整可运行的解密脚本放出来尤其当这个脚本可能影响真实系统时。如果writeup涉及比赛题目还要确认赛事对成绩公示的要求。有的比赛要求先提交名单再开放解析。过早公开可能违反赛事流程。6.4 日志和截图丢了怎么办不要补造。补造的证据比没有证据更麻烦。正确的做法是重新复现一次分析过程并记录“第一次未留存本次为重新复现”。如果原样本还在就用同一份样本重新生成日志如果原样本不在了就明确说明“无法复原原始环境结论保留为推测”。证据留存的核心是可追溯而不是漂亮。哪怕记录里写了“这里当时没来得及截图”也比伪造截图可信得多。6.5 边界出错时最需要做什么一旦发现自己可能越过了授权边界第一时间停止操作不要继续验证也不要删除日志。先记录当前状态联系授权方或项目负责人说明情况再决定下一步。这时候最忌讳的是觉得“都做到这一步了继续吧”。边界问题上停下永远比继续安全。AI可以帮你把逆向分析做得更快但“授权实验、证据留存、发布规范”这三个流程必须是人的判断。想成为一名合格的AI逆向工程师第一课不是学习更复杂的脱壳技巧而是学会在动手前看清边界在过程中留下证据在发布前控制影响。把这三件事做扎实后面的技术细节才有意义。