卡锁
破解与防护怎么对抗：从”锁得死”到”锁得住多久”
前面两篇把攻击面讲完了：Samsung 被 CVE 捅穿过，Transsion 只凭一个 IMEI 就能服务器端脱钩，PayJoy 的 oeminfo 分区被 BROM 专项清除，Apple 停在”Hello 屏半绕过”。
这一篇换个角度：资方怎么打回去。
先说一个前提判断，因为它决定了后面所有动作有没有意义——
2026 年的监管锁攻防，胜负手已经不在”能不能解锁”，而在”解锁后能撑多久”。
原因很简单。破解生态是分工的：有人做漏洞研究、有人做工具、有人在 Telegram 和修理店卖服务。只要一台机器的残值高于破解成本，就一定有人去做。你能做的不是让破解归零，而是让破解不经济——把单位破解的收益压下去，把被发现的概率提上来。
一、先看清对手在打什么
做对抗之前，得知道对方拆机的顺序。2026 年公开渠道能看到的破解路径，实际是一条降级链：
第一步，断网。 拔 SIM、关 WiFi。所有云端锁（Knox Guard、Transsion Cloud ID、PayJoy 联网校验）的前提都是”设备能连服务器”。断网之后，锁指令下发不了、状态上报不了。
第二步，断更新。 冻结系统更新包、屏蔽厂商服务器域名。这一步的目的是让设备停留在”有已知漏洞的版本”，同时避免厂商通过 OTA 打补丁把路封掉。前面 286 篇里提到的商用工具”去锁后防重锁”，标准操作就是冻结 com.sec.android.soagent、com.wssyncmldm 并屏蔽 Samsung 服务器域名。
第三步，断管控。 ADB 关掉企业管控组件的唤醒和前台能力（AppOps 法）、或者用 BROM/Preloader 模式刷分区、或者走服务器端脱钩。
第四步，清痕迹。 恢复出厂、刷零售固件、把设备伪装成”正常二手机”出手。
这四步里，第一步和第二步是资方最该盯的。不是因为它们最难防，而是因为它们最容易留下可观测的信号——一台长期无 OTA、长期无联网、长期 offline 设备，在后台数据里是有特征的。
大多数资方的贷后监控只盯”还款行为”，不盯”设备行为”。这是当前最大的空档。
二、硬件与平台侧：2026 年真正有效的三层防护
看厂商这两年做了什么，会发现方向很明确：从”应用层锁”往”多层锁”走。
Samsung Knox Guard：把锁拆到多个特权层
Samsung 在 2026 年把面向设备融资客户的安全模式做了一次实质升级。按 Samsung Knox 官方文档（2026 年 1 月 28 日更新），选择 Device Financing 域的租户，设备会默认应用一套 Hardened Security mode（加固安全模式），且强制、不可回退。
这套模式包含四个机制：
- Default lock（默认锁）：设备出现异常时直接锁定并施加全部限制。触发后，设备上已下发的策略全部作废，必须重新推送设备策略才能恢复。
- Hacking lock（入侵锁）：检测到可疑行为即触发 Default lock，锁屏显示错误码，标明”因入侵锁被锁定”。
- Multi-layer lock（多层锁）：在不同系统特权层级和组件上设置多个锁点。文档给的例子很具体——bootloader 层可以单独上锁，功能限制在另一层生效。这样单点被攻破不会直接连带其他锁点失效。
- 时间日期设置封锁：强制使用自动时间，用户不能改设备时间。这一条针对的是”改时间绕过时间窗校验”这类老手法。
一个容易被忽略的细节：Hardened Security mode 一旦应用，设备即使从 Knox Guard 中被移除，也不能上传到非融资客户的租户，只能重新上传到任意融资域。厂商在用租户隔离防止”解锁后洗白转租”。
支持范围也要说清楚，这是硬约束：仅 Samsung Galaxy S26 及后续机型，以及 Galaxy A17 LTE 作为例外。文档明确写了，S26 之前发布的设备（除 A17 LTE 外）无法使用或升级到 Hardened Security mode。
对资方来说这条意味着：低价机型（A0x/A1x 系列的大部分）拿不到这层加固。 而新兴市场的分期业务，恰恰以中低端机为主。这是当前 Samsung 方案最大的覆盖缺口。
另外，Samsung 在管理侧给了一些可操作的开关，Knox Guard 控制台里可以对单台设备查看和设置：ADB 命令封锁、开发者模式封锁、Android Enterprise 配置封锁、恢复出厂封锁、固件更新控制（含 WiFi 自动下载、自动安装）、离线锁（Offline lock）、自动锁（Auto-lock）、功能限制、壁纸限制、去电控制。还有两个运营上很有用的字段：Last seen（设备最后一次被 Knox Guard 服务器探测到的时间）和 Relock timestamp（重锁时间戳，仅 PAYG 租户）。
Last seen 这个字段值得单独说。它是判断”设备是否离线漂移”的唯一官方信号。而这个字段默认不开启，需要向 Knox Guard 管理员申请。
如果你在用 Knox Guard，却没开 Last seen，你等于放弃了最有效的异常信号源。
Google DLC：把锁做进系统，但门槛在 OEM 和量
Google 的路子更彻底：不做应用，做系统能力。
Android 14（API 34）起，AOSP 引入了 android.devicelock 系统 API 和 DeviceLockManager。按 Android 官方 API 文档：
- 这是一项系统级设备锁服务，由”特殊应用”（kiosk app，由设备锁方案下载并安装）调用
lockDevice()/unlockDevice()来控制； - 典型场景写得很直白：融资设备，融资方在借款人漏付时锁定设备；
- 锁定时”只保留有限的交互能力（例如拨打紧急电话）”；
- 设备在通过 device lock 后端确认”属于某个项目（例如融资）”后，会走配置流程并安装 kiosk app，此时设备进入”受限”状态。
在配置流程中，方案还会施加三项系统级限制：关闭调试功能（DISALLOW_DEBUGGING_FEATURES）、关闭未知来源安装（DISALLOW_INSTALL_UNKNOWN_SOURCES，需后端配置）、设备锁定时关闭去电（DISALLOW_OUTGOING_CALLS，需后端配置且设备处于锁定状态）。
贷款结清后，kiosk app 调用 clearDeviceRestrictions 解除上述限制，同时放弃锁定能力——这是一个干净的能力回收语义。
从对抗角度看，DLC 的优势在于它不是一个可卸载的 App：
- 它在系统镜像里，普通用户界面里看不到入口；
- 恢复出厂后重新联网会重新校验后端状态，未结清则自动重锁；
- 方案层关闭了调试和未知来源安装，把 ADB 这条路在配置阶段就堵了。
DLC 的短板不在技术，在分发：必须在生产环节由 OEM 在出厂固件中启用，手机卖出后无法追加开通；接入要走系统集成商、需 Google 审批、需与 OEM 达成机型与最小起订量约定，且只在获批国家/地区可用。这套门槛决定了它天然只服务大玩家。
平台侧：2026 年 9 月 30 日生效的开发者验证
还有一条容易被忽略但影响深远的变化：Google 的 Android 开发者验证要求。
按 Google 官方开发者验证页面，2026 年 9 月 30 日起，在巴西、印度尼西亚、新加坡、泰国四国，用户在经过认证的 Android 设备（Android 7 及以上）上从参与计划的商店安装应用时，会启用保护——应用必须由已完成身份验证的开发者注册（包名 + 签名密钥 SHA-256 指纹），否则安装被拦。2027 年扩展至全球。
这条对监管锁攻防的意义是间接但真实的：那些靠”装一个第三方锁机 App + 侧载配置包”来拼方案的中小资方，未来在安装环节就会遇到阻力。 而反过来，走系统级、走 OEM 出厂的方案，不受这条影响。
监管方向是一致的：平台在收窄”非系统级设备控制”的合法生存空间。
三、五个可落地的对抗动作
从上面这些能力往下推，资方能做的具体事有这么几件。
动作一：把”设备行为”接进贷后监控，而不是只看还款
大多数贷后看板只有 M1/M2/M3、滚动率、回收率。2026 年应该加四个设备侧指标：
这四条的共同点：都不依赖用户配合，都是设备自己报上来的。 而它们组合起来，恰好覆盖了前面说的破解降级链的前两步。
一个具体的用法：如果某批次设备的”补丁级别”在同一时间段集体停在某个旧版本、且”OTA 记录”集体中断，这是批量被解锁的典型特征，不是个体行为。这时候该做的是抽检 + 冻结该渠道的新放款，而不是一台一台去查。
动作二：把 OEM/OS 认证变成采购的硬门槛
这条是政策倒逼的，不是自选动作。
印度 RBI 2026 年 8 月 6 日发布的回收修正指引（2027 年 1 月 1 日生效），对设备锁定设了明确条件，其中一条是：NBFC 和/或第三方服务商必须就其所用的技术机制，取得设备 OEM 和/或操作系统平台的认证（如提供）。
同一条指引还规定了完整的合规链条：
- 只有”该设备本身由本笔贷款融资”才可锁定，其他贷款逾期不得动设备；
- 贷款合同必须明确、无歧义地允许该操作，并写明程序；
- 必须先发通知、给出逐步限制的时间表；
- 逾期未满 30 天不得启动任何限制；全额限制须在逾期 60 天后才可生效；60 天前不得限制去电；
- 必须”逐步”施加限制，不得一上来就把设备变砖；
- 不得限制必要功能：来电、短信、紧急 SOS；
- 限制不得导致借款人无法进行工作/就业相关活动；
- 结清后一小时内必须解除限制，否则按每小时 250 卢比向借款人补偿（上限为已发放贷款金额）；
- 用于限制的技术手段在贷款全部结清后必须立即卸载；
- 任何情况下不得访问、存储或使用借款人手机上的数据（通讯录、短信、通话记录、照片、位置历史）。
这些条款里，”OEM/OS 认证”是最容易被国内团队忽略的一条。它的实操含义是：你用的锁机方案，得能拿得出厂商或平台的书面认证。 而拿不出认证的方案，在新兴市场会越来越难通过合规审查——不只是印度，菲律宾、印尼在消费者保护条款上都在往同一方向走。
动作三：把”防重锁”从厂商卖点变成你的验收项
前面提到的商用工具，”去锁后防重锁”是标准配置：冻结系统更新、屏蔽厂商服务器域名。
这意味着两件事：
- 重锁机制本身是有效的——否则破解方不需要专门做这件事；
- 重锁能不能生效，取决于设备还能不能连上厂商服务器。
所以验收时要问的问题不是”能不能重锁”，而是：在用户断网、冻结更新、屏蔽域名的情况下，你的重锁还有几成概率触发？
对云端锁方案，答案取决于三个设计：
- 是否有离线锁（offline lock）能力，即在无网状态下按本地策略触发；
- 是否有重锁时间戳机制（Samsung PAYG 租户有
Relock timestamp），在设定时间点强制复核； - 是否存在“设备被移除后不能转入非融资租户”的隔离约束（Samsung Hardened Security mode 有）。
三条都有的方案，重锁成功率显著高于只有”云端下发+联网校验”的方案。
动作四：把物理可接触当成默认威胁模型
CVE-2026-21007 的前置条件只有两个：物理接触 + 未打补丁。而分期业务的设备 100% 在用户手上，第一条永远成立。
所以任何建立在”用户不会动手”之上的防护假设，都不成立。具体落到三件事：
- 补丁管理进风控流程，而不是 IT 流程。把”设备补丁级别”作为贷后指标之一，和逾期率一起看；
- 对低端机型单独定价。Hardened Security mode 不支持 S26 之前的机型（A17 LTE 除外），DLC 需要 OEM 出厂启用且受 MOQ 约束——这意味着低端机在技术防护上天然弱一档。技术上补不回来的，只能用押金和定价覆盖；
- 不要把”锁得死”当成风控的核心假设。锁是损失缓解手段，不是审批依据。把首付比例、押金、期数设计好，比赌锁能不能扛住更靠谱。
动作五：把每次绕过当成一次策略迭代
这一条是流程层面的，但长期看最重要。
现在行业里普遍的做法是：设备被解锁 → 认定损失 → 核销。真正有效的做法是：设备被解锁 → 归因 → 改策略。
归因要回答四个问题：
- 通过什么路径解的？（CVE/ADB/服务器脱钩/BROM/半绕过）
- 为什么这个路径在这台设备上有效？（补丁级别/机型/锁方案层级/租户配置）
- 有多少同类设备具备同样条件？
- 能不能用技术手段堵？堵不了的部分，用业务手段覆盖多少？
这四问做完，输出应该是三样东西：一个要打得补丁清单、一个要停放的渠道/机型清单、一个要调的首付或押金参数。
四、一句实话：没有任何方案能”锁得住”，只能”锁得住多久”
把前面所有内容收一下。
2026 年的监管锁攻防，实质是一场成本对抗：
- 攻击方的最小成本，已经低到”一个 IMEI”（Transsion Cloud ID 服务器端脱钩）；
- 攻击方的高成本路径，是芯片级/系统级方案（Samsung Hardened Security mode、Google DLC），需要物理接触 + 专项工具 + credits；
- 平台在往系统级收（Android 14 的
android.devicelock、2026 年 9 月 30 日的开发者验证）； - 监管在往”限制锁定能力”收（印度 RBI 的 30/60 天规则、一小时内解锁、每小时 250 卢比补偿、禁读设备数据）。
这四条同时存在，意味着一个不那么舒服但必须接受的结构：
技术防护的上限由 OEM 和平台决定，不由资方决定；资方能决定的是”选哪个层级”和”用业务参数覆盖多少残差”。
所以真正该问自己的问题，不是”我的锁能不能被解开”——一定能。而是：
- 我用的是哪一层？（应用层 / 分区层 / 系统层 / 芯片层）
- 被解开后，我多久能发现？
- 发现后，我能做什么？
- 做不了的部分，定价和押金能不能覆盖？
这四个问题答不上来的方案，宣传得多硬都没用。
反过来说，把这四个问题答清楚，即使锁只是”应用层 + 云端校验”这种相对弱的配置，也能跑出可控的损失率——因为你已经不再依赖”锁不住就完蛋”这个假设了。
锁的本质不是墙，是延迟。 你能买到的是时间，不是绝对安全。
参考来源：Samsung Knox 官方文档（Hardened Security mode，2026-01-28 更新；Knox Guard 设备详情字段说明，2026-10-21 更新）、Android Developers android.devicelock.DeviceLockManager API 参考（API 34 引入，36.1 新增 clearDeviceRestrictions）、Google Android 开发者验证官方页面（2026-09-30 生效节点）、印度储备银行 2026-08-06 贷款回收修正指引（2027-01-01 生效）。
