AI开始拆软件了,逆向工程到底在改变什么?

最近看到一个GitHub 项目，名字挺直接。

叫REA，Reverse Engineer Anything。逆向任何东西。

它的介绍也很容易让人产生联想。看到一个应用里的功能，可以让编程助手去调查它怎么实现，拿出证据，再为自己的项目做一个实现。[1]

你想想看，以前我们看一个做得很好的产品，通常只能停在界面上。

这个交互挺顺。这个搜索怎么这么快。为什么它复制一块内容，粘贴回来还能保留原来的结构？

现在，这些问题有机会继续往里问。

不只问它长什么样，而是追到它的安装包、函数、进程通信，甚至机器指令。

听起来是不是有点像，软件行业突然多了一台透视机？

但读完项目文档和几位长期做逆向的作者分享，我觉得，这件事真正有意思的地方，并不是「以后所有软件都可以随便抄了」。

恰好相反。

越往下看，越能发现，拆开、看懂、复现、合法使用，完全是四件不同的事。

先交代一下，这篇是基于公开文档与实践文章的研究，不是我的REA 实测。文中涉及的实验和结果，会明确归到原作者或项目方名下。

我也不打算把它讲成一篇破解教程。更想聊清楚的是，这门原本有点神秘的技术，到底解决什么问题，又会把什么问题带到我们面前。

我们从一个很小的东西说起。

一块砖。

1996 年的打砖块游戏 DX-Ball，砖块在屏幕左边被击中，声音应该偏左。右边被击中，声音应该偏右。

这件小事背后，藏着一个把横坐标转换成左右声像的计算函数。

REA 官方展示的一个案例，就是协助编程助手从游戏可执行文件里，把这段计算追出来。[2]

有意思的是，最初看到的反编译伪代码并不完整。它看起来没有参数，关键的浮点计算也没被正常表达出来。

如果这个时候直接问模型「帮我解释一下」，很容易得到一段语气坚定、内容却不对的答案。

案例里的做法，是继续追证据。

看机器指令，发现函数确实从栈上读取了一个整数。往上找调用它的地方，发现传进来的是砖块的屏幕位置。再读取相关内存地址里的字节，确认计算用到的常数。

这才拼出计算过程。

而且，拼出来还不算完。

重建项目用原始x86 函数与重写的 C 函数，做了 3,205 组行为对照。又在固定的旧编译器工具链下，经过重定位处理和常数检查，匹配了这个函数完整的 63 个编译字节。

注意，是这个函数。

不是整款游戏已经被一键还原，也不是AI 对所有程序都达到了这种水平。这是项目方展示的、边界很清楚的一次局部验证。

但这个小案例，已经把逆向工程最重要的东西讲出来了。

不是猜一个像样的答案。

是让答案，经得起原物的对照。

我们平时做软件，是从需求出发，设计结构，写代码，再生成一个用户能运行的程序。

逆向工程，是拿到已经存在的东西，从它的结构、行为和留下的线索里，倒着推它如何工作。

拿到的可以是一个程序，也可以是一个文件、一段通信记录、一块电路板，甚至芯片里的电路。

目标不一定是还原原作者写过的每一行代码。

更多时候，是回答一个具体问题。

这份文件怎么读？这个设备说的是什么协议？这个按钮到底改了哪里？这个版本为什么比上一个版本多发了一次请求？

这里特别容易有个误会。

反编译，不是按下撤销键，把编译过程原路退回去。

变量名、注释、部分类型信息和原来的组织方式，可能早就没有了。编译器还会做优化，把人类写出来的结构改成另一种形态。

同一种机器行为，也可能对应许多种不同的源代码写法。

所以，反编译器给出的通常是一种接近源码的表达，不是原作者源代码的原件。

而逆向工程比反编译大得多。你可能不需要反编译，只要比较两个文件、观察一段输入输出，就能解决问题。

反过来，就算拿到了满屏伪代码，也不代表你已经理解了系统。

看见，不等于看懂。

说到这里，再回头看REA，就容易理解了。

它并不是一个新模型，也不是用几段提示词替代了所有专业工具。

它更像一个连接层，通过MCP 这种让编程助手调用外部工具的协议，把助手接到真正的分析工具和调查流程上。

面对原生二进制程序，可以借助Hopper、Ghidra 或 IDA 等工具，取得汇编、伪代码、字符串、调用关系。

面对JavaScript 和 Electron 应用，可以梳理模块、依赖、页面与主进程之间的通信。网站、.NET 程序、Android 安装包和固件，也有各自的分析路线，但能力深度、操作系统和外部工具要求并不相同。[1]

不是支持一个类别，就代表能完整恢复这个类别里的任何东西。

REA 提供观察和证据，编程助手负责继续提问、组织解释，必要时再编写和测试实现。

它的工作流说明里，有一条我觉得很重要。每个结论都要区分观察、推断和未知，不能把静态分析说成亲眼观察到了运行。[3]

这句话比「逆向任何东西」克制多了。

也专业多了。

甚至，只有完整源码仓库的普通代码分析，REA 自己都建议用常规代码工具，不要为了逆向而逆向。

还有一个容易被忽略的门槛。安装它的Skill，只是给助手一份调查说明，不会自动接通 MCP，也不会自动装好分析引擎。

说明书、连接线、仪器，还是得分清楚。

那为什么要费这个劲？

有源码、有文档、有官方接口的时候，直接读它们通常更省事。逆向的价值，往往出现在这些条件不齐的时候。

供应商停止维护，设备却还得用。旧软件打不开了，数据还在里面。某个系统表现异常，但日志解释不了。你想让两个产品互通，对方却没给出足够的格式说明。

这时候，逆向不是为了炫技，而是为了不让一个黑箱，卡住所有后续动作。

Dennis Yurichev 写过一篇很短的实战文章，分析一种未知数据库文件。[6]

他没有因为文件带着一个扩展名，就相信它一定属于某种数据库。也没有上来就堆最复杂的工具。

先看字节分布，再看文件头。他注意到里面反复出现7z 格式的特征，又观察到重复的块边界，于是提取其中一个数据块，交给现成的解压工具验证。

结果，能正常解压，里面是一份HTML 文件。

这里真正漂亮的，不是写了多少代码。

是把一个看似陌生的东西，拆成了已知结构，再用独立工具证明自己的判断。

不过，高熵只能提示数据可能被压缩、加密，或具有接近随机的分布，不能单凭这个就断言「加密了」。找到了一个能解压的块，也不等于整个文件格式已经被完整解释。

你看，连这种短小案例，都要守住证据的边界。

这也是逆向适合做数据迁移、兼容性研究和软件保存的原因。我们未必能找到当年的作者，但还可以从留下来的东西里，重新建立一条可用的路。

再把视线从软件挪到硬件，会更有意思。

Ken Shirriff 分析过 Game Boy 和 Game Boy Color 的音频放大芯片。[5]

两个设备都能播放声音，芯片的功能分区看着也有些相似。可他结合芯片裸片照片重建电路后，发现内部实现有很大区别。

其中一个关键差异，是Game Boy Color 的放大电路结合外部反馈电容，形成了高通滤波效果。这能解释两代设备声音差异中的相当一部分，尤其是低频表现。

原来，玩家嘴里的「听感不一样」，真的能一路追到电路里。

但他也坦诚写了，不知道裸片上电阻的精确阻值，只能从几何尺寸比较比例；对部分电路的解释，也保留了疑问。

我挺喜欢这种表达。

知道哪里看见了什么，也知道哪里还不能下结论。

而且，这种芯片级工作需要成像、电路知识和专业条件，不能因为REA 名字里有 Anything，就以为它也能替你把硅片内部自动看清楚。

工具有工具的边界，经验也有经验的边界。

回到应用软件这块，REA 官方对 Notion 剪贴板的分析，则展示了另一个方向。[4]

它不是停在「Notion 可以复制富文本」。而是沿着页面暴露的接口，经过 Electron 的预加载桥接层和进程间通信，追到主进程调用系统剪贴板的位置。

关于内容结构如何保留，案例还描述了一个关联机制。复制的HTML 带着一个标识，本地保存对应的结构化块数据，粘贴时再尝试把两者对上。

这个结论有具体的桌面版本与缓存资源时间范围，不应该随手扩展成Notion 所有版本、所有平台永远如此。

可对做产品的人来说，它依然很有价值。

我们终于能区分，眼前这个体验，到底是一个前端技巧，还是需要跨进程通信、本地状态和系统能力一起配合。

技术路线判断，会因此更具体。

不过，读懂实现，只能回答它「如何做到」。

不能直接回答用户为什么需要它，更不能证明这个功能值得你做。

这个区别，对产品经理尤其重要。

逆向软件，是调查技术机制。竞品分析，是研究定位、需求和取舍。照着截图做一个相似界面，又是另一回事。

把三件事混在一起，最容易出现的结果，就是技术上抄到了动作，产品上却没接住问题。

所以，真想开始，应该怎么做？

我觉得，不用从「把整个软件拆明白」开始。这个目标太大，连经验丰富的人也很容易迷路。

更好的起点，是把问题缩小到一句可以验收的话。

不是研究一个笔记应用，而是查清楚导出按钮最终把文件写到哪里。不是研究一套旧系统，而是确认某类旧文件能不能稳定读出三个必要字段。

还要先问一遍，有没有更便宜的路。

官方文档能否回答？公开源码里有没有？标准接口够不够？联系供应商能不能拿到格式说明？

不是每一个黑箱，都值得亲手凿开。

确定非做不可，再把授权和环境准备好。哪些文件可以看，哪些程序可以运行，哪些账户可以使用，是否允许联网、采集和保留数据，这些最好提前写清楚。

拿到一个文件，不自动等于获得了对相关线上服务做任何操作的许可。

接着，固定研究对象。

记录版本、平台、文件哈希和工具版本，保留原始副本。否则今天研究的是这个版本，明天程序自动更新了，你会发现前后两份结论根本不是在说同一件东西。

然后再选路线。

静态分析，是先不运行目标，查看文件结构、资源、代码和调用关系。动态分析，是在受控环境里，让目标运行，观察特定动作触发的变化。

前者擅长找可能的路径，后者能补上某次运行真实经过的路径。

但动态测试也不会自动覆盖所有情况。你只点了一次按钮，不能证明所有账户、异常状态和网络条件下都一样。

专业工具按对象来选。原生程序可以用Ghidra、IDA 或 Hopper，Android 字节码可以看 JADX，协议与流量记录可以借助 Wireshark。不是工具装得越多，理解就越深。

如果准备使用REA，初学者也不必拿复杂商业软件练手。项目提供了一个小型 Electron 笔记导出示例，可以先做静态分析，追一次从页面操作、经过进程通信、到 CSV 写入的链路。[8]

这比一上来就喊着复刻一个大产品，踏实得多。

再往下，就是反复做一件事。

提出假设，找证据，想办法推翻它。

看到一个名叫同步的函数，只能说明名字提供了线索。看到它调用了网络接口，仍然要问，什么时候触发，发送了什么，失败以后怎么处理。

一个能约束助手的调查要求，可以这样写。

只分析我提供的、已获授权的目标副本，先做静态检查，不启动程序、不联网、不修改文件。围绕一个具体功能追踪入口、数据流和输出。每个结论标明直接证据、推断或未知，保留版本与来源位置。需要动态验证时，先说明准备执行的动作及可能影响，等确认后再继续。

这不是万能提示词，也不能代替隔离和权限设置。

但它至少能把调查从「你帮我看着办」，拉回「我们现在究竟允许做什么」。

至于复现，别急着写完整产品。

先做一个最小实现，用相同输入对比原对象与新实现的输出。正常输入要测，空输入、边界值、损坏数据和异常路径也要测。

如果是为了互操作或商业交付，还需要单独审查知识产权。必要时，可以把合法取得的行为规格与独立实现过程隔离，保留来源和开发记录，也就是常说的洁净室思路。

但别把它当作法律护身符。权利、合同和具体行为，仍然要逐项判断。

到这一步，才能谈逆向的收益。

它最直接的好处，是把「只能相信别人告诉你什么」，变成「可以检查一部分实际发生了什么」。

对维护者，是恢复遗失的知识。对使用者，是减少数据和设备被单一供应商锁住的风险。对安全研究者，是检查产品声明与实际行为有没有差距。

对学习者，它还提供了一种很特别的学习方式。

不是从最理想的教程里学设计，而是从一个真实交付的东西里，看别人怎样处理限制、兼容旧系统，甚至保留一些不那么漂亮但不得不做的妥协。

REA 这类连接层的机会，则是减少在工具之间搬运材料的重复劳动，让助手围绕一个问题连续追查。

不过，这里只能说有这样的工作机制和潜在收益。官方案例不是跨任务的独立基准，不能拿一个小函数的成功，就推算所有逆向工作的提效倍数。

不然，刚刚建立起来的证据意识，又丢了。

它的代价也很具体。

你可能花很多时间，才发现自己跟错了函数。符号被去掉、代码被混淆、逻辑运行时才生成，都会增加判断难度。再遇上不同架构、编译优化、硬件依赖，问题会继续叠上去。

如果关键逻辑只在服务端运行，本地客户端和合法可见的通信，通常不足以恢复完整后台，更不用说训练数据、运营规则和内部流程。

能看见的那部分，不等于全体。

成本也不是一句开源免费就结束了。REA 自身采用 MIT 许可证，但外部商业分析工具有各自的授权，模型调用、环境搭建、验证和人工复核都要花钱花时间。

更现实的是维护。

对方一更新，文件结构、接口和时序都可能变化。你今天拼出来的适配层，明天也许就得重新检查。

所以，评估时不要只问「能不能拆」，还得问「持续维护它，划不划算」。

给调查设一个时间和预算上限，约定拿到什么证据就停止，卡在什么未知上就换路线。这比无限追着一个黑箱跑，更像真正的工程。

再往深处聊，就绕不开它的双刃剑。

Andrew Huang，也就是 bunnie，和 Sean Cross 做过 microSD 卡研究。bunnie 在 2013 年的文章里写到，他们分析的特定控制器存在固件加载机制，并结合代码分析和测试，研究了内部行为。[7]

这个案例最打破直觉的地方，是一张看起来只是装数据的卡，里面其实也运行着代码。

从正面看，这种研究能帮助我们认识设备的真实边界。从另一面看，如果底层代码被恶意修改，外部看到的正常表现，就未必值得完全信任。

但不能把特定控制器的发现，讲成所有存储卡都存在同一个漏洞。作者自己也说明，其他厂商采用什么机制，当时并不清楚。

这个老案例放在今天，依然提醒我们，逆向能力变得更容易调用，既可能帮助防守，也可能降低恶意研究的部分成本。

对厂商的启发，不是让客户端更难读，就万事大吉。

代码混淆可以提高分析成本，但不能替代真正的权限校验、密钥保护、更新验证和服务端安全设计。不能把「别人暂时看不懂」，当成唯一一道门。

对使用REA 的人，威胁又是另一层。

项目说分析在本地进行，没错。但工具结果会交给编程助手，助手连接的模型服务有自己的数据政策。[1]

本地解析，不等于整条链路的数据都不离开设备。

商业机密、用户数据、流量中的凭据，有可能随着上下文、日志或报告被带到不该去的地方。敏感任务要检查助手和模型服务的数据配置，明确哪些材料不能发送。

还有，REA 的安全文档明确说了，它不是沙箱。[9]

即使没有运行目标程序，分析引擎仍然在解析不可信文件。动态调查更可能改动文件、应用状态、账户或设备。

再叠上Agent，就多了一种需要主动防范的情况。目标里的字符串、页面和文档，都应该被当成证据材料，而不是给助手发号施令的指令。

这属于使用方式上的风险判断，不是说REA 已经被证实存在某个特定提示注入漏洞。

但防范原则很清楚。低权限、隔离环境、最少数据、限制联网，敏感动作单独确认。不因为一句「自动分析」，就给它整个工作电脑的钥匙。

这样看下来，逆向到底是好事还是坏事？

我不太赞成只用工具名字来回答。

为了读取自己的历史数据，为了让旧设备继续工作，为了在授权范围内发现并修复安全问题，它可以非常有价值。

用来窃取数据、绕过未获授权的访问控制、传播侵权成果，又是另一回事。

「学习研究」四个字，也不会自动改变行为的性质。

REA 的使用声明，就明确不支持绕过 DRM、许可检查、反作弊和未授权访问控制，也不支持复制专有软件受保护的代码与素材。[10]

不过，项目方的社区支持边界，不是对各地法律的统一解释。具体能不能做，要看司法辖区、合同、对象、手段与用途。

持有文件不等于拥有所有操作权限，看到伪代码不等于拿到再分发许可，工具开源也不等于目标软件开源。

商业项目碰到这些问题，应该找专业法律意见，而不是从一篇技术文章里领一张通行证。

说真的，真正的挑战可能不是工具够不够强。

而是我们能不能建立一套与它匹配的判断习惯。

做研究的人，要把结论和证据绑在一起，愿意写下不知道的部分。做管理的人，要区分授权、数据处理和实际操作权限。做产品的人，要接受技术实现可能更容易被理解，但用户需求依然得自己验证。

至于岗位会不会被替代，我也不确定速度会有多快。

至少从这些材料能看到，AI 比较适合接手一部分查找、归纳和工具衔接。问题怎么定义、哪种证据足够、实验哪里没覆盖、结果是否可以交付，这些责任还没有凭空消失。

真正容易让人放松警惕的，是它能把不完整的信息，写成一份特别完整的解释。

报告读完了，未知却还在那里。

所以我觉得，评价一次逆向，最值得追问的不是输出了多少页。

是别人能不能根据你保留的版本、材料和步骤，复核你的结论。是你有没有把局部成功说成全局成功。是对象更新以后，你还能不能知道哪些判断已经过期。

这才是它从一场炫技，变成可交付工作的地方。

写到这里，再想起开头那台透视机，我觉得这个比喻还是太轻松了。

逆向更像技术考古。

东西还在，说明书不一定在。原来的作者不一定找得到，当年的环境也未必能完整重建。

你得从痕迹里提出解释，再用更多痕迹检验它。

REA 这样的项目，让编程助手能够参与挖掘、整理、连接证据。它可能降低一部分门槛，但不会让一张碎片，自动变成完整历史。

从这个角度看，我真正期待的，不是人人都能更快复制一个软件。

而是当一个系统决定了我们的数据能否带走、设备能否修复、工作能否继续时，我们除了接受，也多了一种理解它的可能。

回到那块被击中的砖。

声音从左边传来，不是因为模型讲得好听。

是因为有人找到了输入，读出了指令，核对了常数，又认真比过了一遍。

工具可以越来越聪明。

但我们相信一个答案的理由，最好还是证据。

以上，谢谢你看我的文章，我们，下次再见。

---

参考资料与阅读说明

本文按2026 年 10 月 16 日检索到的公开材料整理。REA 更新频繁，主分支能力、已发布软件包和各分析引擎的支持范围可能不同，使用时应核对实际版本。项目案例属于项目方公开展示，未作为独立实测或通用性能结论。以下实践文章的经历均属于原作者。

[1] [REA 项目介绍、能力范围与 FAQ](https://github.com/morluto/rea)，包括本地分析、模型服务数据政策和外部工具授权说明。

[2] [REA官方案例，Rebuilding DX-Ball from its executable](https://rea.tools/showcase/dx-ball/)，声像函数的指令、调用者、常数及两类验证；页面还说明整款游戏重建仍在进行。

[3] [REA 调查工作流说明](https://github.com/morluto/rea/blob/main/.agents/skills/reverse-engineer-anything/SKILL.md)，目标选择、按问题调查、观察与推断区分、证据和未知项管理。

[4] [REA 官方案例，How Notion copies text and HTML](https://rea.tools/showcase/notion/)，桌面进程通信与富文本关联机制。案例标注 Notion Desktop 7.6.1，剪贴板格式材料来自 2026 年 7 月 13 日缓存的网页资源。

[5] Ken Shirriff，[Reverse-engineering and comparing two Game Boy audio amplifier chips](https://www.righto.com/2020/06/reverse-engineering-and-comparing-two.html)，2020 年 6 月。芯片照片、电路重建、反馈结构与声音波形分析，含作者对部分参数和解释的不确定性说明。

[6] Dennis Yurichev，[Unpacking a database of unknown type](https://yurichev.com/blog/rutracker/)，2026 年 6 月 30 日。未知文件的熵、文件头、块边界与解压验证。本文仅讨论方法，不评价或背书原样本内容及其传播权利。

[7] Andrew「bunnie」Huang，[On Hacking MicroSD Cards](https://www.bunniestudios.com/blog/2013/on-hacking-microsd-cards/)，2013 年 12 月 29 日，介绍与 Sean「xobs」Cross 的研究。文中具体结果针对所研究的控制器，不代表全部品牌、型号或现行产品。

[8] [REA JavaScript 与 Electron 教学示例](https://rea.tools/guides/javascript/)，从导出按钮追踪到 CSV 写入，并说明静态路径推断和动态验证的区别。

[9] [REA 安全策略](https://github.com/morluto/rea/blob/main/SECURITY.md)，分析引擎、用户权限、非沙箱边界和私密漏洞报告要求。

[10] [REA 负责任使用与免责声明](https://github.com/morluto/rea/blob/main/DISCLAIMER.md)，授权、运行影响、输出权利与第三方工具许可。本文不构成法律意见。