I am not a native English speaker; this article was translated by AI.

Right after dealing with the WPS root warning, it was Yadea’s turn. Opening the Yadea app with a VPN on shows “检测到VPN环境，请调整网络” (“VPN environment detected, please adjust your network”), and then the app exits. You can’t even get to the vehicle page.

WPS at least only showed a reminder; Yadea just refuses to work. What’s more absurd is that Yadea’s own traffic doesn’t go through the VPN at all. Whether my VPN is on has nothing to do with its network, but it insists on checking anyway.

Symptoms

#

logcat makes it clear: the main process logs “检测到VPN环境,请调整网络” and then exits on its own. The :pushservice push process shows the same message.

I wanted to unpack the APK, but Yadea 8.8.12 is packed with 360 Jiagu. Unpacking it only gives the shell code; the business logic isn’t visible.

In-process hooks blocked by the packer

#

For WPS, I used a temporary LSPosed diagnostic module that hooked the detection method inside the process and logged return values. On Yadea, the packer noticed during initialization and the app kept exiting before reaching the business code; removing the module brought back the original VPN warning. In-process hooking was a dead end. I also tried Frida, but it had version compatibility problems and never ran.

Code dumped from memory

#

Since the static route was blocked, I let the app decrypt itself at runtime. After a normal start, I dumped the business DEX from memory and could finally read the code.

Following the network checks led to an interface-enumeration routine in the Getui push SDK that looks for VPN interfaces like tun0 and ppp0. But there’s no evidence that this is what shows the warning, and I never caught which API triggers it, so I won’t draw a conclusion.

What I could confirm is something else. Yadea’s UID is 10450. It’s not in the list of UIDs the VPN covers, and not in the VPN client’s per-app list either; its traffic was direct all along. So setting Yadea to bypass the VPN in the client doesn’t help: it checks whether the phone has a VPN at all, regardless of how its own traffic is routed. WPS checked which apps were installed; Yadea polices the whole phone’s network state, which reaches even further.

Handling it outside the process

#

Since nothing can be done inside the process, the data has to be changed somewhere the app can’t see. VPN Hide does exactly this, on two layers:

• Java layer: the LSPosed module hooks system_server. At Binder’s writeToParcel, it removes VPN information from NetworkCapabilities, NetworkInfo, and LinkProperties, so the network data the app gets over IPC contains no VPN. Nothing is injected into Yadea’s process, so the packer’s anti-hook and memory-integrity checks don’t notice.
• Native layer: a kernel module (kmod, based on kprobe/kretprobe) hides the tun interface in the kernel. Interface-enumeration ioctls, getifaddrs, and netlink route dumps are all filtered, so native code can’t find it either. The backend can be kmod, KPM, or Zygisk. Zygisk does inline hooks inside the process and may be caught by the packer; this phone’s kernel supports kmod, so I used kmod.

flowchart TD
    Y["Yadea app (360 Jiagu pack + anti-hook)"]
    Y -->|"in-process hook injection"| X["Packer detects it, repeated exits ✗"]
    Y -->|"Java API network queries"| S["system_server
VPN Hide: Binder-layer filtering ✓"]
    Y -->|"native interface/route enumeration"| K["Kernel
VPN Hide kmod: tun0 hidden ✓"]

kmod doesn’t require flashing the kernel or modifying the boot image; the KernelSU module loads a .ko into the existing kernel at boot. But it does change the running kernel’s behavior: if it’s incompatible, the system may crash, and after uninstalling it you need another reboot to fully restore things.

The configuration enables Java and native hiding for com.yadea.smartmoto only, with the LSPosed scope set to the system framework, not Yadea.

Result

#

After rebooting to load the kernel module, with NekoBox connected, Yadea cold-started twice in a row straight into the vehicle home page. No VPN warning, no exit.

VPN Hide has a statistics page. I recorded for 43 seconds, cold-starting Yadea once during that window, and it logged 156 interceptions:

Most of it is native ioctl interface queries. That path returns the interface list, addresses, and up/down state, which is enough to spot VPN interfaces like tun0. Filtering only at the Java layer can’t block these queries, which is why kmod has to be enabled as well. These counts also include normal network calls, though, so they don’t mean Yadea deliberately checked for a VPN 156 times, and the stats alone can’t identify which call triggered the warning.

VPN Hide’s own status page shows “no check needed”, which looks like it isn’t working. It’s actually because VPN Hide itself doesn’t go through the VPN, so that’s the expected display.

VPN Hide only handles VPN traits that can be queried on the phone. It doesn’t hide root or deal with Play Integrity. Server-side checks such as DNS leaks, IP blacklists, and TLS fingerprinting are out of its reach.

Compared with WPS

#

WPS’s check sits in the app layer without protection, so hiding the package name with HMA was enough. Yadea’s check is behind a packer and can’t be touched in-process, so the only option was to go down to system_server and the kernel and change the data it receives.

Unpacking, dumping memory, reading decompiled code, picking a kernel module: in the past, even a professional wouldn’t have found it worth this much effort for one vendor app’s unreasonable restrictions, and ordinary users just had to put up with it. With AI’s help, ordinary people can get this done too, and finally decide for themselves how to use their own phones.

I am not a native English speaker; this article was translated by AI.

I bought this phone, but without root it felt like I was renting it, so I rooted it. Then WPS, starting from some version I can’t pin down, began caring whether my phone is rooted: every time I open it from the launcher, the home page shows “设备已Root，使用WPS Office可能存在安全风险。” (“This device is rooted; using WPS Office may pose security risks.”) It disappears after a second and leaves nothing in notification history. The worst part: I had denied its “read app list” permission, and it still detected KernelSU.

Why the warning can’t be turned off

#

It doesn’t go through the notification shade. It’s a Toast called directly from the app process, so notification permissions don’t apply, notification history keeps nothing, and WPS’s settings have no switch for it. Turning on KernelSU’s “unmount modules” for WPS didn’t help either.

Reading the detection code later explained why: this phone wasn’t being flagged by su files or mount points, so touching the file layer was pointless. At the time I didn’t know that, and just wanted the message gone.

Hiding just this one message

#

I first tried the existing ToastBlocker, scoped to WPS only. The warning was gone, but so were normal toasts like “saved”.

To be more precise, MyAndroidTools’ component toggles were no use: the warning isn’t a separate Activity, Service, or Receiver. The call site is inside HomeControllerImpl$1$1.run() on the home page, which runs the check and calls Toast directly. Blocking only this sentence needs a method-level hook, which means LSPosed.

So I wrote a module with a single rule: exact-match the whole warning sentence (ignoring layout whitespace), let every other Toast through, and leave WPS’s detection result alone. It identifies the content through the public Toast.makeText/setText, marks the matching Toast object, and skips only its show(), without reading the hidden Toast.mText field that Android 16 restricts. The first version used the legacy API and was verified on the device; before release it was rewritten on libxposed API 102’s interceptor chain. Build, signing, and release run on GitHub Actions, and wps-root-toast 1.0.0 is now in the LSPosed module repository.

The warning no longer shows, but the detection still runs; its result is just hidden.

How WPS decides a device is rooted

#

In WPS 26.9.1, the home-page check is KSystemRoot.i(context). It runs six checks in order and returns true as soon as one hits.

flowchart TD
    A["KSystemRoot.i(context)"] --> B1{"su file exists in any PATH directory?"}
    B1 -->|hit| T["Rooted"]
    B1 -->|miss| B2{"persist.sys.root.status set and not 0?"}
    B2 -->|hit| T
    B2 -->|miss| B3{"ro.secure is 0?"}
    B3 -->|hit| T
    B3 -->|miss| B4{"Build.TAGS contains test-keys?"}
    B4 -->|hit| T
    B4 -->|miss| B5{"fingerprint or model shows emulator traits?"}
    B5 -->|hit| T
    B5 -->|miss| B6{"root manager package name found?"}
    B6 -->|hit| T
    B6 -->|miss| F["Not rooted"]
    T --> S["Home-page toast: device is rooted, security risk"]
    style B6 fill:#ffcdd2,stroke:#d32f2f,stroke-width:2px

There are also two separate checks: LogoutTracker.h() looks for su at two fixed paths, and GetDeviceInfoHandler.a() checks /system/bin/su and /system/xbin/su, puts the result into the root field of the device info, and returns it through a JS callback. The code alone doesn’t show whether this is uploaded to a server, so I won’t draw a conclusion.

The code only shows that these six checks exist, not which one my phone hits. So I made a temporary diagnostic build that hooks the detection method itself and only logs each return value, installed it, and did one cold start:

The first five were false; the hit was number six, the package-name query for the KernelSU manager. That’s also why hiding su and changing properties didn’t help: none of them touched this check. After the test I removed the diagnostic build and reinstalled the release module.

The permission was denied, so why does the query work?

#

I really hadn’t given WPS the “read app list” permission, and it still found KernelSU, because these are two separate mechanisms.

The vendor’s “read app list” setting controls enumerating all apps on the device. Package visibility, introduced in Android 11, lets an app name packages in the Manifest’s , and for those named packages it can check whether they’re installed without any runtime permission. WPS’s lists KernelSU, Magisk, and APatch, and the system’s visibility records show the two packages as mutually visible. So tapping “deny” in the permission panel does nothing against these named queries.

This check also doesn’t justify the words “security risk”: having a manager app installed counts as a hit, without checking whether WPS could actually get root; emulator traits count as rooted too, which emulator users probably wouldn’t expect.

Making the query return “not installed”

#

Since the check is a package-name query, WPS just needs to not find the package. There were three options:

I was planning to write another API 102 package-visibility filter module, then found that Hide My Applist (HMA) already does exactly this, so there was no need.

The configuration has two entries: a blacklist template containing only me.weishu.kernelsu, and an app rule applying it to WPS only, with aggressive filtering and verbose logging off. To verify, I turned off the “WPS Root 提示隐藏” module, force-stopped WPS, and reopened it: no warning. The package query was blocked and all six checks returned false. Other entry points using the same check fail the same way, while the original module only covered the home page.

HMA 3.8.3 targets libxposed API 101 and requires the framework to allow loading native libraries in system services. It works on my Android 16 + LSPosed 2.2.1 setup.

Was the module a waste?

#

Looking back, I should have searched for existing solutions first. But without digging out the six checks, I wouldn’t have known the trigger was a package-name query, let alone that one HMA template would fix it.

The wps-root-toast repository is now archived. Its README includes the tested HMA configuration, and the source and released APK remain available for reference.

The module isn’t entirely wasted. If you only want this warning gone without changing package visibility, it still works on its own, and the diagnostic build was made from its code.

Decompiling and hooking were only done on the WPS on my own phone. The module only hides the toast and doesn’t change detection results, and the repository contains no WPS code. The release notes only list the tested combination: Android 16 + WPS 26.9.1 + LSPosed 2.2.1.

Later Yadea started policing VPNs too, with its check hidden behind a packer. That one is in the next post.