程序保护与授权设计

帮助用户回答：保护什么、信任放在哪里、如何授权、如何接入、如何验证、出了问题如何恢复。用用户的语言沟通；不要求特定 AI 厂商、MCP、操作系统或付费授权平台。

任务模式

• 用户要求建议或完整方案：检查可用材料，交付可实施设计；不要擅自修改程序。
• 用户要求加验证、接入或加固：在已授权范围内检查和实施，验证行为，交付改动与运行说明。缺少服务器或账户时可完成本地适配与配置模板，并明确尚未部署。
• 仅有想法、没有目标程序：给出带明确假设的参考方案及适配所需信息，不虚构文件、函数或已完成的测试。

先建立证据

优先从项目、构建配置、安装包和已有说明推断语言、框架、平台、打包方式、入口、更新机制和现有授权链。只询问会改变方案且无法推断的问题，例如必须离线多久、是否能部署后端、允许绑定几台设备。已有选择优先。

区分源码、构建产物、运行观察和推测。发现项标注真实文件/符号/接口或产物位置、证据类型、影响和置信度。没有检查到不等于不存在。

仅有二进制时，先只读检查副本并记录原件摘要；如环境提供 REA 或其他分析工具，可用于用户授权目标的证据收集，不把它设成必需依赖。不为“保护”而默认运行未知安装包、直接改写原件或破坏现有签名。无法可靠改造时，提出源码接入、重新构建或受控服务化路线。外部启动器只能增加入口门槛，不能证明程序本身无法被直接启动。

明确信任边界

假设攻击者能读取和修改自己控制的客户端、模拟本地返回值、复制文件及调整普通系统时钟。按用户实际风险选择措施，不夸大攻击能力或防护收益。

本地签名许可证能证明授权内容来自签发者且未被改动，但不能保证客户端执行校验。联网只有把受保护操作的授权在服务端执行时，才能保护该服务端能力；仅远程返回一个布尔值仍可能被客户端绕过。混淆、加壳、原生编译和完整性检测用于提高成本，不承诺“不可逆向”“绝对防破解”。

涉及 AI 逆向、核心算法、云端下发常数/密钥或“本地完全攻破后仍无法使用”时，阅读 references/hostile-client-design.md。以客户端完全可修改为前提审查关键业务依赖，区分已下发材料可被复制与未来云端计算可被拒绝。主动指出不成立的安全承诺，给出具体替代方案及可验证目标；不要机械地把一个常数搬到云端就宣布解决问题。

执行流程

1. 建立重点保护清单：按 references/protection-review.md 检查资产和信任边界，将优先级落实到用户项目。涉及逆向抵抗、授权绕过或已有壳/验证系统时，再按 references/failure-patterns.md 将失效模式映射到真实资产；每个适用模式给出证据、控制、验收和剩余风险。
2. 选择授权架构：阅读 references/licensing-design.md，比较离线、联网与混合方案。给出一个推荐方案和选择理由，保留用户的明确要求。
3. 补齐接入设计：给出校验位置、数据结构、密钥流向、设备与席位策略、状态转换、失败处理、运维和迁移方式。已有授权平台优先检查真实 SDK/API，不凭记忆编造接口。需要当前依赖信息时查官方文档。
4. 根据任务模式实施或交付方案；按 references/acceptance-and-delivery.md 验证并组织结果。没有执行的测试标为待验证，不把示例或模拟服务说成生产实现。

实施约束

• 签发私钥和管理凭据留在签发工具、后端或密钥管理设施；客户端只携带验签公钥和权限受限的运行凭据。不要把可签发许可证的共享密钥藏进客户端。
• 使用成熟密码库与版本化签名格式。区分签名、加密、哈希及代码签名各自作用，不设计自创密码算法。
• 所有受保护后端操作检查身份和授权，设备/席位上限由服务端原子约束；UI 隐藏和客户端开关不构成服务端访问控制。
• 网络异常、授权到期、撤销和设备不匹配采用分别定义的策略；避免一个宽泛异常处理永久放行。演示后端、测试密钥、调试开关不得静默进入正式构建。
• 保护检查失败时保留用户数据、允许恢复或导出，说明原因及处理方式；不采用删文件、破坏数据或干扰分析环境的措施。

完成标准

用户能明确知道最值得保护的位置、所选授权链的信任边界、如何发放和回收授权、如何接入并测试，以及剩余风险。方案级交付提供具体步骤与验收用例；实施级交付还需列明实际改动、检查结果与尚未配置的外部依赖。

对高优先级问题给出证据或假设、失效原因、最小修复、长期改造、实际接入边界、验收和代价。核心算法保护与授权保护分开评价。无项目材料时用明确假设的参考设计，不只输出“加密、加壳、上云”等建议词。

对于可编辑宏/脚本项目，还要回答“删除授权模块后业务能否独立运行”；对于本地验签项目，还要检查“替换信任公钥后能否自行发卡”。按目标类型选择这些检查，不以绑定因素数量或验签算法名称代替执行边界分析。

根据公开案例维护技能

用户要求调研或从案例改进时，使用 references/research-method.md 记录范围、来源、日期、证据等级与访问缺口。分批资料保存在 references/forum-cases.json。它是有限样本，不是漏洞库或当前产品状态证明；不默认加载整个案例集，不把历史漏洞或作者主张当作已复现事实。

按需核对记录的review_status：source_body_reviewed表示对照摘要依赖的正文关键段，partial_body_reviewed表示材料不完整或出处仍有缺口，header_only_reviewed仅核标题和元数据；均不是运行复现或对原文所有结论的认可。import_review_status保留旧批次的抽查/摘要范围。mapping_role区分作者实践线索、教学说明、架构检查与无映射。区分工具能力、教学样例、架构分析与真实目标实践。重复来源沿用原ID；转载、更新、推荐时间与原始发表日期分开。不要把存储容器大小当密钥位数、把工具示例密钥归到目标产品，或从客户端调用链可改推断服务端可信证明失效。