Firmware tool

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

2. Установленный busybox
3. Установленный dexopt-wrapper

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 - все точно также, с маленькими нюансами.

- Что это такое:
Это микс всех утилит в одном месте - а именно 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 - он его тоже схавает и разберет. У этих скриптов тоже несколько версий и несколько параметров для запуска. Именно это нам и нужно для правильной разборки/сборки.

- После распаковки, и в любой другой момент можно удалить/восстановить структуру используемых папок командами 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 из телефона, а также устанавливать их обратно.
Замечательная на мой взгляд функция - возврат в тело исходников (у нас же есть нетронутая папка с исходными файлами) - что бы мы ни накосорезили при правке и сборке - всегда можно быстро сделать откат и вернуть тело к жизни.