Разработка VPN-клиента под Android (Часть 1)

Всем привет! Поводом к написанию данной статьи стало осознание того факта, что при наличии большого количества статей и обзоров про приложения VPN-клиенты для Android, нет ни одной нормальной статьи описывающей проблемы разработки с использованием VpnService API. Причём, в большинстве случаев вы, как разработчик приложения, не сможете ничего сделать с этими проблемами.

Начнём с самого начала. Некоторое время назад наша компания, на основе проводимых исследований в области безопасности мобильных устройств, решила выпустить небольшое приложение (WebGuard) под Android для блокировки всем уже надоевшей рекламы, а так же защиты от слежки и вирусов при работе из любого браузера. Чтобы реализовать данный функционал нам потребовалось решить множество задач, самой трудоёмкой из которых оказалась задача по перехвату и обработке трафика приложений. Для перехвата и фильтрации соединений браузеров было решено использовать VpnService API, которое появилось в Android с версии 4.0.3 и предоставляет всю нужную функциональность (правда, временами эта функциональность просто не работает по куче разных причин, но выяснилось это несколько позже).

Немного об используемых технологиях

Тут стоит рассказать подробнее, почему было выбрано данное API и какие вообще способы существуют для перехвата сетевого трафика приложений другим приложением на «нерутованном» android-устройстве. Собственно способов всего три (не считая различных уязвимостей) и знать о них будет полезно разработчикам приложений с различными механизмами внутриигровых покупок. Т. к. многие из них считают, что подмена сетевого трафика приложения возможно только на «рутованном» устройстве и «не заморачиваются» с защитой передаваемых данных, хотя есть вероятность (и довольно большая) появления «читерских» приложений вносящих изменения в передаваемые данные.

Итак, первый способ — это установка локального прокси-сервера. Этим способом пользуется большинство антивирусов под Android. Приложению для перехвата трафика достаточно реализовать поддержку HTTP-прокси описанную в стандарте RFC 2068 и установить в настройках WiFi сети прокси-сервер или APN в настройках мобильной сети. В этом случае передача данных будет происходить как на схеме ниже.



Но у этого способа есть куча серьёзных проблем:

• установить WiFi прокси или APN для мобильной сети программно можно только с использование скрытого API (например скрытые методы в WifiManager);
  
  
• нужно следить за появлением новых WiFi или мобильных сетей устанавливая прокси (APN) и для них;
  
  
• данный способ работает только для соединений созданных с помощью класса Http(s)URLConnection и то, если явно не будет указано не использовать прокси (например url.openConnection(Proxy.NO_PROXY)). Есть ещё приложения, которые проверяют наличие прокси-сервера и используют его (или наоборот не используют);
  
  
• если пользователь удалит или просто не запустит приложение с прокси-сервером, то остальные приложения не смогут соединиться ни с одним сервером т. к. в настройках сети все ещё будет указан прокси и пользователю нужно будет самому удалить его из настроек (например);
  
  
• выстроить цепочку из нескольких прокси нельзя, соответственно и приложение перехватывающее трафик может быть только одно.

Эти все проблемы, кроме последней, успешно решаются вторым способом — написанием приложения VPN-клиента использующего классы VpnService и VpnService.Builder. Приложению достаточно вызвать пару функций (в коде опущены обязательные проверки):

        // показываем Activity для запроса прав у пользователя
        Intent intent = VpnService.prepare(PromptActivity.this);
        startActivityForResult(intent, VPN_REQUEST_CODE); // запрос прав

        // и в onActivityResult если нам выдали права
        // requestCode == VPN_REQUEST_CODE && resultCode == RESULT_OK
        VpnService.Builder vpnBuilder = new VpnService.Builder();
        vpnBuilder.addAddress(options.address, options.maskBits);
        vpnBuilder.addRoute("0.0.0.0", 0);
        ParcelFileDescriptor pfd = vpnBuilder.establish();
        FileInputStream in = new FileInputStream(parcelFileDescriptor.getFileDescriptor());
        FileOutputStream out = new FileOutputStream(parcelFileDescriptor.getFileDescriptor());

, и весь TCP/IP трафик всех приложений (даже запущенных под root'ом) будет перенаправлен на TUN интерфейс, который создаст Android, а вашему приложению будет доступен на чтение/запись файл устройства /dev/tun (или /dev/tun0, /dev/tun1 и т. п.), откуда можно вычитывать исходящие сетевые пакеты, передавать их на обработку на удалённый VPN-сервер (обычно через шифрованное соединение) и затем записывать входящие сетевые пакеты. Для того, что бы соединения самого VPN-клиента не «заворачивались» в TUN, используется метод VpnService.protect на TCP или UDP сокетах созданных приложением.

Схема, представленная выше, в данном случае будет выглядеть следующим образом:



У этого способа есть две особенности:

1. Приложению нужно обязательно получить права на использование VpnService через вызов startActivityForResult, при этом система покажет пользователю такой вот диалог:
   
   
   
   
   
   Причём, Android запоминает, что выдал права приложению, только до перезагрузки устройства, поэтому после перезагрузки права нужно запрашивать снова. Как выяснилось (мы этого даже не ожидали) есть пользователи («да их тут сотни» ), которые любят перезагружать свой телефон каждые 10 минут и им это окно мешает, за что они в маркете могут оценить приложение в 1 балл;
   
   
2. «Печалька» чуть побольше предыдущей. Android после включения VPN, в обязательном порядке, отображает иконку уведомления в виде ключика и собственно неубираемое уведомление, нажав на которое можно посмотреть небольшую статистику:
   
   
   
   
   

   &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbspУведомление в «шторке». Иконка уведомления и диалог статуса

   
   Тут недовольство пользователей было ожидаемо, т. к. многие нынешние приложения просто обожают «вешать» уведомления (иногда сразу по несколько) и статус-бар превращается в новогоднюю гирлянду:
   
   
   
   
   Так же, если пользователь нажмёт кнопку «Разъединить» Android отключит VPN и заберёт права у приложения, после чего для активации VPN придётся заново просить права через вызов startActivityForResult.

Есть в этом способе и небольшая дополнительная проблема (не считая «фич» о которых ниже) — для его работы нужен удалённый сервер.

Проблема с наличием сервера решается третьим способом (несколько изменённый способ №2) — приложение VPN-клиент содержит ещё и стек TCP/IP (можно взять готовый или написать самому из-за наличия недостатков в готовых) для разбора трафика из приложений и обработки соединений почти как прокси-сервер. Тогда схема обработки трафика приложений несколько изменится и будет выглядеть следующим образом:



Именно этот способ мы используем в WebGuard. Из недостатков, по сравнению с предыдущим способом, можно отметить только один — это невозможность нормальной обработки протоколов отличных от TCP или UDP (или протоколов «поверх» них), потому что приложению нужно будет создавать «сырые» сокеты для чего обычно нужны права root'а. Чтобы было понятно, о чём идёт речь, возьмём простой пример: пользователь запускает шелл через ADB и выполняет команду «ping www.ya.ru», которая отправляет ICMP эхо-запрос. Далее, приложение VPN-клиент читает из /dev/tun IP пакет, разбирает его, и выясняет что пакет содержит ICMP эхо-запрос к некоему серверу. А так как приложение не может передать запрос далее в сеть, то вариантов у него всего два: игнорировать пакет или эмулировать ping попытавшись установить соединение с нужным сервером и в случае успеха записать поддельный ICMP эхо-ответ в /dev/tun.

«Фичи» VpnService API

В процессе разработки приложения, тестирования и использования первых версий пользователями, мы столкнулись с большим количеством ошибок или недоработок связанных с VpnService API. Часть из них удалось исправить, т. к. по сути это были недоработки наших программистов (о чем мы честно написали и попали на bash.org.ru), а с оставшейся частью сделать что либо довольно сложно или невозможно:

• Нет поддержки TUN интерфейса в ядре linux, соответственно VPN не заработает. В основном эта проблема встречается на самосборных прошивках на основе проектов CyanogenMod, AOSP и др. Авторы сборок либо вообще убирают поддержку из ядра, либо забывают положить модуль tun.ko в прошивку. Такое ощущение, что авторы руководствуются принципом «не знаю что это такое, поэтому не нужно»;
  
  
• Нет файла VpnDialogs.apk который содержит диалоги запроса прав и статистики, VPN опять же не заработает. Как ни странно, эта ошибка чаще всего случается на официальных сборках от производителей телефонов (и у Google в том числе);
  
  
• «Зависание» GUI на некоторых телефонах Samsung с официальной прошивкой, если в VPN-клиенте произойдёт необработанное исключение (при этом шелл через ADB вполне рабочий, но переподключается каждые 1-2 минуты). Вообще производители телефонов с Android, иногда собирают к ним «замечательные» прошивки, забыв проверить часть «редко используемого» функционала. Наш коллектив разработчиков в этом плане просто «обожает» Samsung и считает, что для тестирования приложений под Android обязательно нужно иметь несколько телефонов от разных производителей и несколько разных телефонов от Samsung;
  
  
• Благодаря вот этому изменению пользователь не сможет поставить галочку «я доверяю этому приложению» в диалоге VPN, если его перекрывает другая activity пропускающая нажатия пользователя. Сделано это для того, что бы нельзя было нарисовать сверху другой диалог и обманом заставить пользователя поставить галочку. Проблема в том, что обычно так делают (и уже давно) различные утилиты, лаунчеры и некоторые программы (например «Читай! Бесплатно»), создавая прозрачную activity. В результате некоторые пользователи могут подумать что над ними издеваются;
  
  
• Если пользователь включит ограничение трафика для фоновых процессов, то «под раздачу» попадёт и работающий VPN-клиент (при отправке данных через сокет будет исключение SecurityException c Permission denied), соответственно кинаинтернета не будет;
  
  
• В Linux есть такой замечательный механизм, как OOM Killer, и если вдруг пользователь запустит приложение, которое будет «пожирать» большое количество оперативной памяти устройства (для экспериментов можно взять Firefox, вот уж кому памяти всегда мало), OOM Killer начнёт «валить» все подряд пользовательские процессы кроме, как водится, виновника торжества (точнее его убьют последним). Исключений для нужных процессов (лаунчер или VPN-клиент) естественно не предусмотрено, поэтому нужно быть готовыми постоянно перезапускать свой сервис;
  
  
• После некорректного завершения работы VPN-клиента (даже если он потом перезапустится), в редких случаях, может понадобится перезагрузить устройство т. к. Android неправильно перенастроит маршруты передачи пакетов и пакеты от приложений будут уходить в /dev/null;
  
  
• Если пользователь включит раздачу мобильного интернета через WiFi одновременно с VPN-клиентом, то на большинстве прошивок, как и в случае выше, Android неправильно настроит маршрутизацию пакетов;
  
  
• Несмотря на достойный список «фич» разработчики из Google «внезапно» могут решить переделатьулучшить функционал в новой версии, а разработчиков под Android обычно не предупреждают обо всех изменениях, поэтому нужно внимательно следить за коммитами в репозиторий Android и править свой код. Результат такого подхода чаще всего ощущают на себе пользователи телефонов Nexus, которым обновление приходит быстрее всех (почитать душераздирающие просьбы в стиле «PLIZZZZZZZZZ!!!!!!!!!!!!VPN!!!!!!!!!!!!!!!», «Please fix this issue » на протяжении более 230 дней можно здесь, здесь и здесь). Так что, будьте внимательны и не обновляйте свой Nexus во время деловой поездки.

Вот так прочитаешь этот список и подумаешь — а может ну его этот VPN? К сожалению, другого способа перехватывать весь трафик на «нерутованном» телефоне с Android пока что нет.

Немного о NinePatch

В список выше, не попала ещё одна проблема, последствия решения которой были для нас весьма неожиданны (и не только для нас). Поэтому мы решили рассказать о последствиях поподробнее. Началось все с того, что в какой то момент нужно было сделать самую важную часть приложения — нескучную иконку. Сказано — сделано. Красивая круглая иконка нарисована и мы радостно тестируем предрелизную версию, как вдруг:



Выяснилось, что на части телефонов иконка приложения в уведомлении о VPN может очень странно отображаться (неправильная цветность, размеры или ещё что-нибудь). После экспериментов и недолгого, но жаркого обсуждения



, было приказанорешено сделать иконку приложения в формате nine-patch, благо официальная документация по этому поводу ничего не говорит (т. е. не запрещает) и яйцеобразная проблема решается. Но, после выхода релиза очень быстро появились «пострадавшие». Это были как приложения под Android, так и различные онлайн сервисы работающие с apk-файлами, и не ожидающие получить иконку приложения в формате nine-patch. Самых примечательных мы решили расположить на пьедестале из трёх мест:

&nbsp&nbsp&nbsp&nbsp3. Различные лаунчеры, которые падали при попытке отобразить иконку (например LauncherPro).

&nbsp&nbsp&nbsp&nbsp2. Магазины Android приложений от Samsung и Yandex. При попытке загрузить приложение в Yandex.Store выдавалось вполне понятное описание ошибки: «Не удалось извлечь из APK иконку приложения». C Samsung Apps оказалось веселее. Так как компания высокотехнологичная, то и результаты проверки при добавлении приложения приходят в соответствующем виде — письмо с ссылкой на видео в котором записан процесс тестирования приложения и должно быть видно (по идее) ошибку. Получилось, правда, все как обычно, пришло письмо с ссылкой по которой видео не было.

&nbsp&nbsp&nbsp&nbsp1. Ну а почётное первое место, по праву, занимает компания Sony с телефоном Xperia. Через какое то время после выхода релиза, владельцы Xperia L начали присылать сообщения о том, что WebGuard «убил» им телефон (пример). Оказалось, что падает PackageManagerService при попытке обработать иконку приложения во время установки, после чего телефон автоматически перезагружается и идёт бесконечная загрузка:

E/AndroidRuntime(  790): *** FATAL EXCEPTION IN SYSTEM PROCESS: Thread-123<br />
E/AndroidRuntime(  790): java.lang.ClassCastException: android.graphics.drawable.NinePatchDrawable cannot be cast to android.graphics.drawable.BitmapDrawable<br />
E/AndroidRuntime(  790): at com.android.server.pm.PackageManagerService$SetIconCacheThread.run(PackageManagerService.java:3672)<br />
...<br />
E/AndroidRuntime( 2981): FATAL EXCEPTION: ApplicationsProviderUpdater<br />
E/AndroidRuntime( 2981): java.lang.RuntimeException: Package manager has died<br />
E/AndroidRuntime( 2981): at android.app.ApplicationPackageManager.queryIntentActivitiesAsUser(ApplicationPackageManager.java:487)<br />
E/AndroidRuntime( 2981): at android.app.ApplicationPackageManager.queryIntentActivities(ApplicationPackageManager.java:473)<br />
E/AndroidRuntime( 2981): at com.android.providers.applications.ApplicationsProvider.updateApplicationsList(ApplicationsProvider.java:518)<br />
E/AndroidRuntime( 2981): at com.android.providers.applications.ApplicationsProvider.access$300(ApplicationsProvider.java:69)<br />
E/AndroidRuntime( 2981): at com.android.providers.applications.ApplicationsProvider$UpdateHandler.handleMessage(ApplicationsProvider.java:206)<br />
E/AndroidRuntime( 2981): at android.os.Handler.dispatchMessage(Handler.java:99)<br />
E/AndroidRuntime( 2981): at android.os.Looper.loop(Looper.java:137)<br />
E/AndroidRuntime( 2981): at android.os.HandlerThread.run(HandlerThread.java:60)<br />
E/AndroidRuntime( 2981): Caused by: android.os.DeadObjectException<br />
E/AndroidRuntime( 2981): at android.os.BinderProxy.transact(Native Method)<br />
E/AndroidRuntime( 2981): at android.content.pm.IPackageManager$Stub$Proxy.queryIntentActivities(IPackageManager.java:2027)<br />
E/AndroidRuntime( 2981): at android.app.ApplicationPackageManager.queryIntentActivitiesAsUser(ApplicationPackageManager.java:481)<br />
E/AndroidRuntime( 2981): ... 7 more<br />

В итоге, с версии 1.3 было решено использовать иконку без nine-patch, тем более что его использование всех проблем с отображением иконки не решило:

&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbspУведомление о включении VPN на Ainol Novo10 Hero

Заключение

Нам не хотелось делать слишком большой пост, поэтому было решено разбить статью на несколько частей. В следующей части мы расскажем почему приложения под Android, фильтрующие трафик, потребляют так много заряда аккумулятора (по мнению андроида) и напомним, на примере одного теста производительности, что DalvikVM != JavaVM.

Надеемся наша статья кому-нибудь поможет в написании интересного приложения под Android. Удачной разработки!