Da

[ArThirtyFour]

Короче , помнишь ту хуйню https://t.me/RKNHardering/591

• Я взял его апк через jadx
• Перенес его методы нативного детекта и занес в прогу

(кажется мне хуйня , но посмотрим)

Скрин приложу ниже:

[ArThirtyFour]

Часть иншуе это mostly C++20/23 suggestions (std::format, std::ranges::contains, std::string::contains) которые невозможно применить с C++17 NDK,

Так что @xtclovver забей хуй , работает все норм , проверено

[xtclovver]

Посмотрел PR на head 90ee1da1. Сборка проходит, но перед merge здесь нужно исправить несколько блокирующих проблем.

• P1 — нейтральные измерения превращаются в VPN evidence. В VpnNativeDetectorChecker.evaluateItem() любой распарсенный результат получает EvidenceItem(detected = true), включая udp_pmtu_ok, normal_pmtu, timing_oracle и backpressure. Эти строки мапятся в NATIVE_ROUTE и участвуют в матрице verdict как indirect hit. Поэтому обычное устройство с иностранным GeoIP может получить итоговый DETECTED.

• P1 — привязка сокетов стала fail-open. В ResolverBinding.kt ошибки реального SO_BINDTODEVICE проглатываются через runCatching. При EPERM, ENODEV или reflection-ошибке probe продолжит работу через default route, хотя вызывающий код считает сокет привязанным к выбранному интерфейсу. Это даёт неверные DNS/STUN/IP результаты и может отправить запрос по неправильному network path.

• P1 — часть high-confidence сигналов не влияет на итоговый verdict. bindtodevice_leak, getsockname_leak и udp_port_conflict_physical объявлены high-confidence, но получают источник NATIVE_SOCKET в VpnNativeDetectorChecker.kt. VerdictEngine не включает этот источник ни в R5, ни в R6 и не читает nativeSigns.detected напрямую. В результате Native-категория покажет detected, а общий verdict может не измениться.

• P1 — любой отказ UDP GSO считается подтверждённым VPN. detectGsoLargeSend() превращает любой отказ setsockopt(UDP_SEGMENT) или sendto() в gso_failed / gso_send_failed, а оба результата считаются high-confidence. Отсутствие поддержки UDP GSO или неподходящий размер сегмента — свойство ядра/сокета, а не доказательство VPN.

• P1 — любое правило с FRA_UID_RANGE считается split tunneling. detectSplitTunnelingUid() не проверяет VPN-интерфейс, таблицу или fwmark. Android netd создаёт UID-based rules также для физических, default, unreachable и OEM-сетей, поэтому штатное устройство может получить ложный DETECTED.

• P2 — тяжёлая backpressure-проба. detectBackpressure() выполняет до 50 000 вызовов sendto() по 1400 байт на каждый scan: около 70 МБ локального трафика и 50 тысяч syscall без поддержки cancellation.

Проверка точного head:

gradlew.bat test assembleDebug lint
BUILD SUCCESSFUL in 8m 11s
99 actionable tasks

Новых тестов для JNI-парсеров, source/verdict-матрицы и ошибки interface binding в PR нет. Я бы поставил Request changes: сначала разделить нейтральную телеметрию и реальные признаки, восстановить fail-closed binding, уточнить маршрутизацию evidence в VerdictEngine и добавить regression-тесты для чистого устройства без VPN.

[xtclovver]

Ещё забыл добавить экспорт этих данных в md и json

[sonarqubecloud]

Quality Gate passed

Issues
160 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
3.0% Duplication on New Code

See analysis details on SonarQube Cloud

[xtclovver]

вот так надо, LGTM