ID:
ROOT_SU_BINARYCategory: Root and system state Status in RKNHardering 2.10.0: Active check Role in the verdict: Medium
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.
C++ calls access(F_OK) for 12 paths: /system/bin/su, /system/xbin/su, /sbin/su, /su/bin/su, /data/local/su, /data/local/bin/su, /data/local/xbin/su, /system/sd/xbin/su, /system/bin/failsafe/su, /vendor/bin/su, /product/bin/su, and /apex/com.android.runtime/bin/su. A matching path receives high confidence, but the category sets a review finding rather than detected on its own.
Any fixed path in the list is visible to an existence check from the app UID.
This is a strong local root artifact. The file’s presence does not prove that RKNHardering can execute su, while its absence does not rule out kernel-based root or a nonstandard path.
How the line affects the report: The line does not produce a final verdict on its own, but it sets needsReview=true and adds medium-confidence evidence.
A mount namespace may hide the path only from selected UIDs. Older ROMs, engineering builds, and remnants of an incomplete unroot procedure may leave a nonfunctional su binary.
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.
If root is not needed, the reliable fix is to return the device to stock condition through the official process: remove root through its manager, or flash factory boot/init_boot and system partitions that exactly match the installed build. An unlocked bootloader, custom kernel, and leftover directories may continue to reveal modification even after the manager is removed. Back up the device before recovery; relocking the bootloader on modified firmware can cause data loss or leave the device unbootable. If root has already been removed, do not manually erase the file from a read-only partition. First identify the image or module that introduced it, then restore the partition through the normal procedure.
Root access can only reduce the observable surface; it cannot prove the absence of root. Grant su to as few apps as possible, do not grant it to RKNHardering, disable unnecessary modules, and do not switch SELinux to permissive mode. App Profile/DenyList behavior and mount isolation must be verified on the specific firmware. SUSFS and similar solutions are experimental: they require a compatible kernel and may introduce their own artifacts. A separate stock device is still required for a reference test. Simply renaming su does not hide mounts, management paths, properties, or UID state. Restrict visibility through the official App Profile/DenyList feature of your root solution and test the actual app UID.
adb shell 'for p in /system/bin/su /system/xbin/su /sbin/su /su/bin/su /data/local/su /data/local/bin/su /data/local/xbin/su /system/sd/xbin/su /system/bin/failsafe/su /vendor/bin/su /product/bin/su /apex/com.android.runtime/bin/su; do [ -e "$p" ] && ls -l "$p"; done'
Empty shell output does not guarantee that the app namespace is the same.
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.
Removing a binary from a system partition may break OTA updates or boot. Do not run rm before backing up the image and identifying the mount source.
Restore the saved boot or system image, or reinstall root through the official manager if the file was part of its normal installation.
Medium. Verified from the exact kSuPaths array; Kotlin assigns high confidence and needsReview=true.
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.
native_signs_probe.cpp — native probe implementation.NativeSignsChecker.kt — main native/legacy verdict logic.NativeSignalId.kt — complete ID registry.NativeSignalCatalog.kt — category, slug, and line mapping.Related signals: root-management, root-suspicious-mount, root-uid.