Как устроен Anubis для Android: заморозка приложений по состоянию VPN и защита от утечек через localhost

Anubis из репозитория проекта решает не абстрактную «проблему приватности», а очень конкретную задачу. На Android VPN-клиент может поднять локальный SOCKS5-прокси на 127.0.0.1, а другое приложение на том же устройстве способно достучаться до такого прокси, узнать внешний адрес VPN или вообще выйти наружу в обход задуманных ограничений на уровне приложений. В таком сценарии обычная схема «этот софт идет через VPN, а этот нет» перестает выглядеть надежной.

Поэтому Anubis не строит еще один VPN-клиент, не делает песочницу и не пытается красиво «маркировать» трафик. Anubis берет более грубый, но логичный инструмент: пока VPN активен, одни приложения отключены на уровне пакетного менеджера Android, а когда VPN выключен, отключаются уже другие. Логику угрозы и мотивацию хорошо показывает разбор на Habr, но сам проект интересен именно реализацией. По сути, перед нами диспетчер приложений, который живет на стыке Android shell, Shizuku, VPN API и механики launcher shortcuts.

Сразу важная оговорка. Речь идет не про одноименный антибот-прокси для веб-сайтов, а про Android-проект, который управляет состоянием приложений по факту наличия VPN на устройстве.

Что именно пытается закрыть Anubis

Уязвимое место здесь не в «плохом интернете» и не в том, что Android не умеет VPN. Проблема тоньше. Многие мобильные VPN-клиенты, особенно вокруг xray, v2ray или sing-box, поднимают локальный прокси без аутентификации. Для самого клиента такой прокси удобен: через него можно гонять трафик, обслуживать режимы совместимости и собирать маршрутизацию. Но для соседнего приложения на телефоне такой прокси превращается в боковую дверь.

Дальше начинается неприятная часть. Даже если пользователь аккуратно исключил приложение из VPN на уровне VpnService, такое приложение все равно может проверить localhost, нащупать открытый SOCKS5, отправить через него запрос и понять, какой внешний адрес выдает VPN. Для многих сценариев уже одного такого факта хватает. Можно детектировать использование VPN, обходить логику split tunneling, строить поведенческие признаки и просто ломать модель «вот это приложение не должно знать, что VPN сейчас активен».

Популярный контраргумент звучит так: «Тогда просто вынесем подозрительные приложения в рабочий профиль». На бумаге выглядит красиво, на практике не всегда помогает. Профиль отделяет данные и часть прав, но не гарантирует, что приложение перестанет видеть локальный сетевой контур так, как хотелось бы. Anubis исходит из более жесткой предпосылки: если приложение вообще не запущено и отключено как пакет, никакой код у такого приложения не выполняется, localhost никто не щупает и сервисы не живут в фоне.

Главная идея архитектуры: не изолировать, а выключать

В основе Anubis лежит простая мысль. Пока приложение существует в активном состоянии, у приложения остается шанс сделать что-то нежелательное. Поэтому проект не ограничивает приложение мягко, а переводит пакет в disabled state через системную команду pm disable-user --user 0 package.name. Для Android такой пакет фактически «заморожен». Приложение не запускается, не держит сервисы, не получает широковещательные события и не работает в фоне.

Здесь и проходит главная граница между Anubis и большинством «менеджеров приватности». Anubis не анализирует сетевые пакеты, не строит свой firewall и не обещает универсальную защиту от всего. Anubis просто убирает окно исполнения кода для выбранной группы приложений.

Архитектуру проекта удобно разложить на четыре слоя.

1. Командный слой через Shizuku

Без повышенных привилегий обычное Android-приложение не может спокойно дергать нужные shell-команды. Поэтому Anubis опирается на Shizuku. Shizuku дает приложению контролируемый мост к системным вызовам от имени shell или adb-контекста без полноценного root. За счет этого Anubis может отключать и включать пакеты, опрашивать сетевое состояние, запускать активности и отправлять broadcast-команды в VPN-клиенты.

Фактически Shizuku здесь не «дополнение», а фундамент. Уберите Shizuku, и центральная механика проекта рассыплется.

2. Слой принятия решений

Anubis делит приложения на несколько групп. Одна группа должна жить только без VPN. Другая, наоборот, только при активном VPN. Третья группа не блокируется полностью, но при запуске сначала требует поднять VPN. Такой разбор выглядит бытово, но на деле решает главный конфликт между удобством и контролем. Пользователь не думает каждый раз «а что сейчас включено», а один раз назначает политику.

3. Слой отслеживания VPN

Чтобы принимать решение, Anubis должен понять, какой VPN сейчас поднят и поднят ли вообще. Проект делает это не через глубокую интеграцию с каждым клиентом по отдельности, а через системный снимок состояния сети. Идея простая: посмотреть в вывод connectivity-сервиса Android, найти активную VPN-сессию, достать UID владельца и затем сопоставить UID с пакетом приложения. Такой путь прагматичен. Он позволяет определить не только «есть VPN или нет», но и какой именно клиент владеет туннелем.

Подход хорош универсальностью. Поддержка не завязана жестко на одно приложение. Но именно здесь скрывается один из будущих рисков проекта. Anubis опирается на практику текущих версий Android и на формат системного вывода, а не на богатый официальный SDK для такого сценария. Значит, при изменениях платформы код придется подправлять.

4. Слой оркестрации интерфейса

Самая недооцененная часть проекта не в безопасности, а в UX. Если просто выключать и включать пакеты, пользоваться телефоном станет неудобно. Anubis обходит проблему через свой launcher-слой. Он показывает приложения, умеет запускать их по правилам, красит отключенные ярлыки в серый, поддерживает long press и закрепленные shortcut-сценарии. За счет этого пользователь работает не с «сырой системной заморозкой», а с оберткой, которая скрывает большую часть механики.

Как выглядит жизненный цикл в реальной работе

Представим три типовые группы.

Первая группа называется условно «Local». Такие приложения должны жить только без VPN. Как только VPN активируется, Anubis отключает пакеты этой группы. Пользователь физически не может запустить такие приложения, пока VPN поднят. Когда VPN выключается, Anubis возвращает пакеты в рабочее состояние.

Вторая группа, «VPN Only», работает зеркально. Пока VPN неактивен, приложения отключены. Пользователь жмет на ярлык, Anubis сначала поднимает VPN или убеждается, что туннель уже активен, и лишь потом размораживает пакет и запускает приложение.

Третья группа полезна для промежуточных сценариев. Приложение не блокируется насовсем, но запуск такого приложения должен автоматически потянуть за собой включение VPN. Тут Anubis действует как диспетчер запуска: сначала сеть, потом приложение.

Самое интересное начинается не на старте, а на остановке VPN. Многие Android-клиенты выключаются неидеально. Где-то broadcast переключает виджет, где-то activity гасит туннель, где-то клиент продолжает висеть дольше, чем кажется интерфейсу. Поэтому в проекте заложен многошаговый сценарий остановки. Сначала Anubis пробует штатный способ клиента. Если этого мало, проект временно поднимает собственный «пустой» VPN, чтобы забрать владение туннелем у текущего клиента, после чего завершает чужой процесс и снимает свой служебный VPN. На словах звучит грубовато, но инженерно ход понятный: пока система считает старый VPN активным, размораживать приложения опасно.

Почему Anubis делает ставку на pm disable-user, а не на рабочий профиль

Здесь у проекта очень четкая позиция. Рабочий профиль и аналоги вроде Island, Shelter или Insular помогают разделять софт и данные, но не дают жесткого ответа на вопрос «может ли код приложения прямо сейчас выполниться». Anubis отвечает радикально: если пакет выключен на уровне package manager, кода нет в игре вообще.

У такого решения три сильные стороны. Во-первых, фоновые сервисы не продолжают жить. Во-вторых, приложение не успевает проверить localhost, DNS, сетевые интерфейсы и другие признаки активного VPN. В-третьих, подход не зависит от того, насколько добросовестно конкретный VPN-клиент реализовал split tunneling.

Но и цена ощутимая. Когда пакет отключают системно, ломается гладкость повседневного использования. Пропадают уведомления, не работают фоновые задачи, виджеты теряют актуальность, а некоторые переходы между приложениями становятся медленнее. Если пользователь хочет тонкую политику «этому приложению запретим только localhost, а остальное оставим», Anubis не про такой стиль. Проект предпочитает топор там, где обычные скальпели уже не внушают доверия.

Как Anubis управляет VPN-клиентами

Еще один сильный ход проекта в том, что Anubis не ограничивается одной-двумя программами. Автор разбивает поддержку VPN-клиентов на несколько типов.

Для одних клиентов работает схема с раздельными действиями start и stop. Обычно такой вариант проще всего автоматизировать, если приложение экспортирует явные activity для быстрого включения и выключения.

Для других клиентов Anubis использует схему toggle. Там приложение имеет виджет или receiver, который переключает состояние одним broadcast-событием. Часто у форков v2ray-проектов встречается вполне узнаваемый паттерн: пакет содержит WidgetProvider и принимает действие вида package.action.widget.click. Тогда проекту достаточно отправить нужный broadcast-командой shell.

Если у клиента нет внятного внешнего интерфейса, Anubis оставляет ручной режим. Пользователь сам подтверждает включение VPN, а проект только строит логику вокруг состояния приложений.

Технически здесь самый любопытный момент не в запуске broadcast, а в способе поиска таких точек входа. Для анализа APK автор предлагает использовать JADX, смотреть строки ресурсов, искать провайдер виджета, exported receivers и действия, которые висят на кнопках быстрого включения. С точки зрения Android-разработки это не «взлом» в громком бытовом смысле, а обычный аудит публичных IPC-точек приложения. Но практический вывод простой: поддержка чужих клиентов всегда хрупкая. Сегодня у клиента есть exported receiver, завтра разработчик уберет его, сменит action или завернет логику внутрь, и автоматизация сломается.

Технический стек без лишней романтики

Судя по устройству проекта, стек выбран без экзотики. Интерфейс собран на Kotlin и Jetpack Compose с Material 3. Для локального хранения настроек и групп приложений используется Room. Состояние сети отслеживает ConnectivityManager через callback-механику. Для ярлыков и сценариев быстрого запуска задействован ShortcutManager. Привилегированные действия идут через Shizuku и его AIDL UserService-подход.

Хороший инженерный знак в том, что автор не пытался превратить проект в платформу «на все случаи жизни». Компоненты простые и понятные. Сложность сосредоточена не в фреймворках, а в оркестрации состояний. Для такого класса софта это правильный выбор. Чем меньше декоративной сложности, тем легче отлавливать гонки между VPN, launcher-событиями и состоянием пакетов.

Где у Anubis действительно сильное место

Самая ценная часть Anubis не в пользовательском интерфейсе и не в поддержке конкретных VPN-клиентов. Самая ценная часть в правильной модели угроз. Автор не делает вид, что «раздельная маршрутизация приложений» сама по себе решает проблему. Наоборот, проект исходит из неприятного, но правдоподобного допущения: если подозрительное приложение остается живым на устройстве, оно рано или поздно найдет, что проверить.

В этом смысле Anubis почти аскетичен. Вместо обещаний «невидимости» проект снижает поверхность атаки до очень понятного состояния. Нет живого процесса, нет фонового сервиса, нет локального опроса портов, нет попытки узнать внешний адрес через соседний прокси. Для пользователей с параноидальным, но реалистичным сценарием это сильная позиция.

Где подход ломается или хотя бы скрипит

Теперь о слабых местах, потому что без них обзор был бы нечестным.

Первое. Проект критически зависит от Shizuku. Для тех, кто не любит adb-подготовку, дополнительные разрешения и служебные сервисы, порог входа будет заметным. Anubis не из тех приложений, которые ставят «в два тапа» и забывают.

Второе. Совместимость с VPN-клиентами не гарантирована. Пока у клиента есть подходящий activity, receiver или предсказуемый toggle-механизм, автоматизация работает. После обновления клиента сценарий может сломаться без предупреждения. Причем не из-за бага Anubis, а из-за того, что чужое приложение изменило публичные точки управления.

Третье. Проект не чинит корневую проблему в самом VPN-клиенте. Если клиент поднимает локальный прокси без аутентификации, правильнее было бы закрыть или переработать такой прокси. Anubis помогает уменьшить риск со стороны соседних приложений, но не превращает уязвимый VPN-клиент в образец безопасной архитектуры.

Четвертое. Пользователь сам определяет, какие приложения относятся к локальной группе, какие к VPN-only, а какие должны просто запускать VPN. Ошибка в группировке ломает защитную модель. Оставили «лишнее» приложение размороженным при активном VPN, и весь красивый замысел перестает быть жестким.

Пятое. У Anubis есть естественный предел. Если устройство уже скомпрометировано на более низком уровне, если у злоумышленника есть root, если речь идет о системных компонентах или о побочных каналах вне пользовательских приложений, заморозка пакетов не спасет. Проект решает узкую задачу внутри пользовательского пространства Android, не больше.

Сравнение подходов

Кому Anubis подойдет, а кому нет

Anubis подойдет тем, кто осознанно делит софт на доверенный и недоверенный, пользуется Android как рабочим инструментом и понимает, зачем вообще связывать жизненный цикл приложений с VPN. Это хороший проект для исследователей, для людей с жестким threat model и для тех, кого не смущают Shizuku, adb и разбор APK на предмет exported-компонентов.

Обычному пользователю, который просто хочет «чтобы VPN всегда работал», проект, скорее всего, покажется слишком суровым. Здесь нужно думать группами, проверять совместимость клиентов и мириться с тем, что часть приложений в какие-то моменты будет системно отключена.

Anubis интересен не как «волшебная защита от слежки», а как трезвый инженерный ответ на конкретную дыру в модели split tunneling. Проект выигрывает там, где мягкие ограничения уже не внушают доверия.

Практический вывод

Anubis устроен неожиданно здраво. Автор не пытается победить всю сетевую безопасность Android сразу. Вместо этого проект берет конкретный класс рисков, связанных с localhost и детектированием активного VPN соседними приложениями, и закрывает риск самым прямым способом: пока VPN активен, недоверенное приложение не должно существовать в рабочем состоянии.

Такой подход грубый, местами неудобный, зависит от Shizuku и от чужих не всегда стабильных интерфейсов управления VPN-клиентами. Но в своей нише Anubis выглядит сильнее многих «элегантных» решений, потому что не маскирует реальную проблему. Если угроза состоит в том, что приложение может что-то узнать, лучший способ часто не в том, чтобы запретить часть действий, а в том, чтобы вообще не дать приложению стартовать.

Именно поэтому Anubis производит впечатление не игрушки и не очередного «приватного лаунчера», а точечного инженерного инструмента. Не универсального, не безболезненного, но очень понятного по замыслу. Для мобильной безопасности такой тип проектов ценен больше, чем десяток красивых обещаний без реального контроля над состоянием приложений.

Использовать подобные инструменты стоит ответственно, в рамках закона и правил платформы. Разбор APK, автоматизация IPC и управление VPN не должны превращаться в способ обхода чужих ограничений, блокировок или политик безопасности. Если вы работаете из России, отдельно проверьте местные правовые ограничения на сценарии, связанные с VPN и сетевой маскировкой.

FAQ по Anubis