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

Custom kernel?

Что такое кастомное ядро? Как мы все знаем, Android представляет собой пирог, состоящий из трех базовых слоев: ядро Linux, набор низкоуровневых библиотек и сервисов и виртуальная машина Dalvik, поверх которой работает графическая оболочка, высокоуровневые инструменты и сервисы, а также почти все приложения, установленные из маркета. Создатели большинства альтернативных кастомных прошивок обычно работают только с двумя верхними слоями, добавляя функции в графическую оболочку (например, кнопки в шторке), изменяя ее (движок тем в CyanogenMod), а также добавляя новые системные сервисы (эквалайзер в CyanogenMod) и оптимизируя существующие.

Авторы популярных прошивок также по мере возможностей вносят изменения в ядро Linux: оптимизируют (сборка с более агрессивными флагами оптимизации компилятора), включают в него новую функциональность (например, поддержку шар Windows), а также вносят другие изменения вроде возможности поднимать частоту процессора выше предусмотренной производителем. Зачастую все это остается за кадром, и многие пользователи кастомных прошивок даже не подозревают об этих возможностях, тем более что тот же CyanogenMod поставляется с кастомным ядром только для ограниченного круга девайсов, для которых доступны как исходники родного ядра, так и возможность его замены. Например, почти все прошивки CyanogenMod для смартфонов Motorola используют стандартное ядро — заменить его на свое невозможно из-за непробиваемой защиты загрузчика.

Выбираем алгоритм перезагрузки TCP, планировщик I/O и алгоритм управления энергосбережением

Однако ядро в смартфонах с разлоченным загрузчиком можно заменить отдельно от основной прошивки. И не просто заменить, а установить ядро с огромным количеством различных функций, которые требуют определенных технических знаний для управления, а потому обычно не встраиваются в ядра популярных прошивок, таких как CyanogenMod, AOKP и MIUI. Среди этих функций можно найти поддержку высоких частот работы процессора, управление гаммой экрана, режимами энергосбережения, высокоэффективные менеджеры питания и огромное количество других фич.

В этой статье мы поговорим о том, что нам могут предложить создатели кастомных ядер, рассмотрим основные кастомные ядра для различных устройств, а также попробуем установить ядро независимо от основной прошивки и проверим все на собственной шкуре. Итак, что обычно предлагают разработчики альтернативных ядер?

Регулируем вольтаж

Оптимизации

Зачастую основной целью сборки кастомного ядра становится оптимизация производительности. Обычно вендор мобильной техники старается сохранить баланс между производительностью и стабильностью работы, поэтому даже хорошие техники оптимизации, способные существенно поднять скорость работы девайса, могут быть отвергнуты производителем только на основании того, что после их применения некоторые приложения начали падать каждый десятый запуск. Само собой, энтузиастов такие мелочи не смущают, и многие из них готовы применить к ядру собственной сборки любые опции компилятора, алгоритмы энергосбережения и задрать частоту процессора настолько высоко, насколько только выдерживает девайс. Среди всех оптимизационных техник наиболее распространены четыре:

1. Сборка с помощью компилятора Linaro GCC с агрессивными опциями оптимизации. Писк сезона, используется почти во всех ядрах. Особую популярность этот метод получил после того, как организация Linaro с помощью каких-то непонятных синтетических тестов продемонстрировала 400%-й (!) прирост производительности Android, собранного с помощью своего компилятора. В реальных условиях эффективность Linaro GCC несколько ниже, но польза от него все же ощутима, так как он реально подгоняет код под особенности архитектуры ARMv7 и, если судить по личному опыту, не приносит никаких проблем в стабильность работы ни ядра, ни приложений.
2. Расширение возможностей управления частотой и вольтажом центрального и графического процессоров, а также использование более эффективного для планшетов и смартфонов алгоритма управления энергосбережением. Используется во всех кастомных ядрах и ядрах большинства серьезных кастомных прошивок. Подробнее эту особенность мы рассмотрим в следующем разделе.
3. Активация более эффективных внутренних механизмов, появившихся в последних ядрах Linux. Сюда можно отнести SLQB аллокатор памяти, который, по мнению некоторых разработчиков, может быть более эффективным, чем SLUB, однако никаких экспериментальных подтверждений этому нет. Такой аллокатор используется в ядре GLaDOS для Nexus 7.
   

   Приятная полезность Trickster MOD: возможность включить ADB по Wi-Fi

4. Многие разработчики любят изменять стандартный алгоритм контроля насыщения TCP (TCP Congrestion control), который регулирует размер TCP-окна на основе множества параметров, чтобы сделать поток пакетов более ровным и достичь наивысшей скорости передачи данных. Начиная с версии 2.6.19, ядро Linux по умолчанию использует эффективный алгоритм CUBIC, который также обычно применяется и в стандартных ядрах Android. Проблема только в том, что CUBIC эффективен в проводных сетях с высокой скоростью передачи данных, тогда как для 3G- и Wi-Fi-сетей гораздо лучшим выбором будет алгоритм Westwood+. Именно этот алгоритм используется в ядрах Leankernel для Galaxy Nexus и faux123 для Nexus 7, а franko.Kernel для Galaxy S II и Galaxy Nexus так и вообще включает в себя весь набор доступных алгоритмов. Просмотреть их список и выбрать нужный можно с помощью следующих команд:Изменение алгоритма контроля насыщения TCP

   sysctl net.ipv4.tcp_available_congestion_control sysctl -w net.ipv4.tcp_congestion_control=westwood

В 3G-сетях алгоритм контроля перегрузки TCP Westwood+ всегда выигрывает

Еще один тип оптимизации: изменение стандартного планировщика ввода-вывода. Ситуация на этом поле еще более интересная, так как вместо того, чтобы разобраться в принципах работы планировщиков, некоторые сборщики ядер просто читают в Сети документы по I/O-планировщикам для Linux и делают выводы. Среди пользователей такой подход распространен еще более сильно. На самом деле почти все самые производительные и умные Linux-планировщики совершенно не подходят для Android: они рассчитаны на применение с механическими хранилищами данных, в которых скорость доступа к данным разнится в зависимости от положения головки. Планировщик использует разные схемы объединения запросов в зависимости от физического положения данных, поэтому запросы к данным, которые располагаются близко к текущему положению головки, будут получать больший приоритет. Это совершенно нелогично в случае с твердотельной памятью, которая гарантирует одинаковую скорость доступа ко всем ячейкам. Продвинутые планировщики принесут на смартфоне больше вреда, чем пользы, а лучший результат покажут самые топорные и примитивные. В Linux есть три подобных планировщика:

• Noop (No operation) — так называемый не-планировщик. Простая FIFO очередь запросов, первый запрос будет обработан первым, второй вторым и так далее. Хорошо подходит для твердотельной памяти и позволяет справедливо распределить приоритеты приложений на доступ к накопителю. Дополнительный плюс: низкая нагрузка на процессор в силу ну очень простого принципа работы. Минус: никакого учета специфики работы девайса, из-за чего могут возникнуть провалы производительности.
• SIO (Simple I/O) — аналог планировщика Deadline без учета близости секторов друг к другу, то есть разработанный специально для твердотельной памяти. Две главные изюминки: приоритет операций чтения над операциями записи и группировка операций по процессам с выделением каждому процессу кванта времени на выполнение операций. В смартфонах, где важна скорость работы текущего приложения и преобладание операций чтения над записью, показывает очень хорошую производительность. Доступен в Leankernel, ядре Matr1x для Nexus 4 и SiyahKernel.
• ROW (READ Over WRITE) — планировщик, специально разработанный для мобильных устройств и добавленный в ядро всего несколько месяцев назад. Основная задача: первоочередная обработка запросов чтения, но справедливое распределение времени и для запросов записи. Считается лучшим на данный момент планировщиком для NAND-памяти, по умолчанию используется в Leankernel и Matr1x.

Стоит сказать, что почти все стандартные прошивки и половина кастомных до сих пор используют ядро со стандартным для Linux планировщиком CFQ, что, впрочем, не так уж и плохо, поскольку он умеет правильно работать с твердотельными накопителями. С другой стороны, он слишком сложен, создает бОльшую нагрузку на процессор (а значит, и батарею) и не учитывает специфику работы мобильной ОС. Еще один популярный выбор — это планировщик Deadline, который не хуже SIO, но избыточен. Посмотреть список доступных планировщиков можно с помощью такой команды:

# cat /sys/block/*/queue/scheduler

Для изменения применяется такая (где row — это имя планировщика):

# for i in /sys/block/*/queue/scheduler; do echo row > $1; done

Некоторые сборщики ядер применяют и другой вид оптимизации, связанный с вводом-выводом. Это отключение системного вызова fsync, применяемого для принудительного сброса изменившегося содержимого открытых файлов на диск. Существует мнение, что без fsync система будет реже обращаться к накопителю и таким образом удастся сохранить время процессора и заряд батареи. Довольно спорное утверждение: fsync в приложениях используется не так уж и часто и только для сохранения действительно важной информации, зато его отключение может привести к потере этой же информации в случае падения операционной системы или других проблем. Возможность отключить fsync доступна в ядрах franco.Kernel и GLaDOS, а для управления используется файл /sys/module/sync/parameters/fsync_enabled, в который следует записать 0 для отключения или 1 для включения. Повторюсь, что использовать эту возможность не рекомендуется.

Разгоняем графический процессор

Разгон, вольтаж и энергосбережение

Разгон популярен не только среди владельцев стационарных компов и ноутбуков, но и в среде энтузиастов мобильной техники. Как и камни архитектуры x86, процессоры и графические ядра мобильной техники отлично гонятся. Однако сам способ разгона и предпринимаемые для его осуществления шаги здесь несколько другие. Дело в том, что стандартные драйверы для SoC’ов, отвечающие за энергосбережение и изменение частоты процессора, обычно залочены на стандартных частотах, поэтому для тонкого тюнинга приходится устанавливать либо альтернативный драйвер, либо кастомное ядро.

Почти все более-менее качественные и популярные кастомные ядра уже включают в себя разлоченные драйверы, поэтому после их установки возможности управления «мощностью» процессора значительно расширяются. Обычно сборщики кастомных ядер делают две вещи, влияющие на выбор частоты. Это расширение частотного диапазона за рамки изначально заданных — можно установить как более высокую частоту процессора, так и очень низкую, что позволяет сохранить батарею и увеличить градацию частот, например, вместо трех возможных частот предлагается на выбор шесть. Второе — это добавление возможности регулировки вольтажа процессора, благодаря чему можно снизить напряжение процессора на низких частотах для сохранения заряда батареи и повысить на высоких для увеличения стабильности работы.

Всем этим можно управлять с помощью известной платной утилиты SetCPU или же бесплатной Trickster MOD. Рекомендации по управлению все те же, что и для настольных систем. Нижнюю частоту процессора лучше установить минимальной, но не ниже 200 МГц (чтобы избежать лагов), верхний порог повышается постепенно с тестированием стабильности работы, при падении которой рекомендуется немного поднять вольтаж для данной частоты. Каких-то рекомендаций по вольтажу нет, так как каждый процессор уникален и значения будут для всех разными.

Главный экран утилиты настройки ядер Trickster MOD

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

• SmartAssV2 — переосмысление алгоритма Interactive с фокусом на сохранение батареи. Основное отличие в том, чтобы не дергать процессор на высокие частоты в случае кратковременных всплесков нагрузки, для которых хватит и низкой производительности процессора. По умолчанию используется в ядре Matr1x.
• InteractiveX — тюнингованный алгоритм Interactive, главная особенность которого в залочке процессора на минимальной указанной пользователем частоте и обесточивании второго ядра процессора во время отключения экрана. По умолчанию используется в Leankernel.
• LulzactiveV2 — по сути, изобретенный заново OnDemand. Когда нагрузка на процессор превышает указанную (по умолчанию 60%), алгоритм поднимает частоту на определенное число делений (по умолчанию 1), при понижении нагрузки — опускает. Особый интерес представляет тем, что позволяет самостоятельно задавать параметры работы, поэтому подходит для прожженных гиков.

Вообще, сборщики ядер очень любят придумывать новые алгоритмы энергосбережения по причине простоты их реализации, поэтому можно найти еще с десяток других. Большинство из них полный шлак, и при выборе планировщика следует руководствоваться правилом: либо один из трех описанных выше, либо стандартный Interactive, который, кстати, очень неплох. Сделать выбор можно с помощью все той же Trickster MOD.

Trickster MOD позволяет активировать почти все возможности кастомных ядер

Интерфейсы управления

Большинство популярных кастомных ядер включают в себя несколько механизмов тонкого управления различными параметрами драйверов, наиболее распространены из которых ColorControl, GammaControl, SoundControl и TempControl.

• ColorControl и GammaControl позволяют управлять параметрами цветопередачи. Нужно это для того, чтобы отрегулировать не всегда правильную передачу цветов на экране (например, сделать черный черным) или сделать цвета более мягкими и приятными глазу.
  

  Тюнингуем цветопередачу

• SoundControl. Можно использовать для того, чтобы сделать Boost звука в том случае, если он слишком тихий.
• TempControl. Позволяет регулировать максимальное значение датчика температуры (от 50 до 90 градусов), отключающего SoC при перегреве. Полезно для экспериментов с разгоном.

Первые два интерфейса доступны практически везде, включая ядра CyanogenMod, вторые два — в Leankernel и, может быть, в других. Так или иначе, всеми ими можно управлять с помощью Trickster MOD.

Как установить?

Все ядра распространяются в стандартных для Android ZIP-архивах, которые следует прошивать через консоль восстановления точно так же, как альтернативные прошивки. Обычно ядра совместимы с любыми прошивками, поэтому, подобрав нужное ядро, его можно смело устанавливать. Единственное, на что следует обратить внимание, — это версия Android, с которой обеспечена совместимость ядра. Оно может как подойти ко всем доступным для устройства версиям Android, так и работать только с одной (разработчик обычно явно говорит об этом). Перед прошивкой обязательно сделай бэкап текущей прошивки с помощью все той же консоли восстановления. Если что-то пойдет не так, ты всегда сможешь откатиться.

Выводы

Как ты смог убедиться, кастомные ядра обладают множеством преимуществ перед ядрами, используемыми в стандартных или сторонних прошивках. А что еще более важно — необязательно знать все тонкости Android, чтобы их использовать, достаточно скачать и установить ZIP-архив.

Первый экспериментальный образец полноценного трояна для Android был представлен летом 2010 года на конференции DEF CON 18. С тех пор прошло уже три года, и за это время количество вирусов для мобильной ОС от Google выросло в тысячи раз, а Google успела придумать десятки различных методов противостояния угрозам. В этой статье мы детально исследуем мир вредоносов для Android и проследим противостояние поискового гиганта и хакеров.

До нашей эры, или как написать вирус за 15 минут

Первые попытки создать вредоносный софт для Android и доказать несостоятельность гугловской мобильной платформы с точки зрения безопасности начались с публикации первых предварительных версий Android SDK в 2007 году. Молодые студенты писали софт, который использовал стандартную функциональность смартфона для чтения SMS’ок, а «исследовательские» команды, вроде Blitz Force Massada, демонстрировали аж «30 векторов атак на Android», показывая, как можно использовать стандартные API Android во вредоносных целях.

Это было время игрушек, которые нельзя было назвать ни настоящим вредоносным ПО, ни тем более вирусами. То тут, то там появлялись приложения, вроде Mobile Spy от Retina-X Studios, которые позволяли удаленно читать текстовые сообщения, историю звонков, просматривать фотографии, видео, определять координаты смартфона. Встречались и различные поддельные приложения, такие как обнаруженный в маркете в январе 2010 года неофициальный клиент для различных банков, который ни с чем не соединялся, а просто уводил номера кредитных карт, введенных самим пользователем.

Более-менее настоящий троян был реализован только в 2010 году секьюрити-компанией Trustwave, которая продемонстрировала его на конференции DEF CON 18. Впрочем, Америки они не открыли; троян был всего лишь стандартным модулем ядра Linux, который перехватывал системные вызовы write(), read(), open() и close(), а также создавал реверсивный шелл по звонку с определенного номера. Вся эта функциональность позволяла подключиться к смартфону удаленно и скрытно использовать его возможности в своих целях, в том числе читать конфиденциальную информацию.

Для установки руткита требовался физический доступ к устройству, root-права и смартфон HTC Legend (модуль был совместим только с его ядром), поэтому ни о каком практическом применении руткита речи не шло. Proof of concept, который доказал только то, что ядро Linux и в смартфоне остается ядром Linux.

Настоящий троян в «дикой природе» (не маркете) был найден только в августе 2010 года. Правда, это был совсем не тот тип трояна, о котором принято писать в нашем журнале, а всего лишь SMS-троян, то есть, по сути, обычное приложение, которое шлет SMS на платные номера без ведома юзера. Игрушка, которую хороший программист напишет за полчаса, но очень опасная, попади она к обычному юзеру.

Троян, получивший имя Trojan-SMS.AndroidOS.FakePlayer.a, прикидывался видеоплеером под незамысловатым названием Movie Player и с иконкой стандартного проигрывателя из Windows. Приложение требовало права доступа к карте памяти, отправке SMS и получению данных о смартфоне, о чем система сообщала перед его установкой. Если все это не смущало пользователя и он соглашался с установкой и запускал приложение, оно повисало в фоне и начинало отправку SMS на номера 3353 и 3354, каждая из которых обходилась в пять долларов. Номера эти, кстати, действовали только на территории России, так что нетрудно догадаться о корнях автора данного «произведения».

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

Интересно, что номер телефона злоумышленника не был жестко вбит в код трояна, а конфигурировался удаленно. Чтобы его изменить, требовалось отправить на номер жертвы особым образом оформленную SMS, которая содержала номер телефона и пароль. Пароль можно было изменить с помощью другой SMS, по умолчанию использовалась комбинация red4life.

Geinimi и все-все-все

Первый по-настоящему профессионально написанный и обладающий защитой от анализа вредонос для Android был обнаружен только в декабре 2010 года компанией Lookout. Троян, получивший имя Geinimi, качественно отличался от всего, что было написано ранее, и обладал следующими уникальными характеристиками:

• Распространение в составе легитимного ПО. В отличие от всех остальных зловредов, которые только прикидывались настоящими программами и играми, Geinimi на самом деле внедрялся в реально существующие игры. В разное время троян был найден в составе таких приложений, как Monkey Jump 2, President Versus Aliens, City Defense and Baseball Superstars 2010, разбросанных по местным маркетам Китая и различным torrent-трекерам. Функциональность оригинального приложения полностью сохранялась, поэтому пользователь даже не догадывался о заражении смартфона.
• Двойная защита от анализа. Код трояна был пропущен через обфускатор, что затрудняло его анализ, а все коммуникации с удаленным сервером шифровались (справедливости ради стоит сказать, что использовался ущербный алгоритм DES с ключом 12345678).
• Возможность использования для организации ботнета. В коде Geinimi было найдено более 20 управляющих команд, которые позволяли выполнять такие операции, как установка и удаление приложений (правда, на это требовалось разрешение пользователя), получение списка всех установленных программ или запуск приложений.

В целом Geinimi действовал по следующему алгоритму. После запуска зараженного приложения создавался фоновый сервис, который собирал персональные данные: координаты устройства, номера IMEI и IMSI. Затем с интервалом в одну минуту он пытался связаться с одним из десяти удаленных серверов (www.widifu.com, www.udaore.com, www.frijd.com и другими), куда передавалась вся собранная информация и где собирались команды для удаленного исполнения.

Geinimi стал родоначальником полнофункциональных троянов для Android, и после его первого обнаружения на просторах интернета стали все чаще появляться зловреды с аналогичной или похожей функциональностью. Вскоре была найдена модификация Geinimi под названием ADRD, троян Android.Pjapps и множество других. Все они распространялись через различные сайты, torrent-трекеры, китайские неофициальные магазины, поэтому защититься от них можно было, просто не устанавливая приложения из неизвестных источников. Однако все изменилось, когда был обнаружен троян DroidDream, распространявшийся в составе более чем 50 приложений, опубликованных в официальном Android Market.

DroidDream и начало борьбы за чистоту маркета

В марте 2011 года пользователь Lompolo сообщил на reddit, что в маркете Android обнаружено нескольких десятков вредоносных приложений, опубликованных человеком с ником Myournet. Несмотря на заурядность самого трояна, а также уже известный способ распространения, основанный на внедрении кода в легитимное приложение, факт наличия малвари в маркете, а также предположения о том, что она использует эксплойт rageagainstthecage для получения прав root на устройстве, быстро подогрели интерес к новости пользователей и сотрудников различных секьюрити-компаний. За несколько дней начальный список из двух десятков приложений расширился до 56, а среди публиковавших его людей (или ботов, кто знает) обнаружились Kingmall2010 и we20090202.

Сам по себе DroidDream по функциональности был очень похож на упрощенный Geinimi, но не был его вариацией. Он также собирал информацию о смартфоне, отправлял ее на удаленный сервер (http://184.105.245.17:8080/GMServer/GMServlet) и получал в ответ управляющие команды. Плюс ко всему он также содержал в себе другое приложение, спрятанное в каталоге assets/sqlite.db внутри APK и устанавливаемое в систему под именем DownloadProvidersManager.apk. Очевидно, это была защита от удаления.

В сумме зараженные приложения успели установить от 50 до 200 тысяч пользователей, пока команда безопасности Google не отреагировала на сообщение и не удалила из маркета все найденные копии зловреда и аккаунты выложивших их пользователей. В дополнение в маркете также появилось приложение Android Market Security Tool, с помощью которого пользователь мог очистить смартфон от заразы. Но и здесь не обошлось без конфуза. Буквально через два дня после этого Symantec обнаружила на просторах интернета зараженную версию этого приложения, которая содержала в себе уже другой троян, названный впоследствии Fake10086 за выборочную блокировку SMS с номера 10086.

Факт проникновения малвари в Android Market (а после DroidDream в маркете было обнаружено еще несколько вирусов) заставил Google серьезно задуматься над безопасностью своего репозитория приложений, а так как вручную они ничего делать не привыкли, то в результате в начале 2012 года выкатили сервис Bouncer, который проверял приложения на безопасность с помощью запуска в виртуальной машине. Задача Bouncer состояла в том, чтобы производить многократный запуск софтины, симулировать работу пользователя с приложением и анализировать состояние системы до и после работы с приложением. Если никаких странных и подозрительных действий софтина себе не позволяла, то она пропускалась в маркет, в противном случае публикация блокировалась.

Если верить Google, то сразу после запуска Bouncer сократил количество вредоносов в маркете на 40% (как они это подсчитали, остается загадкой). Однако позднее выяснилось, что его можно легко обойти, просто проанализировав некоторые характеристики системы, такие как email-адрес владельца «смартфона», версию ОС и так далее, а затем создав приложение, которое при их обнаружении будет действовать абсолютно законно и делать грязную работу только на настоящем смартфоне. Скорее всего, Google уже разработала схему противодействия обнаружению Bouncer (например, с помощью генерации уникальных виртуальных окружений для каждого приложения).

Конец 2011 года: начало стремительного роста количества вирусов для Android

Zeus-in-the-Mobile

Пять лет назад по компам пользователей начал свое победоносное шествие троян под названием Zeus. Благодаря изощренному дизайну и продвинутым техникам маскировки, делавшим его обнаружение невероятно трудной задачей, он смог распространиться на миллионы машин по всему миру и создать один из самых крупных ботнетов в истории; только в США было зафиксировано более трех с половиной миллионов случаев заражения.

Так выглядел интерфейс первой обнаруженной версии Zeus

Основная задача Zeus состояла в организации атаки типа man-in-the-browser, то есть использования техник кейлоггинга и формграббинга для перехвата частной пользовательской информации и ее отправки на удаленные серверы. За время своей работы Zeus смог утащить сотни тысяч логинов и паролей от популярных сервисов (Facebook, Yahoo!, hi5, metroFLOG, Sonico, Netlog) и, конечно же, множества онлайн-банков.

Разработчик Zeus быстро отреагировал на появление систем двухфакторной аутентификации и в 2010 году выпустил для Symbian и BlackBerry приложения, задача которых состояла в перехвате аутентификационных SMS-сообщений с одноразовыми кодами авторизации и их последующей отправке на все те же удаленные серверы. В середине 2012 года аналогичное приложение появилось и для Android.

Первая его версия была очень примитивна и представляла собой якобы секьюрити-приложение, которое при запуске выводит код верификации и закрывается. В результате в фоне повисает сервисный процесс, который занимается перехватом SMS и их отправкой на удаленный сервер. Последующие версии Zeus для Android обзавелись также системой удаленного управления с помощью сообщений с определенного номера, однако никаких продвинутых приемов маскировки или распространения вирус не использовал и в этот раз.

Тем не менее мобильная версия Zeus все-таки смогла наделать много шума в СМИ, но, как можно видеть, троян был сильно переоценен.

А так выглядела версия, обнаруженная спустя десять месяцев

Первый IRC-бот

В середине января 2012 года сотрудники «Лаборатории Касперского» сообщили, что обнаружен первый в истории Android IRC-бот. Приложение распространялось в виде установочного APK-файла размером чуть больше 5 Мб и выдавало себя за игру Madden NFL 12. Интересное отличие этого трояна от других было в том, что, по сути, вся его логика работы заключалась в нативных приложениях Linux, которые никак не светились в окне стандартного диспетчера задач Android и к тому же использовали локальный эксплойт для получения прав root.

Во время запуска приложение создавало каталог /data/data/com.android.bot/files, в котором размещало три файла: header01.png, footer01.png, border01.png, а затем ставило на них бит исполнения и запускало первый файл — эксплойт Gingerbreak для получения прав root на устройстве. Если была установлена уже рутованная прошивка, приложение пыталось получить права root штатными средствами, в результате чего у пользователя запрашивалось предоставление повышенных привилегий (тот случай, когда рутованный смартфон безопаснее залоченного).

В случае успешного получения прав root любым из двух способов запускался второй файл, в котором хранился SMS-троян — модификация известного трояна Foncy SMS. Троян определял принадлежность SIM-карты стране и начинал отправку сообщений на короткий платный номер, блокируя все ответные сообщения. Следующим запускался файл border01.png, в котором был код IRC-бота. Он подключался к IRC-серверу с IP-адресом 199.68.. и регистрировался на канале #andros под случайным ником. Все сообщения, отправленные боту, выполнялись в консоли как обычные Linux-команды.

Согласно заявлению сотрудников «Лаборатории Касперского», это было первое приложение такого класса для Android. Однако, по их мнению, опасность его была невелика, так как распространялся он только через серые маркеты, а эксплойт работал только в ранних версиях Android 2.3.

Первый полиморфный троян

В феврале 2012-го компания Symantec сообщила, что обнаружила первый полиморфный троян для платформы Android, который на тот момент не мог быть найден ни одним мобильным антивирусом, кроме ее собственного (сюрприз). Троян, названный Android.Opfake, распространялся через различные веб-сайты, находившиеся преимущественно на территории России и стран СНГ, в виде бесплатной версии популярного приложения или игры.

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

После попадания на смартфон жертвы и запуска троян извлекал из файла res/raw/data.db(который существовал в любой версии трояна) список операторов связи и платных коротких номеров и начинал отправку SMS. В дополнение троян открывал в браузере веб-страницу, содержащую ссылки на другое вредоносное ПО. Интересно, что сообщения также изменялись при каждой новой мутации трояна, в результате чего было невозможно блокировать определенные типы сообщений на стороне оператора.

Различия в контрольных суммах файлов пакета с трояном, скачанных в разное время

Вирус-матрешка

Неделей раньше, а именно 1 февраля 2012 года, на сайте Виктор Чебушев опубликовал заметку, посвященную обнаружению нового типа вируса, распространяемого через магазин Google Play. Вирус маскировался под приложение Superclean, способное, по словам разработчиков, очистить память устройства и таким образом поднять производительность смартфона или планшета. На тот момент приложение имело уже от 1000 до 5000 установок и хороший рейтинг в 4,5 звезды.

Как выяснилось, Superclean действительно выполнял очистку памяти, но делал это простым перезапуском всех фоновых приложений с помощью всего пяти строк на языке Java. На этой «сложной» задаче полезное действие приложения заканчивалось, а самое интересное начиналось дальше. Анализируя код, сотрудник «Лаборатории Касперского» обнаружил, что при запуске приложение соединялось с удаленным сервером и загружало на карту памяти три файла: autorun.inf, folder.ico и svchosts.exe.

Первые два автоматически превращали подключаемый к USB-порту компа смартфон в самозагружаемую флешку, с которой запускался файл svchosts.exe. Сам svchosts.exe на поверку оказался бэкдором Backdoor.MSIL.Ssucl.a, который слушает микрофон компьютера и отправляет все полученные с его помощью данные на удаленный сервер.

Страница приложения Superclean. Обрати внимание на рейтинг

Отличительной чертой трояна был также самый внушительный на тот момент набор функциональности из всех мобильных зловредов для Android. По команде от оператора он мог отправлять сообщения без ведома пользователя, включать и выключать Wi-Fi, собирать информацию об устройстве, открывать произвольные ссылки в браузере, отправлять на удаленный сервер содержимое SD-карты, SMS-переписку и выполнять многие другие операции.

Все, что выводит Superclean на экран

Очередной ответ Google, или принудительная проверка всех приложений

К концу 2012 года ситуация с зловредами для Android стала уже настолько накаленной, что Google решила пойти на очередной кардинальный шаг. В сентябре без лишней огласки был приобретен сервис онлайн-проверки приложений на вирусы VirusTotal, а 29 октября выпущена версия Android 4.2, одним из новшеств которой стала автоматическая проверка любого устанавливаемого не через Google Play приложения на вирусы через удаленный сервис.

Трудно сказать, использовала ли Google купленный VirusTotal для этой задачи, или у них есть собственный сервис проверки, однако не нужно быть сотрудником Google, чтобы понять, что VirusTotal так или иначе был использован для защиты Android от вирусов.

Самый продвинутый троян

В июне этого года сотрудники «Лаборатории Касперского» обнаружили наиболее сложный и продвинутый в техническом плане троян для Android из всех, что встречались до этого. Троян получил имя Backdoor.AndroidOS.Obad.a. Это было независимое приложение, не внедряемое в легитимный софт и, судя по всему, распространяемое под видом известных приложений.

После соглашения пользователя с длинным списком полномочий, установки и запуска он запрашивал права администратора устройства (речь идет не о root, а о собственной системе безопасности Android), которые были нужны только для двух вещей: самостоятельной блокировки экрана и защиты от удаления. Последнее троян делал особенно изысканно. Используя ранее неизвестный баг в Android, он удалял себя из списка приложений с полномочиями администратора, из-за чего его невозможно было лишить этих прав и, как следствие, удалить.

Далее троян проверял в системе наличие прав root и при следующем подключении к Wi-Fi-сети отправлял информацию об устройстве на удаленный сервер. Информация была типична для такого рода приложений и содержала в себе номер телефона, IMEI, MAC-адреса и подобную информацию. В ответ он получал список команд для исполнения и заносил их в базу данных с пометкой о времени исполнения. Удаленными командами могли быть: проверка баланса, отправка сообщений, переход в режим проксирования трафика, скачивание и установка приложений, отправка файлов по Bluetooth, открытие шелла и другие. Плюс ко всему при каждом подключении к другому устройству по синему зубу он копировал сам себя на это устройство.

При попытке анализа кода трояна обнаружилось использование множества техник защиты от анализа. Во-первых, троян эксплуатировал неизвестный ранее баг в утилите dex2jar, из-за которого декомпиляция кода трояна происходила некорректно. Во-вторых, троян использовал еще один неизвестный баг в Android, позволяющий создать файл Manifest.xml, в котором содержится метаинформация о приложении, таким образом, чтобы он противоречил стандартам Google, но при этом корректно обрабатывался при запуске приложения. Из-за этого многие инструменты анализа просто не срабатывали.

Backdoor.AndroidOS.Obad.a требует множество полномочий для работы

Если же удавалось распаковать и декомпилировать код трояна, обойдя эти ограничения, то дальше приходилось иметь дело с многоуровневой системой шифрования, которая защищала от анализа все текстовые данные, а также имена методов (они тоже были строками и вызывались посредством рефлексии). Интересно, что ключом для первого слоя шифрования была строка с главной страницы facebook.com, из-за чего работу трояна невозможно было проанализировать в «стерильной комнате», без подключения к интернету (хотя ограничение, конечно, можно обойти с помощью прокси).

А плюс ко всему еще и запрашивает права администратора

Выводы

Количество вирусов для Android сегодня исчисляется тысячами, и некоторые из них действительно представляют интерес для исследователя как образцы хорошего программирования и знания архитектуры Android. Вот только бояться их не стоит. Автор данной статьи уже четвертый год использует смартфоны на Android без всяких антивирусов и ни разу не поймал на них заразу. Главное — читать полномочия приложений и ставить их только из маркета.