最近看到 REA 和一些 AI 辅助逆向的讨论，一个很实际的问题是：我们自己的软件准备收费时，授权应该放在哪里？核心算法、卡密验证和云端接口，分别能保护到什么程度？
这段时间一边学习公开研究，一边借助 AI 整理软件授权和保护设计的检查方法，做了一个开源的 software-protection Skill。目前还是初步整理，很多地方缺少实测，也可能存在理解不准确的地方，想发出来请各位大佬指点。
先说一个容易混淆的地方
下面两种设计，保护的东西其实不同：
联网验卡 → 返回 valid=true → 客户端完成全部核心计算
提交具体任务 → 服务端检查身份、授权、任务权限和配额
→ 服务端执行必要计算 → 返回任务结果
第一种可以管理正常客户端，但客户端被修改后，本地判断仍可能被跳过。如果云端只是下发固定常数、完整模型或长期密钥，还要考虑一次合法运行之后，这些材料是否可以被保存并用于新的任务。
第二种可以把未来的服务端计算置于授权控制之下，但仍要检查接口越权、撤销、重放、配额和有效账号滥用。上云不是自动安全，也不适合所有离线软件。
我希望这个 Skill 能让 AI 主动追问：本地完全被改之后，真正的付费能力还由谁控制？
从几篇公开分析里学到的问题
下面只摘取与防御设计有关的机制，不提供补丁、激活串或破解附件。逆向发现属于原作者；加固思路是我的理解，未在这些第三方软件上验证，也不代表其当前版本仍有同样问题。如果理解有误，还请原作者和各位大佬指正。
例一：Typora 1.13.7——字节码保护之外，还要看加载和校验链
看雪 WolfSpicy 的《1.13.7Typora离线授权逆向》讨论了该版本离线授权的本地修改：作者先分析 V8 字节码，再围绕密码处理及完整性读取行为进行替换。这不是 RSA 数学算法被破解，也不等于攻破在线授权服务器。
我从中理解到的问题是：把逻辑编译成字节码以后，如果加载入口、密码调用或校验所读取的内容仍可替换，保护链就需要一起考虑。
对自有 Electron 项目，可以先做这些检查：
- 确认最终执行的脚本、字节码和外部组件，是否都处于预期的完整性检查范围。
- 检查“验证的文件”和“实际执行的内容”是否一致，不能只根据客户端自报的摘要判断运行状态。
- 在自有副本中模拟密码函数或授权结果被替换，再观察真正受限的操作是否仍受控制。
这里也有一个限制：客户端自己执行的完整性检查同样可能被修改。因此，这些措施是增加篡改成本；需要强制保护的服务端能力，仍要由后端独立授权。
例二：Nuitka 编译程序——验签成功之后，授权结果还经过哪里？
看雪《Nuitka逆向-战**具 1.5 逆向分析与授权绕过全记录》的作者报告：程序进行验签、解密后，授权结果仍通过可替换的 Python 模块调用被消费。这里参考的是作者的特定版本分析，不据此推断所有 Nuitka 程序都存在同样问题。
这个案例提醒我：原生编译不自动解决授权问题，检查不能停在“用了什么签名算法”，还要继续追踪结果的消费者。
如果自己的程序有类似结构，可以尝试画出：
授权响应 → 验签/解密 → 模块返回值 → 缓存状态 → 付费操作
再逐段检查：最后执行收费功能时，依赖的是可修改的本地标记，还是提供方仍能控制的实际能力？有服务端计算时，应在执行侧核验权限；必须离线时，则明确本地保护的成本与上限。重启、恢复缓存、CLI 和插件入口也应分别测试。
例三：VMP/RSA 自制样例——密码强度与执行链是两件事
看雪 zZhouQing 的《基于 VMProtect授权锁架构的RSA算法另类Bypass思路》使用自制样例说明了运行时参数修改的问题，并有已知目标 ProductCode 等前置条件。它不是完整商业软件实战，也不能据此认为 RSA 或所有 VMP 保护都已失效。
我理解它更适合用于提醒开发者：数学验签是否安全，与被修改的客户端是否按原设计执行验签，需要分开评价。
对自己的授权系统，签发私钥仍应保留在签发端；客户端验签之外，还应检查受信公钥、验签参数、返回结果与最终业务之间的关系。在隔离副本中模拟这些位置被修改，再记录真实付费操作还能做什么，不能只看激活窗口是否显示成功。
这三个例子涉及不同技术，但都让我更重视一件事：从材料下发一直追踪到实际业务结果，逐步说明每项保护究竟控制了什么。上面的建议也还需要更多自有样本和对照测试来验证。
这个项目目前想做什么
给助手提供源码、构建产物或架构材料后，让它按实际证据回答：
- 哪些资产最值得保护：签发秘密、核心算法、业务数据、受限接口、更新链。
- 授权在哪里产生、在哪里消费；删除授权调用或替换本地结果后，业务还能不能独立运行。
- 离线签名许可证、联网卡密和混合租约各有什么取舍，如何处理到期、撤销、席位、换机和断网。
- 云端下发的材料是否真正不可替代，是否可以跨用户、跨任务复用。
- 修复应该改哪些模块、接口和状态，怎样验证，有什么代价和剩余风险。
有源码和相应工具权限时，助手可以协助接入与加固；只有设计材料时先给方案。它提供的是审查与实施指导，不是现成授权服务器或一键 EXE 加壳器。
不只看授权：算法、资源和产品能力怎么保留
最近还发现，别人可能完全不碰授权，直接提取算法、模型、词库、模板，或者根据输入输出重做功能。因此新版先问：复制这个产品的价值，最便宜的路线是什么？再决定预算花在哪里。
目前尝试根据实际语言、构建配置和发布包给建议。例如：
- Python里确有独有且可复用的核心计算时，评估把局部算法抽成C++/Rust扩展，保留Python界面与编排，再核对适配的编译混淆或VMP保护范围。若Python只是调用公开推理库，价值主要在权重，重写薄封装可能帮助不大。
- Electron中有价值的本地算法，可比较原生模块与服务端执行，但还需检查IPC、导出接口和最终消费者；搬到主进程或WASM不自动保密。
- 规则表、权重、素材本身可独立复用时，先考虑最小化下发、按需分发、服务端执行或水印追踪，明确本地明文可被复制的限制。
- 原生程序要按真实函数价值与性能选保护区域，不能只给导出包装器放标记，就认定被调用的核心算法也被保护。
助手也应主动确认已有保护工具、版本和SDK，以及是否接受局部重写、离线约束和性能预算。建议应落实到文件、函数、保护区域、构建产物和验收；OLLVM类方案需匹配编译器，VMP标记需经过实际保护处理。
这些仍是需要样本验证的方法。迁移成本、工具许可、跨平台维护、性能和合法用户体验都应一起比较；公开算法或低成本可重做的功能，也不适合无限投入混淆。
最近补充的防御检查
围绕 AI 逆向工作流，目前尝试用两张表把检查落实到目标项目：
- 执行层次图：容器 → 加载器 → 语言运行时 → 业务逻辑 → 结果消费。入口脚本没有逻辑，不代表核心计算没有交给客户端。
- 运行数据暴露表：记录秘密材料在哪里出现、谁能读取、明文保留多久、能否复用、最终由谁消费。缩短明文寿命和局部原生化可以改变分析成本，不能直接当作保密保证。
验收不只看反编译代码是否难读，还包括：
- 在自有隔离副本里模拟本地校验成功，无有效凭据能否直接调用受限后端。
- 保存一次合法运行的材料后撤销授权，检查能否对不同的新输入继续完成付费业务。
- 区分读出字符串、得到转储、恢复函数、重建程序和真实业务成功，避免把前一阶段算成后一阶段。
- 在干净环境重跑交付物，排除硬编码答案、历史会话和测试环境泄漏造成的假成功。
混淆、虚拟化、反调试和完整性措施仍可提高成本，但应结合性能、兼容性和误判评估。纯离线且完整能力已下发时，项目会明确其上限；不会承诺“防住所有 AI”。授权失败也不应破坏用户数据或静默生成错误业务结果。
怎么使用
项目地址：b6fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6y4N6f1y4Z5k6h3&6Y4x3U0l9H3y4#2)9J5c8Y4y4G2k6Y4c8%4j5i4u0W2i4K6u0V1M7s2u0G2N6r3g2U0N6r3W2G2L8W2)9J5k6s2y4C8K9h3I4D9
当前版本：v0.4.0 与安装包。将 skills/software-protection 整个目录导入支持 Skill 的助手，保留 references；不绑定某一家 AI 或授权平台，具体能力取决于助手的工具和权限。
可以这样提问：
使用 software-protection 检查这个自有项目。先阅读源码、语言、构建配置和发布方式，识别值得保护的算法、资源和产品能力，判断最容易被提取、复用或重做的路径。根据检查发现选择需要深入分析的方向，给出具体保护位置、改进步骤、工具适配、投入取舍和验收方法；缺少关键信息时主动询问。先给分析和建议，不修改程序。
来源和目前的限制
目前资料索引有 76 条候选资料、12 类失效模式。资料包含作者实践主张、教学样例、历史内容和排除记录，不是 76 款已确认破解的软件；第三方样本独立运行复现为 0。结构检查和 CI 通过，也不等于目标软件已通过抗逆向测试。
参考材料包括看雪 zZhouQing 的《VMProtect3.5.1还原演示》、0xAF 的《从 REA 的 19 万 Star 说起》，以及 morluto/rea、manyuegong33/r0crawl_skills 等公开项目。相关逆向成果属于原作者；我的新增部分是防御设计、证据边界和验收方法，不代表原作者为本项目背书。源码仓库记录具体来源与审查范围，署名和来源信息会继续补充完善。
项目没有搬运文章全文或破解附件，MIT 只覆盖本项目原创内容，不替第三方材料重新授权。
后续会继续收录公开案例、修复和反例，经过核对再更新。欢迎指出：哪些防御建议在真实项目中不成立，哪些离线方案的取舍还没说明白，或者哪些摘要和署名需要修正。
想请各位大佬一起建设
目前项目仍缺少大量可核验样本，希望各位大佬有兴趣的话，能一起参与建设。 现在的资料数量远不足以代表真实软件保护的全貌，尤其缺少：
- 可以公开讨论、经授权用于分析的自制样例，以及对应源码、版本和运行条件。
- 授权被绕过之后如何修复、修复前后行为有什么变化的对照。
- 防护有效或某条分析路线失败的案例，以及明确的测试条件。
- 离线许可证、合法换机、断网、服务停运和用户数据恢复的实际经验。
- 对现有摘要、署名、设计建议和验收方法的纠错。
提供原帖链接、一个设计上的疑问，或者指出一句建议不成立，都很有帮助。不方便公开的软件和敏感材料无需上传，项目也不收集第三方破解成品、激活码或私密数据。
欢迎在这里交流，也可以通过 GitHub Issues 或 Pull Request 补充。涉及原作者的研究，会继续核对出处和署名；如果有引用范围或理解上的问题，也欢迎提醒我调整。
个人目前的能力和精力都有限，希望先把这份整理做得踏实一点。如果能在大家的帮助下，逐步形成一些能落地、能验证、也照顾合法用户的授权设计方法，就很有意义了。
