Не уверен, ибо:
“Серверная проверка – устройство зарубежом; клиентская проверка –
устройство в РФ. Решение: Выявлен VPN.”
В принципе можно отключить разрешение на GPS, чтобы избежать проверки, не зависящие от интернета. Но тогда вполне себе могут требовать такое разрешение для работы приложения в целом под предлогом безопасности.
Возможно, проверки на симку тоже осуществят.
Да, можно. Но, если мне не изменяет память, какие-то банки не работают без геолокации. Но самое главное это яндекс карты, а без них в России грустно…
Сейчас получается, что скрыть факт использования на смартфоне невозможно (без рута по крайней мере).
Палить будут по разным признакам и их комбинациям.
Начиная с того, что tun-интерфейс не скроешь, по имени пакета, по наличию локального прокси.
Рабочим вариантом видится туннель до дома (резидентский ip), где далее будет настроена маршрутизация только к незаконно цензурируемому.
Да. Но это, к счастью, косвенные признаки. Основное решение, согласно документу, принимается по основным признакам. Основное требование “впн нет” - вы заходите на Ру сервисы с провайдерского айпи и ваш телефон определяет свое положение как РФ.
Если бы split-tunneling на телефоне работал идеально, тогда вообще не было бы проблем. Но, в свете последних новостей, к этому есть вопросы…
Нет, возможно активно простучать интерфейсы запросом куда-нибудь.
В том-то и драма, что так устроено в андроиде.
Согласен, но все же я опираюсь на текст документа. Там четко прописаны основные признаки и косвенные, которые играют роль только в пограничных случаях.
Там же написано про проверку наличия интерфейсов. А это фактически автоматически означает, что их будут активно тыкать, а мы даже не увидим этого.
Не говоря о том, что подлинность документа неизвестна и могут быть дополнительные разъяснения с грифами и т.п.
В данном случае лучше перебдеть.
У меня стиль такой, я же не нейросеть-бот чтобы <…>.
Во-вторых, эта категоричность – знак к тому, что не стоит связывать эти случаи (следование местному законодательству / регуляторам – пусть оно 100 раз неправильное) И вредительство пользователю (шпионаж).
Нет, закона “шпионить” – нет. Это край, когда App Store вообще может допустить приложение, иначе это нарушит их политики.
Это топ уровень по безопасности пока (монолитная, проверенная временем и боевым опытом крепость), после GrapheneOS (который уже заточен на утечки в Android) на единственной линейке Pixel (официально).
Кроме само собой подразумевающихся VPN статусов (которые нужны для подсказок приложению зачем-то) в системе ничего нет. Про “выбрать любой интерфейс” – в iOS – тоже наверняка не совсем так как вы думаете (без jailbreak) – весь трафик итак бы шел через туннель, кроме Per-App на MDM устройствах (а там нет аналога Android-метода Network.bindSocket и вообще не увидел какое API для этого нужно на iOS, поправьте если это не так). (Я пока не увидел чтобы кто-то без jailbreak смог это сделать на iOS).
Про локальные порты – это идиотизм клиентов, ошибка дизайна (слушать локальный порт – очевидно подразумевается, что все кто может им воспользуются – это все кому не лень).
Кстати на iOS масскан портов сильно ограничен высокоуровневыми API (что сильно замедляет скан, в отличии от Android) – и будет расцениваться как подозрительная активность.
Для этого хотя бы разделение сетевого стека нужно. А это – накладно по батарее, вот и не делают.
На iOS – я пока не увидел какое конкретно API для этого нужно использовать. Судя по всему, на iOS нет способа сделать также как на Android (кроме своих интерфейсов, а не чужих). Если есть – поправьте.
Есть разрешение – Local Network – но оно для физических сетей.
Вот именно что в ведроиде, а не на iOS. Да, какие-то признаки на iOS сливаются, но только для нормальной работы других приложений, полная изоляция всё равно не предусматривается (в рамках дизайна).
Есть методичка вместе с угрозой об отчислении из белого списка (и не только эта угроза), что сделает сервис неконкурентоспособным. Чем конкретно это отличается от закона?
В том же Китае в App Store действуют другие правила, и они меняются по требованиям регуляторов и в том числе.
Опять, ваше мнение. Не констатируйте его как факт.
Нет. Теперь сами обвинения делаете, но доказательств нет.
Это не я так думаю, я цитировал ValdikSS:
А он прав, подобный функционал и на iOS существует (IP_BOUND_IF). И там тоже единственное решение - включение опции, которая подобна “Block connections without VPN”. Причём, в отличие от Android, где уже установлено, что можно заставить весь трафик идти через direct или просто заблочить его при насильном привязывании к TUN-интерфейсу приложением, которое исключено через per-app split tunneling, в iOS пока решение непонятное, кроме того, как наглухо заблокировать весь трафик, который идёт мимо TUN-интерфейса (а это вполне себе может стать проблемой в будущем, если шпионские приложения из-за этого откажутся работать).
Также на более новых версиях Android Network.bindSocket и не нужен для выявления, простого curl-запроса хватает. Но на Android и решение уже нашли.
На уровне ОС или на уровне регулятора магазина приложений? Реглуятор-то и на Android расценит массовое сканирование портов как подозрительную активность.
пока что единственный по настоящему работающий вариант - покупка второго телефона и цифровая гигиена чтобы не замазываться анальными зондами от гебухи в которые превратятся все приложения от компаний неспособных эмигрировать.
одни телефоны для кухонь другие для улиц.
Еще есть в методичке упоминается альернативный вариант геолокации через PLMN .
PLMN (англ. Public Land Mobile Network) — Идентификатор зоны обслуживания мобильной сети. Идентификатор PLMN состоит из MCC и MNC.
MCC (англ. Mobile Country Code)
MNC (англ. Mobile Network Code)
Это возможо только если дать приложению одновременно доступ к вызовам и местоположению.
Да и даже так приложение увидит код страны MNC (250), код оператора МТС (01) и PLMN 25001.
У меня вообще без никаких разрешений приложение определяет MCC местной сети, MCC самой сим-карты и состояние роуминга.
Edit: Тестил с двумя сим-картами. Почему-то на роуминговой сами значения MCC не меняются, но страну происхождения сим-карты (и состояние роуминга) всё равно правильно определяет.
Показывается к какому Вы партнеру провайдеру подключены. То есть Вы условно купили сим Polska Orange и в РФ она будет идти через партнера Мегафон, поэтому MCC у Вас и Мегафоновский, а не Orange. Я думаю Вы это имели в виду
И что это даёт? Чем это заставит модераторов Apple пропустить шпиона в AppStore? То что им вдруг жалко их станет?
Тем, что нет закона, вставлять шпионов в приложения.
А есть законы вредить интернету?
Нет, но это разное. Контроль/политики на уровне инфраструктуры и слежка на уровне личных устройств – разные вещи.
И сколько вы приложений знаете, имеющих внутри себя шпионов, находящихся в китайском AppStore?
“Опять, обвинения делаете (в сторону Apple), но доказательств нет.”
Я в общих рамках говорил, вопреки всеобщим заблуждениям.
У Вас есть доказательства, что данное утверждение действительно распространяется на iOS также как на Android?
То есть подтверждение, что данный тезис:
Является верным для IP_BOUND_IF
И данный тезис:
Является неверным для IP_BOUND_IF (то есть не требуется для использования)?
У меня вот есть пока источник, где его используют лишь для физических сетей.
Читайте дословно, цитирую буквально ещё в одном источнике:
This function will successfully connect so long as the interface is one of the
utuninterfaces created by the VPNs, or a physical interface that is not used by the VPNs.
Думаю ValdikSS на самом деле включил iOS только потому что технически это возможно (при соблюдении некоторых условий), а не то что это работает также дыряво как на Android. Вы просто не совсем правильно его поняли, а часть сами додумали. Он не заявлял что IP_BOUND_IF можно использовать для virtual interface чужих приложений – лично я этого не видел в посте, он этого не говорил, с чего вы это взяли – я не знаю.
ахуеть я ванганул как
Запрос разрешений был из-за того, что разные версии android реагируют по разному на запросы чувствительных данных, без разрешения программа всё равно будет пытаться получить эти данные, если системы их отдала, то покажет их.
Регулятор какой будет то? RuStore?) Я думаю они не будут противодействовать такому
Могу дать подсказку, пробуйте искать в не задокументированных API вызовах, их достаточно много, я думаю Вы сможете найти что-то интересное. Говоря заранее, что такие приложения в AppStore не попадут потому что Apple запрещает выкладывать приложения с недокументированными API вызовами/syscall’ами. Это правда, но как показывает практика, такие приложения такой запрет обходят через написание ровно такой же функции (с мелками правками сильно не влияющие на функционал вызываемого метода) на ассемблере и встраивание в код. Конкретный пример это обнаружения привязки дебаггеров к приложению через ptrace, вот статья (англ)
GrapheneOS тоже не неуязвим, увы (та же проблема с DNS leak с ссылки выше)
Не в курсе починили ли это или еще нет.
Требование регулятора-цензора. Ну и никто не говорил о явном шпионе с описанием “слежка”. Речь о приложениях, которые легально собирают данные в рамках политики конфиденциальности, расширенной под давлением регулятора.
Есть методичка - ей будут следовать крупные компании.
WeChat и AliPay как минимум.
Также у правительства Китая есть доступ ко всем данным (сервера физически находятся внутри страны и у них есть доступ к ключам шифрования), который Apple собирает со своих пользователей.
Вы процитировали источник, который опровергает вашу же позицию.
“This function will successfully connect so long as the interface is one of the
utuninterfaces created by the VPNs, or a physical interface that is not used by the VPNs.”
en0/другой интерфейс (неважно) - это буквально физический интерфейс, VPN его не использует (VPN использует utun*). Значит, привязка к ним работает. Именно это и является механизмом обхода туннеля.
Насчёт разрешения Local Network - оно регулирует доступ к устройствам в локальной сети через Bonjour/mDNS. Привязка сокета к физическому интерфейсу для выхода в интернет - это другой уровень, и он этого разрешения не требует. Это задокументировано Symantec как конкретная уязвимость именно на iOS, без каких-либо оговорок о необходимых “разрешений”:
“Symantec researchers found that third-party applications on both iOS and macOS can evade this [VPN routing] method by explicitly binding a network socket to the IP address of a physical network interface. […] This means that it isn’t tunneled through the VPN client’s virtual interface, regardless of whether the traffic is included in the VPN route table.”
Никакого упоминания о разрешениях нет, потому что их не требуется.
Насчёт того, что говорил ValdikSS: он сказал “любой сетевой интерфейс”, и это технически верно именно потому, что и utun*, и en0 доступны. Сужать его слова до “только при каких-то условиях” - это додумывание за автора.
includeAllNetworks как контраргумент, если что, тоже не всегда работает: Mullvad в марте 2025 года опубликовали подробный технический разбор того, почему они до сих пор не могут его включить - обновление приложения через App Store полностью лишает смартфон сетевого подключения. Баг-репорт отправлен Apple в феврале 2025 года, ответа нет. Проблема на веб-сайте Mullvad до сих пор числится как нерешённая для всех версий iOS.
Не в теме, но иронично, как команда исследователей за TunnelCrack назвала iOS наиболее уязвимыми к этой уязвимости, а Android - наименее…:
We found that VPNs for iPhones, iPads, MacBooks, and macOS are extremely likely to be vulnerable, that a majority of VPNs on Windows and Linux are vulnerable, and that Android is the most secure with roughly one-quarter of VPN apps being vulnerable.