ID:
ROUTE_COUNTКатегория: Маршруты и сетевой стек Статус в RKNHardering 2.10.0: Активная проверка Роль в вердикте: Низкая
Эта страница описывает фактическую реализацию RKNHardering 2.10.0. Здесь отдельно указано, что можно сделать без root, что требует root, а также где способ только уменьшает один сигнал, но не скрывает VPN целиком.
detectRouteCount() вызывает общий netlinkRouteDump(0), считает строки с prefix route| и уникальные значения после |dev=. Всегда выдаётся route_count|total=N interfaces=M, даже N=0. Checker помечает kind informational low.
Строка создаётся при каждом завершившемся вызове функции; это telemetry, а не anomaly threshold.
Числа нужны для baseline и поиска резких различий после включения VPN/модуля. Само количество маршрутов не имеет универсальной нормы и не влияет на detected.
Как строка влияет на отчёт: Строка информационная либо диагностическая. Она нужна для сравнения запусков, но сама по себе не доказывает VPN или вмешательство.
Snapshot зависит от Wi‑Fi/mobile, IPv4/IPv6, OEM, tethering, profiles и момента запуска. Функция считает только строки, которые смог сформировать внутренний parser; ошибка netlink может выглядеть как ноль.
Важно оценивать эту строку вместе с соседними сигналами. Один чистый API не перекрывает Java Binder, libc, raw netlink/syscall, procfs/sysfs, локальные сокеты и серверные признаки одновременно.
Для диагностического сигнала сначала ничего не «исправляйте». Запишите baseline на том же устройстве без VPN, затем повторите с VPN при одинаковой сети, температуре и нагрузке. Только воспроизводимая разница между сериями пригодна для анализа. Одиночное значение MTU, времени или GSO не является доказательством. Снимайте минимум 3–5 запусков без VPN и с VPN на одной сети. Не удаляйте маршруты ради совпадения числа.
Root-модуль может изменить этот показатель, но настройка ради конкретного числа легко нарушает TCP/UDP, DNS, звонки или энергопотребление. VPNHide Next заявляет фильтрацию ряда косвенных параметров, однако такие возможности нужно проверять отдельно от базового сокрытия интерфейсов. Не включайте максимальный набор kernel hooks до получения чистого baseline и рабочего отката. Если filter меняет count, он должен сохранять согласованность с RTM_GETLINK, getifaddrs и реальными route lookups; цель — не фиксированное N.
adb shell 'ip -4 route show table all; ip -6 route show table all'
adb shell 'ip -o link show | wc -l'
Сравнивайте тенденцию, а не точное равенство shell и app snapshots.
После любого изменения сделайте force-stop RKNHardering и VPN-клиента, запустите их заново и повторите полный scan. Для Zygisk/Xposed/kernel-модулей обычно нужна перезагрузка. Сравнивайте не только эту строку, но и соседние сигналы: частичный hook часто создаёт несогласованность между API.
Сама проба выполняется с обычными правами приложения и не запрашивает root. ADB-команды ниже служат только для ориентира: adb shell работает под другим UID и может видеть больше или меньше, чем процесс приложения. Решающий тест — повторный запуск самой проверки после force-stop.
Ручное удаление routes может немедленно оборвать ADB over network, DNS, мобильную связь и VPN.
Не меняйте routing для информационной строки. Если уже меняли, отключите экспериментальный модуль и перезапустите сеть/устройство.
Низкая. Проверено по unconditional result и INFORMATIONAL_KINDS.
Статус стороннего решения не переносится автоматически на это устройство. Заявление разработчика модуля — это исходная гипотеза; подтверждением служит повторяемый результат RKNHardering на конкретной версии Android, прошивки и ядра.
native_signs_probe.cpp — нативная реализация проб.VpnNativeDetectorChecker.kt — deep VPN verdict и confidence.NativeSignalId.kt — полный реестр ID.NativeSignalCatalog.kt — категория, slug и mapping строк.Связанные сигналы: route-table, vpn-policy-rules-netlink, trim-oracle.