RKNHardering Help

Модель угроз и порядок противодействия

Прежде чем выбирать модуль, полезно разложить проверку на три независимых слоя. Большинство неудачных конфигураций закрывают только один слой и принимают это за полный обход.

1. Сервер и реальный сетевой путь

Этот слой находится вне процесса Android. RKNHardering сравнивает внешний адрес, страну, ASN/ISP, ответы RU и non-RU сервисов, DNS-путь, CDN-редиректы, STUN и транспортные пробы. Ни LSPosed, ни kernel-модуль не могут сделать иностранный датацентровый IP российским домашним адресом. Здесь помогает только маршрутизация и подходящий выход.

Практический вопрос: какой адрес и маршрут фактически видит удалённая сторона? Ответ зависит от split tunneling, DNS, IPv4/IPv6, UDP и конкретного endpoint. Подробности — в разделе о сетевом пути.

2. Локальная модель сети Android

Это Binder/Java API и нативные интерфейсы ядра:

NetworkCapabilities, NetworkInfo, LinkProperties, callbacks;
NetworkInterface, getifaddrs, ioctl(SIOCGIF*), netlink RTM_GET*;
/proc/net/*, /sys/class/net, policy rules, qdisc, socket identity;
системный proxy, локальные порты и control API;
видимость установленных пакетов и VpnService.

Здесь и лежит фундаментальная граница non-root. Обычное приложение VPN может исключить пакет из туннеля, но не имеет права переписывать ответы system_server и ядра для другого UID. Внешний роутер устраняет локальные признаки за счёт того, что VPN вообще не создаётся на проверяемом Android. Root-решения могут фильтровать данные в system_server и ядре.

3. Целостность устройства и процесса

Скрывающий модуль сам может стать сигналом. RKNHardering проверяет root-файлы и свойства, mounts, SELinux, хуки, RWX-регионы, целостность библиотек, Java/native расхождения, эмулятор и профиль пользователя. Поэтому модуль, который внедряется прямо в процесс RKNHardering, способен убрать TRANSPORT_VPN, но одновременно оставить более сильный hook/tamper след.

Правильная архитектура root-сценария выглядит так: Java-данные очищаются в system_server, нативные данные фильтруются на уровне ядра, а целевой процесс не получает Xposed/Zygisk-инъекцию. Именно поэтому VPNHide рекомендует связку системного Java-слоя и одного kernel-бэкенда, а Zygisk оставляет запасным вариантом.

Без root

Без root доступны четыре честных действия.

Первое — изменить фактический путь трафика. Например, исключить com.notcvnt.rknhardering из VPN, направить его напрямую или через ожидаемый выход. Это помогает против GeoIP/IP-консенсуса, но текущая TUN Active Probe способна заметить сочетание «TUN есть, VPN для приложения нет».

Второе — вынести VPN за пределы телефона. Роутер, отдельный шлюз или точка доступа дают наиболее чистую локальную картину: Android видит обычный Wi‑Fi, а не VpnService. Это единственный общий non-root способ убрать сразу Binder, TUN, netlink и package-сигналы VPN-клиента с проверяемого устройства.

Третье — убрать лишние утечки конфигурации: системный proxy, PAC, loopback listeners, Clash/sing-box/Xray API, слабую авторизацию, отдельный DNS-путь. Это не скрывает TUN, но закрывает независимые детекты.

Четвёртое — использовать отдельный профиль или пользователя. Он разделяет данные и установленные пакеты, но не является невидимым: Android присваивает профилю отдельный userId/UID, а RKNHardering имеет стабильные и β-сигналы изоляции. В текущем VerdictEngine один профильный сигнал обычно ведёт к review, но в сочетании с сетевым расхождением β-кворум может дать detected.

С root

Root расширяет возможности, но не отменяет сетевой слой. Рабочая схема состоит из четырёх независимых элементов:

Маршрутизация приложения и согласованный egress.
Java/Binder-фильтрация в system_server.
Ровно один native/kernel-бэкенд для ioctl, netlink, routes и proc/sysfs.
Блокировка localhost/control plane и минимизация root/hook следов.

Для поддерживаемого GKI предпочтителен kernel-модуль VPNHide. Для старых/non-GKI ядер возможен KPM/KernelPatch-бэкенд. Zygisk удобнее, но его libc-хуки обходятся raw syscall и видны проверкам целостности процесса. VPNHide Next заявляет дополнительное покрытие MTU/MSS/TCP_INFO, PMTU/GSO, eBPF, qdisc, timing и IPv6 link-local, однако сам проект предупреждает о риске bootloop и kernel panic; это экспериментальная ветка, а не безопасный «максимальный режим» по умолчанию.

Как RKNHardering принимает итоговое решение

Проверено проектом: итог строится не как сумма всех строк. Важны источники, независимость и домен доказательства.

Явный bypass через split tunnel, локальный proxy/Xray/Clash API, gateway leak или binding к underlying network может сразу дать сильное доказательство.
Согласованное расхождение внешних IP или геолокации участвует в отдельной логике консенсуса.
Root, hooks, isolation и часть native-сигналов чаще переводят результат в NEEDS_REVIEW, если нет независимого сетевого подтверждения.
β-проверки выключены по умолчанию. Единственные отдельные hard-authority пути — beta.vpn_binder и beta.tun_fd; им всё равно нужны повторные стабильные выборки. Остальные β-сигналы становятся DETECTED по кворуму независимых групп или в сочетании со стабильным доказательством.

Из этого следует важный практический вывод: бессмысленно «лечить» каждую informational-строку. Сначала закрывайте сильные независимые источники: реальный egress, Binder VPN, нативное перечисление интерфейсов/маршрутов, localhost API и явный root/hook след.

Ложные ощущения безопасности

Только split tunnel. Трафик идёт напрямую, но TUN и VPN-сеть остаются. Текущая проверка специально ищет это сочетание.

Только LSPosed-хук в приложении. Java API становится чистым, зато getifaddrs, netlink и raw syscall остаются, а процесс получает hook-маркеры.

Только Zygisk native hide. Закрываются обычные libc-пути, но direct syscall, альтернативные receive-функции и целостность процесса могут выдать вмешательство.

Только переименование tun0. RKNHardering смотрит не только имя: тип TUN/TAP, ifindex, netlink, маршруты, MTU/MSS, policy rules, qdisc и косвенные socket-сигналы.

Только второе пространство. Пакеты и данные разделены, но userId/profile state видимы; OEM-клоны часто используют характерные userId, которые код проверяет отдельно.

Только root-hiding модуль. Он не меняет внешний IP, DNS, STUN и CDN. Кроме того, несовместимый модуль может создать новые mounts, RWX или linker-аномалии.