ID:
PROC_IPV6_ROUTE_VPNКатегория: Маршруты и сетевой стек Статус в RKNHardering 2.10.0: Активная проверка Роль в вердикте: Высокая
Эта страница описывает фактическую реализацию RKNHardering 2.10.0. Здесь отдельно указано, что можно сделать без root, что требует root, а также где способ только уменьшает один сигнал, но не скрывает VPN целиком.
Проба читает /proc/net/ipv6_route, затем /proc/self/net/ipv6_route. Строка разбивается на десять токенов; десятый принимается за имя интерфейса. Совпадения с tun0, tun1, utun0, wg0, ppp0, xfrm0 увеличивают count.
Хотя бы одна IPv6 route row с фиксированным VPN-именем.
Маршрутная таблица IPv6 прямо ссылается на VPN-like интерфейс. Даже выключенный IPv4 не закрывает этот путь.
Как строка влияет на отчёт: Строка переводится в detected=true и считается высокодостоверным локальным признаком.
Формат procfs kernel-specific и может быть закрыт SELinux. Проба не выводит destination/prefix/table, только count, поэтому для анализа нужен raw snapshot. Нестандартные имена не ловятся.
Важно оценивать эту строку вместе с соседними сигналами. Один чистый API не перекрывает Java Binder, libc, raw netlink/syscall, procfs/sysfs, локальные сокеты и серверные признаки одновременно.
Без root исправляют не отображение таблицы, а саму схему маршрутизации. Для чистого телефона используйте внешний шлюз. Если VPN остаётся в VpnService, настройте split routing так, чтобы проверяемое приложение действительно выходило через ожидаемую физическую сеть, но не считайте это скрытием локальных маршрутов: интерфейс и policy rules могут оставаться видимыми. Не удаляйте маршруты командами ip route на рабочем устройстве — Android и VPN-служба восстановят их, а связь можно оборвать. Отключение IPv6 у профиля уменьшает поверхность, но может привести к утечке IPv6 мимо VPN либо полной потере IPv6; сначала тестируйте в отдельной сети.
На root-устройстве нужен backend, который фильтрует источник данных, а не только libc. В upstream VPNHide kernel-бэкенды предназначены для ioctl, netlink и части route/procfs-векторов; Zygisk остаётся условным fallback. Не ставьте kmod и KPM одновременно: они могут перехватывать одни и те же функции ядра. Расширенные PMTU/MSS/qdisc/BPF-векторы заявлены VPNHide Next, но это внешнее заявление, которое надо воспроизвести на конкретном ядре. Filter должен согласованно закрывать procfs и RTM_GETROUTE IPv6. Подмена только /proc/net/ipv6_route оставляет netlink dump.
adb shell 'cat /proc/net/ipv6_route 2>/dev/null || cat /proc/self/net/ipv6_route 2>/dev/null'
adb shell ip -6 route show table all
После любого изменения сделайте force-stop RKNHardering и VPN-клиента, запустите их заново и повторите полный scan. Для Zygisk/Xposed/kernel-модулей обычно нужна перезагрузка. Сравнивайте не только эту строку, но и соседние сигналы: частичный hook часто создаёт несогласованность между API.
Сама проба выполняется с обычными правами приложения и не запрашивает root. ADB-команды ниже служат только для ориентира: adb shell работает под другим UID и может видеть больше или меньше, чем процесс приложения. Решающий тест — повторный запуск самой проверки после force-stop.
Удаление IPv6 routes вручную может оборвать DNS/NAT64 и не переживёт пересоздание VPN. Kernel seq-file hook с ошибкой может повредить чтение procfs.
Верните последнее изменение: отключите добавленный модуль или правило через штатный менеджер, перезагрузите устройство и повторите baseline. Не накладывайте новый hook поверх неизвестного состояния.
Высокая. Проверено по двум proc paths, token[9] и six-name list; kind high.
Статус стороннего решения не переносится автоматически на это устройство. Заявление разработчика модуля — это исходная гипотеза; подтверждением служит повторяемый результат RKNHardering на конкретной версии Android, прошивки и ядра.
native_signs_probe.cpp — нативная реализация проб.VpnNativeDetectorChecker.kt — deep VPN verdict и confidence.NativeSignalId.kt — полный реестр ID.NativeSignalCatalog.kt — категория, slug и mapping строк.Связанные сигналы: route-table, rtm-getlink-vpn, proc-if-inet6-vpn.