motofan logo
       
> 

ANDROID firmware tool, Сборник скриптов и утилит для работы с прошивкой

noph8
сообщение 22.5.2014, 12:37


Авторитет
********

Группа: Модераторы
Сообщений: 2 558
Регистрация: 22.10.2005
Из: Kyiv
Пользователь №: 55 238
Модель телефона: в подписи
Прошивка: в подписи
Победитель конкурса 2008


Настроение:
Золотые были времена



Рейтинг: 2740



ANDROID_firmware_tool

Прикрепленное изображение

Сборник скриптов и утилит для работы с прошивкой от michфуд c форума china-iphone.ru, призванный максимально упростить работу по деодексированию, разборке, редактированию, сборке, одексированию и пр. Далее от автора (michфуд):

Описание и назначение
Краткое описание:

- Что это такое:
Это микс всех утилит в одном месте - а именно apktool и smali/backsmali - и созданный мной скрипт для объединения всех операций в одном окне.
- Зачем создавалось:
Для удобства.
- Что делает:
Разборка, сборка apk и jar, деодексирование и обратное одексирование с возможностью промежуточного редактирования
- Преимущества:
Объединяет в себе возможности apktools по сборке/разборке ресурсов в apk (jar) с возможностью smali/baksmali работать с кодами в виде dex и odex файлов. Apktools может работать только с деодексированными файлами, а для деодексирования нужен smali. Smali же в свою очередь может деодексировать - но не может работать с ресурсами. Другими словами - вместо использования 2х оболочек типа AutoDeoTool и ApkManager (ApkMultiToll) - можно использовать одну. Также доступно больше вариаций с опциями сборки/разборки.

Немного теории и описание логики работы скрипта:

- Что такое apk?
Это контейнер для приложения андроид. На самом деле - zip архив. Но содержимое этого архива (файлы лежащие внутри) - сжато по специальной технологии. Т.е. если бы внутри лежал файл *.txt - после извлечения из архива прочитать его невозможно в текстовом редакторе - его необходимо еще один раз распаковать.
Обязательный состав:
- папка META-INF внутри которой лежат сертификаты и подпись,
- AndroidManifest.xml - файл с различными свойствами приложения, в том числе - неразрывно связан с предыдущей папкой META-INF. Изменение той или иной составляющей этой связки приведет к тому, что приложение утратит свою подпись, не будет запускаться и будут появляться ошибки.
- папки res, assets и пр - папки, в которых лежат ресурсы - картинки, библиотеки и пр.
- classes.dex - файл с кодом для далвик-машины - то что мы потом увидим как смали.
- resources.arsc - тоже файл с ресурсами (этот файл как правило не сжимается в архиве - по умолчанию у меня все arsc кладутся в архив без сжатия - мое мнение таково, что это пусть мизер, но уменьшит нагрузку на проц телефона при их извлечении - обратная сторона - занимаемое место в разделе system. Иногда оно жестко лимитировано. Здесь нужно действовать по ситуации и поставленным целям).
- Что такое apktools?
Это ява-скрипт, который распаковывает apk в нормальные читаемые файлы. В состав apktools УЖЕ внедрна та или иная версия smali - поэтому он имеет возможность распаковывать classes.dex на смали. НО!!! эта версия жестко привязана к самой версии apktools и мы не имеем возможность запускать smali с параметрами для гибкости - например "-p" - для создания всех регистров в виде v. Т.е. apktools - прекрасно разбирается со всем содержимым apk, кроме самого кода - classes.dex.
Но всегда есть нюансы - от версии к версии правились разные баги, и до сих пор встречаются ситуации, когда apktools косячит с такими вещами, как знаки %, $ и тому подобное - это то с чем сталкивался лично я. Т.е. apktools не всегда может правильно разобрать или собрать apk. Причем разные версии делают это по разному.
И еще одно важное замечание - apktools может рахобрать только заранее ДЕОДЕКСИРОВАННОЕ приложение, т.е. он просто не умеет работать с 2мя файлами в комплексе - *.apk + *.odex - apk он разберет, но кода там не будет.
- Что такое smali / backsmali?
Тоже ява-скрипты, но они работают только с кодом для далвик-машины - другими словами - разбирают и собирают classes.dex или ***.odex - без разницы, одинаково принимает и то и другое - причем если ему подсунуть apk внутри которого лежит classes.dex - он его тоже схавает и разберет. У этих скриптов тоже несколько версий и несколько параметров для запуска. Именно это нам и нужно для правильной разборки/сборки.

Алгоритм моего скрипта таков:

1. Если на входе одексированный apk:
- с помощью apktools разбираем сам apk чтобы извлечь все ресурсы
- с помощью backsmali разбираем ***.odex - чтобы получить код в виде smali файлов.
- потом если надо (или не надо) - коды преобразуются с помощью smali в classes.dex и запихиваются в исходный apk
- потом уже деодексированный файл можно повторно разобрать с помощью apktools - зависит от выбора де/компилятора
т.о. получаем распакованные ресурсы, код и в добавок - деодексированный вариант файла.

2. Если на входе деодексированный файл apk:
- с помощью архиватора вынимаем classes.dex и разбираем с помощью backsmali код (classes.dex удаляем из архива, чтобы его потом нечаянно не разобрал apktools) или если в качестве де/компилятора выбран apktools - сразу переходим к следующему пункту
- с помощью apktools разбираем все ресурсы и прикладываем к коду
т.о. также получаем распакованные ресурсы, код, а деодексированный файл у нас уже был.

3. Cборка - в обратном порядке - apktools сжимает все ресурсы, причем и classes.dex тоже создает из кода - на этом можно остановиться, а можно пересобрать classes.dex с помощью smali и заменить им уже ранее собранный classes.dex с помощью apktools. Для этого и есть опция - что использовать в качестве де/компилятора для classes.dex.
Напоследок - перетаскиваем все что связно с подписью в новый файл apk и производим выравнивание архива с помощью zipalign - якобы так системе проще ориентироваться внутри архива и сразу находить нужные файлы.

Изменится размер apk, степень сжатия и пр. - но это не важно - главное он сохраняет работоспособность и более того - разработчики smali заявляют, что полученный после сборки код может быть более эффективным и оптимизированным нежели исходный.
Что касается jar - все точно также, с маленькими нюансами.
[close]
Системные требования
ТРЕБОВАНИЯ К КОМПЬЮТЕРУ:
1. ОС - Windows (у меня Win7 x86) и свободного места от 1 гигабайта
2. Установленная машина Java (у меня 1.6)
3. Архив желательно распаковывать так, чтобы путь был короткий, без русских символов и пробелов. Например C:\FM_tool\
4. Чтобы корректно отображался русский шрифт мне лично пришлось сделать так: - запусть cmd.exe (или на самом окне FWT), правой кнопкой мыша щелкнуть на заголовке окна - Свойства - и выбрать ТТ шрифт, т.к. при системном отображались крякозябры.
ТРЕБОВАНИЯ К ТЕЛЕФОНУ:
1. ROOT права для adb.
- для этого в boot.img в файле default.prop должны быть следующие параметры:
Код
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1

2. Установленный busybox http://www.busybox.net/about.html
3. Установленный dexopt-wrapper http://code.google.com/p/just-for-you/down...=dexopt-wrapper
[close]
Используемые папки, их структура и назначение
Код
bin                                     - служебные файлы и скрипты
firmware                                 - исходные файлы прошивки и рабочие файлы для редактирования
    \1_source                            - исходники
        \1_image_folder                    - для исходников system.img и userdata.img
        \2_system.img_unpacked                - распакованный system.img
        \4_data.img_unpacked                - распакованный userdata.img
    \2_deodexed                            - деодексированные файлы
        \1_app_deodexed                    - приложения
        \2_framework_deodexed                - framework
    \3_decompiled_source_do_not_edit    - разобранные (декомпилированные) файлы прошивки - не менять - чтобы удобно было сравнивать
        \1_app_decompiled                    - приложения
        \2_framework_decompiled                - framework
    \4_decompiled_mod_to_edit            - разобранные (декомпилированные) файлы прошивки - для внесения изменений
        \1_app_decompiled_mod                - приложения
        \2_framework_decompiled_mod            - framework
    \5_compiled_deodexed_mod            - скомпилированные заново деодексированные файлы
        \1_app_compiled_mod                - приложения
        \2_framework_compiled_mod            - framework
    \6_odexed_mod                        - скомпилированные одексированные файлы
        \1_app_odexed_mod                    - приложения
        \2_framework_odexed_mod            - framework
[close]
Как пользоваться программой
- После распаковки, и в любой другой момент можно удалить/восстановить структуру используемых папок командами 55 и 56.
При этом создастся минимальный набор папок, куда можно класть исходники или получать их с телефона.
- 80-81 позволяют выбирать версию используемых утилит Apktool и smali/backsmali. Сведения о выборе сохранятся в командных файлах set_smali.bat и set_apktool.bat соответственно - при следующем запуске они установятся автоматически.
- для работы Apktool необходимо сначала инсталлировать framework и задать bootclasspath - первое возможно только после:
1. распаковки system.img
2. извлечения framework файлов из телефона или вручную - заполнением папки 1.2/firmware/

Операции с прошивкой:
1. Распаковать system.img.
ВНИМАНИЕ!!! Разбираются только образы в формате yafss!! Для процессоров версии 6575 могут использоваться образы в формате ext4 - их разбирать скрипт не умеет.
Необходимо иметь system.img - он должен лежать в папке 1.1. После выполнения команды - создается и заполняется папка 1.2 (по аналогии - команда 2 разбирает userdata в папку 1.4) - в этих папках будут находится исходные файлы, которые позволят нам всегда откатиться к началу работы.
2. Распаковать userdata.img.
См. выше. В разных случаях название образа может быть userdata.img или data.bin и т.п. Для того чтобы команда выполнилась - необъодимо переименовать образ раздела данных в userdata.img.
3,4 Деодексировать и разобрать ВСЕ APK (JAR)
Процесс деодексирования содержит в себе процесс декомпиляции и обратной компиляции, поэтому отдельно проводить деодексацию не имеет смысла. Данные команды в автоматическом режиме производят деодексацию и декомпиляцию всех APK и JAR соответственно.
Примечание - framework-res.apk и mtkbase-res.apk тоже обрабатываются автоматически вместе со всеми JAR`ами - т.е. их не надо теперь таскать по папкам руками.
После выполнения команд заполняются папки 2.1, 2.2 - деодексированная неизмененная прошивка, а также 3.1 и 3.2 - декомпилированные файлы. При этом одновременно содержимое 3.1 и 3.2 копируется в папки 4.1 и 4.2 - т.о. у нас всегда есть исходный декомпилированный код, который можно сравнивать с внесенными изменениями. Изменения в код вносятся в папки 4.1 и 4.2.
Внимание!!! - уже на этапе разборки могут быть ошибки, которые при сборке дадут нерабочий файл. Это не всегда отобразится в логе или на экране.

5,7 (6,8) Разобрать (Собрать) все деодексированные APK (JAR)
После выполнения предыдущей команды по деодексированию, в папках 2.1 и 2.2 будут созданы (или скопированы из исходных папок, если они уже деодексированы) деодексированные файлы apk и jar. В эти же папки можно положить любые деодексированные приложения для разборки - они будут в данном случае являться исходниками.
После выполнения команд заполняются папки 3.1 и 3.2 - декомпилированные файлы. При этом одновременно содержимое 3.1 и 3.2 копируется в папки 4.1 и 4.2 - т.о. у нас всегда есть исходный декомпилированный код, который можно сравнивать с внесенными изменениями. Изменения в код вносятся в папки 4.1 и 4.2. (все по аналогии с предыдущими командами, только не выполняется деодексирование)
Внимание!!! - уже на этапе разборки могут быть ошибки, которые при сборке дадут нерабочий файл. Это не всегда отобразится в логе или на экране.

После внесения изменений командами 6 и 8 запускается процесс компиляции APK и JAR. Результат - деодексированные собранные файлы в папках 5.1 и 5.2. Т.к. в процессе декомпиляции и компиляции могут возникать ошибки, НЕ РЕКОМЕНДУЕТСЯ автоматическая сборка и заливка всей прошивки - вероятность того, что телефон запустится - 50х50.
9,10 Одексировать все APK (JAR)
Производится одексация папок 5.1 и 5.2 с выводом результата в папки 6.1 и 6.2
Для одексации необходим подключенный по USB телефон с рутом, установленный dexopt-wrapper и busybox с правами 777.

Описание процесса - в папку system/app или framework на телефоне копируется правленый APK или JAR (тот файл что лежит на телефоне временно прячется в папку data/tmp), исходный *.odex уже должен иметься в телефоне - далее они там "варятся" и снова выводятся из телефона в папки 6.1 и 6.2. Т.е. подмены файлов в телефоне не происходит - они снова на компе и заливать в тело можно потом.
Примечание - если в телефоне файл apk или jar был деодексирован (не имеет соответствующего *.odex) - он одексирован не будет - будет предложено сделать это вручную через dalvik cache.

Работа с одиночными файлами - все тоже самое, только команды другие.
Если нет целой прошивки - исходники кладем в папку \2_system.img_unpacked\app или \2_system.img_unpacked\framework соответственно, далее - деодекс/декомпайл и т.д. - даже если они деодексированы - это должно работать.

Добавил команды, которые могут забирать apk и framework из телефона, а также устанавливать их обратно.
Замечательная на мой взгляд функция - возврат в тело исходников (у нас же есть нетронутая папка с исходными файлами) - что бы мы ни накосорезили при правке и сборке - всегда можно быстро сделать откат и вернуть тело к жизни.
[close]
История изменений

Изменения v2.1
- Возможность переподписывания всей прошивки (заново скомпилированных apk и jar (ВНИМАНИЕ! - только если все системные файлы деодексировались и пересобрались без ошибок!)
- распаковка system.img из заводских прошивок в формате EXT4 - с использованием подключенного телефона
[close]
Изменения v2.
Создание одексированных update.zip и патчей отката на исходные версии файлов
[close]
Изменения v1.9
Поиск и замена %1 и замена на %1$d% или чего захотите [attachment=1]22.jpg[/attachment]
[close]
Изменения v1.8
- Создание update.zip[attachment=4]1.jpg[/attachment][attachment=3]2.jpg[/attachment][attachment=2]3.jpg[/attachment]
[close]
Изменения v1.7
- Работа через ADB WiFi[attachment=6]wifi.jpg[/attachment]
Теперь нет необходимости курочить USB разъем в телефоне, после запуска в этом режиме также сразу начинает работать QTAdb.
На телефон можно (нужно) установить практически любой клиент wifi adb - например отсюда https://play.google.com/store/search?q=adbw...less&c=apps
одно из них - приложил во вложениях AdbWireless
- Улучшена работа с проектами (сохранение BCP для проекта и еще всякие мелочи) - желательно удалить .ini папки из проектов - программа пересоздаст их.
- Исправлен баг, требующий повторной установки опорных apk командой 50 после старта скрипта (они нечаянно удалялись)
[close]
Изменения v1.6
1. Возможность выбора просмотра кода на java как исходного файла, так и пересобранного
2. Частично переведено на английский (start.bat - сменить во 2й строке ru на en)
3. Добавлены свежие smali 1.4.1
4. Удалены лишние (старые) версии apktool и smali
5. Выбор смали и apktool не привязан теперь жестко к скрипту - можно самостоятельно кидать в папку bin файлы начинающиеся на apktool_ и smali_ - программа будет выводить их список
6. В работе с boot и recovery исправлена несовместимость с линуксовыми скриптами - теперь после перепаковки моим скриптом их также можно будет потом открыть из-под линукса (cygwin)
7. Автоматическое назначение опорных файлов для apktool - главное чтобы они были в папке \source\system_img_unpacked\framework
[close]
Изменения v1.5
В данном релизе 2 важных изменения:
1. Работа с проектами.
Теперь программа будет видеть только папки начинающиеся с "fw_" - и при создании нового проекта автоматически будет добавлять этот префикс.
Смена текущего проекта - команда 56. Также в проекте теперь будет папка .ini - в ней будут храниться настройки для каждого проекта (все кроме BCP). Теперь не надо переименовывать папку firmware и можно быстро переключаться между разными прошивками.
2. Разборка recovery и boot для процессоров MTKПринцип как и с остальными файлами:
имеем source image (boot.img) - кладем (или получаем с телефона) в папку 1_source\1_image_folder
- после распаковки получаем 1_source\3_boot_unpacked - это исходники, не подлежащие изменениям.
- автоматом все распакованное копируется в папку 4_decompiled_mod_to_edit\3_boot_unpacked_mod - там редактируем
- после сборки получаем папку 7_repacked_images - в ней новые образа для прошивки
[close]

[close]
Отблагодарить автора ANDROID firmware tool
Яндекс кошелек 41001950479219
PayPal
[close]



Сообщение отредактировал noph8 - 23.5.2014, 8:28
Юзер вышелВ друзьяВизиткаП/Я
К началу страницы
+Ответить
ANDROID firmware tool, Сборник скриптов и утилит для работы с прошивкой · Разработка приложений для Android OS · Forum
 

Ответ в темуСоздание новой темы
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



Текстовая версия Сейчас: 31.10.2024, 22:45

Форум живёт: