Не представляю как можно не разобраться в pandas, но ок
Видите, я вам об этом и толкую: у вас профдеформация. Вы не знаете, как можно не разобраться в pandas, а я не знаю, как написать hello world. Будем знакомы!
А как вы поняли что это то, что вам нужно? Возможно это было не то. Для тех кто не разбирается, большинство аналитики и бесполезно по этой причине.
Методика простая: на вход идет цсвшка, в середине заклинания из chatgpt, если на выходе нужный набор данных - значит сработало. На заре становления вайбкодинга в чатах на веб-странице нужно было еще руками тестировать. Сейчас не обязательно, если токенов не жалко.
Как пример которых полно
Я, собственно, не для себя сочинял - это меня упомянутый выше ValdikSS попросил, а я просто прервал очередную итерацию Claude, чтобы она вывалила то, что уже выяснила, в виде документа.
Хорошо когда есть ссылка/информация в которой рассказывают как и что сделать, чтобы даже agent-loop сценарии справлялись.
На тот момент такой информации еще не было, было только сообщение о проблеме. Защиту искал сам Claude Opus* на двух приложениях в эмуляторе, как я написал выше (была информация, на что SFA не проходят прямые подключения по getConnectionOwnerUid, другие кандидаты: NetworkStatsManager-based leak detection, decoy responses for known plain-HTTP IP-echo services, multiple tun interfaces / decoy tun, eBPF cgroup filter, и еще целая гора требующих рута костылей).
На данный момент уязвимость закрыта только в sing-box (SFA) и NekoBox. Из буквально всех VPN клиентов на Android. Ничто не мешает "кошерным" программистам вручную написать тоже самое, взяв либо реализацию из sing-box, либо мою (по смыслу это одно и тоже). Но вот никто пока не сподобился.
*
## Workstream 1: Test harness (sibling project)
Location:D:\skyfall-vpn-bypass-probe\ (sibling to skyfall-proxy-vpn, separate git repo, never merged into Skyfall).
Structure: Single Gradle project, two app modules.
```
skyfall-vpn-bypass-probe/
├── settings.gradle.kts
├── build.gradle.kts
├── victim/ # The "VPN" — owns the tun fd, runs the lookups
│ ├── build.gradle.kts
│ └── src/main/
│ ├── AndroidManifest.xml
│ ├── kotlin/.../ProbeVpnService.kt
│ ├── kotlin/.../MainActivity.kt
│ └── cpp/sockopt.c # JNI for SO_BINDTODEVICE (~30 lines)
└── attacker/ # The "excluded app" — INTERNET only, attacks via SO_BINDTODEVICE
- Builder configured with: address 10.99.99.1/24, MTU 1500, route 0.0.0.0/0, explicitly does NOT calladdAllowedApplication/addDisallowedApplication initially (to test the documented contract). A second test mode adds the victim app itself to the whitelist (the realistic case Skyfall ships).
- Variants exposed via UI buttons or intent extras:
- Variant V1: Default Builder, no whitelist. (Documents "all apps allowed" baseline.)
- Variant V2: Whitelist contains only the victim's own package (the attack target — should exclude the attacker).
- Variant V3: Same as V2 + allowBypass(false) explicitly. (Should be the default but pin it.)
- Variant V4: Same as V2 + allowFamily(AF_INET) only. (Tests whether explicit family restriction is also bypassed, as the user claims.)
- Loopback echo loop: read packets from tun fd, parse IPv4/TCP+UDP, swap src/dst, swap ports for TCP, send back. Just enough that the attacker's connect() completes and read()/write() work end-to-end. ICMP echo replies optional.
- Per-packet UID lookup: for each parsed flow seen, call ConnectivityManager.getConnectionOwnerUid(proto, local, remote) with the variant matrix below, log the returned UID and the tuple used, dedupe by 5-tuple to avoid log spam.
### attacker app (com.skyfall.probe.attacker)
- Permissions: INTERNET only. No VPN, no special perms.
- Single screen with buttons that trigger different attack methods:
- A1: Pure Java — Socket() then Os.setsockoptInt(...). (Will fail — SO_BINDTODEVICE not exposed.)
- A2: JNI — open AF_INET socket, setsockopt(SOL_SOCKET, SO_BINDTODEVICE, "tun0", 5), connect to 1.1.1.1:80, send GET / HTTP/1.0\r\nHost: 1.1.1.1\r\n\r\n, read response, log first 200 bytes.
- A3: Same as A2 but connect("1.1.1.1:443") and just check whether SYN-ACK arrives (no TLS, just kernel-level reachability).
- A4: Bind to a non-tun interface name (wlan0) for the negative control — should work normally without VPN, prove the JNI helper isn't broken.
- A5: Try Network.bindSocket(vpnNetwork) via ConnectivityManager.getAllNetworks() filtering for VPN transport. (Should fail with EPERM — confirms the existing defense.)
- A6 (the deanonymization payload): A2 but GET /ip HTTP/1.1\r\nHost: ifconfig.co\r\n\r\n to confirm the actual exit IP visible from the attacker. This is the screenshot for the bug report.
### Tuple variants for getConnectionOwnerUid (the scientific core)
For each flow read off tun0, query with these local IP variants and log results:
| ID | local IP | local port | Hypothesis being tested |
For each variant, query both IPPROTO_TCP and IPPROTO_UDP (and proto from the packet header). Log: tuple=(proto, local, remote) → uid=N per query.
Decision rule:
- Any variant returning the attacker's UID → hypothesis #1 wins (wrong-tuple). Document which variant works. Skyfall integration becomes viable, plan a follow-up.
- All variants return INVALID_UID consistently across many flows → hypothesis #2 likely (kernel ACL). One more sanity check: spawn a connection from the victim's own UID through the same tun and confirm at least the same-UID lookup works. If yes → strong evidence for cross-UID NETLINK_SOCK_DIAG ACL → close the avenue.
- Mixed results → document carefully, do not declare yet.
Вы говорите про разные вещи совершенно. Это как художники, которые говорят пользователям генеративных сеток "просто возьми карандаш". Я лично провозился пару дней в ковид в попытках заставить pandas выдать мне из csv-шной базы нужную строчку. Не осилил. Через неделю вышла буквально первая публичная версия ChatGPT, еще в браузере и со смешными лимитам по токенам в одном сообщении, и выдала мне рабочий код.
А сейчас я даю Claude Code ссылку на обнаруженную уязвимость в VpnService.Builder.addAllowedApplicationоно изучает сорцы моего VPN-клиента на эту тему, сочиняет репорт в гугл, собирает два тестовых приложения attacker и victim, тестирует в эмуляторе оба полностью автоматически по variant matrix, находит что у attacker uid=-1 и патчит мой клиент так, чтобы такие запросы шли напрямую. Это все оно делало, пока я сидел на основной не-IT работе и приглядывал за этой штукой по RDP. В итоге уязвимость по факту нулевого дня (?) закрыта мной день в день. Я не уверен, что хоть кто-то из разработчиков приложений из списка в той статье уже пропатчил свой клиент. Вот, например, singbox пока патчат.
«Профессионалы уже эффективны, LLM не помогают [повысить им эффективность]»
Вот с этим могу согласиться, ибо не профессионал - вам виднее. Хотя широко известный в узких кругах @ValdikSSписал следующее:
Скрытый текст
Я дал ассистенту доступ к одноплатнику, к которому подключён принтер, чтобы он нашел и исправил баг в USB-подсистеме ядра(!), и он справился в течение часа за несколько итераций. Он сам выдвигал гипотезы, правил код, компилировал ядро, загружал его на одноплатник, перезагружал его, проверял, смотрел, что изменилось, читал kernel log из uart’а в случае проблем (пару раз сломал DMA).
Справился бы я самостоятельно? Однозначно, я примерно знал куда копать, где отлаживать, на какие вещи обратить внимание. Но я только поверхностно знал причину проблемы и систему USB в целом, у меня на это ушло бы несколько полных рабочих дней (и чтение много-сотен-страничных спецификаций USB), а у ассистента ушел час.
Справился бы ассистент без моих знаний и подготовки оборудования? Очень вряд ли — он работает примерно как обычный junior или студент, т.е. ему нужно организовать «рабочее место» и составить ТЗ, он не может просто так взять и написать целиком рабочий код в один пресест.
Я теперь могу исправлять реальные баги в FOSS на языках и в проектах, которые не знаю в полной мере, чтобы решить проблему с наскока. Иными словами, вместо заведения issue и ожидания дней-недель-месяцев для не сильно глубоко технической проблемы, я могу решить ее сам с помощью ассистента в течение минут.
То же самое с реверс-инжинирингом — анализировать чужой скомпилированный код, алгоритмы и прочее теперь еще значительно проще, произошла вторая революция (первой был Hex-Rays).
Так что ваша уверенность в вашей позиции меня несколько смущает.
Это просто по результатом нейросетевого теста, который Claude гонял на эмуляторе, пока я работу работал. В принципе, ничто не мешает использовать подход NekoBox и просто роутить пакеты по uid=-1, если в клиенте есть механизм роутинга:
Скрытый текст
tun2http opens every upstream TCP/UDP socket with protect_socket() → VpnService.protect(fd). That call detaches the kernel socket from the VPN routing table, so every upstream connection the native engine makes is already physically going through the device's real network. For port-443 flows it then connects to the local HTTPS proxy bridge instead of the real destination. For non-443 flows (see tcp.c:1230) it already connects direct (redirect = NULL). So the "direct bypass" behaviour for port 443 is a one-line change: set redirect = NULL when the session is marked uid=-1.
Но если такого механизма нет, то тогда только дропать соединение.
Необходимо признать - найденная уязвимость приводит к неизбежной утечке внешнего ip адреса VPN-сервера. На этом участке мы проиграли. И не нужно тратить время, чтобы принимать неработающие полумеры. Это и есть главный вывод из статьи. Вот из этого и нужно исходить далее.
Не совсем. Тесты показали, что атакующий посылает пакеты, которые ConnectivityManager.getConnectionOwnerUid() отлавливает как uid=-1. Это универсальный маркер для пакетов, которые самостоятельно решили пойти в VPN без разрешения. Все остальные приложения получают свой UID отличный от 0 и -1, например 10235. Таким образом, все такие пакеты можно обнаруживать с оговоркой: первый пакет в любом случае успеет пройти до того, как вы оборвете соединение. Но после этого - пожалуйста, просто гасим VPN по первому прошедшему пакету и дальше ищем виноватого.
Тесты на эмуляторе (Android 16) и одном физическом устройстве (Android 13) поймали несколько false positives DoH до 8.8.4.4, все они при желании отфильтровываются.
План из под нейронки
### 2. Surface uid=-1 from getConnectionOwnerUid as a user-facing alert (RECOMMENDED — Path A confirmed viable)
This is now the recommended ship target. Path A revision (2026-04-07, see [vpn-bypass-tun-binding.md](vpn-bypass-tun-binding.md)) confirmed empirically that calling ConnectivityManager.getConnectionOwnerUid from Skyfall's own service UID, on every new flow read off Skyfall's tun fd, returns:
- The real owning UID for any kernel-routed flow, including from other UIDs (verified for Chrome uid=10154, Skyfall's own bridge uid=10235).
- -1 (Process.INVALID_UID) specifically and only for SO_BINDTODEVICE'd flows, regardless of caller UID.
The discriminator is the bind mechanism, which is the exact property that makes the attack distinguishable from legitimate traffic. There were zero false positives observed in the production verification run — every Chrome browsing flow, every Skyfall bridge flow, every legit whitelisted app flow resolved to its real UID.
#### Implementation
Already partially in place — Path A added a JNI callback notify_new_flow_check in app/src/main/cpp/tcp.c that fires at the new-session SYN point and calls Tun2HttpVpnService.onNewFlowCheck(proto, localIp, localPort, remoteIp, remotePort). The handler queries getConnectionOwnerUid and currently logs to the PathA tag. Productionising it requires:
1. Whitelist comparison. When uid is a real value, check it against the user's pref_vpn_allowed_application (or pref_vpn_disallowed_application in blacklist mode). Real UIDs that match the policy are fine. Real UIDs that violate the policy are also anomalies worth surfacing (this would only happen if Android's per-UID routing rule had a bug — never observed but a useful invariant check).
2. uid == -1 is the attack signal. Increment a counter; record (proto, dst, port, timestamp).
3. Sliding window + thresholding. First-flow vs sustained-pattern policies. A first-flow notification is the strongest possible signal because the attack only needs one round-trip to leak the exit IP — alerting after N events misses the exfiltration. Recommendation: alert on the very first uid=-1 event of any session, with optional rate-limiting to avoid notification spam if a misbehaving system service somehow generates many.
4. Settings toggle: detection vs hard-stop.
- Detection mode (default for first release) — show a persistent notification "Untracked traffic detected on VPN — your exit IP may be exposed", with a tap-target to a details screen showing the destination IP/port and timestamp.
- Paranoid mode (opt-in) — immediately call stopVpnWithError() on the first uid=-1 flow. Accepts the (small) risk of a stray system-service flow killing the VPN in exchange for a hard fail-stop before the leak completes. Recommend offering this only to users who explicitly opt in via a Settings toggle.
5. Localised strings — both English and Russian, following the existing values/strings.xml and values-ru/strings.xml pattern.
#### Pros
- No special permission required (getConnectionOwnerUid is part of the public framework API and the VPN owner has access by virtue of holding the tun fd).
- No polling. Triggered by the actual event (the SYN arriving at the native tun reader).
- Cheap (~100 lines of Kotlin + the JNI callback already in place from Path A).
- Catches the attack at the moment it happens — not minutes later via stats buckets.
- Empirically validated discriminator. The smoking gun: in the Path A verification run, Skyfall's own bridge → uid=10235, attacker SO_BINDTODEVICE → uid=-1, run side-by-side on the same tun in the same second. No ambiguity.
- Independent confirmation in another VPN client: [sing-box's process detection](https://github.com/SagerNet/sing-box) logs router: failed to search process: android: connection owner not found for exactly this case — same observation, different codebase.
#### Cons
- Detection, not prevention. The TCP handshake completes before onNewFlowCheck fires, and a fast attacker can complete an HTTPS round-trip in 50–100ms (verified in the smoking-gun ifconfig.co run). Paranoid mode mitigates this by tearing down the VPN on the first event but cannot retroactively prevent the leaked first request.
- False-positive risk on edge cases is unmeasured at scale. Path A saw zero false positives in the verification run on a single emulator over a few minutes of mixed Chrome + Skyfall traffic. Long-term real-device behaviour may surface rare edge cases (e.g. very-short-lived kernel sockets evicted before the lookup happens, certain system services). Recommend a 1–2 week telemetry window with the detection-only mode before shipping paranoid mode by default.
- A sophisticated attacker could skip SO_BINDTODEVICE entirely if they discovered another path into the tun. None known today (Path A ruled out Network.bindSocket — it returns EPERM against the VPN network), but the workaround only catches the specific attack class we know about.
**Verdict:**ship it. This is the only confirmed-viable defensive signal we have. Detection-only by default, paranoid mode behind a Settings toggle. Estimated effort: half a day to productionise (the JNI callback and getConnectionOwnerUid plumbing already exist from Path A; what's left is the policy comparison, sliding window, notification UI, Settings toggle, and i18n strings).
Могу залить репу с victim и attacker для тестов, если кому интересно.
Палка о двух концах: если бы никто не писал такие статьи, большая часть народу уже бы отвалилась и переехала в MAX.
Это было два года назад, нет?
Потому что все проблемные деды во власти по большей части за 70?
Видите, я вам об этом и толкую: у вас профдеформация. Вы не знаете, как можно не разобраться в pandas, а я не знаю, как написать hello world. Будем знакомы!
Методика простая: на вход идет цсвшка, в середине заклинания из chatgpt, если на выходе нужный набор данных - значит сработало. На заре становления вайбкодинга в чатах на веб-странице нужно было еще руками тестировать. Сейчас не обязательно, если токенов не жалко.
Я, собственно, не для себя сочинял - это меня упомянутый выше ValdikSS попросил, а я просто прервал очередную итерацию Claude, чтобы она вывалила то, что уже выяснила, в виде документа.
На тот момент такой информации еще не было, было только сообщение о проблеме. Защиту искал сам Claude Opus* на двух приложениях в эмуляторе, как я написал выше (была информация, на что SFA не проходят прямые подключения по getConnectionOwnerUid, другие кандидаты: NetworkStatsManager-based leak detection, decoy responses for known plain-HTTP IP-echo services, multiple tun interfaces / decoy tun, eBPF cgroup filter, и еще целая гора требующих рута костылей).
На данный момент уязвимость закрыта только в sing-box (SFA) и NekoBox. Из буквально всех VPN клиентов на Android. Ничто не мешает "кошерным" программистам вручную написать тоже самое, взяв либо реализацию из sing-box, либо мою (по смыслу это одно и тоже). Но вот никто пока не сподобился.
*
Они пока еще со своими TURN-ами не разобрались, так что время есть.
Знаете почему Шекспир старость назвал "вторым детством"?
Это список для самопального клиента на HTTPS/VK/WB, который я все не решусь вывалить в открытый доступ.
Вы говорите про разные вещи совершенно. Это как художники, которые говорят пользователям генеративных сеток "просто возьми карандаш". Я лично провозился пару дней в ковид в попытках заставить pandas выдать мне из csv-шной базы нужную строчку. Не осилил. Через неделю вышла буквально первая публичная версия ChatGPT, еще в браузере и со смешными лимитам по токенам в одном сообщении, и выдала мне рабочий код.
А сейчас я даю Claude Code ссылку на обнаруженную уязвимость в
VpnService.Builder.addAllowedApplicationоно изучает сорцы моего VPN-клиента на эту тему, сочиняет репорт в гугл, собирает два тестовых приложения attacker и victim, тестирует в эмуляторе оба полностью автоматически по variant matrix, находит что у attacker uid=-1 и патчит мой клиент так, чтобы такие запросы шли напрямую. Это все оно делало, пока я сидел на основной не-IT работе и приглядывал за этой штукой по RDP. В итоге уязвимость по факту нулевого дня (?) закрыта мной день в день. Я не уверен, что хоть кто-то из разработчиков приложений из списка в той статье уже пропатчил свой клиент. Вот, например, singbox пока патчат.Вот с этим могу согласиться, ибо не профессионал - вам виднее. Хотя широко известный в узких кругах @ValdikSSписал следующее:
Скрытый текст
Так что ваша уверенность в вашей позиции меня несколько смущает.
Я и без Интернета не уверен, что готов жить, я вам честно скажу.
Можно, но если хоть какую-то активность будете проявлять, то выгонят ссаными тряпками. Это еще в 2016 было, щас наверное сразу в автозак упакуют.
Они видят включен или нет ВПН в системе как флаг true или false
LLM за сто баксов напишет мне сервис, а профессионал - нет. Только индус, и качество там будет значительно хуже LLM-ного. Боинг не даст соврать.
Это просто по результатом нейросетевого теста, который Claude гонял на эмуляторе, пока я работу работал. В принципе, ничто не мешает использовать подход NekoBox и просто роутить пакеты по uid=-1, если в клиенте есть механизм роутинга:
Скрытый текст
tun2httpopens every upstream TCP/UDP socket withprotect_socket()→VpnService.protect(fd). That call detaches the kernel socket from the VPN routing table, so every upstream connection the native engine makes is already physically going through the device's real network. For port-443 flows it then connects to the local HTTPS proxy bridge instead of the real destination. For non-443 flows (seetcp.c:1230) it already connects direct (redirect = NULL). So the "direct bypass" behaviour for port 443 is a one-line change: setredirect = NULLwhen the session is markeduid=-1.Но если такого механизма нет, то тогда только дропать соединение.
Ручные заявки РКН собирает уже давно, кто до сих пор не спохватился - тому не сильно нужно.
Не совсем. Тесты показали, что атакующий посылает пакеты, которые
ConnectivityManager.getConnectionOwnerUid()отлавливает какuid=-1. Это универсальный маркер для пакетов, которые самостоятельно решили пойти в VPN без разрешения. Все остальные приложения получают свой UID отличный от 0 и -1, например 10235. Таким образом, все такие пакеты можно обнаруживать с оговоркой: первый пакет в любом случае успеет пройти до того, как вы оборвете соединение. Но после этого - пожалуйста, просто гасим VPN по первому прошедшему пакету и дальше ищем виноватого.Тесты на эмуляторе (Android 16) и одном физическом устройстве (Android 13) поймали несколько false positives DoH до 8.8.4.4, все они при желании отфильтровываются.
План из под нейронки
### 2. Surface
uid=-1fromgetConnectionOwnerUidas a user-facing alert (RECOMMENDED — Path A confirmed viable)This is now the recommended ship target. Path A revision (2026-04-07, see [
vpn-bypass-tun-binding.md](vpn-bypass-tun-binding.md)) confirmed empirically that callingConnectivityManager.getConnectionOwnerUidfrom Skyfall's own service UID, on every new flow read off Skyfall's tun fd, returns:- The real owning UID for any kernel-routed flow, including from other UIDs (verified for Chrome
uid=10154, Skyfall's own bridgeuid=10235).-
-1(Process.INVALID_UID) specifically and only for SO_BINDTODEVICE'd flows, regardless of caller UID.The discriminator is the bind mechanism, which is the exact property that makes the attack distinguishable from legitimate traffic. There were zero false positives observed in the production verification run — every Chrome browsing flow, every Skyfall bridge flow, every legit whitelisted app flow resolved to its real UID.
#### Implementation
Already partially in place — Path A added a JNI callback
notify_new_flow_checkinapp/src/main/cpp/tcp.cthat fires at the new-session SYN point and callsTun2HttpVpnService.onNewFlowCheck(proto, localIp, localPort, remoteIp, remotePort). The handler queriesgetConnectionOwnerUidand currently logs to thePathAtag. Productionising it requires:1. Whitelist comparison. When
uidis a real value, check it against the user'spref_vpn_allowed_application(orpref_vpn_disallowed_applicationin blacklist mode). Real UIDs that match the policy are fine. Real UIDs that violate the policy are also anomalies worth surfacing (this would only happen if Android's per-UID routing rule had a bug — never observed but a useful invariant check).2.
uid == -1is the attack signal. Increment a counter; record (proto, dst, port, timestamp).3. Sliding window + thresholding. First-flow vs sustained-pattern policies. A first-flow notification is the strongest possible signal because the attack only needs one round-trip to leak the exit IP — alerting after N events misses the exfiltration. Recommendation: alert on the very first
uid=-1event of any session, with optional rate-limiting to avoid notification spam if a misbehaving system service somehow generates many.4. Settings toggle: detection vs hard-stop.
- Detection mode (default for first release) — show a persistent notification "Untracked traffic detected on VPN — your exit IP may be exposed", with a tap-target to a details screen showing the destination IP/port and timestamp.
- Paranoid mode (opt-in) — immediately call
stopVpnWithError()on the firstuid=-1flow. Accepts the (small) risk of a stray system-service flow killing the VPN in exchange for a hard fail-stop before the leak completes. Recommend offering this only to users who explicitly opt in via a Settings toggle.5. Localised strings — both English and Russian, following the existing
values/strings.xmlandvalues-ru/strings.xmlpattern.#### Pros
- No special permission required (
getConnectionOwnerUidis part of the public framework API and the VPN owner has access by virtue of holding the tun fd).- No polling. Triggered by the actual event (the SYN arriving at the native tun reader).
- Cheap (~100 lines of Kotlin + the JNI callback already in place from Path A).
- Catches the attack at the moment it happens — not minutes later via stats buckets.
- Empirically validated discriminator. The smoking gun: in the Path A verification run, Skyfall's own bridge →
uid=10235, attacker SO_BINDTODEVICE →uid=-1, run side-by-side on the same tun in the same second. No ambiguity.- Independent confirmation in another VPN client: [sing-box's process detection](https://github.com/SagerNet/sing-box) logs
router: failed to search process: android: connection owner not foundfor exactly this case — same observation, different codebase.#### Cons
- Detection, not prevention. The TCP handshake completes before
onNewFlowCheckfires, and a fast attacker can complete an HTTPS round-trip in 50–100ms (verified in the smoking-gun ifconfig.co run). Paranoid mode mitigates this by tearing down the VPN on the first event but cannot retroactively prevent the leaked first request.- False-positive risk on edge cases is unmeasured at scale. Path A saw zero false positives in the verification run on a single emulator over a few minutes of mixed Chrome + Skyfall traffic. Long-term real-device behaviour may surface rare edge cases (e.g. very-short-lived kernel sockets evicted before the lookup happens, certain system services). Recommend a 1–2 week telemetry window with the detection-only mode before shipping paranoid mode by default.
- A sophisticated attacker could skip SO_BINDTODEVICE entirely if they discovered another path into the tun. None known today (Path A ruled out
Network.bindSocket— it returnsEPERMagainst the VPN network), but the workaround only catches the specific attack class we know about.**Verdict:** ship it. This is the only confirmed-viable defensive signal we have. Detection-only by default, paranoid mode behind a Settings toggle. Estimated effort: half a day to productionise (the JNI callback and
getConnectionOwnerUidplumbing already exist from Path A; what's left is the policy comparison, sliding window, notification UI, Settings toggle, and i18n strings).Могу залить репу с victim и attacker для тестов, если кому интересно.
Проходили уже, все причастные просто говорят "мы ничего не блокируем", а "эксперты" подтверждают. В особо запущенных случаях вообще говорят, что не ваше дело, пусть жалуются владельцы сайтов.
Изымают домены.
В контексте поиска выходного IP - да, а вот постучать на "недоступный" домен TG и увидеть, что он почему-то доступен - запросто.
Я уже какое-то время назад перешел на вебвью, надоело бекпортить фиксы.