「一张 2099 年的通行证」智简魔方面板授权机制逆向与离线化

是什么，为什么，怎么做 —— 从 /v1/clouds 接口的 7 秒卡顿，到授权链路的逆向还原，再到一套纯 PHP 的离线化修复

免责声明：本文记录的是对自己拥有、被授权维护的系统进行的授权机制研究与修复，目标是消除性能故障、恢复面板可用性。文中只讨论方法论、数据流、关键常量与离线化思路，不提供授权生成器、不提供二进制破解件，也不讨论如何伪造第三方授权。请读者遵守所在地法律法规及软件授权协议。

一、现象：一个 7 秒起步的列表接口

目标系统是智简魔方（ZJMF）云面板，版本 3.9.14 / 3.9.22，底层是 ThinkPHP 6.0.3，前端 Vue2 + Element UI，数据库 MariaDB 5.5，PHP 代码经过 ionCube 加密。

问题最初表现为：/v1/clouds 云主机列表接口一次请求耗时 7-11 秒。云主机列表是面板中使用最频繁的入口之一，其延迟直接决定操作体验。按常规排查顺序，列表接口慢通常先检查数据层：SQL 是否走索引、分页是否限流、磁盘 IO 是否抖动、数据库连接是否被拖垮。这些方向均无结论。该慢点有一个稳定特征：每次都是 7-11 秒，不像数据层问题那样时好时坏。

进一步对照 3.9.14 的解码产物与线上版本，我们在 ionCube 加密的 CloudController.php 构造器中找到了一个 sleep() 调用，位于授权校验失败的分支。

授权校验失败时，面板不直接拒绝请求，而是先执行数秒 sleep() 再继续。接口表面可用，每次实例化 CloudController 都要为授权失败支付一次惩罚性延迟。数据层正常，慢来自授权层的延迟设计。

授权失败没有让接口直接返回 403/500，而是让接口变慢。排查「可用而慢」的接口时，除数据层外，应同时检查请求链路上的中间件、构造器与外部校验点。

二、逆向：把加密黑盒还原成数据流

ionCube 加密使源码不能直接阅读，运行时行为则可观察，合法还原后的 PHP 可读。逆向过程分三步：先确定慢请求落在哪个控制器和构造器；再以 3.9.14 解码产物为锚点，顺藤摸瓜找到授权函数的调用关系；最后把常量与函数名拼成一张链路图。

加密 PHP 中，函数名、类名与常量仍然可见，可作为路标；抓住这些路标并配合 3.9.14 解码产物的明文对照，即可逐步拆解黑盒。

沿着 CloudController 构造器追下去，授权链路逐渐清晰：

• strcode：RC4 变体，default_key 为 "default_key"；
• _strcode：key 为 "zjmf_key_strcode"；
• zjmf_authorize：授权数据块，使用 RSA-1024 公钥解密校验；
• get_license_info($check, $return_err)：核心校验函数，各调用路径最终都汇聚到这里。

RC4 是一种对称流密码；这里的「变体」未完全按标准 RC4 实现，思路一致：用 key 对数据做可逆的对称变换。两个函数使用两把不同 key——"default_key" 与 "zjmf_key_strcode"——混淆是分层的，不同阶段、不同字段使用各自的 key。zjmf_authorize 数据块用 RSA-1024 公钥解密校验，即「验签」：数据块由私钥签发，校验方持有公钥，能解开且内容合法即通过。从命名看，get_license_info 的 $check 控制是否执行真实校验、$return_err 控制是否回传错误信息；该函数是所有授权入口最终汇聚的裁决点。

整条链路的数据流：授权信息先经 strcode / _strcode 两层对称混淆，内层的 zjmf_authorize 数据块再用 RSA-1024 公钥解密校验，get_license_info 做最终裁决。外层对称混淆负责「藏」，内层非对称校验负责「信」。

现场保留了员工留下的 crack .so，其原理为两处 hook：hook openssl_pkey_get_public，将函数返回的公钥替换为 crack 自带的公钥；hook stream_socket_client，直接断网。前者让校验方取到 crack 可识别的公钥，后者切断需要外联的校验路径，授权校验随之落入离线信任分支。该方案是二进制层面的黑盒：其行为与副作用无法审计，且 PHP 版本或扩展接口变化后可能失效。

我们没有继续采用该 crack：排查与修复需要确定性，一个能运行而无法说清原理的二进制不满足这一要求。

三、机制：惩罚性延迟与「软破坏」

CloudController 构造器在授权校验失败时执行 sleep()，这是 /v1/clouds 耗时 7-11 秒的直接原因：列表接口每次进入都要先构造控制器，构造器为授权失败先执行延迟。7-11 秒的区间可视为固定 sleep() 与请求其余耗时叠加的结果。

这种设计取向：授权失败不报错、不中断，用延迟让系统保持「能用」的表面状态，同时显著降低可用性。从工程角度看，sleep() 制造的是一种介于「可用」与「不可用」之间的状态：监控不会立刻告警，用户体验已经受损。这类「软破坏」容易把排查方向带偏：日志中没有明显错误，性能指标上只留下一个稳定的慢点。前端每 5 秒轮询一次 /v1/authorize_info，授权失败时返回 400，弹窗源由此产生；接口慢与弹窗叠加，操作体验进一步恶化。

从资源角度看，惩罚性延迟具有放大效应：每个慢请求占用一个 PHP 工作进程数秒到十几秒，并发稍高即占满工作进程，其他接口随之排队。影响范围从单个接口的响应速度扩大到整个面板的吞吐能力。

四、修复：一条更干净的纯 PHP 路线

我们决定不依赖 crack .so，改走纯 PHP + 配置的离线化方案。

第一步，解码 3.9.14 应用。 3.9.14 的解码产物作为整套修复的明文基线。拿到明文 PHP 后，授权相关代码可完整审计。这一步决定后续方案的质量：只有看到源码，才能确认哪些函数是裁决点、哪些文件会被覆盖。

第二步，stub 授权函数。 对 get_license_info、compareLicense、get_license_data、LicenseLogic 做桩替换，让它们固定返回合法结果：

// 返回值示意（非完整实现）
return [
    'status'            => 200,
    'edition'           => 1,
    'last_license_time' => 4102444800, // 2099 年
];

这四个目标覆盖校验、比对、取数与逻辑层：get_license_info 是总裁决，compareLicense 负责比对，get_license_data 提供数据，LicenseLogic 是业务逻辑封装。返回值固定后，后续代码无论以何种路径调用，得到的都是同一份本地授权。

第三步，用 auto_prepend 做命名空间级注入。 auto_prepend_file 在每个 PHP 请求执行应用代码之前先加载指定文件，stub 先于任何控制器实例化就位。授权函数分散在 app\controller、app\middleware、app\logic、app\model、app\command 五个命名空间中；PHP 的未限定函数调用优先命中当前命名空间，例如 app\controller 中的代码调用 get_license_info()，会先查找 app\controller\get_license_info。在对应命名空间注入同名覆盖函数后，各处的授权调用统一落到 stub，无需逐文件改写业务逻辑，升级时只需维护这一份覆盖文件。

不直接改文件的原因：解码后的 app 文件众多，逐文件修改工作量大，面板升级会整体覆盖文件，改动会被冲掉。auto_prepend 方案把改动收敛到一个入口文件，升级后只需确认该覆盖文件仍存在，维护成本更低。

第四步，断网授权。 在 /etc/hosts 中把 license.soft13.idcsmart.com 和 my.idcsmart.com 指向 127.0.0.1，让可能的外联请求直接落回本机。断网授权与 stub 相互配合：stub 保证返回值，hosts 保证外联路径可控。

第五步，禁用 .so。 将 /etc/php.d/40-idcsmart.ini 改名为 .disabled，PHP 不再加载 crack .so，二进制 hook 被移除。

与 crack .so 的「替换公钥 + 断网」相比，该方案的信任锚点为自写的 stub 与 hosts 配置，行为可读、可审计、可回滚；不引入未知二进制，不伪造第三方签名。离线包不包含任何 crack .so。

整个修复未改动授权算法本身，仅将校验入口替换为本地可控实现，并将外联域名固定到本机，对系统其他部分的影响降至最低。

五、结果：一张 2099 年的通行证

修复后逐项验证：

• 登录接口返回 201；
• /v1/clouds 从 7-11 秒降到 0.18-0.21 秒 / 200；
• /v1/authorize_info 返回 200：max_node=9999、各模块 9999、状态 Active、到期时间 2099 年；
• 前端每 5 秒轮询 authorize_info 产生的 400 弹窗源消除。

将授权状态固定为可预期的本地值，相当于为这套自维护系统签发了一张长期有效的本地通行证；目的不是欺骗第三方，而是让系统行为可预期、可维护。

从数字上看，0.18-0.21 秒表明授权层的延迟完全消失，接口回到纯业务耗时区间；/v1/authorize_info 返回 200 后，前端轮询不再产生弹窗。

工程上还有一些与授权无关的坑：面板重装过，admin 路径与数据库密码均已变化，手工恢复容易在路径和口令上出错。最终将这些整理为一个 2.9MB、249 文件的一键离线包：解码后的 app + 解码后的 index.php + DB 备份 + deploy.sh + upload_and_deploy.py + README。deploy.sh 负责落地部署，upload_and_deploy.py 负责上传与执行，README 记录步骤与注意事项。新环境按 README 执行即可恢复，无需重复上述手工步骤。

复盘要点

• 授权失败时的惩罚性 sleep() 是常见的「软破坏」：系统不报错，只变慢。性能问题排查不应局限于 IO/DB，先检查中间件与授权层。
• hook 类 crack 不可控：二进制层面替换公钥与断网有效，副作用无法审计。纯代码 stub + hosts 断网更干净、更可维护。
• 逆向的价值不在于拿到某个密钥，而在于把「加密黑盒」还原为「数据流 + 常量 + 流程」：看清数据如何流动、哪些函数在裁决、哪些常量是锚点，修复方案随之浮现。