RKNHardering for Android VPN and Proxy Detection

RKNHardering's Android Detection Scope

RKNHardering addresses a specific problem: Android applications and network observers can often tell that a device is using a VPN or proxy, but the available indicators are spread across system APIs, kernel files, installed packages, active transports, and external IP services. The project gathers these signals in an Android application so a user can inspect the device from one interface. It is intended for people studying VPN and proxy detection, including researchers who need to understand what an Android device exposes.

The README describes the application as an implementation of the RKN approach to identifying circumvention tools. That description does not turn every detected sign into definitive attribution to a particular VPN client or blocking authority. Some findings are merely suspicious signals. The project documentation also separates information verified by the project from claims supplied by the community or another project. It explicitly says that community-reported and externally declared claims are not guarantees of operation or security.

The application supports Android 8.0, API 26, and newer. It is written primarily in Kotlin and uses an Android project structure containing `app/`, Gradle files, documentation, scripts, tools, and Xray protocol definitions. RKNHardering is a diagnostic project. Its purpose is to observe and classify signs. It does not configure VLESS, Xray, or another VPN service, and it does not conceal VPN use.

Parallel Check Modules and Verdict Boundaries

RKNHardering runs independent check modules in parallel and sends their results toward `VerdictEngine`, which calculates the final verdict. This architecture separates different observation methods. A finding from one module does not need to rely on the same external service or Android API as every other finding.

The module list covers several distinct surfaces. `GeoIpChecker` examines public IP geography and hosting, proxy, VPN, Tor, or datacenter signals. `DirectSignsChecker` reads direct Android and system indicators such as `NetworkCapabilities`, the system proxy configuration, TUN behavior, and installed VPN applications. `IndirectSignsChecker` covers network interfaces, routes, DNS, `dumpsys` output, and proxy-technology signals.

Several modules test active network behavior. `CallTransportChecker` examines STUN and MTProto behavior, including leakage and availability. `CdnPullingChecker` makes HTTPS requests to CDN or redirector endpoints. `DomainReachabilityChecker` follows a DNS, TCP, and TLS pipeline to identify evidence of DPI blocking. `RttTriangulationChecker` uses RTT triangulation against Russian and foreign hosts and is marked as SNITCH beta. `IcmpSpoofingChecker` looks for an ICMP response from a blocked host that should not answer.

`BypassChecker` expands the inspection to localhost proxies, the Xray gRPC API, Clash and sing-box REST APIs, SOCKS5 authentication probes, and possible underlying-network leaks. `NativeSignsChecker` uses JNI to inspect routes, interfaces, host routes, TUN and TAP interfaces, hooks, root state, emulators, and isolation conditions. These labels describe check categories. The README excerpt does not provide every threshold, weighting rule, or network timeout used by the modules.

GeoIP, IP Comparison, and Consensus Processing

Public IP analysis is an important part of the project, but its role has a documented boundary. `GeoIpChecker` primarily uses `https://api.ipapi.is/` for GeoIP fields and proxy, VPN, Tor, or datacenter signals. Its documented fallback is `https://www.iplocate.io/api/lookup`, which supplies GeoIP fields and an additional hosting vote through `privacy.is_hosting`.

The visible logic says that `countryCode != RU` makes the IP foreign. If the IP is foreign and there is neither a `hosting` nor a `proxy` signal, the GeoIP result is `needsReview`. A hosting signal is processed through a majority vote in the partially shown table. The README excerpt ends before the complete voting and verdict rules are visible, so it would be inaccurate to invent thresholds for the rest of that logic.

`IpComparisonChecker` is handled differently. It compares Russian and non-Russian IP checkers, but its result is stored and shown in the interface as a diagnostic block. It does not participate directly in `VerdictEngine`. Instead, its data feeds `IpConsensusBuilder`. This means the interface can show an IP comparison without allowing that single check to dictate the final verdict. Users should therefore distinguish the diagnostic IP panel from the engine's overall assessment.

An external IP service is not the same thing as proof that traffic passes through a VPN. The repository also warns that community-reported and externally claimed techniques may not work. The result should be interpreted as a collection of network conditions, not as a standalone anonymity verdict.

Installing RKNHardering and Running a First Inspection

The README does not provide a source-build tutorial, Gradle invocation, package installation command, or required configuration file. It provides two download routes instead: GitHub Releases and F-Droid. The first practical use therefore begins by obtaining the application from one of those documented sources rather than inventing a build command.

The project links to the latest GitHub release:

https://github.com/xtclovver/RKNHardering/releases/latest

This address points to the project's release page. The README does not state whether a release asset is signed or document an Android installation workflow. Users must inspect the release information available from the project and their chosen distribution page.

The documented F-Droid listing is:

https://f-droid.org/en/packages/com.notcvnt.rknhardering/

The package identifier shown by that listing is `com.notcvnt.rknhardering`. F-Droid can serve as the documented installation path when it offers a compatible build, while GitHub Releases provide the project's own release distribution route.

After installation, open RKNHardering and start the available inspection. The architecture says independent checks run in parallel, so the screen may show several modules progressing rather than one sequential checklist. The expected output is an overall verdict produced by `VerdictEngine`, plus separate diagnostic information where the interface exposes it, including the `IpComparisonChecker` block. The README does not identify the exact button label, explain required permissions, or document whether network access must be disabled during a scan. Those details cannot be supplied without guessing.

Detection Limits and Situations Where It Is the Wrong Tool

The clearest limitation is the separation between detection and evasion. The project documents how a VPN or proxy may be exposed, while its community request asks for research into methods that would prevent detection. Those methods are described as contributions or proof-of-concept topics, not as implemented guarantees. Users who need a VPN to connect should not confuse RKNHardering with a VPN client.

A detection result can also change with network conditions. GeoIP depends on two external services, while call transport, CDN, domain reachability, RTT triangulation, and ICMP checks depend on active network behavior. A non-Russian address may trigger `needsReview` rather than a conclusive verdict. A restricted route or unavailable endpoint may also change what a network probe can observe. The README does not promise that every module will succeed in every network.

The `BypassChecker` name is easy to misread. Its listed checks concern detection surfaces such as localhost proxy access, control APIs, SOCKS5 authentication, and underlying-network leakage. The README does not say that the application creates, modifies, or repairs a bypass configuration. It is therefore the wrong tool for diagnosing whether a specific VPN can reach a destination, repairing a broken Xray profile, or guaranteeing that DNS and traffic stay within the tunnel.

Some modules depend on privileges, platform state, or endpoints that may not be available in every installation. `NativeSignsChecker` looks at root, emulator, isolation, hooks, and low-level interface conditions. `DirectSignsChecker` reads installed applications and system proxy state. The README does not explain how the app handles denied permissions, rooted devices, emulators, or a missing native component. Those cases require inspection on the actual device.

RKNHardering Compared With Direct Android Inspection

The main alternative is manual inspection of Android networking state. A developer can inspect `NetworkCapabilities`, `NetworkInterface.getNetworkInterfaces()`, `/proc/net/route`, `/proc/net/tcp`, system proxy settings, installed packages, and selected `dumpsys` output directly. That approach gives tighter control over the exact API call and avoids a separate detector application, but it requires assembling and interpreting each indicator independently.

RKNHardering takes a broader, application-oriented approach. Its parallel modules combine low-level interface checks, system APIs, package inspection, external IP services, transport probes, CDN requests, native checks, and cross-module IP consensus. The project also provides a reference guide for individual checks, with labels that separate project-verified information from community reports and external claims. That documentation structure is useful when reviewing why a result appeared.

The trade-off is visibility. Manual inspection can make the observation path explicit to the person conducting it, while RKNHardering applies a predefined runner and `VerdictEngine`. The application is more convenient for a repeatable inspection, but the README does not publish the complete thresholds, weighting rules, or failure behavior for every module. It is therefore better suited to initial triage than to a fully reproducible audit whose entire decision procedure must be inspected line by line.

A proxy or VPN configuration tool serves a different purpose. It creates or manages network connections. RKNHardering observes signs after or while those connections exist. The two tools should not be treated as substitutes.

Release Cadence, AGPL-3.0, and Upgrade Work

The repository is not archived. Its last push was on 2026-07-26, and the documented releases include `v2.11.0` on 2026-07-26, `v2.10.0` on 2026-07-10, and `v2.9.0` on 2026-06-11. The README does not provide a compatibility policy, migration guide, database format, or procedure for preserving results across upgrades. Users who rely on recorded scans should keep the application version and the interpretation of each check in their own records.

The project is licensed under `AGPL-3.0`. That identifier matters for organizations considering redistribution, modification, or network use because the license contains its own conditions and obligations. This is not legal advice. The repository includes the license file, but the README does not summarize packaging requirements, modification notices, or source-offer duties.

The reference documentation says that claims marked as community-reported or declared by an external project are not guarantees of functionality or security. That warning should carry through upgrades as well. A new release may add modules or change the evidence assembled by `VerdictEngine`, but the README does not document whether old verdicts remain comparable. Before upgrading an operational workflow, check the release notes for changes to modules, verdict logic, external endpoints, Android requirements, and the `AGPL-3.0` distribution implications.

Editorial conclusion

Adopt RKNHardering when you need a transparent Android diagnostic of VPN, proxy, interface, DNS, and transport signals. Do not treat it as proof of anonymity, a VPN configurator, or a tool for evading detection. Before relying on a result, verify the application version, confirm that Android 8.0 or newer is available, and review which check modules contribute to the reported verdict.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. xtclovver/RKNHardering on GitHub