ID:
INTERFACE_ENUMERATIONКатегория: Интерфейсы Статус в RKNHardering 2.10.0: Активная проверка Роль в вердикте: Смешанная
Эта страница описывает фактическую реализацию RKNHardering 2.10.0. Здесь отдельно указано, что можно сделать без root, что требует root, а также где способ только уменьшает один сигнал, но не скрывает VPN целиком.
NativeInterfaceProbe.collectInterfaces() получает интерфейсы через нативный getifaddrs(), объединяет записи по имени и добавляет индекс, MTU, flags, тип ARP и адреса. evaluateInterfaces() всегда выводит сводку количества интерфейсов и активных интерфейсов. Затем активные имена сравниваются с шаблонами tun*, tap*, wg*, ppp*, utun*, zt*, tailscale*, svpn*, gre*, l2tp*, he-ipv6*.
Высокодостоверное срабатывание создаётся только для интерфейса isUp=true, имя которого после нормализации совпало с VPN-шаблоном. Пустой список интерфейсов даёт review низкой уверенности; обычная сводка информационная.
Строка с конкретным VPN-like именем — сильный локальный признак TUN/WireGuard/PPP-пути. Сводка без такого имени ничего не доказывает и нужна для сравнения запусков.
Как строка влияет на отчёт: Один и тот же ID используется и для информационной сводки, и для подозрительных строк. Итог зависит от конкретного detail и ветки checker.
Имена OEM и корпоративных интерфейсов могут совпасть с шаблоном. Обратная проблема тоже возможна: переименованный туннель не попадёт под шаблон, но его выдадут тип TUN/TAP, netlink, маршруты или несогласованность JVM/native.
Важно оценивать эту строку вместе с соседними сигналами. Один чистый API не перекрывает Java Binder, libc, raw netlink/syscall, procfs/sysfs, локальные сокеты и серверные признаки одновременно.
Самый надёжный non-root способ — не создавать VPN-интерфейс на проверяемом телефоне: вынести туннель на роутер, travel-router, отдельный телефон-шлюз или другой узел сети. Per-app bypass в VpnService меняет маршрут трафика выбранного приложения, но establish() всё равно создаёт системный VPN-интерфейс, поэтому локальная проверка интерфейсов может продолжить срабатывать. Режим локального HTTP/SOCKS-прокси без TUN иногда убирает этот конкретный вектор, но оставляет порты, proxy-настройки и не покрывает приложения, которые игнорируют прокси.
Для лабораторного сокрытия обычно нужен системный Java-слой и один native-бэкенд. У VPNHide это APK + Vector/LSPosed со scope только System Framework и ровно один из kmod, KPM или Zygisk. Для проверки, которая может идти прямым syscall или netlink, предпочтительнее kmod/KPM: userspace-хук Zygisk можно обойти и он оставляет след внутри процесса. Сначала изучите карту покрытия VPNHide и скачивайте сборки только из официального release. VPNHide Next заявляет более широкое покрытие, но сам предупреждает о возможных bootloop и kernel panic; его следует проверять только на тестовом устройстве.
adb shell ip -details link show
adb shell ip -br address show
adb shell cat /proc/net/dev
Сравните имя, состояние UP, индекс и MTU с деталью RKNHardering. Помните, что shell UID не равен UID приложения; окончательно проверяйте после adb shell am force-stop com.notcvnt.rknhardering и повторного запуска.
После любого изменения сделайте force-stop RKNHardering и VPN-клиента, запустите их заново и повторите полный scan. Для Zygisk/Xposed/kernel-модулей обычно нужна перезагрузка. Сравнивайте не только эту строку, но и соседние сигналы: частичный hook часто создаёт несогласованность между API.
Сама проба выполняется с обычными правами приложения и не запрашивает root. ADB-команды ниже служат только для ориентира: adb shell работает под другим UID и может видеть больше или меньше, чем процесс приложения. Решающий тест — повторный запуск самой проверки после force-stop.
Внешний шлюз меняет весь сетевой путь. Root/kernel-фильтрация может вызвать потерю сети, зависание getifaddrs() или bootloop при несовместимом ядре.
Верните последнее изменение: отключите добавленный модуль или правило через штатный менеджер, перезагрузите устройство и повторите baseline. Не накладывайте новый hook поверх неизвестного состояния.
Смешанная. Проверено по evaluateInterfaces(), NetworkInterfacePatterns и C++-сборщику интерфейсов. Основной signal покрыт unit-тестами каталога и checker.
Статус стороннего решения не переносится автоматически на это устройство. Заявление разработчика модуля — это исходная гипотеза; подтверждением служит повторяемый результат RKNHardering на конкретной версии Android, прошивки и ядра.
NativeSignsChecker.kt — основной native/legacy verdict.native_signs_probe.cpp — нативная реализация проб.NetworkInterfacePatterns.kt — правила имён интерфейсов.NativeSignalId.kt — полный реестр ID.NativeSignalCatalog.kt — категория, slug и mapping строк.Связанные сигналы: tuntap-type, jvm-native-mismatch, getifaddrs-vpn, rtm-getlink-vpn.