WPS 好歹只是提醒一下，雅迪是直接不让用。更离谱的是，雅迪自己的流量根本不走 VPN，我开不开 VPN 跟它的网络没关系，它就是要管。

现象

#

logcat 里很清楚：主进程打出「检测到VPN环境,请调整网络」，接着自己退出。:pushservice 推送进程也会弹同样的提示。

本来想拆 APK 看看，结果雅迪 8.8.12 套了 360 加固，拆出来只有壳代码，业务逻辑看不到。

进程内 hook 被加固拦住

#

WPS 那次是写个临时的 LSPosed 诊断模块，进进程 hook 检测方法、记录返回值。同样的办法放到雅迪上，加固壳初始化时就发现了，App 反复退出，走不到业务代码；把模块撤掉，又变回原来的 VPN 提示。进程内 hook 这条路走不通。试了下 Frida，版本兼容有问题，也没跑起来。

内存里 dump 出来的代码

#

静态拆不开，就等它运行时自己解密。正常启动后从内存里 dump 出业务 DEX，就能看到代码了。

顺着网络检测找，在个推 SDK 里有一段枚举网卡的代码，检查 tun0、ppp0 这类 VPN 网卡。不过没有证据证明那条提示就是它弹的，具体是哪个 API 触发的也没抓到，这里不下结论。

能确定的是另一件事。雅迪的 UID 是 10450，不在 VPN 接管的 UID 列表里，VPN 客户端的分应用名单里也没有它，它的流量本来就是直连的。所以在 VPN 客户端里把雅迪设成绕过也没用，它查的是整台手机有没有 VPN，跟自己的流量走哪条路无关。WPS 查的是装了什么应用，雅迪管的是整台手机的网络状态，伸得更远。

换到进程外面处理

#

进程里动不了，就只能在它看不到的地方改数据。VPN Hide 就是这么做的，分两层：

• Java 层：LSPosed 模块挂在 system_server 上，在 Binder 的 writeToParcel 处把 NetworkCapabilities、NetworkInfo、LinkProperties 里的 VPN 信息去掉，App 通过 IPC 拿到的网络数据里就没有 VPN。整个过程不注入雅迪进程，加固的反 Hook 和内存完整性检测发现不了。
• 原生层：用内核模块（kmod，基于 kprobe/kretprobe）在内核里隐藏 tun 网卡，接口枚举的 ioctl、getifaddrs、netlink 路由转储都会过滤，native 代码也查不到。后端可以选 kmod、KPM 或 Zygisk，Zygisk 是在进程内做 inline hook，可能被加固识破，这台手机的内核支持 kmod，就用了 kmod。

flowchart TD
    Y["雅迪 App（360 加固 + 反 Hook）"]
    Y -->|"进程内 Hook 注入"| X["加固检测到介入，反复退出 ✗"]
    Y -->|"Java API 查询网络状态"| S["system_server
VPN Hide：Binder 层过滤网络数据 ✓"]
    Y -->|"native 枚举网卡、路由"| K["内核
VPN Hide kmod：藏起 tun0 ✓"]

kmod 不用刷内核，也不改 boot 镜像，是 KernelSU 模块开机时往现有内核里加载一个 .ko。但它确实改了运行中内核的行为，不兼容的话可能导致系统崩溃，卸载后也要再重启一次才能完全恢复。

配置只针对 com.yadea.smartmoto 开启 Java 和原生两层隐藏，LSPosed 作用域只勾系统框架，不勾雅迪。

结果

#

重启加载内核模块后，NekoBox 保持连接，雅迪连续两次冷启动都正常进了车辆首页，没再弹 VPN 提示，也没退出。

VPN Hide 有个统计页，开着抓了 43 秒，期间冷启动一次雅迪，一共记录到 156 次拦截：

大头是原生层的 ioctl 接口查询，这条路能拿到接口列表、地址和启用状态，足够发现 tun0 这类 VPN 网卡。只在 Java 层过滤的话，这部分查询是拦不住的，这也是要同时开 kmod 的原因。不过这些计数里也包含正常的网络调用，不能理解成雅迪专门查了 156 次 VPN，也没法靠统计确定弹警告的是哪一次调用。

VPN Hide 自己的状态页显示「无需检查」，看着像没生效，其实是因为它本身不走 VPN，显示这个是正常的。

VPN Hide 只处理手机上能查到的 VPN 特征，不隐藏 root，也不管 Play Integrity。服务端那边的检测，比如 DNS 泄漏、IP 黑名单、TLS 指纹，它管不了。

和 WPS 对比

#

WPS 的检测就在应用层，没有保护，用 HMA 隐藏包名就够了。雅迪的检测藏在加固后面，进程里动不了，只能往下到 system_server 和内核去改它拿到的数据。

脱壳、dump 内存、读反编译代码、挑内核模块，这一套放在以前，就算是专业人士，为了一个厂商 App 的不合理管制花这么多工夫也不太值，普通用户更是只能忍着。现在有 AI 帮忙，普通人也能把这些活干完，自己的手机想怎么用，总算能自己说了算。

这句警告为什么关不掉

#

这东西压根没走通知栏，是进程里直接调用的 Toast，通知权限管不着，通知历史不留痕，WPS 设置里也翻不到开关。把 KernelSU 对 WPS 的「卸载模块」打开，照弹不误。

后来看了检测代码才知道为什么没用：这台手机根本不是因为 su 文件或挂载点被查出来的，动文件层自然白搭。不过当时还不知道，只想先让这句话闭嘴。

先让这一句消失

#

先试了现成的 ToastBlocker，作用域只勾 WPS。警告是没了，「保存成功」这类正常提示也跟着没了。

想拦得准一点，写轮眼（MyAndroidTools）那套组件开关用不上，这句警告不是单独的 Activity、Service 或 Receiver，调用点在首页 HomeControllerImpl$1$1.run() 里，检测完直接调 Toast。只拦这一句，就只能上方法级 Hook，也就是 LSPosed。

于是写了个模块，规则只有一条：整句精确匹配那句警告（忽略排版空白），其他 Toast 照常显示，WPS 的检测结果也不动。实现上通过公开的 Toast.makeText/setText 认内容，标记命中的 Toast 对象，只跳过它的 show()，不去读 Android 16 已经限制访问的隐藏字段 Toast.mText。第一版用 legacy API 在实机上验证过，发布前又迁到 libxposed API 102 的 interceptor chain 重写了一遍。构建、签名、发布都走 GitHub Actions，wps-root-toast 1.0.0 已经进了 LSPosed 模块仓库。

警告是不弹了，但检测还在跑，只是看不见结果。

WPS 怎么判定「已 Root」

#

把 WPS 26.9.1 拆开，首页用的判定在 KSystemRoot.i(context)，六项检查按顺序走，任何一项命中就返回 true。

flowchart TD
    A["KSystemRoot.i(context)"] --> B1{"PATH 各目录下存在 su 文件？"}
    B1 -->|命中| T["判定已 Root"]
    B1 -->|未命中| B2{"persist.sys.root.status 非空且不为 0？"}
    B2 -->|命中| T
    B2 -->|未命中| B3{"ro.secure 为 0？"}
    B3 -->|命中| T
    B3 -->|未命中| B4{"Build.TAGS 含 test-keys？"}
    B4 -->|命中| T
    B4 -->|未命中| B5{"指纹或型号含模拟器特征？"}
    B5 -->|命中| T
    B5 -->|未命中| B6{"查询到 Root 管理器包名？"}
    B6 -->|命中| T
    B6 -->|未命中| F["判定未 Root"]
    T --> S["首页 Toast：设备已Root，使用WPS Office可能存在安全风险"]
    style B6 fill:#ffcdd2,stroke:#d32f2f,stroke-width:2px

另外还有两处独立检测：LogoutTracker.h() 查两个固定路径的 su；GetDeviceInfoHandler.a() 查 /system/bin/su 和 /system/xbin/su，结果放进设备信息的 root 字段，通过 JS 回调返回。光看代码看不出会不会上传到服务器，这里不下结论。

代码只能说明有这六项，看不出我这台手机命中的是哪一项。于是临时改了个诊断版，hook 检测方法本身，只记录每一项的返回值，装上冷启动一次：

前五项都是 false，命中的是第六项，查 KernelSU 管理器的包名。前面藏 su、改属性之所以没用，也是因为碰的都不是这一项。测完把诊断版卸了，换回正式模块。

权限被拒，为什么还查得到

#

我确实没给 WPS「读取应用列表」权限，它照样查到了 KernelSU，因为这是两套机制。

厂商设置里的「读取应用列表」管的是枚举设备上的全部应用。Android 11 之后的包可见性机制允许 App 在 Manifest 的 里点名一批包名，点了名的包不需要任何运行时权限就能查装没装。WPS 的 里就列着 KernelSU、Magisk、APatch，系统的可见性记录也显示这两个包互相可见。所以权限面板上点的「拒绝」，对这种点名查询根本不起作用。

这套判定也配不上「安全风险」这个说法：装了管理器 App 就算命中，根本不看 WPS 自己能不能拿到 root；模拟器特征也算 Root，用模拟器的人大概也想不到会被这么提醒一句。

让查询返回「未安装」

#

既然查的是包名，那让 WPS 查不到这个包就行。可选的做法有三种：

本来打算再写一个 API 102 的包可见性过滤模块，后来发现 Hide My Applist（HMA）干的就是这事，就没必要自己写了。

配置只有两条：建一个黑名单模板，里面只放 me.weishu.kernelsu；应用规则只对 WPS 生效，激进过滤和详细日志都不开。验证时先把「WPS Root 提示隐藏」模块关掉，强停后重开 WPS，没再弹。说明包名查询直接被挡住了，六项检测都返回 false。其他入口如果也用同一套判定，一样会失效，原来的模块只能遮住首页这一处。

HMA 3.8.3 用的是 libxposed API 101，还要求框架允许在系统服务里加载原生库，我这套 Android 16 + LSPosed 2.2.1 上实测正常。

模块白写了吗

#

回头看，确实该先找找现成方案再动手。不过不把六项检测挖出来，也不知道触发点是包名查询，更想不到 HMA 一个模板就能解决。

wps-root-toast 仓库现已归档，README 保留了 HMA 的实测配置，源码和已发布 APK 也保留供查阅。

模块也不算完全白写。只想去掉这句提醒、不想改包可见性的话，它还能单独用；诊断版也是在它的代码上改出来的。

反编译和 Hook 都只在自己手机上的 WPS 里做，模块只隐藏提示、不改检测结果，仓库里没有 WPS 的代码。发布说明里也只写了实测过的 Android 16 + WPS 26.9.1 + LSPosed 2.2.1。

后来雅迪也开始管 VPN，而且检测藏在加固后面，处理过程写在下一篇。