简介面向PHP开发人员与安全分析人员的代码解密工具集合内含黑刀dezender5、Dezender及DeZend_Tool三款工具可处理Base64、gzcompress、eval混淆及Zend Guard等多种常见加密方式帮助还原可读源码适用于代码审计、二次开发或加密逻辑分析场景。压缩包共144个文件大小11.25MB以PHP源码文件108个与DLL依赖库13个为主并包含EXE可执行程序、INI配置文件及TXT说明文档等附带的安装前必看.txt帮助完成环境配置。已有2582人学习下载。通过三款工具相互补充可应对不同加密类型快速定位加密入口、对比解密前后差异并借助批量处理能力提升调试效率是应对PHP加密代码的实用工具组合。1. 3款PHP代码解密工具拿到加密源码别急着删先分清它是哪一种壳从客户服务器里拖回来的 PHP 源码打开全是eval(gzinflate(base64_decode(...)))改一个字都报错网上下载的模板安装到一半弹出“未授权”日志里却不知道它在校验什么。这些场景都用得上 PHP 代码解密工具但多数人第一次用时都吃过亏拿一个神器挨个去解 ionCube、SourceGuardian 加密的文件结果越解越乱。这篇文章按三类最常见的加密形态讲清楚哪种壳能还原、哪种壳只能换环境跑、以及在批量解密、排错时容易翻车的细节。适合买来源码要二次开发的开发者、做应急响应的安全工程师以及正在搭建自己的解密小工具箱的人。2. 先认清加密类型eval 压缩壳、变量混淆和商业加壳的分水岭2.1 三类常见加密的识别指纹拿到一个陌生 PHP 文件先别急着上工具。我一般会先看文件开头的 200 个字节很多加密特征其实一眼就能认出来。第一类是 eval 压缩壳特征非常直白文件里能找到eval(gzinflate(base64_decode(一串很长的密文)))有时候外面还会再包str_rot13或str_replace但核心逻辑都是先解压再执行这类代码在“域名授权系统网站源码”和“网络验证系统 PHP 源码”里出现率极高因为授权校验代码不想让别人看懂。第二类是变量函数混淆特征是不直接写函数名而是把函数名装进$_COOKIE、$_REQUEST、$GLOBALS里运行到那一行才拼接出来。比如把base64_decode写成$f $_COOKIE[k]; $f($code);静态扫一眼全是乱码但用 xdebug 单步跟一下行为并不难还原。第三类是商业加密ionCube、SourceGuardian、Zend Guard 这一类打开文件看到的是二进制或带明文字符串的壳源代码被编译成中间格式工具解不开只能靠官方 Loader 在运行时还原。这里有个新手最容易踩的认知误区解密工具不是“一把万能钥匙”它解决的是第一类和第二类第三类只能保证代码能跑起来改不了源码。分清这三类之后后面的选型才有意义。2.2 用 grep 与 file 命令先过一遍识别不靠猜命令行三件套就能完成。在项目根目录执行一次全局搜索能把 eval 压缩壳直接筛出来find . -name *.php -exec grep -lE eval[[:space:]]*\(|gzinflate|base64_decode {} \;解释一下参数-exec grep -lE是对每个命中的 PHP 文件执行一次正则搜索-l只输出文件名不给匹配行[[:space:]]*表示允许 eval 和括号之间有空格或换行很多混淆代码会用换行拆开函数调用这一步能被顺手揪出来。如果文件数量大可以加-maxdepth 3限制深度避免把 vender 目录里的源码也扫出来。接下来用file判断是否二进制格式。命令行执行file path/to/file.php输出里带PHP script说明壳是 PHP 层的带data或binary说明是商业加密产物。再补一句head -c 200 file.php | strings能直接看到头部有没有ionCube、SourceGuardian这类明文标识。按我的习惯这三步做完基本就能定案不用再瞎试工具。2.3 解密边界能还原到源码还是只能保证运行先把边界画出来后面才不至于白忙。下表列的是三类加密的落地路径加密类型能不能还原源码落地方式适合人群eval/gzinflate 压缩壳能直接剥壳解密后得到可读 PHP二次开发、找授权逻辑变量函数混淆能但需要人工跟逐步还原关键调用安全分析、排错ionCube/SourceGuardian不能还原安装匹配 Loader运行时转译部署、迁移服务器前面两类解密工具能帮你把壳剥掉但剥完之后代码里可能还有授权校验、时间锁、域名校验这些业务逻辑那是另外一回事。商业加密则是另一个维度我曾经在客户那遇到过拿 Zend Guard 加密的旧项目换到新服务器后整站 500最后不是解密而是找到对应 PHP 版本的 Loader 才跑起来。这个边界想清楚了就不会折腾一晚上去解一个压根解不开的文件也不会把能解开的文件误判成“工具不行”。3. 用 3 款工具逐个击破最小解密脚本与运行方案3.1 工具Aeval/gzinflate 解包的最小 PHP 脚本eval 压缩壳占所有“PHP代码解密工具”使用场景的一半以上先写一个能直接上手的命令行脚本。新建unpack_eval.php内容如下?php // unpack_eval.php 工具A剥离 eval(gzinflate(base64_decode(...))) 单层或多层壳 if ($argc 2) { fwrite(STDERR, 用法: php unpack_eval.php 待解密文件 [输出文件]\n); exit(1); } $src file_get_contents($argv[1]); if ($src false) { fwrite(STDERR, 读取失败: {$argv[1]}\n); exit(1); } $count 0; // 同一份文件里可能套了多层最多剥 5 层防止死循环 for ($i 0; $i 5; $i) { if (!preg_match(/eval\s*\(\s*gzinflate\s*\(\s*base64_decode\s*\(\s*([^])/, $src, $m)) { break; } $payload gzinflate(base64_decode($m[1])); if ($payload false) { fwrite(STDERR, 第 . ($i 1) . 层 gzinflate 解压失败密文可能被二次修改\n); exit(1); } $src str_replace($m[0], $payload, $src); $count; } $outFile $argv[2] ?? preg_replace(/\.php$/, .dec.php, $argv[1]); file_put_contents($outFile, $src); echo 完成: 剥离 {$count} 层, 输出 {$outFile}\n;代码逻辑不复杂先正则匹配出eval(gzinflate(base64_decode(密文)))整段然后base64_decode解出字节流再用gzinflate解压最后用str_replace把最外层的加密调用替换成解出来的明文。循环最多执行五次是因为部分文件会一层套一层比如先压缩一次再把结果压缩一次。三个参数值得细说。第一个是正则里的([^])它只吃单引号包裹的密文如果你手上的文件用的是双引号或 heredoc 写法要改成([^])这是最常遇到的适配点。第二个是gzinflate前的错误抑制符解密时有大几率遇到 PHP 7 以上版本对gzinflate的告警加不加不影响结果但不加会把终端刷屏。第三个是循环上限 5设大了没有必要设小了遇到五层以上的套壳只能手动跑第二遍。解密完成后用php -l dec.php验语法能过就说明这层壳剥干净了。3.2 工具Bstr_replace/base64 变种混淆的还原脚本eval 壳遇到强化版本就变了密文不是直接给 base64而是先经过str_replace做字符替换常见手法是把换成_把a换成b解压前要先还原这些替换才能得到合法的 base64。这类混淆在“卡密生成”“充值接口”相关的源码里非常常见工具A直接套上去会报 gzinflate 失败。新建restore_mixed.php?php // restore_mixed.php 工具B处理 str_replace base64 eval 混用混淆 if ($argc 2) { fwrite(STDERR, 用法: php restore_mixed.php 待还原文件 [输出文件]\n); exit(1); } $code file_get_contents($argv[1]); if ($code false) { fwrite(STDERR, 读取失败: {$argv[1]}\n); exit(1); } // 特征1: eval(gzinflate(base64_decode(str_replace(_,,...)))) $pattern /eval\s*\(\s*gzinflate\s*\(\s*base64_decode\s*\(\s*str_replace\s*\(\s*([^]*)\s*,\s*([^]*)\s*,\s*([^]*)\s*\)\s*\)\s*\)/; while (preg_match($pattern, $code, $m)) { $clean str_replace($m[1], $m[2], $m[3]); $decoded gzinflate(base64_decode($clean)); if ($decoded false) { break; } $code str_replace($m[0], $decoded, $code); } // 特征2: 纯 base64 eval无压缩 $pattern2 /eval\s*\(\s*base64_decode\s*\(\s*([^])\s*\)\s*\)/; while (preg_match($pattern2, $code, $m)) { $decoded base64_decode($m[1]); $code str_replace($m[0], $decoded, $code); } $out $argv[2] ?? preg_replace(/\.php$/, .restored.php, $argv[1]); file_put_contents($out, $code); echo 还原完成: {$out}\n;逻辑说明第一个正则捕获str_replace的三个参数分别是待替换字符、替换目标、密文原文str_replace($m[1], $m[2], $m[3])按混淆反方向还原再走一遍 base64 和 gzinflate。第二个正则处理没有压缩的纯 base64 变体因为有些壳只做编码不做压缩。这里要注意参数顺序str_replace(_,,密文)意思就是把密文里的全部下划线换回等号脚本里第一个参数必须是混淆后的字符第二个必须是原字符。很多新手在这一步搞反解出来的字节流直接是坏的。另外这个脚本故意没用preg_replace做替换因为解码出来的明文本身可能包含正则替换的特殊字符用str_replace做整串替换最稳。解密完成后同样用php -l验证如果语法还错说明壳外面还有一层str_rot13或变量函数调用的包装再往下就要结合 3.1 和人工跟堆栈了。3.3 工具C商业加密ionCube/SourceGuardian的运行时兼容方案前面说清楚了ionCube 这类壳解不开但也不是放任不管。实际场景里项目换服务器、phpStudy 升级 PHP 版本之后整站报错最常见的原因不是代码坏了而是 Loader 没装对。安装 Loader 本身不算解密它是让加密后的代码能在当前 PHP 环境正常运行的官方组件并且官方免费提供。这里给你一个快速检测脚本check_loader.php?php // check_loader.php 工具C检测当前 PHP 环境能否运行商业加密代码 phpinfo(INFO_MODULES);在命令行执行php -c /path/to/php.ini check_loader.php | grep -i -E ioncube|sourceguardian|zend能看到 Loader 的版本、路径和许可证状态。如果没有输出说明扩展没装phpinfo 页面上直接搜ionCube PHP Loader也行。确认缺了之后按 PHP 版本号、线程安全还是非线程安全两项下载对应扩展放进ext目录并在php.ini里加zend_extension /path/to/ioncube_loader_lin_版本号.so。注意是zend_extension不是普通extensionOrder 在前在后也有讲究一般放在[PHP]段落末尾即可。这个方案解决的是“解密之后跑不起来”的最后一公里。商业加壳代码只要 Loader 版本匹配安装过程不出错运行效率和原生 PHP 几乎一致。别被网上那些宣称能还原 ionCube 源码的商业工具带偏这类工具大多只能做运行时转储拿到的东西远比直接换环境跑复杂得多而且大概率违反授权协议。代码能用、能迁移、能维护接口就已经完成了这类项目的落地目标。4. 批量解密与参数设置别让单文件操作毁掉整个周末4.1 解密前的文件快照与目录规划只解一两个文件时前面两个脚本足够。可现实是要解密整个项目十几个目录、几百个 PHP 文件直接上手批量处理前必须做的一件事备份。不是简单复制一份而是带时间戳打成一个压缩包便于后面随时回滚。find /data/www -maxdepth 3 -name *.php | tar czf source_backup_$(date %Y%m%d_%H%M%S).tar.gz -T -参数说明-maxdepth 3限制深度防止把备份目录自身也扫进去无限递归$(date %Y%m%d_%H%M%S)生成时间戳这样一周内多次操作也能区分版本。备份包建议放在项目目录之外比如/data/backup避免解密脚本把备份包里的文件也当成目标处理。这一步花不到一分钟却是整个批量操作里最大的后悔药。4.2 批量扫描目录深度、白名单与锁定文件批量处理有一个隐藏陷阱工具A在解壳时会生成.dec.php文件如果输出目录还在项目根目录里下一轮扫描就会把刚生成的解密文件再次当作输入正则匹配失败后跳过但白白浪费大量时间。更稳妥的做法是单独建一个decoded输出目录并且跳过vendor、node_modules、storage这些不该动的目录。?php // batch_unpack.php 工具A批量模式用法: php batch_unpack.php 项目目录 [输出目录] [最大层数] $root $argv[1] ?? .; $outBase $argv[2] ?? decoded; $limit isset($argv[3]) ? (int)$argv[3] : 5; $skipDirs [vendor, node_modules, storage, decoded]; if (!is_dir($outBase)) { mkdir($outBase, 0755, true); } $it new RecursiveIteratorIterator( new RecursiveDirectoryIterator($root, FilesystemIterator::SKIP_DOTS) ); foreach ($it as $file) { if ($file-getExtension() ! php) { continue; } $rel str_replace($root, , $file-getPathname()); foreach ($skipDirs as $skip) { if (strpos($rel, / . $skip . /) ! false) { continue 2; } } $src file_get_contents($file-getPathname()); $changed false; for ($i 0; $i $limit; $i) { if (!preg_match(/eval\s*\(\s*gzinflate\s*\(\s*base64_decode\s*\(\s*([^])/, $src, $m)) { break; } $payload gzinflate(base64_decode($m[1])); if ($payload false) { break; } $src str_replace($m[0], $payload, $src); $changed true; } if ($changed) { $outFile $outBase . $rel; if (!is_dir(dirname($outFile))) { mkdir(dirname($outFile), 0755, true); } file_put_contents($outFile, $src); echo [OK] {$rel}\n; } }三个参数要按实际项目调整。第一个是$limit默认 5 层普通授权系统的壳通常只套两层5 足够如果你手头文件确认超过 5 层可以调到 10但不建议调到 20 以上因为多层嵌套解到头很可能遇到二进制内容继续解只会产出乱码。第二个是$skipDirs这个白名单必须跟项目结构对齐laravel 项目通常要加bootstrap、config因为有些框架文件本身就是可读的扫进去纯属浪费时间。第三个是输入输出目录分离我习惯输出到decoded目录处理完核对无误后再整体覆盖回去这个“先分离、后替换”的流程能避免大批量操作之后出现一半新一半旧的混乱状态。4.3 批量验证php -l 与安装流程合并批量解密完语法检查是最快的试金石。直接在命令行跑find decoded -name *.php -exec php -l {} \; | grep -v No syntax errorsphp -l的输出里没有语法错误的文件会打出一句No syntax errors detected用grep -v反向过滤就能把那些报错的文件单独列出来。看到报错不要急着改先看报错文件是不是本身就带加密特征比如还残留eval(那就说明该文件不是标准 eval 壳要回到工具B走人工分析如果报错是Parse error: syntax error大概率是解密结果里混入了非 PHP 内容需要打开文件看头部和尾部的残余数据。语法检查通过之后别立刻删原文件。把decoded目录里的文件整体拷回项目目录然后完整跑一遍安装向导或登录接口。这一步能暴露语法检查看不出的问题例如某些加密壳运行时会向$_SERVER注入自定义项解密后注入逻辑没了某些功能就不再工作还有的文件带上额外的空格和换行虽然不报语法错但会在 session 输出时产生已在发送 header 的告警。所以我的习惯是解密后至少跑三条链路首页、登录、一个写库操作。5. 避坑解密后 500、乱码、Loader 失效的 5 个常见问题5.1 解密后 PHP 直接 500错误日志却干干净净现象复制 .dec.php 覆盖原文件后整个站点 500打开 PHP error log 却只有一行空白。原因大概率不是解密代码本身错了而是文件头部带了 BOM 或者解密前的代码里有exit;提前退出。常见触发场景是用编辑器批量替换的时候把 BOM 也带过去PHP 解析器把 BOM 当作输出内容再遇到 header 发送就会报“headers already sent”但错误级别不高时日志里看不到。解决先用php -l对单个文件验语法再用sed -i 1s/^\xEF\xBB\xBF// decoded/*.php去掉 BOM。如果还是 500把display_errors On临时打开重新请求一次这次能看到具体报错行。另外提一句做应急响应分析别人丢进来的混淆样本时也可以先用 PHP 的伪协议配合文件包含场景把源码读出来再走上述流程原理一样只是入口不同。5.2 解密出来的中文全变乱码其实是编码不是加密现象解出来的 PHP 文件代码里所有中文字符串变成“锟斤拷”风格的乱码英文和语法完全正常。原因原文件是 GBK 编码你解密时用 UTF-8 的脚本处理并输出编码不一致导致。这和加密完全无关。解决先确认原始文件编码再转换。命令行直接执行file original.php iconv -f GBK -t UTF-8 original.php decoded.phpfile输出会显示ISO-8859或GBKiconv按对应编码转换成 UTF-8。转换完再跑一次语法检查。注意如果原始文件是 GBK 且牵扯到数据库连接转换编码之后还要核对数据库连接配置里的charset否则页面上中文正常但入库全空那是另一个常见翻车点。5.3 嵌套壳解不干净eval 还在文件里现象工具A跑完提示完成打开输出文件还能搜到eval(或base64_decode(。原因这个文件的壳不是单向压缩而是先base64编码再当字符串拼进另一段代码里工具A的正则只匹配gzinflate(base64_decode(...))匹配不到就跳过了。另一个原因是循环上限设为 1只剥了一层。解决把$limit调大到 10 再跑一遍如果还剩 eval就把文件里残留的那段手工复制出来单独用base64_decode解一下看内容形态。很多“用户管理机制”或者“接口数组对象”相关的加密代码外层解完后里面还有一层变量函数调用比如$_COOKIE[x]($str)这种就回到工具B的思路上先把变量函数还原成字面函数名再走批量解密。5.4 用 phpStudy 升级 PHP 版本后 Loader 失效现象整站迁移后安装一切正常但访问时直接输出 “Site error: the ionCube PHP Loader needs to be installed”。原因商业加密代码在编译时绑定了特定 PHP 版本用 phpStudy 升级 PHP 版本后原网站目录下的 Loader 扩展还是旧版或者根本没装新版对应的扩展。这类问题不在解密脚本的处理范围内但它是“解密后跑不起来”的最高频原因之一。解决确认当前 PHP 版本和线程安全性。命令行执行php -v和php -i | grep Thread Safety输出enabled就找 TS 版本disabled就找 NTS 版本然后到 ionCube 官方下载对应版本扩展放到 phpStudy 当前 PHP 版本的ext目录最后在php.ini里追加zend_extension配置项并重启。注意 PHP 8.0 以上已经移除了不少旧版扩展如果你的加密文件是老项目最稳妥的不是硬上高版本 PHP而是保持与原编译环境一致的版本。5.5 主机安全软件把解密脚本当后门直接删除现象批量解密脚本运行到一半被中断查看目录发现unpack_eval.php不见了或者decoded目录里刚生成的文件消失了。原因安全软件检测到脚本里包含eval(、base64_decode(、gzinflate这些特征直接判定为后门或一句话木马并查杀。这个坑在 Windows 本地环境尤其常见云服务器和主机面板上也时有发生。解决把解密工具放在项目目录之外的独立文件夹里运行用php unpack_eval.php /data/www/test.php /tmp/decoded.php这种方式指定输入输出路径给临时生成的解密结果加上.txt后缀确认内容无误后再改回.php。我在一次处理“php 验证码识别”相关组件时也遇到过这种误杀后来把工具脚本压缩成 zip 再解压到临时目录还是被查杀最后直接改用php -d disable_functionsexec,system参数运行避免工具本身被内嵌的恶意代码二次利用才算顺利跑完。处理完记得删除临时文件夹别让一堆带有恶意特征的文件留在服务器上。6. 解密之后的验证与收尾把工具沉淀成自己的检测清单6.1 用 error_reporting(E_ALL) 重跑完整流程解密代码能打开只是第一步跑通完整流程才算真的能用。我会在入口文件上加一个临时配置?php ini_set(display_errors, 1); error_reporting(E_ALL);然后重跑一遍安装向导、登录接口和一个写库操作重点观察三项有没有 Deprecated 级别的告警、有没有 header 发送时序问题、解密后的业务逻辑和原来是否一致。如果解密前是加密状态时功能正常解密后功能异常优先看被剥掉的壳代码里是不是还藏着不可见的检查逻辑而不是急着改业务代码。最后一件事给这个项目建一个decrypt_notes.md记录哪些文件用了哪个工具、解了几层、有没有残留 eval。这个习惯是我吃过几次亏才养成的——整套代码解完没记录过两个月回来看发现有个文件还在跑旧逻辑找半天才发现是当初漏了解一个子目录。工具有边界人的记性也有边界留一份解密清单比重复排查省太多时间。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/13 17:21:45 · 阅读 1.2k PHP代码解密工具实战：三类加密识别与批量解密指南
简介面向PHP开发人员与安全分析人员的代码解密工具集合内含黑刀dezender5、Dezender及DeZend_Tool三款工具可处理Base64、gzcompress、eval混淆及Zend Guard等多种常见加密方式帮助还原可读源码适用于代码审计、二次开发或加密逻辑分析场景。压缩包共144个文件大小11.25MB以PHP源码文件108个与DLL依赖库13个为主并包含EXE可执行程序、INI配置文件及TXT说明文档等附带的安装前必看.txt帮助完成环境配置。已有2582人学习下载。通过三款工具相互补充可应对不同加密类型快速定位加密入口、对比解密前后差异并借助批量处理能力提升调试效率是应对PHP加密代码的实用工具组合。1. 3款PHP代码解密工具拿到加密源码别急着删先分清它是哪一种壳从客户服务器里拖回来的 PHP 源码打开全是eval(gzinflate(base64_decode(...)))改一个字都报错网上下载的模板安装到一半弹出“未授权”日志里却不知道它在校验什么。这些场景都用得上 PHP 代码解密工具但多数人第一次用时都吃过亏拿一个神器挨个去解 ionCube、SourceGuardian 加密的文件结果越解越乱。这篇文章按三类最常见的加密形态讲清楚哪种壳能还原、哪种壳只能换环境跑、以及在批量解密、排错时容易翻车的细节。适合买来源码要二次开发的开发者、做应急响应的安全工程师以及正在搭建自己的解密小工具箱的人。2. 先认清加密类型eval 压缩壳、变量混淆和商业加壳的分水岭2.1 三类常见加密的识别指纹拿到一个陌生 PHP 文件先别急着上工具。我一般会先看文件开头的 200 个字节很多加密特征其实一眼就能认出来。第一类是 eval 压缩壳特征非常直白文件里能找到eval(gzinflate(base64_decode(一串很长的密文)))有时候外面还会再包str_rot13或str_replace但核心逻辑都是先解压再执行这类代码在“域名授权系统网站源码”和“网络验证系统 PHP 源码”里出现率极高因为授权校验代码不想让别人看懂。第二类是变量函数混淆特征是不直接写函数名而是把函数名装进$_COOKIE、$_REQUEST、$GLOBALS里运行到那一行才拼接出来。比如把base64_decode写成$f $_COOKIE[k]; $f($code);静态扫一眼全是乱码但用 xdebug 单步跟一下行为并不难还原。第三类是商业加密ionCube、SourceGuardian、Zend Guard 这一类打开文件看到的是二进制或带明文字符串的壳源代码被编译成中间格式工具解不开只能靠官方 Loader 在运行时还原。这里有个新手最容易踩的认知误区解密工具不是“一把万能钥匙”它解决的是第一类和第二类第三类只能保证代码能跑起来改不了源码。分清这三类之后后面的选型才有意义。2.2 用 grep 与 file 命令先过一遍识别不靠猜命令行三件套就能完成。在项目根目录执行一次全局搜索能把 eval 压缩壳直接筛出来find . -name *.php -exec grep -lE eval[[:space:]]*\(|gzinflate|base64_decode {} \;解释一下参数-exec grep -lE是对每个命中的 PHP 文件执行一次正则搜索-l只输出文件名不给匹配行[[:space:]]*表示允许 eval 和括号之间有空格或换行很多混淆代码会用换行拆开函数调用这一步能被顺手揪出来。如果文件数量大可以加-maxdepth 3限制深度避免把 vender 目录里的源码也扫出来。接下来用file判断是否二进制格式。命令行执行file path/to/file.php输出里带PHP script说明壳是 PHP 层的带data或binary说明是商业加密产物。再补一句head -c 200 file.php | strings能直接看到头部有没有ionCube、SourceGuardian这类明文标识。按我的习惯这三步做完基本就能定案不用再瞎试工具。2.3 解密边界能还原到源码还是只能保证运行先把边界画出来后面才不至于白忙。下表列的是三类加密的落地路径加密类型能不能还原源码落地方式适合人群eval/gzinflate 压缩壳能直接剥壳解密后得到可读 PHP二次开发、找授权逻辑变量函数混淆能但需要人工跟逐步还原关键调用安全分析、排错ionCube/SourceGuardian不能还原安装匹配 Loader运行时转译部署、迁移服务器前面两类解密工具能帮你把壳剥掉但剥完之后代码里可能还有授权校验、时间锁、域名校验这些业务逻辑那是另外一回事。商业加密则是另一个维度我曾经在客户那遇到过拿 Zend Guard 加密的旧项目换到新服务器后整站 500最后不是解密而是找到对应 PHP 版本的 Loader 才跑起来。这个边界想清楚了就不会折腾一晚上去解一个压根解不开的文件也不会把能解开的文件误判成“工具不行”。3. 用 3 款工具逐个击破最小解密脚本与运行方案3.1 工具Aeval/gzinflate 解包的最小 PHP 脚本eval 压缩壳占所有“PHP代码解密工具”使用场景的一半以上先写一个能直接上手的命令行脚本。新建unpack_eval.php内容如下?php // unpack_eval.php 工具A剥离 eval(gzinflate(base64_decode(...))) 单层或多层壳 if ($argc 2) { fwrite(STDERR, 用法: php unpack_eval.php 待解密文件 [输出文件]\n); exit(1); } $src file_get_contents($argv[1]); if ($src false) { fwrite(STDERR, 读取失败: {$argv[1]}\n); exit(1); } $count 0; // 同一份文件里可能套了多层最多剥 5 层防止死循环 for ($i 0; $i 5; $i) { if (!preg_match(/eval\s*\(\s*gzinflate\s*\(\s*base64_decode\s*\(\s*([^])/, $src, $m)) { break; } $payload gzinflate(base64_decode($m[1])); if ($payload false) { fwrite(STDERR, 第 . ($i 1) . 层 gzinflate 解压失败密文可能被二次修改\n); exit(1); } $src str_replace($m[0], $payload, $src); $count; } $outFile $argv[2] ?? preg_replace(/\.php$/, .dec.php, $argv[1]); file_put_contents($outFile, $src); echo 完成: 剥离 {$count} 层, 输出 {$outFile}\n;代码逻辑不复杂先正则匹配出eval(gzinflate(base64_decode(密文)))整段然后base64_decode解出字节流再用gzinflate解压最后用str_replace把最外层的加密调用替换成解出来的明文。循环最多执行五次是因为部分文件会一层套一层比如先压缩一次再把结果压缩一次。三个参数值得细说。第一个是正则里的([^])它只吃单引号包裹的密文如果你手上的文件用的是双引号或 heredoc 写法要改成([^])这是最常遇到的适配点。第二个是gzinflate前的错误抑制符解密时有大几率遇到 PHP 7 以上版本对gzinflate的告警加不加不影响结果但不加会把终端刷屏。第三个是循环上限 5设大了没有必要设小了遇到五层以上的套壳只能手动跑第二遍。解密完成后用php -l dec.php验语法能过就说明这层壳剥干净了。3.2 工具Bstr_replace/base64 变种混淆的还原脚本eval 壳遇到强化版本就变了密文不是直接给 base64而是先经过str_replace做字符替换常见手法是把换成_把a换成b解压前要先还原这些替换才能得到合法的 base64。这类混淆在“卡密生成”“充值接口”相关的源码里非常常见工具A直接套上去会报 gzinflate 失败。新建restore_mixed.php?php // restore_mixed.php 工具B处理 str_replace base64 eval 混用混淆 if ($argc 2) { fwrite(STDERR, 用法: php restore_mixed.php 待还原文件 [输出文件]\n); exit(1); } $code file_get_contents($argv[1]); if ($code false) { fwrite(STDERR, 读取失败: {$argv[1]}\n); exit(1); } // 特征1: eval(gzinflate(base64_decode(str_replace(_,,...)))) $pattern /eval\s*\(\s*gzinflate\s*\(\s*base64_decode\s*\(\s*str_replace\s*\(\s*([^]*)\s*,\s*([^]*)\s*,\s*([^]*)\s*\)\s*\)\s*\)/; while (preg_match($pattern, $code, $m)) { $clean str_replace($m[1], $m[2], $m[3]); $decoded gzinflate(base64_decode($clean)); if ($decoded false) { break; } $code str_replace($m[0], $decoded, $code); } // 特征2: 纯 base64 eval无压缩 $pattern2 /eval\s*\(\s*base64_decode\s*\(\s*([^])\s*\)\s*\)/; while (preg_match($pattern2, $code, $m)) { $decoded base64_decode($m[1]); $code str_replace($m[0], $decoded, $code); } $out $argv[2] ?? preg_replace(/\.php$/, .restored.php, $argv[1]); file_put_contents($out, $code); echo 还原完成: {$out}\n;逻辑说明第一个正则捕获str_replace的三个参数分别是待替换字符、替换目标、密文原文str_replace($m[1], $m[2], $m[3])按混淆反方向还原再走一遍 base64 和 gzinflate。第二个正则处理没有压缩的纯 base64 变体因为有些壳只做编码不做压缩。这里要注意参数顺序str_replace(_,,密文)意思就是把密文里的全部下划线换回等号脚本里第一个参数必须是混淆后的字符第二个必须是原字符。很多新手在这一步搞反解出来的字节流直接是坏的。另外这个脚本故意没用preg_replace做替换因为解码出来的明文本身可能包含正则替换的特殊字符用str_replace做整串替换最稳。解密完成后同样用php -l验证如果语法还错说明壳外面还有一层str_rot13或变量函数调用的包装再往下就要结合 3.1 和人工跟堆栈了。3.3 工具C商业加密ionCube/SourceGuardian的运行时兼容方案前面说清楚了ionCube 这类壳解不开但也不是放任不管。实际场景里项目换服务器、phpStudy 升级 PHP 版本之后整站报错最常见的原因不是代码坏了而是 Loader 没装对。安装 Loader 本身不算解密它是让加密后的代码能在当前 PHP 环境正常运行的官方组件并且官方免费提供。这里给你一个快速检测脚本check_loader.php?php // check_loader.php 工具C检测当前 PHP 环境能否运行商业加密代码 phpinfo(INFO_MODULES);在命令行执行php -c /path/to/php.ini check_loader.php | grep -i -E ioncube|sourceguardian|zend能看到 Loader 的版本、路径和许可证状态。如果没有输出说明扩展没装phpinfo 页面上直接搜ionCube PHP Loader也行。确认缺了之后按 PHP 版本号、线程安全还是非线程安全两项下载对应扩展放进ext目录并在php.ini里加zend_extension /path/to/ioncube_loader_lin_版本号.so。注意是zend_extension不是普通extensionOrder 在前在后也有讲究一般放在[PHP]段落末尾即可。这个方案解决的是“解密之后跑不起来”的最后一公里。商业加壳代码只要 Loader 版本匹配安装过程不出错运行效率和原生 PHP 几乎一致。别被网上那些宣称能还原 ionCube 源码的商业工具带偏这类工具大多只能做运行时转储拿到的东西远比直接换环境跑复杂得多而且大概率违反授权协议。代码能用、能迁移、能维护接口就已经完成了这类项目的落地目标。4. 批量解密与参数设置别让单文件操作毁掉整个周末4.1 解密前的文件快照与目录规划只解一两个文件时前面两个脚本足够。可现实是要解密整个项目十几个目录、几百个 PHP 文件直接上手批量处理前必须做的一件事备份。不是简单复制一份而是带时间戳打成一个压缩包便于后面随时回滚。find /data/www -maxdepth 3 -name *.php | tar czf source_backup_$(date %Y%m%d_%H%M%S).tar.gz -T -参数说明-maxdepth 3限制深度防止把备份目录自身也扫进去无限递归$(date %Y%m%d_%H%M%S)生成时间戳这样一周内多次操作也能区分版本。备份包建议放在项目目录之外比如/data/backup避免解密脚本把备份包里的文件也当成目标处理。这一步花不到一分钟却是整个批量操作里最大的后悔药。4.2 批量扫描目录深度、白名单与锁定文件批量处理有一个隐藏陷阱工具A在解壳时会生成.dec.php文件如果输出目录还在项目根目录里下一轮扫描就会把刚生成的解密文件再次当作输入正则匹配失败后跳过但白白浪费大量时间。更稳妥的做法是单独建一个decoded输出目录并且跳过vendor、node_modules、storage这些不该动的目录。?php // batch_unpack.php 工具A批量模式用法: php batch_unpack.php 项目目录 [输出目录] [最大层数] $root $argv[1] ?? .; $outBase $argv[2] ?? decoded; $limit isset($argv[3]) ? (int)$argv[3] : 5; $skipDirs [vendor, node_modules, storage, decoded]; if (!is_dir($outBase)) { mkdir($outBase, 0755, true); } $it new RecursiveIteratorIterator( new RecursiveDirectoryIterator($root, FilesystemIterator::SKIP_DOTS) ); foreach ($it as $file) { if ($file-getExtension() ! php) { continue; } $rel str_replace($root, , $file-getPathname()); foreach ($skipDirs as $skip) { if (strpos($rel, / . $skip . /) ! false) { continue 2; } } $src file_get_contents($file-getPathname()); $changed false; for ($i 0; $i $limit; $i) { if (!preg_match(/eval\s*\(\s*gzinflate\s*\(\s*base64_decode\s*\(\s*([^])/, $src, $m)) { break; } $payload gzinflate(base64_decode($m[1])); if ($payload false) { break; } $src str_replace($m[0], $payload, $src); $changed true; } if ($changed) { $outFile $outBase . $rel; if (!is_dir(dirname($outFile))) { mkdir(dirname($outFile), 0755, true); } file_put_contents($outFile, $src); echo [OK] {$rel}\n; } }三个参数要按实际项目调整。第一个是$limit默认 5 层普通授权系统的壳通常只套两层5 足够如果你手头文件确认超过 5 层可以调到 10但不建议调到 20 以上因为多层嵌套解到头很可能遇到二进制内容继续解只会产出乱码。第二个是$skipDirs这个白名单必须跟项目结构对齐laravel 项目通常要加bootstrap、config因为有些框架文件本身就是可读的扫进去纯属浪费时间。第三个是输入输出目录分离我习惯输出到decoded目录处理完核对无误后再整体覆盖回去这个“先分离、后替换”的流程能避免大批量操作之后出现一半新一半旧的混乱状态。4.3 批量验证php -l 与安装流程合并批量解密完语法检查是最快的试金石。直接在命令行跑find decoded -name *.php -exec php -l {} \; | grep -v No syntax errorsphp -l的输出里没有语法错误的文件会打出一句No syntax errors detected用grep -v反向过滤就能把那些报错的文件单独列出来。看到报错不要急着改先看报错文件是不是本身就带加密特征比如还残留eval(那就说明该文件不是标准 eval 壳要回到工具B走人工分析如果报错是Parse error: syntax error大概率是解密结果里混入了非 PHP 内容需要打开文件看头部和尾部的残余数据。语法检查通过之后别立刻删原文件。把decoded目录里的文件整体拷回项目目录然后完整跑一遍安装向导或登录接口。这一步能暴露语法检查看不出的问题例如某些加密壳运行时会向$_SERVER注入自定义项解密后注入逻辑没了某些功能就不再工作还有的文件带上额外的空格和换行虽然不报语法错但会在 session 输出时产生已在发送 header 的告警。所以我的习惯是解密后至少跑三条链路首页、登录、一个写库操作。5. 避坑解密后 500、乱码、Loader 失效的 5 个常见问题5.1 解密后 PHP 直接 500错误日志却干干净净现象复制 .dec.php 覆盖原文件后整个站点 500打开 PHP error log 却只有一行空白。原因大概率不是解密代码本身错了而是文件头部带了 BOM 或者解密前的代码里有exit;提前退出。常见触发场景是用编辑器批量替换的时候把 BOM 也带过去PHP 解析器把 BOM 当作输出内容再遇到 header 发送就会报“headers already sent”但错误级别不高时日志里看不到。解决先用php -l对单个文件验语法再用sed -i 1s/^\xEF\xBB\xBF// decoded/*.php去掉 BOM。如果还是 500把display_errors On临时打开重新请求一次这次能看到具体报错行。另外提一句做应急响应分析别人丢进来的混淆样本时也可以先用 PHP 的伪协议配合文件包含场景把源码读出来再走上述流程原理一样只是入口不同。5.2 解密出来的中文全变乱码其实是编码不是加密现象解出来的 PHP 文件代码里所有中文字符串变成“锟斤拷”风格的乱码英文和语法完全正常。原因原文件是 GBK 编码你解密时用 UTF-8 的脚本处理并输出编码不一致导致。这和加密完全无关。解决先确认原始文件编码再转换。命令行直接执行file original.php iconv -f GBK -t UTF-8 original.php decoded.phpfile输出会显示ISO-8859或GBKiconv按对应编码转换成 UTF-8。转换完再跑一次语法检查。注意如果原始文件是 GBK 且牵扯到数据库连接转换编码之后还要核对数据库连接配置里的charset否则页面上中文正常但入库全空那是另一个常见翻车点。5.3 嵌套壳解不干净eval 还在文件里现象工具A跑完提示完成打开输出文件还能搜到eval(或base64_decode(。原因这个文件的壳不是单向压缩而是先base64编码再当字符串拼进另一段代码里工具A的正则只匹配gzinflate(base64_decode(...))匹配不到就跳过了。另一个原因是循环上限设为 1只剥了一层。解决把$limit调大到 10 再跑一遍如果还剩 eval就把文件里残留的那段手工复制出来单独用base64_decode解一下看内容形态。很多“用户管理机制”或者“接口数组对象”相关的加密代码外层解完后里面还有一层变量函数调用比如$_COOKIE[x]($str)这种就回到工具B的思路上先把变量函数还原成字面函数名再走批量解密。5.4 用 phpStudy 升级 PHP 版本后 Loader 失效现象整站迁移后安装一切正常但访问时直接输出 “Site error: the ionCube PHP Loader needs to be installed”。原因商业加密代码在编译时绑定了特定 PHP 版本用 phpStudy 升级 PHP 版本后原网站目录下的 Loader 扩展还是旧版或者根本没装新版对应的扩展。这类问题不在解密脚本的处理范围内但它是“解密后跑不起来”的最高频原因之一。解决确认当前 PHP 版本和线程安全性。命令行执行php -v和php -i | grep Thread Safety输出enabled就找 TS 版本disabled就找 NTS 版本然后到 ionCube 官方下载对应版本扩展放到 phpStudy 当前 PHP 版本的ext目录最后在php.ini里追加zend_extension配置项并重启。注意 PHP 8.0 以上已经移除了不少旧版扩展如果你的加密文件是老项目最稳妥的不是硬上高版本 PHP而是保持与原编译环境一致的版本。5.5 主机安全软件把解密脚本当后门直接删除现象批量解密脚本运行到一半被中断查看目录发现unpack_eval.php不见了或者decoded目录里刚生成的文件消失了。原因安全软件检测到脚本里包含eval(、base64_decode(、gzinflate这些特征直接判定为后门或一句话木马并查杀。这个坑在 Windows 本地环境尤其常见云服务器和主机面板上也时有发生。解决把解密工具放在项目目录之外的独立文件夹里运行用php unpack_eval.php /data/www/test.php /tmp/decoded.php这种方式指定输入输出路径给临时生成的解密结果加上.txt后缀确认内容无误后再改回.php。我在一次处理“php 验证码识别”相关组件时也遇到过这种误杀后来把工具脚本压缩成 zip 再解压到临时目录还是被查杀最后直接改用php -d disable_functionsexec,system参数运行避免工具本身被内嵌的恶意代码二次利用才算顺利跑完。处理完记得删除临时文件夹别让一堆带有恶意特征的文件留在服务器上。6. 解密之后的验证与收尾把工具沉淀成自己的检测清单6.1 用 error_reporting(E_ALL) 重跑完整流程解密代码能打开只是第一步跑通完整流程才算真的能用。我会在入口文件上加一个临时配置?php ini_set(display_errors, 1); error_reporting(E_ALL);然后重跑一遍安装向导、登录接口和一个写库操作重点观察三项有没有 Deprecated 级别的告警、有没有 header 发送时序问题、解密后的业务逻辑和原来是否一致。如果解密前是加密状态时功能正常解密后功能异常优先看被剥掉的壳代码里是不是还藏着不可见的检查逻辑而不是急着改业务代码。最后一件事给这个项目建一个decrypt_notes.md记录哪些文件用了哪个工具、解了几层、有没有残留 eval。这个习惯是我吃过几次亏才养成的——整套代码解完没记录过两个月回来看发现有个文件还在跑旧逻辑找半天才发现是当初漏了解一个子目录。工具有边界人的记性也有边界留一份解密清单比重复排查省太多时间。希望帮到你。本文还有配套的精品资源点击获取