RCE靶场实战：命令注入利用与中文乱码修复全攻略

1. 项目概述：RCE练习中的乱码谜题

1.1 这个标题到底在讲什么

RCE（远程代码执行/命令执行）是Web安全里绕不开的一类高危漏洞。简单说，就是应用把用户的输入直接拼进了系统命令或者代码上下文，导致输入本身变成了可执行内容。CTFHub是国内CTF玩家常用的一类在线练习平台，上面挂载了大量真实场景的题目和靶场；pikachu则是一个基于PHP的Web漏洞靶场，把RCE、SQL注入、XSS、文件包含、越权等常见漏洞都做成了可交互的教学模块。

我最初在CTFHub上刷pikachu靶场RCE模块的时候，遇到了一个非常劝退的现象：页面中文全部变成"锟斤拷"一类的乱码，命令执行输出的中文结果也全是乱码。当时第一反应是靶场坏了，换了好几个浏览器都一样。后来折腾了一圈才发现，根本不是靶场的问题，而是编码链路断了。页面源码、响应头、数据库连接、系统终端各自的字符集没有统一，Web页面按UTF-8渲染，Windows下的cmd按GBK输出，两边对不上，乱码就出现了。

这篇内容不打算只讲"怎么把乱码改好"这么简单，而是把RCE命令执行、代码执行的完整利用过程走一遍，再把乱码问题的底层原理、排查思路、四套可落地的修复方案全部拆开讲清楚。如果你正在刷CTFHub这类平台上的pikachu靶场，或者在自己电脑上部署了类似靶场但被乱码拦住，这篇文章能直接帮你省下至少半天排查时间。

1.2 谁会需要这篇内容

我把这篇文章的目标读者大致分成三类：

第一类，刚开始刷Web漏洞靶场的新手。你可能刚搞懂什么是RCE，正打算在pikachu上练手，结果一打开页面就乱码，连payload都看不清楚。这篇文章会把从环境搭建到漏洞利用的每一步都写明白，遇到乱码也能按图索骥。

第二类，有一定基础但没系统处理过编码问题的选手。你能打通RCE，但每次遇到乱码都是临时百度"UTF-8转GBK命令"，修好一个，换个场景又乱。这种情况本质上是没把编码链路想清楚，第四章和第五章就是为你准备的。

第三类，把CTFHub当日常练习场的活跃用户。你可能需要快速定位某个靶场实例的编码问题，或者在做题时被响应包里的乱码卡住。文末的速查表和避坑经验，可以直接当工具备忘录用。

2. RCE原理与靶场环境准备：先搞懂漏洞再动手

2.1 RCE漏洞的本质：为什么输入会变成代码

把Web应用比作一家餐厅的前台，后端命令执行就像后厨的加工台。正常情况下，顾客点单"宫保鸡丁"，后厨就照着固定菜谱做。但如果中间的订单处理流程没有做校验，顾客在订单里夹带了一句"宫保鸡丁，顺便把后厨的门打开"，后厨看完照单全收，门就真的被打开了。命令注入就是这种场景：后端拿用户输入去拼接系统命令，但没过滤其中的特殊字符，攻击者的输入就变成了命令的一部分甚至是整条命令。

在代码实现层面，问题通常出在system()、exec()、passthru()、shell_exec()这类命令执行函数，以及eval()、assert()这类代码执行函数上。pikachu靶场的RCE模块恰好把两种场景都做了出来：一个是ping接口，用system()执行ping命令；另一个是eval接口，把输入交给eval()处理。

拿ping接口举例，后端常见写法类似这样：

$ip = $_POST['ipaddress']; system("ping " . $ip);

这里没有对$ip做任何过滤。正常情况下你提交127.0.0.1，后端执行ping 127.0.0.1。但如果你提交127.0.0.1 && whoami，实际执行的就是ping 127.0.0.1 && whoami，先ping本机，再执行whoami命令。一个本应只做连通性测试的接口，瞬间变成了远程命令执行入口。

代码执行场景更直接，后端可能是这样写的：

eval($_POST['txt']);

你在输入框提交phpinfo();，PHP就直接执行了phpinfo函数，相当于对方直接给了你一个PHP执行环境，危害比命令执行更上一层。

2.2 pikachu靶场环境搭建：在线和本地两种玩法

要在CTFHub上练习RCE，最省事的方式是直接用平台提供的在线靶场实例。浏览器打开、创建实例、等待启动，然后就能进入靶场页面。在线实例的好处是零配置、即开即用，不需要关心PHP版本、数据库连接、编码设置等环境问题，适合快速刷题。

但如果你想把乱码问题彻底搞明白，尤其是想看源码、改源码、观察编码变化，我更推荐本地部署一份pikachu靶场。本地环境不受平台约束，想怎么调试都行。

本地部署步骤大致如下：

1. 下载pikachu靶场源码包，放到Web服务器的根目录。Windows下直接用PHP集成环境即可，版本选PHP 5.x到7.x都行，但PHP 8以上部分老函数会报弃用警告，不影响主流程，只是看着烦。
2. 修改inc目录下的数据库配置文件，把数据库账号密码改成你本地的实际值。
3. 启动Apache和MySQL服务，浏览器访问靶场首页，按提示初始化数据库。
4. 初始化完成后，进入RCE漏洞模块，确认页面正常显示。

这里有几个容易踩的坑。第一，解压路径不要带中文，否则PHP的include路径容易出问题。第二，如果访问后页面白屏，去配置文件里开启display_errors，把PHP错误提示打开，能看到具体报错原因。第三，Windows下部署时，如果源码文件被记事本以ANSI编码保存过，页面就会出现典型的中文乱码，这一点我在第四章会详细展开。

2.3 环境验证与模块初探

环境验证很简单，访问靶场首页检查中文是否正常显示，再进入RCE模块，找到"RCE漏洞"下的"exec"和"eval"两个实验入口。先提交一次正常请求试试响应，比如在ping输入框填127.0.0.1，看是否返回ping结果；在eval输入框填phpinfo();，看是否渲染PHP信息页面。

这一步同时也是给"正常行为"留个基线。只有知道正常返回是什么样，后面出现了乱码、报错、空白响应时，才能快速判断是哪一环出了问题。很多人在乱码出现之后到处找解决方案，其实第一步应该是确认：页面本身正常吗？响应头是什么编码？只有命令输出乱码，还是整个页面都乱码？这些信息决定了后续排查方向。

3. RCE漏洞利用完整实操：从ping注入到eval代码执行

3.1 命令执行场景：ping接口的注入利用

进入pikachu的RCE模块，先看命令执行入口。页面上有个输入框，提示输入IP地址。正常情况下提交127.0.0.1，后端会执行ping命令，返回一段ping结果。如果是在Windows靶机上，结果里带中文提示"来自 127.0.0.1 的回复"，如果是在Linux靶机上，结果通常是英文。

现在开始注入。在输入框提交：

127.0.0.1 && whoami

因为后端执行的是system("ping " . $ip)，实际拼接后的命令是ping 127.0.0.1 && whoami。&&的意思是前一条命令成功执行后，再执行后一条命令。提交后，响应里除了ping结果，还能看到当前操作系统用户。Windows下一般显示desktop-xxx\user这样的格式，Linux下显示用户名和用户组信息。

除了&&，其他几个拼接符也值得记住：

• ;：在Linux下是命令分隔符，在Windows下新版cmd也支持
• |：管道符，把前一条命令的输出作为后一条的输入
• ||：前一条命令失败时才执行后一条
• &：在Windows下表示并行执行，前后命令都会跑
• %0a：换行符，某些过滤场景下能绕过

我用Burp Suite抓包观察一下这个请求。在靶场页面提交任意IP，Burp里能看到类似这样的请求：

POST /rce/ping.php HTTP/1.1 Host: 127.0.0.1 Content-Type: application/x-www-form-urlencoded ipaddress=127.0.0.1&&whoami

在后端没有过滤的情况下，这个请求直接拿到命令执行结果。多试几个系统命令，比如Windows下用ipconfig查看网络配置，Linux下用ls列出当前目录，用cat /etc/passwd读文件，都是同一套思路。

3.2 代码执行场景：eval接口的任意代码执行

再看eval接口。这个入口的输入框提示输入PHP代码，提交后后端直接调用eval()执行。先输入最基础的内容：

phpinfo();

页面会完整渲染PHP的配置信息，包括PHP版本、环境变量、扩展模块等。这里能确认PHP是否正常运行，也能判断当前是Windows还是Linux环境、运行的PHP版本是多少，这些信息后面排查编码问题也用得上。

接着测试系统命令执行：

system('whoami');

或者用更灵活的方式：

echo shell_exec('dir');

Windows下执行dir列目录，Linux下执行ls。在eval场景中，用户输入就是代码本身，不需要拼接，自由度更高。甚至可以写多行PHP代码，比如：

$cmd = 'ipconfig'; $output = shell_exec($cmd); echo '<pre>' . $output . '</pre>';

这段代码以pre标签包裹输出，在页面上排版更好看，中文乱码问题也更容易观察。eval接口的利用价值比命令执行更高，因为你可以直接读取敏感配置、写文件、反弹shell等。不过这里只是靶场教学环境，点到为止即可。

3.3 绕过与变形：遇到过滤时的几种经典思路

pikachu靶场本身没有太多过滤，可以直接利用。但真实场景和CTF题目中，后端往往会有粗浅的过滤，比如拦截;、&&、空格等字符。这里顺带提几种经典绕过思路，属于RCE模块常见的"加餐"内容。

第一种是空格绕过。Linux下可以用${IFS}替代空格，比如：

127.0.0.1;cat${IFS}/etc/passwd

也可以在URL中用%09（Tab）代替空格。

第二种是关键字过滤绕过。如果后端把whoami、cat这类命令名禁掉了，可以用变量拼接：

127.0.0.1;w$9hoami

或者用反引号和base64编码：

127.0.0.1;echo d2hvYW1p|base64 -d|sh

这里的d2hvYW1p是whoami的base64编码。这种思路在CTF题目里出现频率很高。

第三种是换行符绕过。如果后端只过滤了单行内的特殊字符，可以用%0a换行：

ipaddress=127.0.0.1%0awhoami

命令执行时换行符会被当作新命令的开始，相当于把注入的命令单独成行。

这些绕过手法在pikachu靶场里未必都能触发，因为后端没有过滤逻辑，但理解原理对刷CTF题很有帮助。真正做题时，后端可能还有WAF、白名单、黑名单等多层策略，绕过方式要按具体情况调整。

4. 乱码问题定位：编码链路到底断在哪一环

4.1 先把编码基础讲透：UTF-8、GBK、代码页

聊乱码之前，必须把编码的几个基础概念讲清楚。UTF-8是一种跨平台的Unicode变长编码，一个中文字符通常占3个字节，现在Web应用默认用它；GBK/GB2312是国内早期常用的中文编码，一个汉字占2个字节，Windows中文版的cmd默认输出就是GBK；代码页（Code Page）是Windows系统对字符集的编号，936对应GBK，65001对应UTF-8。

浏览器渲染页面时，会根据两个信息决定用什么编码：一是HTTP响应头Content-Type字段里的charset，二是HTML文档里的meta charset声明。如果这两个都没有，浏览器会尝试自动检测，检测不出来就用系统默认编码，比如中文版Windows的浏览器可能默认用GBK。当文件实际编码、HTTP声明编码、浏览器最终采用的编码三者不一致时，乱码就产生了。

"锟斤拷"这个经典乱码，本质是GBK字节流被用UTF-8解码后，无效字节序列被替换成U+FFFD（替换字符），而U+FFFD编码成UTF-8是EF BF BD，连续几个替换字符的字节流再被GBK解码，就成了"锟斤拷"这几个字。理解了这一点，你就明白乱码不是数据丢了，而是同一个字节流被两套编码规则解读，结果完全不同。

4.2 三条典型编码链路：页面、命令、数据库

在pikachu靶场这种Web环境里，乱码通常出现在三条链路上。

第一条是页面渲染链路。PHP源码文件的保存编码 vs HTTP响应头charset vs HTML meta charset，这三者需要保持一致。最常见的场景是：源码文件原本是UTF-8，但有人用Windows记事本打开后另存为ANSI编码，结果文件变成GBK；页面meta声明的是UTF-8，浏览器按UTF-8解析GBK字节流，自然乱码。

第二条是命令输出链路。PHP代码里调用system()或exec()执行系统命令，命令的输出编码取决于操作系统的终端代码页。Windows下cmd默认936（GBK），输出的中文提示是GBK字节流；而页面整体按UTF-8渲染，结果命令输出部分的中文乱成一片。Linux下终端一般默认UTF-8，所以同样一套靶场部署在Linux上很少出现命令输出乱码。

第三条是数据库链路。pikachu需要初始化数据库，数据库连接字符集如果没设置，MySQL默认可能用latin1；应用按UTF-8写入，读出来再用UTF-8展示，中间某一环不对，数据库里的中文就变成"???"或者乱码。这个问题在首次初始化时最明显，因为菜单、标题、说明文本全部来自数据库。

4.3 用排除法找到断点

遇到乱码，最忌上来就改源码编码，改完发现没用。正确做法是用排除法一条条链路验证。

第一步，看是全部页面乱码，还是只有命令输出乱码。只有命令输出乱码，说明页面渲染链路没问题，问题在命令输出链路；全部乱码，重点检查源码和响应头。

第二步，看HTTP响应头。用浏览器开发者工具打开Network面板，点开文档请求，看Response Headers里的Content-Type字段。如果显示text/html; charset=utf-8，再看HTML源码里meta标签是否也声明UTF-8；如果响应头没有charset，或者标的是gb2312，那问题很可能在这。

第三步，看PHP文件实际编码。用VS Code或Notepad++打开页面文件，注意右下角状态栏显示的编码。如果显示UTF-8，再确认是否带BOM。带BOM的UTF-8文件在PHP输出时会先在头部塞入隐藏字符，可能导致响应头声明失效，出现"头信息已发送"之类的报错。

第四步，如果是命令输出乱码，在靶机上手动执行一条含中文输出的命令，看终端显示什么编码。Windows下cmd里执行ping 127.0.0.1，中文正常显示，说明cmd是按GBK显示；再对比Web页面输出，就能确认是GBK和UTF-8的冲突。

第四步做完基本就能锁定断点了。接下来按方案修即可。

5. 乱码解决方案：四套可复制的修复实操

5.1 方案一：统一PHP源码编码

如果页面整体乱码，但把浏览器手动切到GBK编码后显示正常，说明PHP源码文件实际编码是GBK，但meta声明是UTF-8。解决办法是把源码统一转成UTF-8无BOM。

实操步骤：

1. 用Notepad++打开乱码的PHP文件，菜单栏选"编码"，查看当前文件编码。如果是"ANSI"或"GB2312"，复制全部内容。
2. 新建一个空文件，菜单栏选"编码" -> "转为UTF-8编码"。
3. 粘贴刚才复制的内容，保存，覆盖原文件。

如果你习惯用VS Code，操作更简单：打开文件后，点击右下角编码按钮，选择"通过编码重新打开"，选UTF-8；再选择"通过编码保存"，选UTF-8。注意保存时不要勾选"添加BOM"的选项。

为什么强调无BOM？因为带BOM的PHP文件在执行时，BOM字符会先于PHP标签输出到缓冲区，导致header()函数报错，或者让响应头里的charset失效。这一点很多人忽略，排查乱码时很容易被带偏。

如果靶场文件数量多，手动一个个转太累。可以写个小的批处理或PHP脚本批量转，但要注意备份。我自己的习惯是改之前先把整个目录压缩一份，改坏了随时还原。

5.2 方案二：显式声明响应头与meta

源码编码统一之后，还要确保HTTP响应头和HTML meta标签都明确声明UTF-8，让浏览器不会再猜来猜去。

在pikachu的公共头部PHP文件中，找到页面输出HTML之前的PHP代码区，增加一行：

header('Content-Type: text/html; charset=utf-8');

这行代码的作用是让服务器在响应头直接告诉浏览器"我是UTF-8"。只要这行在PHP中有实际输出之前执行，就不会报错。

同时检查HTML模板的head区域，确认meta声明存在：

<meta charset="utf-8">

有些老版本PHP模板写的是：

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

两种写法等价，但注意charset值必须和响应头一致。如果响应头写UTF-8，meta写GBK，浏览器会优先遵循响应头，一般也能正常显示；但如果响应头没有charset，meta又写错了，那就只能靠浏览器猜了。

5.3 方案三：命令执行输出编码转换

这个方案专门解决Windows靶机上命令输出中文乱码的问题。原因前面说过，cmd默认GBK，页面按UTF-8渲染。

最省事的思路是让cmd先切到UTF-8代码页，再执行你的命令。在PHP代码里可以这样写：

system('chcp 65001 >nul && ping 127.0.0.1');

chcp 65001把当前cmd窗口的代码页切到UTF-8，>nul把切换成功的提示信息丢掉，不干扰正常输出。执行完系统命令后，输出就是UTF-8字节流，页面渲染自然正常。

如果不想改靶场源码，或者不方便加chcp前置命令，也可以在PHP端做编码转换。利用exec()获取命令输出数组，再用mb_convert_encoding把GBK转成UTF-8：

header('Content-Type: text/html; charset=utf-8'); $cmd = 'ping 127.0.0.1 2>&1'; $output = []; exec($cmd, $output); $text = implode("\n", $output); echo mb_convert_encoding($text, 'UTF-8', 'GBK');

这里的2>&1是把错误输出也并入标准输出，防止命令出错时只返回空数组。mb_convert_encoding的第二个参数是目标编码，第三个参数是源编码；源编码这里写GBK，是因为Windows下cmd输出确实是GBK。如果你的靶机是Linux，输出本来就是UTF-8，不需要转换，强行转反而会把正常中文转坏。

实测下来，chcp和mb_convert_encoding双管齐下的最稳。只改chcp，需要确保每个调用system()的地方都前置；只做PHP转换，又需要找全所有命令输出点。两个机制配合，基本能覆盖大部分场景。

5.4 方案四：数据库连接字符集修正

如果靶场页面里的中文内容全部正常，但数据库初始化后菜单或题库数据变成"???"或者显示异常，大概率是数据库连接字符集没设置好。

pikachu初始化时会创建数据库、导入数据，整个过程依赖PHP连MySQL。如果PHP连接MySQL时没有指定字符集，连接可能采用latin1或系统默认字符集，写入的数据就按错误字符集存储，读出来自然不对。

修复方法分两步。第一步，在数据库配置中加入字符集设置，在建立连接后执行：

mysqli_set_charset($conn, 'utf8mb4');

或者在SQL语句中执行：

SET NAMES utf8mb4;

第二步，确认数据表本身的字符集是utf8mb4，如果之前已经建好且数据乱掉了，需要重建表或者修正字符集。可以在管理工具里执行：

ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

修改完之后重新访问页面，数据库里的中文就应该正常显示了。这一步最好在靶场初始化之前就做，省得初始化完还要回头补救。

5.5 CTFHub在线场景的特殊处理

本地靶场的乱码问题解决了，再看CTFHub在线场景的特殊情况。在线靶场出乱码，往往不是源码编码问题，而是响应数据本身做了额外编码，或者显示工具解析错了。

第一种情况，题目返回的内容可能是Base64编码。很多CTF平台为了避免二进制数据在HTTP传输中被破坏，会把命令输出做Base64处理。你在页面上看到一串乱码字符，复制下来扔到解码工具里，Base64解码后才是真实结果。怎么判断是不是Base64？看字符串是否由A-Z、a-z、0-9、+、/、=这些字符组成，结尾可能带一两个=号。

第二种情况，响应头没有charset，Burp Suite默认按ISO-8859-1显示，中文全乱。这时在Burp的Repeater或Proxy响应面板中，右键选择"显示"或"修改显示编码"，手动切到UTF-8。如果是命令行终端查看响应，确保终端本身也是UTF-8编码。

第三种情况，靶场做了Gzip压缩或者Transfer-Encoding，抓包工具需要自动解压，否则看到的是压缩后的二进制乱码。Burp通常能自动处理，但有些自己写的脚本没有自动解压，需要手动加Accept-Encoding: identity，或者用响应里的Content-Encoding做解码。

在线场景的乱码大多是"看起来乱、实际能解"，和本地靶场的"真乱码"性质不同。先判断是哪种，再决定是改靶场源码还是改解码工具。

6. 常见问题与避坑宝典

6.1 乱码问题速查对照表

我在实际练习中积累了一些常见场景，整理成表格，方便直接对照：

6.2 实战中积累的几条独家经验

第一，永远不要在Windows记事本里编辑PHP源码。记事本保存时会自动加BOM，还会把UTF-8文件另存成ANSI。这两个操作都是乱码的温床。改用VS Code或者Notepad++，能随时看到文件编码，也能强制无BOM保存。

第二，排查乱码时，先看响应头再看meta最后看源码。响应头是浏览器真正信任的编码来源，meta只是HTML内部声明，源码编码是最终根源。按这个顺序查，能避免许多无用功。

第三，Windows下打RCE靶，先执行一次cmd /c chcp看当前代码页。如果靶机本身被你切成了65001，那命令输出自然就是UTF-8，不用再做转换。很多教程默认按936处理，不一定符合你的环境。

第四，用Burp抓包看乱码问题时，注意底部有几个编码选项。除了UTF-8、GBK，还有"自动检测"选项。但自动检测不一定可靠，还是手动指定更稳。

第五，改完任何编码相关配置，都要清缓存或无痕窗口重试。浏览器对编码有缓存，改完还看到乱码，八成是旧页面缓存没清掉。

第六，打靶时命令没回显，先考虑是不是2>&1没加。命令报错信息默认走错误输出，不加重定向就看不到。这个和乱码问题经常同时出现，很容易让人误判成"没执行"。

6.3 安全边界与练习态度

RCE是高危漏洞，这里所有的利用思路都应当在授权的靶场环境内实践。CTFHub的在线靶场、你自己搭建的pikachu本地环境，都属于明确的练习场景。拿这些技术去测试未授权的线上系统，不仅是违规行为，还涉及法律风险。学习RCE的最终目的，是理解漏洞如何产生，从而知道如何在开发时做防护：输入白名单、参数化拼接、最小权限执行、禁用危险函数，这些才是生产中真正重要的东西。

乱码问题同样如此。它看起来是小事，但背后是编码、字符集、系统环境、HTTP协议多个层次的综合问题。把编码链路吃透了，以后不管是在靶场里看中文输出，还是在生产环境里排查日志乱码，都能迅速抓住关键点。

我自己在刷靶场时，乱码问题踩过不少坑。印象最深的一次是pikachu在Windows下命令输出全是乱码，最初以为是命令写法错了，怀疑了半天，最后才发现是cmd代码页和页面编码不一致。用chcp 65001和mb_convert_encoding双管齐下之后，问题彻底解决。从那以后我养成了一个习惯：遇到乱码先看链路，从源码到响应头再到终端，一段段排除，而不是瞎改一通。这个思路放到任何Web开发或者漏洞练习场景里都通用。下次再有人在群里问"RCE靶场怎么全是乱码"，你就可以把这篇文章甩给他了。