Typecho 主题 Handsome 正版用户被迫用上盗版了，为什么会有拉爆 CPU 负载的授权机制
忍一时风平浪静，退一步越想越气。
原则上我一直都是支持正版的，也愿意为了开发者的辛勤劳动花点钱，我觉得是他们应该得到的。
前几天发现服务器 CPU 和负载异常飙升，经排查排除了外部攻击的可能，定位问题根源在于 Handsome 主题的 CoreInterface.php 文件。
该文件采用商业加密混淆方案 DyEncrypt，通过多层 eval() 动态执行加密代码，其授权验证机制因服务器网络连通性或防篡改校验问题陷入死循环，导致单次请求执行成本畸高，4 核 CPU 瞬间满载。
尝试更换多个 PHP 版本、确认扩展安装、联系主题作者均未获解决。主要是作者很久没有登过 QQ 的感觉。
授权掉了之类的都能理解，但是把负载和 CPU 都拉满是什么机制，关键我也是正版用户啊。
我在网上找了很多资料，说这个主题到处都是授权连接远程服务器的钩子。虽然我相信作者不会干坏事，但是属实有点用力过猛了。
我给作者发的信息是 AI 帮我整理的，有大佬帮我看看也行：
### 问题标题
正版 Handsome 主题在访问时导致 PHP 陷入死循环、CPU 4 核瞬间 100% 满载
### 环境信息
- 系统环境：Debian / 宝塔面板
- 博客程序：Typecho1.2.1
- PHP 版本：已测试 PHP 7.4 、8.0 、8.2 （目前稳定在 PHP 7.4）
- 已开启扩展：curl, mbstring （ Opcache 未安装）
### 故障现象
只要启用 Handsome 主题并访问网站，服务器 CPU 就会瞬间飙升至 100%，系统负载（Load Average）极高。通过重命名主题目录可以立刻恢复正常，确定是主题代码引发的死循环。
### PHP 慢日志（Slow Log）关键堆栈信息
script_filename = /www/wwwroot/[www.52txr.cn/index.php](http://www.52txr.cn/index.php)
[0x00007f01a4e37b50] [INCLUDE_OR_EVAL] /www/wwwroot/[www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php:19](http://www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php:19)
[0x00007f01a3d60020] [INCLUDE_OR_EVAL] /www/wwwroot/[www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php(1197)](http://www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php(1197)) : eval()'d code:1
...
[0x00007f01a4e4f450] [INCLUDE_OR_EVAL] /www/wwwroot/[www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php(1029)](http://www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php(1029)) : eval()'d code:1029
...
[0x00007f01a3d37b30] () /www/wwwroot/[www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php:18](http://www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php:18)
### 已尝试的排查步骤
- 测试服务器外网及 curl 连通性（curl -I [https://www.baidu.com/](https://www.baidu.com) 返回 200 OK ，外网请求正常）。
- 将 PHP 版本从 8.2 / 8.0 降级至 7.4，并重新确认安装了 curl 和 mbstring 扩展，但问题依旧。
- 重新打包上传了解密/加密核心文件覆盖，但只要访问前台就会触发 CoreInterface.php 中的高频 eval() 循环卡死。
### 诉求
怀疑是授权验证机制或解密引擎在当前环境下陷入了死锁，请问是否有针对此现象的排查建议或修复补丁？
---
原文链接：[点击查看](https://www.v2ex.com/t/1231293)
原则上我一直都是支持正版的，也愿意为了开发者的辛勤劳动花点钱，我觉得是他们应该得到的。
前几天发现服务器 CPU 和负载异常飙升，经排查排除了外部攻击的可能，定位问题根源在于 Handsome 主题的 CoreInterface.php 文件。
该文件采用商业加密混淆方案 DyEncrypt，通过多层 eval() 动态执行加密代码，其授权验证机制因服务器网络连通性或防篡改校验问题陷入死循环，导致单次请求执行成本畸高，4 核 CPU 瞬间满载。
尝试更换多个 PHP 版本、确认扩展安装、联系主题作者均未获解决。主要是作者很久没有登过 QQ 的感觉。
授权掉了之类的都能理解，但是把负载和 CPU 都拉满是什么机制，关键我也是正版用户啊。
我在网上找了很多资料，说这个主题到处都是授权连接远程服务器的钩子。虽然我相信作者不会干坏事，但是属实有点用力过猛了。
我给作者发的信息是 AI 帮我整理的，有大佬帮我看看也行：
### 问题标题
正版 Handsome 主题在访问时导致 PHP 陷入死循环、CPU 4 核瞬间 100% 满载
### 环境信息
- 系统环境：Debian / 宝塔面板
- 博客程序：Typecho1.2.1
- PHP 版本：已测试 PHP 7.4 、8.0 、8.2 （目前稳定在 PHP 7.4）
- 已开启扩展：curl, mbstring （ Opcache 未安装）
### 故障现象
只要启用 Handsome 主题并访问网站，服务器 CPU 就会瞬间飙升至 100%，系统负载（Load Average）极高。通过重命名主题目录可以立刻恢复正常，确定是主题代码引发的死循环。
### PHP 慢日志（Slow Log）关键堆栈信息
script_filename = /www/wwwroot/[www.52txr.cn/index.php](http://www.52txr.cn/index.php)
[0x00007f01a4e37b50] [INCLUDE_OR_EVAL] /www/wwwroot/[www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php:19](http://www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php:19)
[0x00007f01a3d60020] [INCLUDE_OR_EVAL] /www/wwwroot/[www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php(1197)](http://www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php(1197)) : eval()'d code:1
...
[0x00007f01a4e4f450] [INCLUDE_OR_EVAL] /www/wwwroot/[www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php(1029)](http://www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php(1029)) : eval()'d code:1029
...
[0x00007f01a3d37b30] () /www/wwwroot/[www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php:18](http://www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php:18)
### 已尝试的排查步骤
- 测试服务器外网及 curl 连通性（curl -I [https://www.baidu.com/](https://www.baidu.com) 返回 200 OK ，外网请求正常）。
- 将 PHP 版本从 8.2 / 8.0 降级至 7.4，并重新确认安装了 curl 和 mbstring 扩展，但问题依旧。
- 重新打包上传了解密/加密核心文件覆盖，但只要访问前台就会触发 CoreInterface.php 中的高频 eval() 循环卡死。
### 诉求
怀疑是授权验证机制或解密引擎在当前环境下陷入了死锁，请问是否有针对此现象的排查建议或修复补丁？
---
原文链接：[点击查看](https://www.v2ex.com/t/1231293)
· 0 个赞