ID:
UNKNOWNCategory: Service signals Status in RKNHardering 2.10.0: Active check Role in the verdict: Service
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.
NativeSignalCatalog.info(null) and unknown IDs use UNKNOWN. In the legacy and deep mappers, an unknown kind normally resolves to null, after which a finding may receive a fallback article or may not pass a particular parser at all. This page exists for forward compatibility rather than for one C++ probe.
The UI or link receives a null/unknown NativeSignalId, or a new native row has not yet been added to the catalog mapping.
This is a version-alignment defect among the producer, parser, enum, and documentation. Confidence or mitigation cannot be assigned from one unknown row; the raw kind/detail and commit/version are required first.
How the line affects the report: This is an umbrella or fallback ID. It links a group of lines to the documentation, but does not always have its own positive producer.
A release APK may not display the complete raw row. When APK and documentation versions are mixed, slugs and titles may diverge. An unknown result must not automatically be treated as either clean or detected.
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.
Save the exported report, APK version, ABI, and exact detail. Reinstall the official release without repacking and repeat the test. Attach only the minimum necessary log to an issue, with personal data removed.
Repeat the test without modules that alter JNI or strings. When adding a custom native probe, update NativeSignalId, NativeSignalCatalog, the mapper, UI strings, the Russian article, and unit tests together.
rg -n 'NativeSignalId|fromLegacyVpnKind|fromDeepVpnKind|UNKNOWN' app/src/main/java/com/notcvnt/rknhardering
./gradlew testDebugUnitTest --tests com.notcvnt.rknhardering.NativeSignalCatalogTest
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.
A published raw log may contain interface names, IP addresses, paths, and package names. Remove secrets and personal data before filing an issue.
Revert the incompatible producer/catalog change, or install matching versions of the APK and documentation.
Structural. Verified from the catalog fallback and mapping tables. This is a service-level signal.
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.
NativeSignalId.kt — complete ID registry.NativeSignalCatalog.kt — category, slug, and line mapping.NativeSignsChecker.kt — main native/legacy verdict logic.VpnNativeDetectorChecker.kt — deep VPN verdict and confidence.Related signals: native-library, general-diagnostics, syscall-unavailable.