Эта инструкция описывает обратную сторону проверок RKNHardering: что именно видит приложение, какие способы действительно меняют наблюдаемое состояние, а какие только создают видимость решения. Она написана для разработки, совместимости и проверки собственных защитных механизмов. Настройки ниже не дают универсальной гарантии прохождения сторонних антифрод-систем: у них могут быть дополнительные серверные сигналы, аппаратная аттестация и собственные правила.
Материал сверён с исходным кодом RKNHardering 2.10.0 из этой копии проекта. Полнота контролируется по трём реестрам: 65 EvidenceSource, 85 NativeSignalId и 41 β-проверка. Для каждого идентификатора в полной матрице есть отдельные колонки «без root», «с root» и «что всё равно останется видно».
| Что обнаруживает RKNHardering | Что реально нужно менять | Практически лучший вариант |
|---|---|---|
| GeoIP, разные IP у RU/non-RU проверок, CDN, STUN, звонки | Маршрут и фактический внешний адрес | Корректная маршрутизация приложения и согласованные DNS/HTTP/UDP; при необходимости — выход нужной страны/типа сети |
TRANSPORT_VPN, TUN, маршруты, netlink, /proc, интерфейсы |
Локальное представление сети внутри Android | Без root — вынести VPN на роутер/другое устройство; с root — системный Java-слой плюс один kernel/native-бэкенд |
| Localhost-порты, Clash/sing-box/Xray API | Доступ целевого UID к локальному control plane | Выключить listener/API; с root — блокировать loopback для целевого UID |
| Установленные VPN-приложения | Package visibility | Отдельный профиль помогает только частично; с root — фильтрация PackageManager в system_server |
Magisk/KernelSU/APatch, хуки, RWX, maps, свойства, mount |
Состояние процесса и пространства монтирования | Не внедрять хуки в целевой процесс; минимизировать root-поверхность; kernel-level решение предпочтительнее Zygisk |
| Второе пространство, рабочий профиль, клон | Android user/profile identity | Запуск в основном пользователе; перенос в профиль не является полноценным обходом и сам даёт сигнал |
Android VpnService создаёт виртуальный интерфейс и системную модель VPN. Исключение приложения из туннеля через per-app routing меняет путь его трафика, но не обязано скрывать существование TUN, VPN-сети и связанных маршрутов. В текущем RKNHardering это проверяется отдельно: активный TUN при отсутствии VPN у самого приложения рассматривается как признак явного per-app исключения. Поэтому «добавить RKNHardering в bypass» полезно против серверных IP-сигналов, но само по себе не является скрытием VPN.
Самый сильный вариант без root — убрать VPN с телефона как системный объект: поднять его на роутере, travel-router, отдельном телефоне в режиме точки доступа или другом шлюзе. Тогда на проверяемом Android нет VpnService, TUN и VPN-приложения. При этом внешний IP и серверные признаки всё равно должны быть согласованы.
Официальное описание Android: VpnService и VpnService.Builder. Поля addAllowedApplication/addDisallowedApplication управляют маршрутизацией приложений, а establish() создаёт сам VPN-интерфейс.
Обозначения источников используются прямо по тексту:
Начинать лучше не с установки модулей, а с модели угроз и порядка работ. Затем выберите нужную страницу:
boot.img/init_boot.img согласно вашему root-решению, список модулей, конфиги VPN и резервную копию данных профилей.Успех — не одна зелёная карточка. Нужны одновременно: