一、开放注入是什么
控制台「软件管理 → 编辑」里的 「开放注入（DAG）」 开关。开启后，任何人在注入器里只要填入你的 AppKey，就能完成注入——不需要登录控制台、不需要填 AppSecret、不需要填 AES 密钥，全部配置由服务端按 AppKey 自动下发。
注入过程中服务端会做三件事保护你的 APK：
| 机制 | 作用 |
|---|---|
| 构建登记 | 注入完成后，产物的签名证书、包名等指纹登记到服务端，作为唯一合法快照 |
| 运行时证明（attest） | 产物运行时上报实测指纹，与登记快照比对；换签名重打包的包会被拒绝（421） |
| 短时授权（grant） | 验证通过后服务端用 Ed25519 私钥签发 15 分钟授权，产物内置公钥离线验签后放行门禁——伪造「验证通过」响应不再可能 |
诚实说明：实测指纹由客户端上报，技术扎实的攻击者可伪造上报内容绕过比对。DAG 的价值 = 重打包可检测、可撤销（控制台「注入构建」页一键吊销）+ 防伪造响应，不是绝对拦截。
二、使用步骤（作者视角）
| 步骤 | 操作 | 说明 |
|---|---|---|
| 1 | 控制台 → 软件管理 → 编辑 → 勾选 「开放注入（DAG）」 → 保存 | 一次性操作。开启后你名下该软件的注入器用户零配置 |
| 2 | 把 AppKey 发给你的用户（或贴在下载页） | 这是用户唯一需要填的东西 |
| 3 | 用户在注入器里：粘贴 AppKey → 选择目标 APK → 开始注入 | 注入器自动完成：取配置 → 注入 → 登记构建 → 写入产物 |
| 4 | （可选）控制台「注入构建」页查看/管理产物 | 每个注入产物是一个「构建」：可看设备数、验证通过/拒绝计数；泄露时一键吊销（在线设备 ≤15 分钟失效）或删除 |
不开启开放注入也可以用：注入器支持登录你的控制台账号（安全强度更高，密钥不经公开接口下发）。开放注入只是把「填三把密钥」简化成「填一个 AppKey」，是否开启取决于你是否接受：任何拿到 AppKey 的人也能用注入器处理你的软件（风险细节见 §四、§五）。
三、注入器对接接口
开放模式下注入器只调两个免签接口（/api/v1 前缀），流程先后固定：
| 顺序 | 接口 | 返回 |
|---|---|---|
| ① | POST /injector/open-register，body：{"appkey":"nk...","pkg":"宿主包名","cert_fpr":"产物证书SHA-256","version":"1.0.0"}（软件开了「强制构建令牌」时需附 build_token） | deployment_id（构建号，写入产物）、inject_secret（注入专用签名密钥）、dag_aes_key（构建派生 AES 钥，软件开了 AES 才有意义）、pubkeys（验签公钥）。同一产物重复注入返回同一构建号（幂等） |
| ② | GET /injector/config?appkey=nk...&dep=dep_x | 软件名/版本/公告、enc_enabled（是否开 AES）、strict_mode（是否开设备会话）、allow_register 等展示配置 |
产物运行后周期调用 POST /injector/attest 上报实测指纹换授权（请求带 ik=1 用 inject_secret 签名；换签名重打包 → 421 拒绝）。接口细节以注入器内置实现为准，此表仅供理解流程。
四、与 AES 传输加密的关系
结论：开放注入与 AES 完全兼容，不用关。
- AES 是什么：控制台「AES 传输加密」开关。开启后，产物与服务器之间的请求/响应业务数据用 AES-256-GCM 加密，防抓包直接看到卡密等内容。
- 开放注入怎么处理 AES 密钥：注入器需要把 AES 钥匙放进产物才能加密。开放模式下服务端不下发你的软件密钥本体，而是按构建派生一把独立钥匙（
dag_aes_key）下发：- 每个注入产物一把，互不相同；吊销/删除该构建，对应钥匙随即失效
- 你软件的原始 AES 密钥（enc_key）全程不出服务端
- 产物运行时加密请求，服务端按构建号派生同一把钥匙解密
- 代价：这把派生钥匙嵌在产物里，能拆 APK 的人提取得到——但传输加密防的是链路上的抓包者，不是拆包者；且泄露面被限制在单个构建，与「整个软件的密钥泄露」不是一个量级。
历史说明：早期版本开放模式曾直接下发 enc_key（当时建议关闭 AES），现已改为构建派生方案，该顾虑不复存在。
五、与设备会话模式（strict_mode）的关系
结论：strict_mode 是「要不要把 AppSecret 从产物里彻底拿掉」的选择，与开放注入正交、可叠加。
| 不开 strict_mode | 开 strict_mode（设备会话） | |
|---|---|---|
| 业务请求怎么签名 | 用 AppSecret（所以产物里仍会内置 AppSecret） | 先设备注册（enroll）换会话密钥，业务全用会话签名 |
| 产物泄露后果 | 提取 AppSecret 可伪造登录/卡验证等业务请求 | 产物里没有 AppSecret，只有受限密钥（签不了业务接口）；会话密钥 15 分钟级过期 |
| 对用户的影响 | 无感 | 旧版客户端（未接入会话协议的）将无法验证——开启前确认产物走新协议 |
两个开关的分工：开放注入管「注入器怎么拿到配置」（零登录、只填 AppKey）；strict_mode 管「产物运行后用什么凭证与服务器通信」。互不依赖，同时开启是完整形态。
注：注入器取配置的接口里也可以代你开关 strict_mode（POST /api/dev/injector/config，需登录态）；手动开关在控制台软件编辑弹窗。
六、推荐组合
| 组合 | 配置 | 适合 |
|---|---|---|
| 省事 | 开「开放注入」，其他不动 | 快速分发。产物含 AppSecret（业务签名需要），但换签名重打包被 421 拦、可吊销 |
| 推荐 | 开「开放注入」+ 开「AES 传输加密」+ 开「设备会话模式」 | 产物不含 AppSecret、流量加密、指纹比对、可吊销——四层防护全齐，且三个开关互不冲突 |
| 强对抗 | 推荐组合 + 控制台「注入构建」页定期看 attest 拒绝计数 | 发现拒绝突增（疑似重打包）立即吊销对应构建 |
七、常见问题
- 用户反馈注入器提示「该软件未开放注入模式」？——你没开开关，或开了之后没保存。控制台 → 编辑软件 → 勾选「开放注入（DAG）」。
- AppKey 泄露了怎么办？——AppKey 本来就是公开的（嵌在每个产物里）。它单独换不来任何东西：业务签名要 AppSecret 或会话密钥；注入配置里给的是受限密钥与构建派生钥。真正要处理的是泄露的构建：控制台「注入构建」页吊销。
- 某个产物被破解了？——「注入构建」页找到它（按包名/构建号搜）→ 吊销（可恢复）或删除（不可恢复）。在线设备 ≤15 分钟内失效。
- 注入器报「激活尝试过于频繁」？——注入产物的设备注册/卡激活有防滥用限频（同设备 2 次/小时、同卡密 3 次/小时），正常用户无感，触发说明在被滥用。
- 想撤销整个开放注入？——关掉开关即可，公开接口立即 403；已登记的构建与其保护继续有效（吊销/删除仍走「注入构建」页）。
八、注入器构建令牌（build_token）
开放注入 + 公开 AppKey 意味着「任何拿到 AppKey 的人都能登记构建」。如果你向第三方分发注入器、或想精确控制谁能产出你软件的构建，开启软件的 「强制构建令牌」：
| 步骤 | 操作 |
|---|---|
| 1 | 控制台「注入构建 → 注入器构建令牌」→ 新建令牌：选择软件、可选绑定注入器 ID、日配额（0=不限）、有效期（0=永久） |
| 2 | 令牌明文只显示一次，复制后配置到注入器（register / open-register 请求的 build_token 参数） |
| 3 | 软件编辑弹窗勾选 「强制构建令牌」并保存。之后无令牌登记一律 426 拒绝；令牌可随时吊销/恢复/删除 |
- 令牌库中只存 SHA-256，拖库无法还原明文；绑定注入器 ID 后该令牌只对该注入器实例有效。
- 日配额按 UTC 日重置；幂等重登记（同一产物）不消耗次数。
- 不开「强制」也能用令牌：携带了令牌就一定校验，写错令牌会被 426 拒绝（防错配静默生效）。
- 控制台登录态登记（注入器登录你的账号）不受令牌限制——账号本身就是凭证。
九、Key Attestation 完整性证明
指纹比对依赖客户端上报，理论上可伪造；Key Attestation 把信任根转移到设备硬件：注入产物在 AndroidKeyStore 生成 TEE/StrongBox 硬件密钥并请求证书链，attest 时一并上报，服务端验证证书链 + challenge + 安全等级 + Verified Boot 后才签发授权。
| 构件 | 说明 |
|---|---|
| 信任根 | 控制台「注入构建 → Key Attestation 信任根」（平台管理员）粘贴厂商/Google 根证书 PEM。未配置信任根时完整性证明一律失败 |
| 构建策略 | 登记构建时在 policy 里配置：require_integrity（1=必须提供）、integrity_min_level（0 软件 / 1 TEE / 2 StrongBox）、integrity_require_verified_boot（1=要求 Verified Boot） |
| attest 提交 | integrity: {"kind":"key_attestation","chain":["base64 DER",...],"sig":"base64"}；challenge 约定为 "dag|<deployment_id>|<请求nonce>"，证书链中 attestationChallenge 必须与之一致，sig 为 leaf 私钥对同一 challenge 的签名 |
| 拒绝码 | 未通过返回 425；未开启要求的构建提交了无效证明时仅告警并记入风控 |
十、风控报表
控制台「风控报表」页汇总 DAG 的安全信号（开发者只能看到自己名下软件）：
- 汇总与按日趋势：构建/设备总数、attest 通过/拒绝、拒绝率、每日新增设备与事件。
- 疑似重打包告警：窗口内出现 cert_fpr/pkg 不符的构建，按构建聚合告警次数与涉及设备；可直接吊销跳转处理。
- 构建设备分布：各构建设备数 / 窗口新增 / 拒绝次数 / 设备上限，快速发现超量或异常构建。
- IP 异常聚集：同一 IP 关联 ≥3 台活跃设备，疑似共享/批量注册。
- 异常设备与事件明细：产生风控事件的设备排行与最近 100 条事件（指纹不匹配、严格阻断、设备超限、完整性失败、令牌失败）。
- 支持按 1/7/30 天切换与 导出 CSV。