关于PCLPoC

2311 字
12 分钟
关于PCLPoC

最近 PCL2 “爆出 RCE(远程代码执行)”,“披露者”煞有介事地写了 PoC(漏洞报告):PCLPoC。然而,事情真的如某些人所言非常严重吗?

本文写作时主要参考了 PCLPoC 仓库和边亮的 PCL不能下载? 我来救你!

本文是我对 PCLPoC 事件评论的第三版。

本文完全由人类写作 ;) 因此也具有作者主观色彩,包括存在的阴谋论和不当论证。

怎么一回事#

PCL2 客户端提供了“启动前执行命令”的功能,此功能可以调用 Windows CMD 在选择的 MC 实例路径下运行用户提供的命令。

PCL2 提供了自动更新与公告功能,数据来自存储于腾讯云 COS 的 json 文件。根据逆向结果,客户端会读取 json 文件中的 LaunchAdvanceRun,创建并执行 CMD 命令。公告 json 必然获取一次,龙猫称这是为了分发必要的安全更新。

PoC 论点在于:PCL2 没有对远程命令和安装包文件进行核查,存在 RCE 可能。

“你未能理解定义”#

在 PoC 中,作者大谈为什么这是“后门”(Backdoor),并引用 NIST(美国国家标准与技术研究院)的解释:“An undocumented way of gaining access to computer system. A backdoor is a potential security risk”(通过未有记录的方式获取计算机的访问权限。一个后门是一个潜在的安全隐患)。

只可惜,这位作者看来需要一本词典和一份逻辑学介绍书籍 ;)

首先我们来看 Backdoor(后门)的定义:

  • “An undocumented way of gaining access to computer system. A backdoor is a potential security risk” (NIST)
  • “在信息安全领域,后门指绕过安全控制获取系统访问权的方法。程序员可能在软件中创建后门以便修改缺陷,若未删除或被他人知晓,则成为安全隐患”(百度百科)

后门作为一种非公开的访问方式,本身并不代表恶意行为。同时:

  • PCL2 具有可审计的本地软件行为日志,会记录命令执行情况
  • PCL2 本身没有在普通用户态下绕过 Windows 安全系统的能力;至于管理员权限,一般都是你自己给 PCL 放了 UAC 授权……
  • 被污染的软件包?但是主语变成了这个被污染的 PCL2 具有“后门”和 RCE,和原版 PCL2 没有关系啊

另外,“后门”一词经过大大小小的安全事件,在日常用语中已经蕴含“主动恶意”的语意。这也就是为什么 XZ Utils 事件被宣传为“后门”,而 PHP 闹得沸沸扬扬的两个 CVE 被宣传为“漏洞”(vulnerability)。“后门”应当证明执行者具有主观恶意才能使用,而不是 PoC 作者认为的“存在即为后门”。

对于具体软件,应依据其实际机制、授权边界、可利用性及相关证据作出判断,而不应仅凭存在风险就推定恶意,也不应仅凭缺乏恶意证据就排除后门的存在。(ChatGPT 6 Luna)

所以 PCL2 还能用吗#

目前,360、火绒和边亮等人或组织确认,PCL2 存在相关安全隐患,但不存在实际的恶意行为,也没有任何实际利用报告。

PoC 的复现通过本地服务器和自签名证书进行,对应现实就是攻击者控制了 CA 证书/PCL2 服务器。(?!强!?)

这也就是为什么龙猫、边亮等人希望强调的事情:漏洞以攻击者可以攻击分发服务为前提,利用难度高。

PoC 作者也向两家漏洞报告平台提交了报告:

  • Sploitus 给出 CVSS 评分为 6.5(中等),基于 PoC 作者的复现代码给出 88% 的可信度
  • Vulners 给出 AI 评分为 6.5(中等),但可信度标记为“低”

此漏洞的实现有两种路径:

  1. 诱导玩家使用篡改过的客户端
  2. 篡改客户端下载的云端文件

无论哪种路径利用难度都比较高。基于开源社区的信赖机制和龙猫与 PCL2 在 MC 社区内的过往信用,普通用户不必对此漏洞过分关注。

如果你不信任 PCL2 或者龙猫,也可以选择使用其他修改器:HMCL、BakaXL、Prism、Axolotl、XMCL 等启动器。

对于 PCL2 开服与维护团队,需要考虑是否要为了一个几乎没有使用过的功能而削减当前的安全性,以及增加和远程通信时的数据校验(SHA、数字签名等),毕竟确实有 issues 指出问题……

厨房里有一把刀,当然不一定会拿去伤人,但也要小心有没有熊孩子偷了刀到处挥舞 :)

但是数字签名这个的话有点难说,因为许多个人/小团队的开源项目也没有上数字签名,当然你说龙猫收了赞助就应该有钱做这个的话……不予置评。

人的可信度#

PoC 认为,闭源代码难以审查,而龙猫本人的信誉并不永远可靠。但是披露者的信誉又从哪里来呢?

与之同时,PoC 认为“公开的代码可能好不到哪里去,但是至少有很多人会盯着看”。但其所提及的 XZ Utils 的后门一开始也不是看代码看出来的,已经是传递到终端用户才通过测试测测出来的。即使修复,仍然有着持续影响。

“Binarly 最新 (2025/8) 研究发现:潜伏一年的后门仍在扩散”(XZ Utils后门安全事件后续:持续潜伏的供应链威胁)

XZ 遇到的事情和 PCL2 类似:上游存在被污染的可能。下游一觉醒来,只是更新了一下软件包,电脑就炸了(

CrowdStrike导致大规模系统崩溃事件,同样自动更新,一个配置文件就能崩全球服务器,后门!

国内安卓系统,应用市场 WiFi 可以自动静默更新,还有我不知道干了什么的云控,也是后门!

你使用的浏览器、服务器程序、操作系统等都存在可能未发现的漏洞被分发下去,那么客观来讲,是不是开发者写出了后门?

什么,你说不可能?有什么难的,反正服务器都有可能分发“恶意”代码(doge

什么,你说有各种机制阻拦?那么 2023 年 PDD 被 Google Play 点名下架呢?

于是,商业公司不一定可信、安全公司不一定可信、CA 机构不一定可信、闭源软件不可信、开源项目也不一定可信。只要你的软件连着互联网,只要你的软件依赖远程下发的数据,那么你的设备就有被攻击到的可能。

最终我们选择不再杞人忧天,选择相信可信的机构、组织、个人,相信他们可以提供安全的服务。

利益相关担忧#

PCLPoC 的作者或许想着做个正义之士,但是 TA 参考的上游示范动机却疑似不那么单纯。根据 还有黑手!深挖PCL相关信息,我找到了这些… 的调查,上游的几个示例作者都和 PCL 有直接/间接的利益冲突和争议记录。

我为何如此担忧?我曾经参与过 RoadWeaver 的争论。当时我的争论点主要在许可证和工程实践方面,而另一群人则将矛头指向 AI 开发。可惜当时 AI 开发远没有现在如此流行,使得 RoadWeaver 承受了超预期的舆论。而当时 AI 开发的争论声量最大,不断有各种开发者批判 AI 开发的危害、项目的不可维护性,导致一年后还有人看到 RoadWeaver 就喊“AI 开发,质量堪忧”。

这些舆论多少会从漏洞分析本身运动到 PCL 本体上,更何况其中被有心人推动呢。这篇 PoC 确实“火上浇油”、“恰逢其时”。

RoadWeaver 确实有缺憾,那么同类模组在哪里呢?作为先行者的 Countered’s Settlement Roads 维护不下去,最终停更;另一个尝试无 AI、按照传统开发模式开发的 RoadArchitect 被拿来对比,但是同样被人评价“卡顿令人遗憾,任重道远”,现在 GitHub 仓库提交停留于 5 months ago。

至少 RoadWeaver 一直在更新,在修复优化。对于大部分缺乏精力和技术的玩家而言,似乎……也只能选择相信作者了。

结语#

这份 PoC 以及相关联的争议不应该引起如此大的争论。PCL2 的舆论集中在一段时间内爆发:举报、关闭面向中国的游戏下载服务、DDoS、“后门”争论……一个已有相关 issues 讨论的“漏洞”却在现在被重新拿起来炒作,令人怀疑。

自然语言有其力量。

文章分享

如果这篇文章对你有帮助,欢迎分享给更多人!

关于PCLPoC
https://blog.watermelonabc.top/p/about-pclpoc/
作者
Watermelonabc
发布于
2026-10-28
许可协议
CC BY-NC-SA 4.0

评论区

Profile Image of the Author
Watermelonabc
追寻各色世界
🎉 抓到你啦
欢迎来到 Watermelonabc 的 Blog!这个博客主要是技术向的内容,现在也有生活元素了 OwO
分类
文章目录