System bin android что это такое

После этого происходит инициализация переменных, необходимых для работы устройства. Если вас заинтересует эта тема, то вы легко найдете информацию о той или иной комманде. Давайте подробно рассмотрим следующий блок (который я уже приводил в этой статье):

MTD — Memory Technology Devices. Если в общих чертах, то MTD — это специальный чип с энергонезависимой (т.е. данные на этом чипе сохраняются после перезагрузки или выключения) flash-памятью (типа NOR или NAND), на который сохраняются образы дисков. В этой статье более подробно рассказывается об этом типе устройств, а также об ограничениях. Специально для этих разновидностей flash-памяти были разработаны специальные файловые системы, например, YAFFS. Одно из самых важных ограничений этих типов памяти заключается в том, что для того чтобы записать данные в сектор, куда уже записаны какие-то данные, вам надо полностью сначала стереть весь сектор. Поэтому производители стали переходить на новый тип блочной flash-памяти (eMMC), на которые можно поставить обычную ext4 файловую систему и избавиться от указанного ограничения. Т.к. я показываю пример init.rc файла для эмулятора, где вся работа эмулируется, то в нем по умолчанию используется файловая система YAFFS2 (думаю, что это пережитки прошлого, т.к. YAFFS2 использовалась для всех устройств до Android 2.2). В реальном устройстве (это как раз один из примеров, когда необходимо использовать init.rc файл для определенного железа) эти комманды будут перезаписаны. Например, в случае устройства herring (Google Nexus S), в файле init.herring.rc эта секция выглядит следующим образом:

Где fstab.herring — это файл, содержимое которого выглядит следующим образом:

Как вы могли заметить, /system, /data, /cache — это просто mounting points (точки монтирования файловой системы), которые указывают либо на MTD устройства (в случае эмулятора), либо на блочные устройства (в случае настоящего устройства), куда записаны соответствующие дисковые образы (system.img, userdata.img и cache.img). Я не уверен, но думаю, что внутри смартфона находится один единственный чип с flash-памятью, разделенный на partitions (тома), в каждый из которых записан соответствующий образ. Этот чип с flash-памятью — то, что мы знаем под именем Internal storage (внутренняя память), объем которой — один из основных параметров смартфона.

Следует заметить, что /system смонтирован read-only (только для чтения). Это означает, что содержимое данного раздела не изменяется в процессе работы устройства, а только когда вы, например, обновляете систему на вашем устройстве (используя системные обновления).

Продолжим рассматривать наш init.rc. По триггеру post-fs-data формируется базовая структура файловой системы /data раздела. Там, в общем всё понятно — набор mkdir, chown, chmod команд.

Далее init.rc запускает несколько демонов. Если вернуться к рисунку в начале статьи, то они перечислены в блоке Native daemons. На этом мы пока остановимся. Как вы могли заметить из рисунка, я не полностью рассмотрел процесс загрузки операционной системы. Некоторые непокрытые этапы я рассмотрю в следующих статья.

Заключение

В следующей части я расскажу, откуда берутся образы system.img, userdata.img и cache.img и рассмотрю безопасность на уровне Native user space. Как всегда приветствуются исправления, дополнения, а так же предложения, о чем написать. И хотя у меня уже есть некоторый план, о чем писать в следующих статья, я готов его подкорректировать.

Ссылки

Update

• Комментарий от пользователя bmx666 про различные варианты размещения загузчика на MTD устройствах.
• Комментарий от пользователя SamOwaR про инициализацию CPU на разных SoC

Источник

Еще один [почти] неудаляемый троянец под Android

В конце прошлого года с помощью функции обнаружения изменений в системной области у некоторых наших пользователей было зафиксировано изменение системного файла /system/lib/libc.so. Это одна из главных библиотек операционных систем на базе Linux, которая отвечает за системные вызовы и основные функции. Подробное рассмотрение этого случая позволило выявить новые образцы из семейства троянцев Android.Xiny, известного нам с 2015 года.

У его представителей мы впервые увидели установку атрибута «неизменяемый» на файлы, что существенно усложняло удаление троянцев с устройств.

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

В этой статье мы рассмотрим еще один интересный метод самозащиты, применяемый новыми версиями Android.Xiny.

Android 5.1? В 2019 году?

Троянец, рассматриваемый в данной статье, работает под ОС Android до версии 5.1 включительно. Может показаться странным, что вредоносное ПО, рассчитанное на столь «древние» версии Android, всё ещё активно (версия 5.1 вышла в 2015 году). Но, несмотря на свой возраст, старые версии всё ещё используются. По данным корпорации Google на 7 мая 2019 года, 25.2% устройств работают под управлением Android 5.1 и ниже. Статистика по нашим пользователям даёт чуть большее число — около 26%. Это значит, что около четверти всех Android-устройств являются потенциальными целями, что не так уж и мало. Учитывая, что указанные устройства подвержены уязвимостям, которые никогда не будут исправлены, неудивительно, что старые версии ОС Android всё ещё представляют интерес для вирусописателей. Ведь права root, которые можно получить с помощью эксплуатации упомянутых уязвимостей, развязывают вирусописателям руки — с их помощью можно делать на устройстве всё что угодно. Хотя чаще всего это сводится к банальной установке приложений.

Основные функции троянца

Начиная с самых ранних версий, главная функция троянца Android.Xiny — установка на устройство произвольных приложений без разрешения пользователя. Таким образом злоумышленники могут зарабатывать, участвуя в партнёрских программах, которые платят за установку. Насколько можно судить, это один из основных источников дохода для создателей данного семейства. После запуска некоторых его представителей можно за несколько минут получить практически неработоспособное устройство, на котором будет установлено и запущено множество безвредных, но ненужных пользователю приложений. Кроме того, данные троянцы могут устанавливать и вредоносное ПО — всё зависит от команды, полученной с управляющего сервера.

Самое интересное, что выделяет новые версии троянца Android.Xiny — это защита от удаления. За неё отвечают два компонента. Рассмотрим их подробнее.

Установщик

sha1: f9f87a2d2f4d91cd450aa9734e09534929170c6c
детект: Android.Xiny.5261

Данный компонент запускается после получения прав root. Он подменяет собой системные файлы /system/bin/debuggerd и /system/bin/ddexe, чтобы обеспечить свой автоматический запуск, а оригиналы сохраняет под именами с суффиксом _server, действуя как классический вирус-компаньон. Также он копирует в системный раздел ещё несколько исполняемых файлов из папки, переданной в параметрах командной строки. Кроме того, троянец может обновлять компоненты, которые установил в системный раздел, если его запустить с особыми параметрами и указать папку, где лежат новые версии.

Android.Xiny.5261 содержит внушительный список файлов для удаления. В него входят пути, характерные для более старых представителей семейства, а также для конкурирующих семейств троянцев, устанавливающихся в системный раздел. Таких как, например, Triada.

Кроме того, Android.Xiny.5261 удаляет некоторые предустановленные приложения — возможно, чтобы освободить место. Наконец, он удаляет известные приложения для управления правами root – такие как SuperSU, KingRoot и другие. Таким образом, он лишает пользователя возможности использовать root-права, а значит, и удалить троянские компоненты, установленные в системный раздел.

Модифицированная системная библиотека libc.so

sha1: 171dba383d562bec235156f101879223bf7b32c7
детект: Android.Xiny.5260

Этот файл заинтересовал нас больше всего, и с него началось это исследование. При беглом взгляде на него в hiew можно заметить наличие исполняемого кода ближе к концу в секции .data, что подозрительно.

Открываем файл в IDA и смотрим, что это за код.

Выясняется, что в данной библиотеке были изменены следующие функции: mount, execve, execv, execvp, execle, execl, execlp.

Код изменённой функции mount:

int __fastcall mount ( const char * source , const char * target , const char * filesystemtype , unsigned int mountflags , const void * data )
<
unsigned __int8 systemPath [ 19 ] ; // [sp+18h] [bp-1Ch]
bool receivedMagicFlags ; // [sp+2Bh] [bp-9h]
int v13 ; // [sp+2Ch] [bp-8h]
v13 = MAGIC_MOUNTFLAGS ; // 0x7A3DC594
receivedMagicFlags = mountflags == MAGIC_MOUNTFLAGS ;
if ( mountflags == MAGIC_MOUNTFLAGS )
mountflags = 0x20 ; // MS_REMOUNT
if ( receivedMagicFlags )
return call_real_mount ( source , target , filesystemtype , mountflags , data ) ;
if ( mountflags & 1 ) // MS_RDONLY
return call_real_mount ( source , target , filesystemtype , mountflags , data ) ;
if ( getuid_ ( ) ) // not root
return call_real_mount ( source , target , filesystemtype , mountflags , data ) ;
memCopy ( systemPath , ( unsigned __int8 * ) off_73210 + 471424 , 8 ) ; // /system
decrypt ( systemPath , 8 ) ;
if ( memCompare ( ( unsigned __int8 * ) target , systemPath , 8 ) || ! isBootCompete ( ) )
return call_real_mount ( source , target , filesystemtype , mountflags , data ) ;
* ( _DWORD * ) errno_ ( ) = 13 ;
return — 1 ;
>

В начале тут происходит проверка параметра mountflags на наличие «волшебного» значения 0x7A3DC594. Если функции передано это значение, управление сразу передаётся настоящей функции mount. Далее проверяется, происходит ли попытка перемонтировать раздел /system на запись и завершена ли загрузка ОС. Если эти условия выполняются, настоящая функция mount не вызывается и возвращается ошибка. Таким образом, модифицированная троянцем функция mount не даёт перемонтировать системный раздел на запись никому, кроме самого троянца, который вызывает её с «волшебным» параметром.

Код изменённой функции execve (в остальных exec*-функциях всё аналогично):

int __fastcall execve ( const char * filename , char * const argv [ ] , char * const envp [ ] )
<
int v3 ; // r3
if ( targetInDataOrSdcard ( filename ) >= 0 ) // returns -1 if true
<
sub_7383C ( ) ;
v3 = call_real_execve ( filename , argv , envp ) ;
>
else
<
* ( _DWORD * ) errno_ ( ) = 13 ;
v3 = — 1 ;
>
return v3 ;
>

int __fastcall targetInDataOrSdcard ( const char * path )
<
char buf [ 516 ] ; // [sp+8h] [bp-204h]
if ( isDataOrSdcard ( path ) )
return — 1 ;
if ( * path == ‘.’ && getcwd_ ( buf , 0x200u ) && isDataOrSdcard ( buf ) )
return — 1 ;
return 0 ;
>

Здесь проверяется, начинается ли путь к запускаемому файлу с «/data/» и содержит ли «/sdcard». Если одно из условий выполняется, запуск блокируется. Напомним, что по пути /data/data/ находятся директории приложений. Таким образом блокируется запуск исполняемых файлов из всех директорий, в которых обычное приложение может создать файл.

Изменения, внесённые в системную библиотеку libc.so, нарушают работу приложений, предназначенных для получения прав root. Из-за изменений в функциях exec* такое приложение не сможет запустить эксплойты для повышения привилегий в системе, поскольку обычно эксплойты представляют собой исполняемые файлы, которые скачиваются из сети в директорию приложения и запускаются. Если же повысить привилегии всё-таки удалось, изменённая функция mount не даст перемонтировать системный раздел на запись, а значит, и произвести в нём какие-либо изменения.

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

Как бороться с таким троянцем?

Чтобы избавиться от Android.Xiny.5260, устройство можно перепрошить – при условии, что в открытом доступе существует прошивка для него. Но можно ли удалить вредоносную программу другим способом? Сложно, но можно – есть несколько путей. Для получения прав root можно использовать эксплойты в виде so-библиотек. В отличие от исполняемых файлов, их загрузку троянец не заблокирует. Также можно воспользоваться компонентом самого троянца, который предназначен для предоставления root-прав другим его частям. Он получает команды через сокет по пути /dev/socket/hs_linux_work201908091350 (в разных модификациях путь может отличаться). Что касается обхода блокировки mount, можно использовать «волшебное» значение параметра mountflags, либо напрямую вызвать соответствующий syscall.

Реализовывать я это, конечно, не буду.

Если ваше устройство подхватит такого троянца, мы рекомендуем использовать официальный образ операционной системы для его перепрошивки. Однако не забывайте, что при этом удалятся все пользовательские файлы и программы, поэтому заранее позаботьтесь о создании резервных копий.

Источник