刷到一个 第三方免费在线编译的openwrt固件 Kwrt固件，在x的评论 ，说会偷跑pdcn

我用这固件一年多了，没发现啊。

我以前也用后来只用官方版

在用这个，持续关注

定制 OpenWRT 固件「后台偷跑 PCDN」说法核查报告

本文已脱敏：涉及内网地址、自有域名、服务商名、端口与设备标识的内容均已隐去或替换为占位符（<...>），不影响技术结论的可验证性。

• 核查对象：本机（192.168.x.1），Kwrt 系定制 OpenWRT 25.12.0-rc3，x86_64
• 核查方式：SSH 只读取证（未改动任何配置、未重启、未终止业务进程）
• 核查时间：2026-09-26
• 系统已长期运行（超过 2 个月），负载 0.03 / 0.19 / 0.12

一、结论

帖子所指控的「该系统在后台偷偷运行 PCDN」——在当前设备上不成立，未发现任何证据支持。

同时对帖子原文的技术描述做了一项重要更正：帖子描述的现象本身也不是 PCDN，而是一个 opkg 包管理锁被占用的固件缺陷（bug），与"偷跑 PCDN"是两个完全不同的性质。 该 bug 在本机上同样未复现。

二、系统指纹（确认与帖子描述为同一类固件）

Linux <hostname> 6.12.x x86_64 GNU/Linux
NAME="Kwrt"   VERSION="25.12.0-rc3"   ID="kwrt"   ID_LIKE="lede openwrt"
OPENWRT_RELEASE="Kwrt 25.12.0-rc3"

• 官方软件源：dl.openwrt.ai；另配置了一个第三方自定义源
• 确认属于 Kwrt / kiddin9 系定制固件，与帖子语境一致。

注意：帖子提到的关键组件 luci-app-gpsysupgrade 在本机 不存在（见第五节）。

三、进程维度：无 PCDN 特征

对全部 113 个用户态进程做了完整枚举与归类，全部可解释：

网络/代理类（用户自建）
网络代理与 DNS 分流组件若干、dnsmasq、odhcpd、pppd、odhcp6c、wireguard、端口转发组件、miniupnpd

容器类
dockerd、containerd、containerd-shim、docker-proxy、容器管理面板

应用类
智能家居服务、流媒体网关、云盘挂载服务×2

监控 Agent（用户自建，非固件预置）
nezha-agent -s <自建监控域名1>:443
komari-agent -e <自建监控域名2>

系统类
procd、ubusd、netifd、rpcd、logd、crond、dropbear、nginx、uwsgi、ttyd、ntpd、nlbwmon

关键词扫描 pcdn|xunlei|onething|wxedge|hcdn|sweet 对活动进程表命中数为 0。
首轮出现的若干命中（dropbear / sysfsutils / firewall），经逐条复核为 unknown（含 "nkn" 子串）造成的误报。

隐藏进程（rootkit）校验

ps pids = 218   /proc dirs = 217
present in /proc but not in ps = (空)

首轮 diff 出现的若干 PID，经复测确认每次运行都递增且随即消失，为检测脚本自身的瞬时子进程，非隐藏进程。判定：无进程隐藏。

四、自启与服务维度：无 PCDN 痕迹

init.d 全量 76 项，自定义项逐一审阅源码，均为正常功能：

crontab 全量（无隐藏项）

3 3 12 12 * /usr/bin/nginx-util 'check_ssl'
* * * * *   /usr/bin/wireguard_watchdog
0 * * * *   /usr/bin/log_cleanup.sh
0 4 * * *   lua /usr/share/<代理组件>/rule_update.lua log all cron
0 6 * * *   lua /usr/share/<代理组件>/subscribe.lua start <配置ID> cron

/etc/cron.d 为空，/etc/crontabs/ 仅 root 一个文件。无下载器、无常驻拉取、无 PCDN 调度。

rc.local 仅两条无害命令：一处 bind-mount 与一处代理组件双栈修补的 sed。

hotplug.d 全量 14 个脚本，均在标准目录（block/iface/leds/net/ntp/ieee80211），不存在帖子所述的 online/ 目录。

五、关于帖子技术描述的关键更正

帖子原文指向：luci-app-gpsysupgrade 插件 → /etc/hotplug.d/online/50-opkg-restore

本机实测结果：

[1] ls /etc/hotplug.d/online/            → NO /etc/hotplug.d/online/  （目录不存在）
[2] /etc/hotplug.d/online/50-opkg-restore → NOT FOUND
[3] find / -iname '*gpsys*'               → (空)
[4] find / -iname '*opkg-restore*'        → (空)
[5] opkg list-installed | grep gpsys      → (空)

该插件与脚本在本机完全不存在。 这说明：

1. 帖子描述的 luci-app-gpsysupgrade + 50-opkg-restore 是 Kwrt 生态中另一个版本/分支的固件才有的组件，并非本机所有；
2. 该脚本的行为是「WAN 上线时后台恢复软件包列表，占住 opkg 锁」——这是一个包管理锁竞争 bug，属于功能性缺陷，与"偷跑 PCDN"在性质上毫无关系；
3. 帖子的表述把「opkg 锁被占 → 无法安装插件」误导向了「后台偷跑 PCDN」，属于因果误判。

本机 opkg 锁状态：干净

/var/lock/  → 仅 procd_*.lock 等正常锁，无 opkg.lock 残留
ps | grep opkg  → 无占锁进程

/etc/opkg-restore-auto（帖子提到的完成标记）同样不存在——但因脚本本身不存在，无需该标记。

六、网络连接维度：全部可归属

出站连接共 53 条 ESTABLISHED，逐条归类：

无任何一条连接指向 PCDN 类基础设施。

监听端口核验：所有 LISTEN socket 均已成功映射到具体进程，netstat 中 无"无主监听"（would-hide-a-daemon 检查为空）。监听项全部为 DNS 服务、Web 服务、转发代理、管理面板、远程登录、容器代理与 UPnP 服务等已知组件，未发现来源不明的监听。

七、流量维度：无异常上行（决定性证据）

全生命周期统计（超过 2 个月累计）

avg RX = 0.226 Mbps
avg TX = 0.011 Mbps
down/up ratio = 19.7 : 1

上行平均仅 0.011 Mbps，占下行 4.8%，比值 19.7:1 —— 这是极其典型的家用网关流量画像（以下行为主）。

PCDN / 边缘计算 / 流量变现类业务的核心特征恰恰相反：需要持续、可观的上行带宽（通常几十至几百 Mbps 持续占用），上行占比会显著拉高，绝不可能出现 4.8% 这种比值。

实时抽样（连续多轮差分采样）

pppoe-wan 上行稳定在 0.02 ~ 0.03 Mbps 量级

当前上行约 0.025 Mbps（≈3 KB/s），属于心跳/保活级别。系统 负载 0.03，无任何后台重负载任务。

UPnP 映射说明（重要澄清，避免误判）

miniupnpd 租约表中有大量 UDP 映射，其标签呈现两类特征：

一类：live-xxxxxxxx / vod1-xxxxxxxx / vod10020-yyyyyyyy   （语义化标签，含 live/vod 前缀与数字后缀）
另一类：32 位随机字符串                                    （标签已隐去）

这些不是路由器自身行为，而是内网设备的 UPnP IGD 主动申请，来源主机为：

这些映射全部发生在本机之外（destination 为内网其他主机），本机只是代其做 NAT。不构成本机自身运行 PCDN 的证据。 若确有 PCDN，实际嫌疑在这些内网终端，而非路由器。

八、取证方法与可复现性

本次核查采用只读手段，未产生任何持久化改动：

1. 系统指纹：uname / /etc/os-release / openwrt_release
2. 进程完整性：ps w 全量枚举 + 与 /proc/[0-9]* 做 PID 差集（隐藏进程检测）
3. 自启完整性：/etc/init.d/* + /etc/rc.d/* 符号链接全量 + 逐脚本源码审阅
4. 持久化：crontab -l、/etc/crontabs/、/etc/cron.d/、/etc/rc.local、/etc/hotplug.d/
5. 文件系统：find / -iname '*gpsys*'、'*opkg-restore*' 全盘搜索
6. 包完整性：opkg list-installed 全量 + 可疑包名扫描
7. 连接：netstat -tulnp LISTEN 全量 + PID 映射（无主监听检测）、ESTABLISHED 逐条归属
8. 流量：/proc/net/dev、/sys/class/net/*/statistics/* 累计值 + 多轮差分采样
9. 容器：docker ps / docker inspect（veth iflink 映射 + 容器内进程）
10. 纠偏：对首轮关键词误报逐条复核（unknown 含 nkn 子串）

所有临时诊断脚本在核查结束后已从设备 /tmp 清理，SSH 会话已关闭。

九、最终判定

对帖子说法

「定制 OpenWRT 系统会在后台偷偷运行 PCDN」——在本机不成立。
六条排查路径（进程 / 自启 / 连接 / 流量 / 隐藏进程 / 持久化）全部为阴性，其中流量画像（上行占比 4.8%、比值 19.7:1、平均上行 0.011 Mbps）是最强的反证——与 PCDN 业务特征在数量级上完全不符。

对帖子技术描述

帖子实际描述的 50-opkg-restore 是一个 opkg 锁竞争缺陷（功能性 bug），与"偷跑 PCDN"性质完全不同，属于因果误判。且该组件在本机根本不存在。

唯一值得留意项（非本机问题）

某一内网终端持续申请随机标签的 UPnP 映射，具有 P2P 终端特征。若要排查真实的 PCDN 行为，建议转向该终端设备本身，而非路由器。

建议

1. 若需长期自证：本机已装 nlbwmon（24h 粒度），可保留其历史库作为流量基线，任何异常上行都会在曲线中显现；
2. 若在意 UPnP 风险：可关闭 miniupnpd 或为相关内网终端设置静态映射，减少随机端口暴露；
3. 关于该帖：建议以"opkg 锁占用的固件缺陷"理解，不必按"PCDN 后门"处理。