ID:
INTERFACE_ENUMERATIONCategory: Interfaces Status in RKNHardering 2.10.0: Active check Role in the verdict: Mixed
This page describes the actual implementation in RKNHardering 2.10.0. It distinguishes what can be done without root, what requires root, and where a mitigation only reduces one signal without hiding the VPN as a whole.
NativeInterfaceProbe.collectInterfaces() obtains interfaces through native getifaddrs(), groups records by name, and adds the index, MTU, flags, ARP type, and addresses. evaluateInterfaces() always emits a summary of total and active interface counts. It then compares active names against the patterns tun*, tap*, wg*, ppp*, utun*, zt*, tailscale*, svpn*, gre*, l2tp*, and he-ipv6*.
A high-confidence finding is created only for an interface with isUp=true whose normalized name matches a VPN pattern. An empty interface list produces a low-confidence review finding; the ordinary summary is informational.
A line containing a specific VPN-like name is a strong local indicator of a TUN, WireGuard, or PPP path. A summary without such a name proves nothing and exists for comparison between runs.
How the line affects the report: The same ID is used for both informational summaries and suspicious lines. The outcome depends on the specific detail and checker branch.
OEM and corporate interface names may match a pattern. The reverse problem is also possible: a renamed tunnel may evade the name pattern but still be exposed by its TUN/TAP type, netlink, routes, or a JVM/native inconsistency.
This line must be evaluated together with neighboring signals. A clean result from a single API does not simultaneously cover Java Binder, libc, raw netlink/syscalls, procfs/sysfs, local sockets, and server-side indicators.
The most reliable non-root approach is not to create a VPN interface on the phone being tested: move the tunnel to a router, travel router, separate gateway phone, or another network node. Per-app bypass in VpnService changes the route used by the selected app, but establish() still creates a system VPN interface, so local interface checks may continue to trigger. A local HTTP/SOCKS proxy mode without TUN can sometimes remove this specific vector, but it leaves listening ports and proxy settings and does not cover apps that ignore the proxy.
Laboratory-grade hiding usually requires a system Java layer and one native backend. With VPNHide, this means the APK plus Vector/LSPosed scoped only to System Framework, and exactly one of kmod, KPM, or Zygisk. For a check that may use a direct syscall or netlink, kmod/KPM is preferable: a userspace Zygisk hook can be bypassed and leaves traces inside the process. Review the VPNHide coverage map first, and download builds only from the official release page. VPNHide Next claims broader coverage, but also warns about possible boot loops and kernel panics; it should be tested only on a test device.
adb shell ip -details link show
adb shell ip -br address show
adb shell cat /proc/net/dev
Compare the name, UP state, index, and MTU with the RKNHardering detail. Remember that the shell UID is not the app UID; perform the final verification after adb shell am force-stop com.notcvnt.rknhardering and a fresh launch.
After any change, force-stop both RKNHardering and the VPN client, start them again, and repeat the full scan. Zygisk, Xposed, and kernel modules usually require a reboot. Compare not only this line but also neighboring signals: a partial hook often creates inconsistencies between APIs.
The probe itself runs with ordinary app permissions and does not request root. The ADB commands below are for orientation only: adb shell runs under a different UID and may see either more or less than the app process. The decisive test is to run the check again after a force-stop.
An external gateway changes the entire network path. Root or kernel filtering can cause loss of connectivity, a hung getifaddrs(), or a boot loop on an incompatible kernel.
Revert the most recent change: disable the added module or rule through its normal manager, reboot the device, and repeat the baseline scan. Do not layer another hook on top of an unknown state.
Mixed. Verified against evaluateInterfaces(), NetworkInterfacePatterns, and the C++ interface collector. The primary signal is covered by catalog and checker unit tests.
The status of a third-party solution does not automatically carry over to this device. A module developer’s claim is only the initial hypothesis; confirmation requires a reproducible RKNHardering result on the specific Android version, firmware, and kernel.
NativeSignsChecker.kt — main native/legacy verdict logic.native_signs_probe.cpp — native probe implementation.NetworkInterfacePatterns.kt — interface-name rules.NativeSignalId.kt — complete ID registry.NativeSignalCatalog.kt — category, slug, and line mapping.Related signals: tuntap-type, jvm-native-mismatch, getifaddrs-vpn, rtm-getlink-vpn.