What is android system img

Android_ROM_IMG_Repacker_v22.zip ( 234.25 КБ )

За помощь в создании спасибы master_lee
За ImgExtractor And_pda
Мануал по установке от Shipiloff69 Видео

Сообщение отредактировал A.S._id — 21.08.17, 09:14

никаких морок с размером, атрибутами и контекстами — всё сохраняется

Сообщение отредактировал A.S._id — 26.04.15, 01:27

A.S._id,
Да, конвертит отлично.

А вот сборка из папки.

A.S._id,
Да, конвертит отлично.

А вот сборка из папки.

Ну я честно говоря не совсем понимаю как описывать добавление контекстов селинукс, вот для сравнения попробуйте тоже самое на телефоне как будет работать.
Или лучше я думаю это надо смотреть Makefile сборки Android из исходников, как там описано.
Вобщем разобрался в чем было дело и починил.
Короче говоря переделал я исходники и пересобрал тулзы — я по началу сделал make_ext4fs по подобию как для Linux т.е. при сборке атрибуты должны сохраняться, но т.к. для винды это не подходит (атрибутов UNIX у файлов НЕТ), поэтому пришлось добавлять атрибуты при сборке по умолчанию 644 root:root. Это значит что после сборки атрибуты файлов нужно править в соответствии с параметрами ОС, хотя по идее операнд -а
mount point по идее должен выставить правильные атрибуты сам, но я не проверял — надо будет попробовать

Попробовал — атрибуты выставляются верные

Источник

What is android system img

/ramdisk# gzip -dc ../boot.img-ramdisk.gz | cpio -i
986 блок
[email protected]:

#
В папке ramdisk 18 объектов, всего 514,6 КБ
Где все остальное ?? где файлы ядра ?

Какие еще файлы ядра??

boot.img-kernel — это zImage-образ ядра. Если ты имеешь ввиду исходники ядра, то с образа их никак не получишь.
boot.img-ramdisk.gz — cpio/gz архив рамдиска с init.rc и прочей хренью. Его содержимое распаковано в папку ramdisk.
А больше ничего в буте и нету. То же самое касается и recovery.img

system.img (и userdata.img) — образ файловой системы в формате yaffs2. Распаковывается утилитой unyaffs под линухом. Ну или могу под винду утилиту подкинуть.

Ну что же, мысль здравая, если знаете что к чему.

1 Скачайте/найдите в интернете исходники для своего устройства. Если устройство htc, то developer.htc.com, если другое, ищите в интернете.
2 Ввнесите нужные изменения в файл arch/arm/mach-msm/acpuclock.c,
3 Скачайте к примеру NDK с андроидовского сайта (нужно для кросс-компиляции). Как я понял, у вас убунту. Тогда дальше все просто.
4 ARCH=arm CROSS_COMPILE=/путь_куда_установили_ndk/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- make zImage
5 mkbootimg —kernel arch/arm/boot/zImage —ramdisk ваш_рамдиск.gz —cmdline то_что_писало_когда_вы_извлекали_рамдиск -o boot.img
6 adb push boot.img /cache/ && adb shell flash_image boot /cache/boot.img

Нельзя ли поподробней с компиляцией ?
Вот эту строку которую вы указали, ка я понял надо вписывать в Makefile ? И вообщем у последнего NDK совсем другой путь папок ! Может дадите ссылку на ваш NDK ?
И еще можно ли делать компиляцию через arm-2007q3 как написано тут http://www.anddev.org/learning_porting_and. step-t3252.html .
Или через windows компиляцию сделать можно ?

Сообщение отредактировал bobjob — 17.02.11, 17:33

unyaffs под винду.
При распаковке:
— теряются owners, permissions и даты создания/изменения/доступа
— симлинки заменяются на файлы в фигурных скобках <>, внутри — путь куда указывает симлинк
Просто для извлечения данных этого вполне достаточно.
Написано на коленке в делфях.
Использование: unyaffs.exe файл.img
Cygwin не нужен.

Скачать: unyaffs.zip ( 12.23 КБ )

Источник

Основы безопасности операционной системы Android. Native user space, ч.2

Вступление

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

Список статей

Что подразумевается под Native user space

Под Native user space подразумеваются все компоненты пространства пользователя, которые выполняются вне Dalvik Virtual Machine, и которые не являются частью Linux kernel. Native user space — это исполняемые файлы, скомпилированные под определенную архитектуру. К ним относятся исполняемые файлы, которые запускаются из init скрипта автоматически или в случае наступления какого-либо события, toolbox утилиты, а также некоторые исполняемые файлы, которые пользователь может запустить из-под shell.

Начало

Как я уже рассказывал в первой части, в основе Android лежит Linux kernel. Как и во всех Linux системах, в основе безопасности Android лежит access control. Т.е. каждый ресурс (например, файл) содержит мета-информацию о том, кто создал этот файл — owner (владелец) — и к какой основной группе (owner group) принадлежит owner (владелец). Каждый процесс запускается от имени какого-то user (пользователя). У каждого пользователя есть основная группа. Кроме того он может являться членом других групп. Таким образом, если к каждому ресурсу прикрепить информацию (в формате rwxrwxrwx) о том, кто может читать/писать/исполнять ресурс (например, файл), то можно контролировать доступ к этому файлу. Например, файлу можно назначить разрешения: что может делать с этим файлом owner (владелец) этого файла; что могут делать пользователи, которые входят в состав owner group; что могут творить все остальные. Здесь об этом можно почитать подробнее.

Но у Android есть некоторые отличия. Во-первых, изначально Android — это операционная система для телефонов, которые, как известно, относятся к очень личным вещам и которые мы не любим давать в чужие руки. То есть она была задумана как операционная система, у которой только один пользователь. Поэтому было принято решение использовать различных Linux users для обеспечения безопасности (для каждого приложения — отдельный пользователь, как я уже рассказывал в первой статье). Во-вторых, в Android некоторые user (пользователи) и их UID (идентификаторы) были жестко запрограммированы в систему, что вызывает очень много нареканий людей связанных с безопасностью (хотя я, если честно, не очень понимаю, почему критикуется такой подход). Мы уже видели этих пользователей в файле system/core/include/private/android_filesystem_config.h Например, root имеет идентификатор 0, а system — 1000.

Как я уже отмечал, процесс запускается от имени того же пользователя (UID), что и процесс, который запускает этот новый процесс, т.е. UID(calling_process) == UID (called_process). Первый процесс, который запускается в Android — init — запускается от имени root (UID == 0). Таким образом, по-идее, все процессы также должны быть запущены от имени того же пользователи. Так оно, наверное, бы и было. Но, во-первых, процессы, запущенные от имени привилегированного пользователя (а так же те, кто обладает определенными capabilities), могут изменять свой UID на менее привилегированный. А во-вторых, в Android при запуске демонов в init.rc скрипте так же можно указать, с привилегиями какого пользователя и каких групп запускать данный процесс.

Все процессы, которые будут запущены через этих демонов, уже не будут иметь root привилегии.

System, data и cache

Я столько раз анонсировал эту тему, что можно было подумать, что она очень сложная и запутанная. На самом деле, это не так. System.img, userdata.img и cache.img — то, что получается в результате компиляции операционной системы Android. То есть в результате сборки системы получаются эти три файла, которые мы и записываем на наше устройство.

Но самое важно здесь не это. Благодаря тому, что в Android системе user name и UID системных пользователей жестко запрограммированы, уже на этапе компиляции мы можем определить права доступа различных системных пользователей к различным директориям в данных образах. Эти права доступа указаны в файле system/core/include/private/android_filesystem_config.h, который мы уже рассматривали в первой статье. Права доступа определяются отдельно для директорий (android_dirs[]) и отдельно для файлов (android_files[]) следующим образом:

А функция static inline void fs_config(const char *path, int dir, unsigned *uid, unsigned *gid, unsigned *mode, uint64_t *capabilities), которая определена дальше в этом файле отвечает за выставление owner, owner group, capabilities и прав доступа. Эта функция вызывается во время сборки образа.

В общем здесь всё должно быть более-менее понятно, за исключением установки флагов прав доступа (setuid и setgid) для некоторых файлов (например, для «system/xbin/su» права доступа определены как 06755, где первая 6 означает, что выставлен флаг установки ID пользователя (4) и флаг установки ID группы (2)). Установка этих флагов означает, что пользователь может повысить права запускаемого процесса до уровня owner (владельца) файла или owner group (группы владельца). В случае Android, каждое приложение — это пользователь со своими UID и GID. Таким образом, по умолчанию если вы из своего приложения запускаете какой-нибудь native executable, он исполняется с теми же UID и GID, как и приложение его вызвавшее. Установка данных флагов прав доступа позволяет выполнить native executable с правами владельца. В нашем случае, владелец — AID_ROOT (root). Происходит это следующим обрзазом system/extras/su/su.c:

Т.е. вызываются функции setuid и setgid. В этом случае, если данные функции выполнились успешно, то процесс начинает работать от имени owner и owner group данного файла. В нашем примере, данный процесс получает права суперпользователя, т.е. он может делать всё, что ему пожелается 🙂 Подобная анархия не всегда оправдана, поэтому в Linux ввели понятие capabilities. Так приложению «run-as» не нужны всё права суперпользователя, ему достаточно иметь возможность только менять свой идентификатор, чтобы запускать приложения от имени различных пользователей. Кстати, capabilities похоже появились недавно — в Android 2.3.x я их не встречал.

Безопасность

В случае привилегированных программ (типа, su) необходимо ограничивать круг приложений, которые могут вызывать эти программы. В противном случае любое приложение может получить права суперпользователя. Поэтому очень часто в такие программы встраивают проверку по UID:

Т.е. программа вначале проверяет, от чьего имени запущен вызывающий процесс, используя функцию getuid(). А потом сравнивает эти значения со значениями, которые жестко запрограммированы в систему. В данном случае, только процессы запущенные от имени пользователей «system» и «root» имеют право использовать su.

Заключение

В данной статье мы закончили разбирать, как обеспечивается безопасность на уровне Native user space. В следующих статьях я планирую разобрать, как работают permission (разрешения), но в связи с большой текущей загрузкой не знаю, когда приступлю к их написанию. Как всегда, буду очень рад дополнениям и исправлениям.

Источник

Русские Блоги

Разархивируйте system.img в системе Android

В этой статье объясняется, что такое system.img, и как его запаковать и распаковать.

Что такое system.img

system.img — это образ (образ), используемый для хранения системных файлов в системе Android. Формат файла — yaffs2 или файловая система ext. Файл будет создан после компиляции исходного кода Android. Он будет смонтирован (смонтирован) в каталог / system или системный раздел процессом init путем анализа файла init.rc

Как сделать system.img

Используйте следующую команду, чтобы сделать system.img

Описание команды
make_ext4fs Используется для создания зеркального отображения файловой системы ext4 на платформе Android.
Описание параметра
-s Указывает на тихую обработку, отсутствие действия вывода, дополнительные параметры
-T Представляет временную метку Unix, устанавливает время модификации файла в system.img
-S File_contexts, представляющие sepolicy
-l Представляет наибольший размер файла (ограничен размером раздела)
-a Указывает точку монтирования Android, такую ​​как система, пользовательские данные, восстановление, make_ext4fs Будет основано на private/android_filesystem_config.h Установите разрешения, определенные в папке, чтобы сбросить разрешения для всех файлов в папке, если они не указаны -a Параметры, используйте разрешения по умолчанию
system.img Указывает имя выходного файла
system/ Указывает входной каталог, который содержит framework, app, bin и другие каталоги
После выполнения команды вы получите сжатый файл system.img, который нельзя смонтировать напрямую. Как просмотреть содержимое system.img, мы расскажем позже.

Как распаковать system.img

system.img входит в пакет прошивки системы, распакуйте архив прошивки, обычно есть две ситуации

Получите system.img напрямую

В версиях до Android 5.0 (не включая 5.0) system.img можно получить напрямую, распаковав флэш-пакет, а system.img может быть файловой системой raw, yaffs2 или ext.
использовать file Команда может различать формат файловой системы system.img

Если вывод — это данные файловой системы Linux версии 1.0 ext4, это означает, что это необработанный файл.
Если на выходе получается исполняемый файл VMS Alpha, это означает, что это файл yaffs2
Если вывод — это данные, это означает, что это файл ext.

Просмотрите содержимое system.img в сыром формате

Данные файловой системы Linux версии 1.0 ext4 показывают, что system.img представляет собой полный образ раздела, который можно напрямую использовать для монтирования. Используйте следующую команду для просмотра содержимого системы.

Разархивируйте system.img в формате yaffs2

скачать исходный код unyaffs, затем выполните следующую команду, чтобы скомпилировать исполняемый файл unyaffs

Источник