Записки сумасшедшего...

Перейти к содержимому

Записки сумасшедшего...

Страница 1 из 1
  • Вы не можете создать новую тему (зарегистрируйтесь)
  • Вы не можете ответить в тему (зарегистрируйтесь)

Xakep-a

#1
Пользователь офлайн   Xakep 

  • просто Xakep
  • Автор прошивок /ромодел/
  • Перейти к галерее
  • Вставить этот ник в форму быстрого ответа
  • Дополнительная информация
И еще раз всем здрасте!..
Вот решил организовать отдельную тему. И повод как мне кажется есть.
Суть в том что как многим нам стало известно, наш широко любимый WM лишился поддержки своим разработчиком. Новые билды уже не появляются, что то новое придумать в организаций прошивки или ее построений, нам элементарно лень или не хватает знаний.
И вот мы сидим и потихоньку заплываем жиром, и если прямо признаться теряем свой былые познания.

Я знаю что среди нас WM ромоделов, есть лютые ненавистники Android. И что бы сильно не разглагольствовать. Я отвечу просто.
Настоящему ромоделу насрать что потрошить WM или программируемый будильник, или Androida...


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

В ближайшее время я подготовлю и выложу статьи…
«Разборка и сборка НЕХ прошивок на примере Liquid Mini»
«Разборка и сборка boot.img на примере Liquid Mini»
«Разборка и сборка system.img на примере Liquid Mini»
«Разборка и сборка flex.img на примере Liquid Mini»
«Разборка и сборка recovery.img на примере Liquid Mini»

А для начала выложу две очень познавательные статейки по потрошению Android прошивок.
Разработка и модификация прошивки для Android телефонов на примере HTC Hero GSM. Часть 1

Причины по которым люди ставят модифицированные версии прошивок различны. Кому-то хочется удивить друга смешной анимацией загрузки, кому-то не хватает определенного функционала (например vpn), кто-то хочет выжать максимум производительности из своего телефона за счет разгона процессора, а кто-то пять месяцев ждет новую версию операционной системы Android для своего любимого HTC Hero.

На данный момент уже существует превеликое множество самых невообразимых сборок для самых различных телефонов на базе Android. Иногда они даже появляются в той или иной форме на Хабре.

Я же хочу Вам рассказать о процессе и особенностях создания кастомной прошивки на основе официальной. Данные знания были получены в процессе разработки одной из не многих отечественных прошивок на базе Android 2.1 для HTC Hero GSM. И более или менее успешно опробованы на себе и других подвернувшихся пользователях одного крупного российского форума.

Не смотря на то, что все нижеследующее было сделано для HTC Hero, данные правила и особенности имеют полную силу для всех телефонов, особенно тех, которые разработаны компанией HTC и используют фирменную оболочку Sense.

Для экспериментов нам понадобится:

  • Android SDK желательно последней версии
  • Утилита apktool для реинжениринга системных приложений
  • Утилиты smali/baksmali для де-оптимизации системных приложений
  • Утилита unyaffs для извлечения системных файлов из образа
  • Скрипт split_bootimg.pl для извлечения ядра и ramdisk-а
  • Утилита testsign для подписывания пакета обновления и отдельных приложений
  • установленное и настроенное JRE
  • телефон с операционной системой Android
  • права суперпользователя и модифицированная подпрограмма восстановления (recovery rom)


Все вышеперечисленное доступно в версиях как для системы Linux так и для Windows. Но в своих примерах я буду ориентироваться на использование Linux.

Конечно же ни root-права ни recovery нам не нужен для того, чтобы начать разработку, однако если мы захотим опробовать наше творение, они нам понадобятся. Для HTC Hero можно использовать RA-hero-v1.6.2.

Наверное, самое время напомнить, что использование неофициальных прошивок лишает нас гарантии, но где наша не пропадала. И несмотря на то, что большинство операций безопасно — всегда нужно четко понимать что и зачем делается, дабы не причинить необратимый вред своему андроиду[/url]



Основа



Существует несколько различных подходов к разработке прошивки.



Несмотря на то, что платформа Android вроде как и является открытой, но в реальных телефонах используются закрытые компоненты. Это и драйверы распространяющиеся в бинарном виде (wifi/gps/fm), и ключевые компоненты системы, такие как Маркет и другие сервисы Google. Также сюда нужно добавить разработки компаний в области интерфейса, такие как HTC Sense, Motoblur, TouchWiz от Sumsung. Это создает местами непреодолимые трудности по разработке прошивки из исходных кодов.

Я предлагаю остановиться на модификации готовых прошивок, предоставляемых вендорами телефонов.

Прошивки для телефонов HTC существуют в двух видах:

  • RUU. Rom Update Utility (Утилита обновления прошивки). Утилита для ОС Windows производящая обновление телефона
  • OTA. Over the Air (Обновление по «воздуху»). Пакет, скачиваемый самим телефоном через wifi/gprs сети, который устанавливается на телефон без какого-либо участия компьютера


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

Будем использовать RUU обновление.



Извлечение rom.zip



1. Скачиваем подходящую версию RUU для интересующего нас телефона. Найти которую можно либо на сайте HTC, либо в других источниках. Для HTC Hero воспользуемся, вышедшей в начале июня версией Android 2.1 для оператора Chunghwa (Тайвань)

2. RUU утилита при обновлении телефона прошивает сразу несколько областей:

  • загрузчик boot (hboot)
  • ядро linux + ramdisk (boot)
  • прошивка для радио-модуля (radio)
  • подпрограмма восстановления (recovery)
  • системный раздел (/system)
  • пользовательский раздел (/data)


Однако мы не можем позволить RUU-утилите перезаписать наш любовно установленный загрузчик и recovery. Дабы иметь и далее возможность устанавливать не только официальные прошивки. Для этого нам необходимо извлечь радио/boot/system/data.

В сущности RUU является InstallShield-овским инсталлятором, который несет в себе необходимые нам образы в rom.zip.

Запускаем его и попадаем в заглавный приветственный экран. Не заходя дальше, открываем системную папку %TEMP%, в которой мы видим 2 новые папки, в одной из которых мы найдем файл rom.zip. Копируем в уединенное место и закрываем RUU отменой установки.

Изображение



Распаковка образов



Распаковав полученный архив и удалив не интересные для нас образы, мы увидим:
  • $ ls -1 rom
  • boot.img
  • Radio_Signed_HERO_63.18.55.06O_6.35.15.01.img
  • system.img
  • userdata.img

Телефон несет в себе 512Мб NAND Flash, которые разбиты на следующие логические блоки
  • $ adb shell cat /proc/mtd
  • dev: size erasesize name
  • mtd0: 00040000 00020000 "misc"
  • mtd1: 00500000 00020000 "recovery"
  • mtd2: 00280000 00020000 "boot"
  • mtd3: 0aa00000 00020000 "system"
  • mtd4: 08200000 00020000 "cache"
  • mtd5: 0a5c0000 00020000 "userdata"

Как мы видим, данные области памяти непосредственно связаны с полученными нами образами. RUU производит запись образов as-is, но мы хотим ведь изменить наполнение системы, поэтому нам необходимо распаковать их.

В качестве файловой системы для NAND в android используется yaffs2
  • $ adb shell mount | grep yaffs
  • /dev/block/mtdblock3 on /system type yaffs2 (ro)
  • /dev/block/mtdblock5 on /data type yaffs2 (rw,nosuid,nodev)
  • /dev/block/mtdblock4 on /cache type yaffs2 (rw,nosuid,nodev)

Распакуем system и data (/cache остается пустым)
  • $ mkdir system && cd system && unyaffs ../../../rom/system.img
  • $ mkdir ../data && cd ../data && unyaffs ../../../rom/userdata.img

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

Изображение



Стоит учитывать, что в распакованном архиве содержатся символические ссылки, которые будут утеряны на файловых системах не поддерживающих оные (fat/ntfs). Которые мы можем восстановить через скрипт обновления, о чем будет рассказано в другой статье.



Ядро



Также нам понадобиться boot-раздел, который по сути является linux ядром (для выбранной прошивки это 2.6.29 armv6l) с ramdisk-ом и имеет следующий формат:


** +-----------------+
** | boot header | 1 page
** +-----------------+
** | kernel | n pages
** +-----------------+
** | ramdisk | m pages
** +-----------------+
** | second stage | o pages
** +-----------------+
**
** n=(kernel_size + page_size - 1) / page_size
** m=(ramdisk_size + page_size - 1) / page_size
** o=(second_size + page_size - 1) / page_size


Если мы захотим заменить ядро, либо модифицировать скрипты инициализации, нам необходимо их извлечь из boot-образа. Для этого нам понадобиться замечательный perl-скрипт split_bootimg.pl за авторством William Enck.
  • $ split_bootimg.pl ../rom/boot.img
  • $ ls
  • boot.img-kernel boot.img-ramdisk.gz data system



С самим ядром мы ничего не можем сделать, кроме как заменить его другим, а рамдиск можно распаковать для последующего изменения и настройки:
  • $ mkdir ramdisk && cd ramdisk && gzip -dc ../boot.img-ramdisk.gz | cpio -i
  • $ ls
  • data default.prop dev init init.goldfish.rc init.hero.rc init.rc logo.rle proc sbin sys system

В данной статье мы не хотим ничего делать ни с ядром ни с ramdisk-ом, а потому запакуем все обратно (либо вернемся на шаг назад и вообще не будем трогать boot)
  • find . | cpio --quiet -o -H newc | gzip > ../new-ramdisk.gz
  • $ cd .. && mkbootimg --kernel boot.img-kernel --ramdisk new-ramdisk.gz --cmdline "no_console_suspend=1 console=null" -o newboot --base 0x19200000

Для других телефонов настроки базового смещения могут отличаться. Коммандлайн мы получаем из split_bootimg при распаковке.



Скрипт обновления



Для обновления будем использовать update-скрипт, который пишется на специальном скриптовом языке edify, о синтаксисе которого можно прочитать в исходниках android. Скрипт /META-INF/com/google/android/update-script может быть таким:
  • show_progress 0.1 0
  • format CACHE:
  • format SYSTEM:
  • copy_dir PACKAGE:system SYSTEM:

  • set_perm_recursive 0 0 0755 0644 SYSTEM:
  • set_perm_recursive 0 2000 0755 0755 SYSTEM:bin
  • set_perm 0 3003 02755 SYSTEM:bin/netcfg
  • set_perm 0 3004 02755 SYSTEM:bin/ping
  • set_perm_recursive 1002 1002 0755 0440 SYSTEM:etc/bluez
  • set_perm 0 0 0755 SYSTEM:etc/bluez
  • set_perm 1002 1002 0440 SYSTEM:etc/dbus.conf
  • set_perm 1014 2000 0550 SYSTEM:etc/dhcpcd/dhcpcd-run-hooks
  • set_perm 0 2000 0550 SYSTEM:etc/init.goldfish.sh
  • set_perm_recursive 0 0 0755 0555 SYSTEM:etc/ppp
  • set_perm 0 0 04755 SYSTEM:etc/ppp/ip-up-vpn
  • show_progress 0.1 10

  • show_progress 0.2 0
  • copy_dir PACKAGE:data DATA:
  • show_progress 0.2 10

  • show_progress 0.3 0
  • format BOOT:
  • write_raw_image PACKAGE:boot.img BOOT:
  • show_progress 0.3 10

Пока этот скрипт очень примитивен и единственное что он делает — подготавливает соответствующие разделы.



Подпись пакета обновления



Для того, чтобы мы смогли прошить нашу прошивку, нам необходимо подписать пакет обновления. Этот процесс аналогичен процессу подписывания jar-пакетов. К пакету добавляется ваш (либо тестовый) сертификат и сохраняются контрольные суммы для файлов внутри него.
  • $ zip -r habrarom.zip .
  • $ java -classpath ../../bin/testsign.jar testsign habrarom.zip habrarom-signed.zip



Прошивка радио модуля



Это самая простая часть в плане создания пакета обновления, но и самая опасная в плане последствий при неудачном обновлении.

Пакет обновления создается абсолютно идентично предыдущему, только содержать он будет бинарный блоб с радио, который мы извлекли из RUU и скрипт для его записи в соответствующий раздел памяти.

Простенький скрипт:
  • show_progress 0.1 0
  • write_radio_image PACKAGE:Radio_Signed_HERO_63.18.55.06O_6.35.15.01.img
  • show_progress 0.1 10

Не многое, что будет включено в данный пакет обновления.
  • $ ls -1
  • META-INF
  • Radio_Signed_HERO_63.18.55.06O_6.35.15.01.img



Всё это упаковывается и подписывается как делалось ранее.



Прошивка



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

Для этого
  • Копируем в корень карты наш пакет обновления
  • Загружаемся в recovery
  • Делаем nanroid backup
  • Делаем wipe
  • Прошиваем
  • Перегружаемся


Радуемся тому, что наш больной пережил сложную операцию.

Изображение


Разработка и модификация прошивки для Android телефонов. Часть 2

В первой части мы научились перепаковывать официальную прошивку из формата RUU в формат пакета обновлений, что дало нам возможность использовать созданную нами прошивку, не опасаясь затирания модифицированного раздела восстановления (recovery rom). И тем временем, пока HTC воюет с хорошими ресурсами, мы продолжим изучать и улучшать прошивку.

В предыдущей части, хоть мы и создали прошивку, которая загружается и работает как часы, мы бы хотели расширить базовый функционал оной. Одним из самых востребованных расширений является поддержка работы с правами суперпользователя (root). Также сюда можно отнести интегрирование busybox. Кроме того, мы научимся запускать произвольные скрипты при старте системы и адаптируем ramdisk под свои нужды.



Busybox



busybox — это набор консольных unix утилит, ориентированный на малый размер и производительность, что так актуально для мобильных систем. Вместе с системой android поставляется свой набор утилит — toolbox, который предоставляет минимально необходимых функционал для системы, и как следствие более простой в количественном и функциональном плане. Наличие busybox в системе, с одной стороны, позволит нам, как разработчикам, чувствовать себя более комфортно при удаленной работе на устройстве, с другой, позволит писать сложные скрипты, и, например, реализовать механизм запуска собственных скриптов при загрузке, используя run-parts. Также стоит учитывать, что для некоторых android приложений (особенно те, которые используют root) наличие busybox — обязательно.[/url]



Дабы упростить себе жизнь, воспользуемся уже собранным busybox под нашу платформу. Например, 1.16.0 от небезызвестного modaco можно забрать тут. Кто смел духом, и обладает лишним временем, может собрать busybox из оффициального дерева (немного напильника по адаптации к андроидовскому toolchain-у, и bionic — андроидовской реализации libc), либо воспользоваться инструкцией XVilka по сборке с crosstool-ng и uCLibc, либо собрать из ветки cyanogenmod, где уже решены проблемы с bionic.

Итак, прежде чем мы добавим busybox, в систему нам нужно решить несколько идеологических моментов:

  • При общей схеме использования busybox/toolbox мы должны положить исполняемый файл и создать ссылки на него с именами апплетов. Ссылки должны быть доступны по пути из переменной $PATH. Где хранить ссылки для busybox? В /system/bin? /system/xbin? отдельная директория?
  • Использовать заранее созданные ссылки, или генерировать на этапе установки прошивки?

    В примере из первой части мы использовали заранее созданные ссылки для toolbox. Но данный вариант затруднителен, если разработка прошивки ведется на системе Windows, где есть определенные проблемы с символическими ссылками.
  • В зависимости от сборки busybox мы можем перекрыть набор команд, который уже доступен в toolbox. Кто главнее?

    С одной стороны, busybox предоставляет более широкий функционал (как пример: буквенное задание прав для chmod), но с другой стороны — мы можем захотеть исключить уже реализованные утилиты из busybox для уменьшения размера набора.


Чтобы узнать, какие апплеты поддерживает busybox, достаточно запустить его на устройстве без параметров:


  • $ adb remount && adb push busybox /cache/
  • $ adb shell chmod 0755 /cache/busybox
  • $ adb shell /cache/busybox | tail
  • tcpsvd, tee, telnet, telnetd, test, tftp, tftpd, time, timeout, top,
  • touch, tr, traceroute, true, tty, ttysize, tunctl, udpsvd, umount,
  • uname, uncompress, unexpand, uniq, unix2dos, unlzma, unlzop, unzip,
  • uptime, usleep, uudecode, uuencode, vconfig, vi, vlock, volname, watch,
  • watchdog, wc, wget, which, who, whoami, xargs, yes, zcat, zcip



Для получения списка доступных апплетов для toolbox будем ориентироваться на те ссылки, которые были созданы в изначальной прошивке.


  • $ find habrrom/system/bin/ -type l -printf '%f, ' | tail
  • getprop, insmod, ifconfig, setprop, wipe, watchprops, log, sync, schedtop, ioctl, rm,
  • sleep, notify, sendevent, dmesg, df, route, vmstat, mv, iftop, rmmod,
  • dd, renice, kill, mount, start, rmdir, ps, ln, cmp, dumpcrash, top, getevent,
  • umount, mkdir, setconsole, printenv, newfs_msdos, chown, cat, hd, chmod, date,
  • stop, smd, netstat, ls, lsmod, id,



Единственным линком, указывающим не на toolbox является dumpcrash:


  • $ ls -o habrrom/system/bin/ | grep dumpstate
  • lrwxrwxrwx 1 astar 9 2010-06-16 03:59 dumpcrash -> dumpstate
  • -rwxr-xr-x 1 astar 14296 2010-06-16 03:55 dumpstate



Это также стоит учесть при формировании скрипта обновления.

Предположим, что мы решили, что главным у нас будет busybox. У меня получилось, что следующие апплеты toolbox уникальны:
  • getevent, getprop, iftop, ioctl, log, newfs_msdos, notify, schedtop,
  • sendevent, setprop, smd, start, stop, top, umount, vmstat, watchprops, wipe

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


  • symlink dumpstate SYSTEM:bin/dumpcrash
  • #
  • symlink toolbox SYSTEM:bin/getprop
  • # повторяем процедуру для необходимых апплетов toolbox
  • symlink busybox SYSTEM:xbin/[
  • # повторяем процедуру для всех апплетов busybox



Не забудем удалить ссылки из самой прошивки.
  • $ rm `find habrrom/system/bin/ -type l`

Плюс, нам понадобиться, выставить правильные права на busybox
  • set_perm 0 0 04755 SYSTEM:xbin/busybox

Попробуем усложнить себе задачу. Давайте поместим ссылки для busybox в отдельную директорию, например /system/xbin/bb. Для этого нам понадобится в структуре прошивки добавить непустую папку (пустую папку, откажется копировать скрипт обновления):


  • $ mkdir habrrom/system/xbin/bb
  • $ touch habrrom/system/xbin/bb/placeholder



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


  • symlink ../busybox SYSTEM:xbin/bb/[
  • # и так далее





Модификация ramdisk



Однако, просто поместить ссылки в отдельную папку — мало. Нужно расширить путь поиска исполняемых файлов для системы. Для этого нам понадобиться дополнить переменную $PATH, которая в случае с андроидом на HTC Hero определяется в /init.rc


  • $ adb shell cat /init.rc | grep "export PATH"
  • export PATH /sbin:/system/sbin:/system/bin:/system/xbin



Все файлы корневой директории являются частью ramdisk-а (как и некоторые другие вложенные директории). Воспользуемся знаниями из первой части: распакуем boot, после чего мы можем изменить переменную PATH


  • $ cat habrrom.boot/ramdisk/init.rc | grep "export PATH"
  • export PATH /sbin:/system/sbin:/system/bin:/system/xbin:/system/xbin/bb



Прежде чем мы соберем ramdisk обратно, сделаем еще несколько полезных дел.

Для упрощения жизни нам бы хотелось иметь следующее:

  • Возможность монтирования файловой системы с правами на запись
  • Отладка по usb, включенная по-умолчанию. Иначе, если что-то пойдет не так, мы не сможем получить хоть какую-то полезную информацию о причинах, так как сервис adbd будет отключен и как следствие — adb logcat во время загрузки будет недоступен
  • Запуск произвольных скриптов при загрузке системы (самыми популярными вариантами использования являются: включение app2sd, перенос dalvik-cache в /cache)


Для этого обратим свой взор на /default.prop, в котором среди прочего хранятся следующие настройки:

  • ro.secure — используется то тут то там по всей системе, но из интересующих нас свойств, включает adb remount на запись а, также, adb shell выполняется с правами суперпользователя. Выставим значение в 0
  • persist.service.adb.enable — отвечает за старт сервиса adbd, который нам помогает совершать удаленное взаимодействие с телефоном по средством adb. Выставляем в 1




Скрипты инициализации



Для осуществления третьего пункта, нам понадобиться модифицировать скрипт инициализации /init.rc. Данный скрипт как водится, представляет собой собственный велосипед андроид скрипт на Android Init Language. Ознакомиться с форматом предлагаю в исходниках android. Нам же интересна возможность добавить собственный сервис (мы не можем добавить свои команды прямо в триггер, потому как там набор команд строго ограничен):
  • service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
  • disabled
  • oneshot

Т.е. мы назвали наш сервис sysinit, который при своем старте выполнит run-parts /system/etc/init.d, что в свою очередь запустит все скрипты из соответствующей папки в порядке отсортированном по алфавиту. logwrapper нам необходим, дабы перенаправить вывод вместо /dev/null (по-умолчанию) в систему логирования (доступную по logcat).

Осталось запустить наш сервис (опция disabled, говорит, что данный сервис не будет стартовать автоматически). Для этого последнюю команду из тригера on boot переместим в наш собственный триггер окончания выполнения скриптов и вызовем наш сервис.


  • # не сейчас
  • # class_start default
  • start sysinit

  • on property:habr.sysinit.done=1
  • # вот сейчас
  • class_start default



Также создадим два простых скрипта в /system/etc/init.d для демонстрации того, что все это работает. Первый будет делать стандартное echo (Hello World!, как же без него), а второй очищать кеш, и сообщать init скрипту, что мы уже закончили и можно дальше продолжать загружаться.


  • $ cat habrrom/system/etc/init.d/00banner
  • #!/system/bin/sh
  • echo "Hello habrahabr!";
  • $ cat habrrom/system/etc/init.d/99complete
  • #!/system/bin/sh
  • sync;
  • setprop habr.sysinit.done 1



И последний штрих — установим им права на запуск (все там же — в скрипте обновления прошивки)
  • set_perm_recursive 0 2000 0755 0755 SYSTEM:etc/init.d



Права суперпользователя. Root.



Для многих, наверное, самый актуальный вопрос. Для тех терпеливых, кто дочитал.

Не смотря на то, что в исходниках есть своя реализация su, она нам не подходит, потому как основной ее целью является запуск приложений суперпользователем (или из adb shell) с правами других user-ов.

Мы же воспользуемся разработкой ChainsDD — приложением Superuser 2.1. Суть приложения аналогична знакомым нам sudo, или даже Admin Approval Mode из системы Windows. Если приложение хочет повысить свои права до прав суперпользователя (и не только), у пользователя запрашивается разрешение. Также можно запомнить принятое правило и автоматически применять для всех будущих вызовов.

Воспользуемся уже собранным приложением для Android 2.1, хотя всегда есть возможность изучить и собрать [url=http://github.com/ChainsDD/android_packages_apps_Superuser]самому из исходников.

Приложение состоит из двух компонент:

  • native модуль su. Который при запросе на изменение прав перенаправляет запрос в собственный Activity и ждет реакции пользователя
  • приложение Superuser.apk — набор интерфейсов (Activity), отвечающих за взаимодействие с пользователем, хранение настроек.


Изображение Изображение



Для того, чтобы добавить в нашу прошивку указанный функционал — добавим модули в соответствующие разделы системы,


  • $ cp su habrrom/system/xbin/
  • $ cp Superuser.apk habrrom/system/app/



и настроим права для исполняемого файла (плюс линк в /system/bin/, так как некоторые приложения могут вызывать su по абсолютному пути)
  • symlink ../xbin/su SYSTEM:bin/su
  • set_perm 0 0 06755 SYSTEM:xbin/su



На этом все.



Любой желающий может выкладывать в этой теме полезные ссылки.
Или copy-paste интересных и полезных статей по потрошению Android.


В этой теме категорически запрещается задавать какие либо вопросы!!!
В случае нарушения. Пост с вопросом будет удален, а автору поста будет выдан РО на неделю.

"О, сколько нам открытий чудных готовит Microsoft’а дух, и Intel - сын ошибок трудных, и Borland - Paradox’ов друг..."
Моя лычка только для общения с девушками о любви! Остальные все вопросы, через форум!
Изображение
Зарегистрируйтесь и объявления пропадут! :)
15


Страница 1 из 1
  • Вы не можете создать новую тему (зарегистрируйтесь)
  • Вы не можете ответить в тему (зарегистрируйтесь)

Ответы в этой теме

#2
Пользователь офлайн   Xakep 

  • просто Xakep
  • Автор прошивок /ромодел/
  • Перейти к галерее
  • Вставить этот ник в форму быстрого ответа
  • Дополнительная информация
Сегодня я вам расскажу о разборке и сборке прошивок НЕХ формата, на примере Liquid Mini.
Этот формат широко используется Acer, для Android и WM прошивок.
Для общего ознакомления с чем мы вообще имеем дело. Настоятельно рекомендую почитать [Intel HEX — Википедия]

Для начала скачаем маленькую программку Прикрепленный файл  Hex_romtool.exe (60К)
Количество загрузок:: 294
Изначально это программка писалась для работы с прошивками Motorola, но как показывает практика с небольшими танцами с бубном она работает и с нашими прошивками.

И так:
Запускаем ЕХЕ-шник с прошивкой, дожидаемся появления первого окна приветствия, и идем искать куда распаковался установочный пакет.
У себя я все это добро нашел в c:\Users\Xakep\AppData\Roaming\ACER_EUU_Download_Tools\
Можно просто скопировать из этой папки все файлы с расширением *.hex, но я предпочел скопировать всю папку ACER_EUU_Download_Tools , в последствий ее можно будет использовать для сборки модифицированной прошивки.

Скопировав все файлы с расширением *.hex в отдельную папку и закинув туда же Hex_romtool.exe .
У меня это выглядит так:

Прикрепленное изображение: monthly_06_2011/post-10051-0-56755700-1309338302.jpg

Приступаем к разбору НЕХ файлов.
Для начала давайте определимся что будем разбирать. Как видим из скриншота, в моем случае это скорее всего файл Kseries_user.Android.1.001.23.hex , т.к. он имеет самый большой размер, и соответственно скорее всего и содержит раздел system.img

В командной строке запускаем Hex_romtool.exe Kseries_user.Android.1.001.23.hex
И… Получаем один файл Kseries_user.Android.1.001.23.hex.pre.bin размером в 11байт…

Ладно. Не расстраиваемся. А открываем файл Kseries_user.Android.1.001.23.hex с помощью любого текстового редактора (если вы читали Вики то уже знаете что НЕХ формат это чисто текстовый формат) я рекомендую Notepad2 или что нибудь подобное, т.к. не любой текстовый редактор позволит открыть документ размером в ~260Мбайт…

Открыв файл в самом начале видим примерно следующую картину …

Прикрепленное изображение: monthly_06_2011/post-10051-0-26278000-1309338337.jpg

Как видим самая первая строка не совсем корректная (снова читаем Вики и находим ошибку, своего рода домашнее задание ;) )
Можно просто удалить эту строку, сохранить файл и продолжить экспериментировать.
Но забегая чуть вперед, мы проделаем некоторые операций.
Для начала скажу что вторая строка (т.е. :020000040000FA ) содержит так называемый признак разделения разделов.
Выделяем в редакторе часть теста от начала файла до второго признака разделения разделов.

Прикрепленное изображение: monthly_06_2011/post-10051-0-08068100-1309338364.jpg

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

Снова в командной строке запускаем команду Hex_romtool.exe Kseries_user.Android.1.001.23.hex
После чего у меня появились новые файлы. Что уже соответствует действительности.

Прикрепленное изображение: monthly_06_2011/post-10051-0-79358500-1309338371.jpg

В общем это и есть наша прошивка, IMG и другие файлы что в нее входят.
В моем случае, Kseries_user.Android.1.001.23.hex.part5.bin = system.img , т.к. это самый большой раздел в прошивке.
Kseries_user.Android.1.001.23.hex.part4.bin = boot.img , т.к. заглянув в файл можно увидать в самом начале слово «ANDROID!», это универсальный признак у всех Android зверьков.
Kseries_user.Android.1.001.23.hex.part7.bin = recovery.img т.к. он так же начинается с «ANDROID!», но чуть больше boot.img, а как нам известно recovery.img это фактически копия boot.img которая содержит в себе дополнительную программку recovery …
В моем случае в этом списке не оказалось flex.img. Но как позже выяснилось этот раздел лежит в отдельном НЕХ файле Acer_E310_1.001.23_EMEA_CUS6.hex ...

Как разбирать полученные файлы я расскажу в следующий раз. А сейчас расскажу как правильно собрать все это назад. В НЕХ файл.

Для начала нужно запомнить что нельзя удалять не одного файла BIN иначе мы не соберем полноценный НЕХ файл, как он был изначально. Т.е. отредактируйте необходимые BIN и положите их назад с теми же именами, после этого можно приступить к сборке.
А вообще, рекомендую первый раз разобрать и собрать НЕХ файл без каких либо изменений BIN файлов. Что бы можно было сравнить изначальный и полученный результаты.

И так. Снова в командной строке вводим команду Hex_romtool.exe /b Kseries_user.Android.1.001.23.hex
На выходе получаем файл Out.hex .

Прикрепленное изображение: monthly_06_2011/post-10051-0-46448800-1309338379.jpg

Как видим он получился несколько больше оригинального файла Kseries_user.Android.1.001.23.hex
Сравниваем по содержимому оригинальный и новый файлы…

Прикрепленное изображение: monthly_06_2011/post-10051-0-73262900-1309338402.jpg

Как видим у нас отличаются только контрольные суммы строк первого раздела (это последствие патча, вносимого программой для Motorola).
Помните в начале разборки НЕХ файла мы сохранили как раз эту часть в другой файл? ;)
Вот сейчас и вставляем этот кусок обратно. Для чистоты эксперимента и в оригинальный файл верните «кривую» первую строчку.
И снова сравниваем…

Прикрепленное изображение: monthly_06_2011/post-10051-0-07472000-1309338427.jpg

Как видим наши файлы полностью одинаковы.
Но!!! Почему у них разный размер???
А ответ оказался до банальности прост. :D
Оригинальный файл сохранен в кодировке ANSI UNIX с переводом строки по знаку LF.
А новый файл сохранился в кодировке ANSI WINDOWS с переводом строки по знаку CR+LF…
Просто в редакторе перегоняем из одного формата в другой,

Прикрепленное изображение: monthly_06_2011/post-10051-0-40911500-1309338437.jpg

Сохраняем и любуемся…

Прикрепленное изображение: monthly_06_2011/post-10051-0-13864900-1309338447.jpg

Вот на сегодня и все. Удачи вам в потрошений прошивок!
"О, сколько нам открытий чудных готовит Microsoft’а дух, и Intel - сын ошибок трудных, и Borland - Paradox’ов друг..."
Моя лычка только для общения с девушками о любви! Остальные все вопросы, через форум!
Изображение
10

#3
Пользователь офлайн   Xakep 

  • просто Xakep
  • Автор прошивок /ромодел/
  • Перейти к галерее
  • Вставить этот ник в форму быстрого ответа
  • Дополнительная информация
Продолжаем серию статьей о потрошений Миника. Сегодня поговорим о разборке и сборке boot.img, а так же все ниже сказанное относится и к разборке и сборке recovery.img.
Так как эти два раздела фактически дублируют себя и отличаются совсем не значительно.

В общем то рассказывать о разборке и сборке я особо не буду. Так как инструкций по этому поводу в сети валяется уйма, особенно в разделах посвященных замене бутанимаций на Android.
А вот кстати одна из них, цитата из первого поста этой темы

Цитата

Ядро

Также нам понадобиться boot-раздел, который по сути является linux ядром (для выбранной прошивки это 2.6.29 armv6l) с ramdisk-ом и имеет следующий формат:


** +-----------------+
** | boot header | 1 page
** +-----------------+
** | kernel | n pages
** +-----------------+
** | ramdisk | m pages
** +-----------------+
** | second stage | o pages
** +-----------------+
**
** n=(kernel_size + page_size - 1) / page_size
** m=(ramdisk_size + page_size - 1) / page_size
** o=(second_size + page_size - 1) / page_size


Если мы захотим заменить ядро, либо модифицировать скрипты инициализации, нам необходимо их извлечь из boot-образа. Для этого нам понадобиться замечательный perl-скрипт split_bootimg.pl за авторством William Enck.
  • $ split_bootimg.pl ../rom/boot.img
  • $ ls
  • boot.img-kernel boot.img-ramdisk.gz data system



С самим ядром мы ничего не можем сделать, кроме как заменить его другим, а рамдиск можно распаковать для последующего изменения и настройки:
  • $ mkdir ramdisk && cd ramdisk && gzip -dc ../boot.img-ramdisk.gz | cpio -i
  • $ ls
  • data default.prop dev init init.goldfish.rc init.hero.rc init.rc logo.rle proc sbin sys system

В данной статье мы не хотим ничего делать ни с ядром ни с ramdisk-ом, а потому запакуем все обратно (либо вернемся на шаг назад и вообще не будем трогать boot)
  • find . | cpio --quiet -o -H newc | gzip > ../new-ramdisk.gz
  • $ cd .. && mkbootimg --kernel boot.img-kernel --ramdisk new-ramdisk.gz --cmdline "no_console_suspend=1 console=null" -o newboot --base 0x19200000

Для других телефонов настроки базового смещения могут отличаться. Коммандлайн мы получаем из split_bootimg при распаковке.

Собственно весь процесс разборки и сборки в этой цитате описан достаточно подробно.
Замечу только что разборку и сборку boot.img и recovery.img, можно производить только из под Linux, пусть даже установленном в VirtualBox...

Я остановлюсь на некоторых специфических моментах с которыми мне пришлось столкнутся.

И так…
Вовремя разборки boot миника, выяснилось что у него не два как обычно раздела, а три.
И предлагаемые в многих инструкциях скрипты просто не справлялись с разборкой моего boot. Зато упомянутый в первом посту этой темы скрипт split_bootimg.pl прекрасно справился с этой задачей. После его работы у меня появились новые файлы и папка (помечены красным).

Прикрепленное изображение: monthly_07_2011/post-10051-0-72607500-1309596559.jpg

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

Опцию добавления третьего раздела, мне подсказал сам mkbootimg (если его просто запустить без пораметров) это оказалась опция –second.
А вот за –cmdline и –base, пришлось идти в НЕХ редактор и просматривать оригинальный boot.
Cmdline находится довольно просто, эта строка хранится в открытом виде в начале boot.img. Вот как это выглядит у меня.

Прикрепленное изображение: monthly_07_2011/post-10051-0-28839000-1309596562.jpg

А вот что бы выяснить –base, пришлось даже посмотреть исходники mkbootimg и выяснить принцип его работы. :D
В общем если не задовать опцию –base, то он сам ее выставит по умолчанию как 0х1000000 …
А посмотреть какой у вас –base, так же можно в оригинальном boot.img.
Вот мой пример.

Прикрепленное изображение: monthly_07_2011/post-10051-0-05898900-1309596563.jpg

Вспоминаем что адреса в машином коде хранятся в обратном порядке и переводим это значение в понятный нам вид, после чего у нас получится 02 Е0 80 00 .
Но так же не забываем что это не просто адрес, а базовое смещение, которое добавляется к заранее данному адресу. В моем случае это 80 00, т.е. просто откидываем это значение и в итоге у меня получилось 02 Е0 00 00 , или 0х2Е00000

Если вы в НЕХ редакторе увидите за место цифр которые у меня, значение ** ** 00 01 , то можете просто даже не выяснять свой –base, и даже не вставлять эту опцию в команду сборки boot.img.
В противном случае преобразуйте значение и добавьте его в –base.

После того как выяснили все значения и опций составляем команду сборку.
У меня получилась следующая конструкция.

./mkbootimg --cmdline 'console=ttyMSM2,115200n8 androidboot.hardware=qcom' --kernel boot.img-kernel --ramdisk ramdisk-repack.cpio.gz --second boot.img-second.gz --base 0x2e00000 --output newboot.img

После отработки этой команды я получил свежее изготовленный и перебранный newboot.img

Ну вот собственно на сегодня и все. Удачи вам в потрашений ваших зверьков. ;)

ps Прикладываю свой комплек утилит для разборки boot.img и recovery.img . Но мой скрипты изрядно подправлены под мой нужды, т.ч. вам придется их переправлять под себя.
Прикрепленный файл  Tools_for_boot.rar (30,61К)
Количество загрузок:: 343
"О, сколько нам открытий чудных готовит Microsoft’а дух, и Intel - сын ошибок трудных, и Borland - Paradox’ов друг..."
Моя лычка только для общения с девушками о любви! Остальные все вопросы, через форум!
Изображение
8

#4
Пользователь офлайн   Xakep 

  • просто Xakep
  • Автор прошивок /ромодел/
  • Перейти к галерее
  • Вставить этот ник в форму быстрого ответа
  • Дополнительная информация
А сегодня мы поговорим о так называемой защите от изменения system.img применяемой ACER на многих своих аппаратах.

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

И так. Суть в том что когда мы разбираем system.img, нескольким извлеченным файлам применяются неверные права доступа. Как удалось добиться этого Acer я пока не разобрался, но, факт остается фактом.
И когда мы собираем снова system.img, эти неверные права прописываются в новый system.img.
Когда мы пытаемся запустить систему с новым system.img, система просто не может загрузить те файлы с неверными правами, и вылетает с ошибкой.
В следствий чего мы и наблюдаем вечные ребуты.

А решение очень простое. Когда мы только разобрали system.img, идем в полученную папку etc и всем файлам из этой паки назначаем права доступа 755 или по другому RWXR XR X . Обязательно проверяем что права назначелись всем файлам в этой папке.
Все, после этого можем спокойно вносить любые изменения и собирать новый system.img.

Ну вот собственно на сегодня и все. Удачи вам в потрашений ваших зверьков. ;)
Dragoon (01 Март 2012 - 21:10):
Для тех случае когда права 755 не помогают, рекомендую 777. Тут уж 100%я гарантия

"О, сколько нам открытий чудных готовит Microsoft’а дух, и Intel - сын ошибок трудных, и Borland - Paradox’ов друг..."
Моя лычка только для общения с девушками о любви! Остальные все вопросы, через форум!
Изображение
7

#5
Пользователь офлайн   Xakep 

  • просто Xakep
  • Автор прошивок /ромодел/
  • Перейти к галерее
  • Вставить этот ник в форму быстрого ответа
  • Дополнительная информация
В общем в связи с тем что многие побаиваются связываться с геморроем разборки файлов формата НЕХ.
На досуге я собрал комплект утилит и объединил их батникоми для разборки и сборки файлов НЕХ в автоматическом режиме.
Прикрепленный файл  Kitchen.7z (1017,67К)
Количество загрузок:: 198

Немного расскажу как пользоваться всем этим.
Добываем НЕХ файлы, как это делать я не буду повторятся т.к. в этой теме уже говорилось об этом.
Нас интересуют два самых больших НЕХа.
Ложем эти НЕХы в одну папку с утилитами.
После чего у нас должно получится примерно вот так...

Прикрепленное изображение: monthly_10_2011/post-10051-0-72320700-1318252095.jpg

Чтобы распаковать один из НЕХ файлов, в командную строку вводим команду...

Прикрепленное изображение: monthly_10_2011/post-10051-0-43836000-1318252199.jpg

После отработки батника, у вас в папке появится несколько новых файлов и папка.

Прикрепленное изображение: monthly_10_2011/post-10051-0-01430800-1318252297.jpg

То что находится в паке, это разобранный имидж. Для дальнейшей работы он фактически не годится, а вот оперативно посмотреть что находится в прошивке само то.
Для дальнейшей работы нам понадобятся файлы IMG. Перекидываем их в Linux, разбираем, работаем, собираем, и перекидываем обратно с заменой в папку с утилитами.
Что бы собрать назад НЕХ с измененными IMG, просто вводим команду...

Прикрепленное изображение: monthly_10_2011/post-10051-0-54121200-1318252877.jpg

Т.е. в качестве аргумента вводим имя того НЕХ с которым и работаем.
После отработки батника, у вас в папке появится ваш новый НЕХ, и *.НЕХ.old с старым НЕХом (на всякий случай)...

Вот в общем то и все. Если что непонятно, спрашивайте в Беседке или в Асе.

Приятного ковыряния вам ваших зверьков... ;)
"О, сколько нам открытий чудных готовит Microsoft’а дух, и Intel - сын ошибок трудных, и Borland - Paradox’ов друг..."
Моя лычка только для общения с девушками о любви! Остальные все вопросы, через форум!
Изображение
7

#6
Пользователь офлайн   Xakep 

  • просто Xakep
  • Автор прошивок /ромодел/
  • Перейти к галерее
  • Вставить этот ник в форму быстрого ответа
  • Дополнительная информация
Сегодня вам расскажу как распаковать архив ZIP из FOTA обновления.
Метод опробывался на Метале, Минике, Экспрессе.
Суть в том что наш широко любимый Acer шифрует архив ZIP для FOTA по методу XOR...

И так.
  • Для начала нам понадобится програмка WinHEX. Взять ее можно прямо ЗДЕСЬ.
  • В WinHex откройте свой зашифрованный ZIP.
  • Правка >> Выбрать все
  • Правка >> Модифицировать
  • В появившемся окне выбираем метод XOR и рядом в окошке вписываем цифру 12, жмем Ок.
  • WinHex ругнется и предупредит что откат после этой операций будет невозможен. Соглашаемся.
  • Файл >> Save
  • Подтверждаем сохранение.
  • Все. Можем закрывать WinHex а архив ZIP открывать любым архиватором.

Если все прошло успешно, могу вас поздравить, вы только что взломали защищенный архив Acer, и с этого момента стали НЕ законопослушными Хакерами ...
:D
"О, сколько нам открытий чудных готовит Microsoft’а дух, и Intel - сын ошибок трудных, и Borland - Paradox’ов друг..."
Моя лычка только для общения с девушками о любви! Остальные все вопросы, через форум!
Изображение
9

#7
Пользователь офлайн   Xakep 

  • просто Xakep
  • Автор прошивок /ромодел/
  • Перейти к галерее
  • Вставить этот ник в форму быстрого ответа
  • Дополнительная информация
Сегодня поговори о созданий тем под программу MetaMorph.

Кто еще не в курсе,. Эта программа позволяет вносить изменения в системные АРК файлы прямо на зверьке. Тем самым позволяет изменять к примеру внешний вид интерфейса.
Изменения можно вносить только в системные АРК файлы, т.е. в те которые располагаются в /system/app/ .
Если вы попытаетесь внести изменения в АРК файл располагающийся в /data/app/ то после внесения изменений, АРК файл окажется нерабочим.


Принцип работы программы:
  • Программа копирует в временную папку АРК файл или файлы, в которых будет производится изменения.
  • Распаковывает его, как простой ZIP архив.
  • Заменяет в нем одноименные файлы взятые из ZIP архива с темой.
  • Упаковывает APK файл обратно, как простой ZIP архив.
  • И подменяет им АРК файл в /system/app/


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

Что бы лучше было понятно что я описываю. Давайте скачаем любой архив с темой, например ТУТ. И откроем его в любом ZIP архиваторе.
Вы увидите примерно следующую картину.

Прикрепленное изображение: monthly_03_2012/post-10051-0-62155600-1332781550.jpg

Как видим в архиве располагаются папки названия которых соответствуют названиям АРК файлов в которых будут производится изменения. Единственно, что название папок не содержат расширение ‘.apk’.
В нутрии этих папок располагаются файлы с сохранением дерева каталогов как в оригинальном АРК файле.Так же должен заметить что все файлы которыми будет производится подмена, должны быть откомпилированными. Проще всего взять эти файлы из уже готового и проверенного АРК файла, просто распаковав его как простой ZIP архив.
Ну и в корне архива с темой, помимо папок, находится один или два файла.
Один файл с расширением PNG - этот файл не обязателен и может отсутствовать.. В нем хранится скриншот темы.
И файл с расширением XML - этот файл обязателен. В нем прописано что и где менять, автор темы, название и т.п., описание структуры файла смотрите ниже.


Формат XML файла настроек

Общая структура файла выглядит следующим образом:
<?xml version="1.0" encoding="UTF-8"?>
<useless>USELESS</useless>

<themename>THEME-NAME</themename>
<themeversion>THEME-VERSION</themeversion>
<screenshot>SCREENSHOT-FILENAME</screenshot>
<author>AUTHOR-NAME</author>
<authorweblink>THEME-URL</authorweblink>
<phone>PHONE-NAME</phone>
<rom>ROM-NAME</rom>
<themedescription>THEME-DESCRIPTION</themedescription>

<item>ITEM-NAME</item>
<path>PACKAGE-FILE-SYSTEM-FOLDER</path>
<description>ITEM-DESCRIPTION</description>


Обратите внимание, что технически этот файл не является полностью XML, потому что ему не хватает ограждающих тегов элемента документа. Если вы попытаетесь отредактировать файл в XML-редакторе, который выполняет проверку синтаксиса, такие как Eclipse. Вы просто должны игнорировать ошибки при редактировании.

Описание полей и примеры:
USELESSЭтот блок текста не используется и не отображаться для пользователя. В этом разделе можно положить свои собственные заметки и т.д.
THEME-NAMEНазвание темы. Для отображения на экране.
THEME-VERSIONВерсия темы. Для отображения на экране.
SCREENSHOT-FILENAMEИмя файла скриншота, пишется без расширения PNG. Файл скриншота должен лежать в корне ZIP архива с темой. И должен быть только с расширением PNG. Например если в архив мы положили файл "myscreenshot_1.png" то в поле мы его должны записать как "myscreenshot_1".
AUTHOR-NAMEИмя автора. Для отображения на экране.
THEME-URLЛинк на страницу поддержки темы. Для отображения на экране.
PHONE-NAMEИмя и модель телефона, для которого разрабатывалась тема. Для отображения на экране.
ROM-NAMEНазвание прошивки, для которой разрабатывалась тема. Для отображения на экране.
THEME-DESCRIPTIONОписание темы. Для отображения на экране.

Следующие три поля должны присутствовать для каждого элемента:
ITEM-NAMEИмя APK файла в котором будут производится изменения.
PACKAGE-FILE-SYSTEM-FOLDERПолный путь до изменяемого APK файла. Например "/system/app/", Название пути должно заканчиваться символом "/".
ITEM-DESCRIPTIONОписание того, что изменяет этот пункт. Для отображения на экране.


Пример:
<?xml version="1.0" encoding="UTF-8"?>
<useless>Yes, this is useless.</useless>

<themename>HtcBlackStatusBarTheme</themename>
<themeversion>1.3</themeversion>
<screenshot>screenshot_2</screenshot>
<author>Ken Ellinwood</author>
<authorweblink>http://forum.xda-developers.com/showthread.php?t=779488</authorweblink>
<phone>Eris,Hero,etc. Any phone with 320x480 resolution.</phone>
<rom>Any CyanogenMod-6 variant</rom>
<themedescription>Installs the HTC black status bar, 
just like the one you had back in the days of the OTA ROM.</themedescription>

<item>Calendar.apk</item>
<path>/system/app/</path>
<description>Calendar notification icon updates</description>

<item>Mms.apk</item>
<path>/system/app/</path>
<description>SMS notification icon updates</description>

<item>framework-res.apk</item>
<path>/system/framework/</path>
<description>General status bar updates</description>


Как копировать файлы:
В приведенном ниже примере файлы копируются из папки "themelibs" находящегося в архиве темы в "/system/lib/" папку. Расширение ".cpy" на имени элемента указывает на необходимость простого копирования. Расширение ".cpy" отбрасывается чтобы определить, какие папки в ZIP содержат файлы для копирования. Файлы копируются в путь, указанный в <path> элемента.

<item>themelibs.cpy</item>
<path>/system/lib/</path>
<description>Updated library files required for this theme</description>

"О, сколько нам открытий чудных готовит Microsoft’а дух, и Intel - сын ошибок трудных, и Borland - Paradox’ов друг..."
Моя лычка только для общения с девушками о любви! Остальные все вопросы, через форум!
Изображение
4

#8
Пользователь офлайн   Xakep 

  • просто Xakep
  • Автор прошивок /ромодел/
  • Перейти к галерее
  • Вставить этот ник в форму быстрого ответа
  • Дополнительная информация
А сегодня я распишу вам команды используемые в update-script.

И так:

package_extract_dir
Синтаксис: package_extract_dir("<src-dir>", "<dst-dir>");
Копирует содержимое <src-dir> в <dst-dir>. Файлы в <dst-dir> имеющиеся в <src-dir> перезаписываются.
Пример: package_extract_dir("system", "/system"); Скопирует файлы из папки update.zip/system в /system

package_extract_file
Синтаксис: package_extract_file("<src-file>", "<dst-file>");
Копирует файл <src-file> в <dst-file>. Если файл <dst-file> существует, то он перезаписывается.
Пример: package_extract_file("test.sh", "/tmp/test.sh"); Скопирует файл test.sh из update.zip в /tmp/test.sh

format
Синтаксис: format("MTD", "<root>");
Форматирует раздел <root>(см. приложение).
Пример: format("MTD", "system"); Полностью отформатирует /system .
Примечание: форматирование удаляет данные необратимо.

delete
Синтаксис: delete("<file1>"[, "file2", ..."fileN"]);
Удаляет файл(ы)
Пример: delete("/system/app/Calculator.apk"); Удалит Calculator.apk из папки system/app.

delete_recursive
Синтаксис: delete_recursive("<dir1>"[, "dir2", ..."dirN"]);
Рекурсивно удаляет папку(и) со всем содержимым
Пример: delete_recursive("/data/dalvik-cache"); Удалит папку /data/dalvik-cache со всем содержимым.

run_program
Синтаксис: run_program("<filetorun>"[, "<opt1>", "<opt2>", "<opt3>"]);
Запускает программу(скрипт) <filetorun>.
Пример: run_program("/tmp/install_busybox.sh"); Запустит скрипт /tmp/install_busybox.sh.

set_perm
Синтаксис: set_perm(<uid>, <gid>, <mode>, "<pathtofile>"[, ... "pathtofileN"]);
Устанавливает владельца, группу и разрешения для файла или папки, как ‘chmod’, ‘chown’, и ‘chgrp’ всё в одном
Пример: set_perm(0, 2000, 0550, "/system/etc/init.goldfish.sh"); Установит владельца, группу и разрешения для файла /system/etc/init.goldfish.sh

set_perm_recursive
Синтаксис: set_perm_recursive(<uid>, <gid>, <dir-mode>, <file-mode>, "<path>"[, ... "<pathN>"]);
Рекурсивно устанавливает владельца, группу и разрешения для содержимого папки. <dir-mode> - для папок, <file-mode> - для файлов.
Пример: set_perm_recursive(0, 0, 0755, 0644, "/system/app"); Установит права для содержимого /system/app, для папок - 0755, для файлов - 0644.

show_progress
Синтаксис: show_progress(<fraction>, <duration>);
Продвижение прогрессбара на долю <fraction> за <duration> секунд. <duration> может быть нулевым для продвижения его по командe set_progress, а не по времени.
Пример: show_progress(0.100000, 1); Увеличит прогресс на 0.1 часть за 1 секунду

set_progress
Синтаксис: set_progress(<fraction>);
Устанавливает положение прогрессбара на долю <fraction>, для самого последнего вызова команды show_progress.
Пример: set_progress(0.500000);

symlink
Синтаксис: symlink("<link-target>", "<link-path1"[, "<link-path2>", "<link-path3>"]);
Создает символическую ссылку (как ‘ln-s’). <link-path> пишется в формате root:path, а <link-target> в формате целевой файловой системы (и может быть относительным)
Пример: symlink("/data/app_s", "/system/app"); Создаст символическую ссылку на папку /data/app_s для папки /system/app

mount
Синтаксис: mount("<kind>", "<what>", "<path>");
Монтирует <what> в путь <path>. <what> должно быть название раздела, если <kind> это "MTD", или блок памяти если <kind> это "vfat"
Пример: mount("MTD", "userdata", "/data");

unmount
Синтаксис: unmount("<path>");
Отключает <path>.
Пример: unmount("/data");

ui_print
Синтаксис: ui_print("<message>");
Выводит на экран сообщение <message>
Пример: ui_print("Formatting SYSTEM...");

write_raw_image
Синтаксис: write_raw_image("<img-file>", "<root>");
Записывает файл образа раздела <img-file> в раздел <root>.
Пример: write_raw_image("/tmp/boot.img", "boot"); Записывает файл образа раздела boot.img из папки /tmp, в раздел boot .
Примечание: Старые данные при записи удаляются.


Пример скрипта установки прошивки на устройство
ui_print("");
ui_print("Пример");
ui_print("скрипта");
ui_print("установки");
ui_print("прошивки");
ui_print("на");
ui_print("устройство");
ui_print("");
ui_print("с");
ui_print("");
ui_print("помощью");
ui_print("");
ui_print("update-script...");
ui_print("");
ui_print("");
ui_print("  --> Wiping cache...");
delete_recursive("/cache");

ui_print("  --> Formating system...");
format("MTD", "system");

ui_print("  --> Installing system...");
mount("MTD", "system", "/system");
show_progress(0.500000, 70);
package_extract_dir("system", "/system");

ui_print("  --> Creating symlinks: toolbox...");
symlink("toolbox", "/system/bin/cat", "/system/bin/cmp",
        "/system/bin/date", "/system/bin/dd", "/system/bin/dmesg",
        "/system/bin/getevent", "/system/bin/getprop", "/system/bin/hd",
        "/system/bin/id", "/system/bin/ifconfig", "/system/bin/iftop",
        "/system/bin/insmod", "/system/bin/ioctl", "/system/bin/kill",
        "/system/bin/log", "/system/bin/lsmod", "/system/bin/mkdir",
        "/system/bin/netstat", "/system/bin/newfs_msdos", "/system/bin/notify",
        "/system/bin/printenv", "/system/bin/ps", "/system/bin/reboot",
        "/system/bin/renice", "/system/bin/rmdir", "/system/bin/rmmod",
        "/system/bin/route", "/system/bin/schedtop", "/system/bin/sendevent",
        "/system/bin/setconsole", "/system/bin/setprop", "/system/bin/sleep",
        "/system/bin/smd", "/system/bin/start", "/system/bin/stop",
        "/system/bin/sync", "/system/bin/top", "/system/bin/uptime",
        "/system/bin/vmstat", "/system/bin/watchprops",
        "/system/bin/wipe");

ui_print("  --> Setting permissions on /system...");
set_perm_recursive(0, 0, 0755, 0644, "/system");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
set_perm_recursive(0, 2000, 0755, 0755, "/system/etc/init.d");
set_perm(0, 3003, 02755, "/system/bin/netcfg");
set_perm(0, 3004, 02755, "/system/bin/ping");
set_perm(1002, 1002, 0440, "/system/etc/dbus.conf");
set_perm(1014, 2000, 0550, "/system/etc/dhcpcd/dhcpcd-run-hooks");
set_perm_recursive(0, 0, 0755, 0555, "/system/etc/ppp");
set_perm_recursive(0, 2000, 0755, 0755, "/system/xbin");
set_perm_recursive(1010, 1010, 0777, 0777, "/system/xbin");
run_program("/tmp/installbusybox");
set_perm(0, 0, 04755, "/system/bin/sysrw");
set_perm(0, 0, 04755, "/system/bin/sysro");
set_perm(0, 0, 04755, "/system/bin/nano");
set_perm(0, 0, 04755, "/system/bin/bash");
set_perm(0, 0, 04755, "/system/bin/e2fsck");
set_perm(0, 0, 6755, "/system/bin/su");
symlink("/system/bin/su", "/system/xbin/su");
ui_print("  --> Creating symlinks: busybox...");
package_extract_file("installbusybox", "/tmp/installbusybox");
set_perm(0, 0, 0777, "/tmp/installbusybox");
run_program("/tmp/installbusybox");
unmount("/system");

ui_print("  --> Installing data content...");
mount("ext4", "EMMC", "/dev/block/mmcblk0p1", "/data");
package_extract_dir("data", "/data");
set_perm_recursive(0, 0, 0777, 0666, "/data");
set_perm_recursive(1010, 1010, 0777, 0777, "/data/misc/wifi");
unmount("/data");


show_progress(0.200000, 10);
ui_print("  --> Writing boot image...");
show_progress(0.100000, 10);
package_extract_file("boot.img", "/tmp/boot.img");
write_raw_image("/tmp/boot.img", "boot");
delete("/tmp/boot.img");

show_progress(0.100000, 0); 

"О, сколько нам открытий чудных готовит Microsoft’а дух, и Intel - сын ошибок трудных, и Borland - Paradox’ов друг..."
Моя лычка только для общения с девушками о любви! Остальные все вопросы, через форум!
Изображение
7

Поделиться темой:


Страница 1 из 1
  • Вы не можете создать новую тему (зарегистрируйтесь)
  • Вы не можете ответить в тему (зарегистрируйтесь)

1 человек читают эту тему
0 пользователей, 1 гостей, 0 скрытых пользователей


Вернуться назадАвторизация на сайте
Зарегистрироваться