
Комментарии 77
а что если в виртуалку спрятать не скам / яндекс / госуслуги, а наоборот все нужные приложения? это не поможет?
я как раз тут вчера пробегая по постам и комментариям натыкался на примерно аналогичный вариант чтобы не светить интерфейс впн использовать - шелтер, в нем прокси на локалхосте и там уже телеграм и прочее. Но тот товарищ ошибается насчет того что локалхосты у шелтера и основного профиля разные, локалхост у них один и те-же и прокси поднятый на порту в шелтере так-же доступен из основного профиля и наоборот.
Закрыть прокси на локалхосте для всех приложений и оставить только для выбранных не смогут даже файрволы которые запускаются без рута.
P.S. впрочем он сам написал что бухой, так что простительно :-)
На Секлабе писали Шелтер течет=(
Upd: На ведроиде
походу создателям андроида и шелтера и в страшном сне не снилось, что кому-то нужно будет целенаправленно на своем устройстве запускать спайваре работать с ней и пытаться от нее-же защитится.
М.б. внешние поведенческие, через счетчики аналитик завязанных на идентификации, вроде Я.Метрика?
Вот да. Тоже кажется начнут на страницах стучать на заграничные сервера и сверять ip.
Там уже не кажется, там либо уже начали либо вот вот начнут, проблем то минимум, добавить java скипт который будет делать запрос к любому узлу из этих:
https://api.ipify.org?format=json
либо свой собственный аналог на зарубежном vps поднимут и сохранять данные на сервере что-то типа (по токенам грока):

В firefox на этот случай есть (в остальных браузерах понятия не имею есть ли аналоги):



Нужные странички в "личное", спайваре в "покупки" или куда пожелаете и пускай стучатся
Яндекс фингерпринты при случае делает, собирая данные вплоть до названий Wi-Fi сетей (BSSID) и гео. Прокси не спасут, если отпечаток уплыл через Яндекс.Браузер или скрипты Яндекс приложений. Идентификация идет через склейку сессий с Яндекс айди (Canvas, WebGL, шрифты и+100500 условных параметров).
тем кто пользуется яндекс браузером по моему скромному мнению внп вообще противопоказан. Кстати подозреваю что им как раз хорошо зайдет и мессенджер "телега"
Я.Бразуер это часто один рабочий метод выхода для пожилых людей на стареньких устройствах, посмотреть тот же ютуб. Даже выкиним Я.Браузер, есть Я.Гоу, например и еще кучу сервисов от Яндекса, которые тупо висят в телефоне.
Можно прокси запускать только для контейнера
CORS не даст. Запрос-то они сделают, а вот ответ им прочитать браузер не даст.
Но зачем нам ещё один vpn-клиент? Могли бы вы сделать форк, например, Nekobox без socks? А в идеале чтобы он ещё мог использовать плагин Naiive без открытого +одного порта socks?
А там может вы бы влили эту функциональность в основную ветку.
Тут интересный вопрос родился. Какие DNS будут использоваться для резолвинга приложениями, которые ходят через VPN?
я вообще мало понимаю в подобном и потому решил спросить тут. вот я пользовался обновленным и (на телефоне) Happ и каринг и этой прогой с этой статьи, но... хз на счет других прог но вот чтобы я не делал приложение личный кабинет мегафон всегда просит отключить ВПН. получает оно видит что ВПН включен и значит ТЕМА не работает так?
Основной посыл в том, что vpn имеет кучу косвенных признаков на android. Главная проблема - утечка вашего внешнего ip. Вы можете добавить приложение в исключения впн клиента, но оно все равно может задетектить внешний ip - клиент в статье борется именно с этим.
сам андроид устроен так что при включении любого стороннего сетевого интерфейса появляется значек - VPN. Насколько я в курсе это не поборимо без доступа к ядру (т.е. рута).
Альтернатива - использовать прокси т.е. 127.0.0.1:XXXX это в системе не светится, но приложения и веб странички с помощью JS могут определить его наличие и соответственно куда он ведет.
Если кому интересно насчет настроек браузера firefox, мультиконтейнера с раздельным прокси и перекрытия доступа js со страничек открытых в напрямую (без контейнера с настроенным прокси) к сканированию прокси сервисов, пишите расскажу.
А можете сделать в приложении чтобы выбирать: либо кто через vpn, либо кто напрямую. А то сейчас долго выбирать кто напрямую;)
как думаете, какие еще неочевидные маркеры наличия VPN могут начать массово использовать для детекта в ближайшем будущем?
Так ведь давно уже же используют обратный пинг для этого. Приложение пингует определенный хост и засекает время ответа. Хост пингует выходной IP квн приложения и сообщает ему время ответа. На разнице этих времен весь кордебалет и палится
я как не великий специалист в этой области ничего не понял, можно подробнее?
На 2ip.ru зайдите при включенном квн и проверьте наличие туннеля. Вкратце, приложение, скажем озон, пингует хост где-то за рубежом. Пинг идет через ваш квн сервер, и это долго. Потом тот хост пингует адрес, который его пинговал (ваш квн за рубежом), и это быстро (внезапно!). Вот и все, сижу на амнезии премиум и у них на выходной ноде не отключен ICMP. Такая беда...
А как побороли возможность любому приложению отправить запрос через tun? Например,
curl https://chatgpt.com/cdn‑cgi/trace ‑interface tun0
что выдает?
лол! Нафига? Есть специальные сервисы для этого, а если надо его несложно сделать самому подняв впс в нидерланда с nginx или caddy который будет возвращать json с данными о твоем конечном адресе, браузере, операционной системе и твое локальное время.
Ну типа стандартного - https://ipinfo.io/json
Смысл в том, чтобы приложение не могло отправить запрос в туннель, а отправляла бы его через обычный интернет
а, ну для этого мы используем раздельное маршрутизирование для приложений, это решает проблему с тоннелем, но остается открытой проблема с socks5 прокси на локалхосте, которую как раз пытается решить автор этой статьи.
P.S. Мое лол-нафига относилось к этой части вашего комментария -
curl https://chatgpt.com/cdn‑cgi/trace ‑interface tun0
для определения обхода блокировок проще использовать так -
curl https://ipinfo.io/json ‑interface tun0
В этом-то и проблема, что маршрутизация для приложений в большинстве клиентов для vless не работает. Точнее не работает фильтрация "разрешенных приложений".
Сайты типа ipinfo - уж больно явно являются сервисами проверки. Кажется, что такие известные домены можно заблокировать в приложении. Но вот пример с chatgpt на самом деле иллюстрирует гораздо бОльшую проблему: все домены работающие через cloudflare имеют у себя эндпоинт /cdn-cgi/trace а их не заблокировать без блокировки домена. Да и утопия это - писать правила для блокировки всех доменов работающих через cloudflare
Нафига? Есть специальные сервисы для этого
О, нет, это наоборот прекрасно. Я оценил трюк. Клиент может использовать политику:
1. «По этому короткому списку в туннель».
2. «Все остальное напрямую».
В тоже время сервер может иметь политику:
1. «По этому короткому списку выпустить в интернет».
2. «Все остальное заблокировать».
И тогда твой сервис который ты любовно поместил в свой список начинает на тебя стучать. Даже при такой жесткой политике
Android без рут прав у приложения не дает биндить сокет в туннель, если приложение находится в списке исключений. Binding socket to network 207 failed: EPERM (Operation not permitted).
Ну вот на обычных клиентах, типа v2rayNG, из termux (если он даже не в списке проксируемых) получается, что вполне себе запрос отправляется легко.
Или имеется в виду, что надо делать типа "черный список" - то есть исключать приложения из прокси? Ну тогда получается весь служебный трафик будет через vps идти. Зачем? Имхо проще же заворачивать через прокси отдельные приложения, а по умолчанию все пускать напрямую, нет?
Как раз добавил "обратный" список
Виноват, всё нашёл. Тестирую.
Протестировал - к сожалению, такая же штука, как и у большинства клиентов: выбор приложения для прохода через прокси не запрещает другим слать через tun0 запросы

я правильно понял что вы закрыли порт прокси рэндомным паролем и биндите его на разные порты, при этом тоннель впн доступен приложениям из списка определяемого пользователем. Сам статус впн в системе без рут прав скрыть не получится но спайваре им по крайне мере воспользоваться не могут, а прокси для них становится недоступен?
Вообще, работающую блокировку по приложению я только у flclash нашел. Но там конфиги все переписывать надо
к обратному списку стоит поменять красный перечеркнутый кружок на значке приложения на что-то другое. (v 1.0.5)
а если я "настоящий" виндовз накачу на смартфон, это поможет ? видел, были такие "хакнутые" устройства или выйду через второй смартфон и с него буду раздавать трафик ?
А можно добавить параметр, чтобы по умолчанию всё шло мимо впн, а то что надо пустить в впн, самому отметить?) А то сиди выбирай кучку программ которым не надо впн, вдруг чтото пропустим
А, всё, нашел галочку, извините. А не, не работает, вот что выдает:
Start failed: addAllowedApplicationalready called
Я не силен в мобильной разработке. Но скормил Ваш клиент чатужпт, чтобы провести аудит. Вот его ответ:
Конфиги с секретами сохраняются в plaintext в SharedPreferences. В сериализацию попадают uuid, password, publicKey, shortId и даже rawUri, то есть фактически полный импортированный URI. Подписки тоже сохраняют URL целиком. См. /tmp/ teapod‑stream/lib/core/models/vpn_config.dart:99, /tmp/teapod‑stream/lib/core/models/vpn_config.dart:120, /tmp/teapod‑ stream/lib/core/models/vpn_config.dart:122, /tmp/teapod‑stream/lib/core/services/config_storage_service.dart:64, /tmp/ teapod‑stream/lib/core/services/config_storage_service.dart:117, /tmp/teapod‑stream/lib/core/services/ config_storage_service.dart:121.
Поверх этого в AndroidManifest не отключён backup/export rules. Там нет ни android:allowBackup=«false», ни явных dataExtractionRules. Для обычного пользователя это не мгновенная межприложная утечка, но для high‑risk сценария это плохая гигиена хранения секретов. См. /tmp/teapod‑stream/android/app/src/main/AndroidManifest.xml:11.
Клиент действительно генерирует случайные SOCKS‑логин/пароль и порт, это хороший ход. Но затем сервис логирует полный запуск tun2socks, включая строку вида socks5://user:password@127.0.0.1:port, в logcat. То есть секреты, которые только что защитили localhost‑прокси, тут же утекли в системный лог. См. /tmp/teapod‑stream/lib/providers/vpn_provider.dart: 96, /tmp/teapod‑stream/lib/providers/vpn_provider.dart:103, /tmp/teapod‑stream/lib/protocols/xray/xray_config_builder.dart:20, /tmp/teapod‑stream/android/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:234, /tmp/te apod‑stream/android/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:249, /tmp/teapod‑stream/andro id/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:430.
README обещает больше, чем реально реализовано. Заявлены Trojan, Shadowsocks, H2, QUIC, но builder по факту собирает полноценные outbound‑настройки только для VLESS и VMess; для остальных протоколов возвращается пустой settings‑блок, а supportsConfig() всё равно отвечает true. Это не прямая уязвимость, но плохой сигнал по зрелости и может дать ложное ощущение «всё поддерживается». См. /tmp/teapod‑stream/README.md:7, /tmp/teapod‑stream/README.md:8, /tmp/teapod‑stream/ lib/protocols/xray/xray_config_builder.dart:124, /tmp/teapod‑stream/lib/protocols/xray/xray_config_builder.dart:150, / tmp/teapod‑stream/lib/protocols/xray/xray_engine.dart:230.
Допускаю, что ИИ мог нафантазировать. И свою безграмотность в этом вопросе тоже беру в расчет. Но если я правильно понял - Вы сами несколько раз в открытом виде кладете секреты
android:allowBackup - Чего плохого в возможности бэкапа пользователем? "Но затем сервис логирует полный запуск tun2socks" - кто имеет доступ к логам? Пользователь?
Не совсем понимаю претензии к автору. Он честно признался, что за пару дней подпивасно накодил прогу в качестве proof of concept. Он не позиционировал её как самое защищённое решение на свете, а просто показал, что исправление так сильно всех напугавшей уязвимости, в целом, несложное.
Давайте и за меня ответит ИИ.
Вот краткое резюме по каждому пункту:
Открытые конфиги (SharedPreferences): Не страшно. Защищено встроенной изоляцией Android. Без root-прав (взлома системы) другие приложения до этих файлов не доберутся.
Резервное копирование (Backup rules): Не критично. Конфиги просто сохраняются в ваш бэкап на Google Drive или доступны через USB-кабель. Если телефон запаролен и аккаунт защищен — угрозы нет.
Пароли в логах (Logcat): Не опасно. Утекли пароли от локального узла (внутри самого телефона). Из интернета к нему не подключиться, а Android запрещает обычным приложениям читать системный лог.
Заглушки вместо протоколов: Это не уязвимость. Разработчик просто не дописал код для Trojan и Shadowsocks, хотя пообещал их в описании.
Общий вывод: Для личного использования это безопасно. Это проблемы "чистоты" кода, а не реальные дыры, через которые ваш телефон могут взломать извне.
Расскажите, а зачем вы это сделали? Вы считаете что автор не смог этого сделать сам?
Отдельный айфон для адекватной жизни в неадекватной стране уже готов. Наивысшая сейчас мера - изоляция "плохих" и "хороших" приложений друг от друга на уровне физического устройства.
С iPhone по очевидным причинам проверить не могу. А есть ли возможность ограничивать некоторые приложения доступом только к некоторому сегменту сети (все ру идут в ру или идут нафиг)?
AmneziaWG лишена этой уязвимости?
curl --interface tun0 whatismyip.akamai.comпоказывает выходной IP прокси даже если приложение из проксируемых исключено. Увы, но ваш клиент тоже уязвим на Android с ядром 5.7+. В Exclave уже починили и можно tun защитить правилами, а socks вообще отключить.
У меня детекти все-равно) Tun виден
А без сборки как нибудь выложить можно? В виде apk для чайников.
Уже вторая неделя статей про всякие утечки, методички, RKNHardering, кто-то там что-то тестирует. А хоть кто-нибудь делал хоть малейший аудит RKNHardering? Автору на гитхабе без году неделя отроду и все тупо ставят это приложение. Откуда вообще такое доверие? Почему вы решили, что это приложение просто не собирает определённую информацию? Кстати тоже самое относится и к TeapodStream. ))
как думаете, какие еще неочевидные маркеры наличия VPN могут начать массово использовать для детекта в ближайшем будущем?
Например, пользователь цитирует "запрещенные" источники, недоступные без VPN. И вообще какой-то слишком умный.




Критическая уязвимость VLESS клиентов? Подержите мое пиво…