В этом посте хочу вам поведать о том насколько просто декомпилировать и извлекать различного рода информацию из файлов apk . В файлах с этим расширением запечатаны игры и программы Андроида, говоря иными словами это основной формат приложений OS Android.

Скажу сразу: вся инструкция по декомпиляции игр и приложений андроида приведена для Windows.сс

Для начала нам понадобятся несколько программ, декомпиляторов. Всех их я собрал в архив:

В архиве 3 компонента - dex2jar, Java Decompiler, ApkTool.

1. Создайте папку, с любым названием. В ней мы будем проводить декомпиляцию, например назовите её Decomp.

2. Подготовимся.

2.1. Распакуйте содержимое архива в созданную нами папку. Теперь создайте внутри папки Decomp папку apk, в которую мы и будем закидывать файлы андроид приложений. Поместите в папку apk приложение которое хотите декомпилировать.

2.2. Поместите в папку с операционной системой (обычно это C:/Windows/) содержимое .

3. Приступим к декомпиляции. Декомпиляция, делиться на 2 части. В зависимости от того что вам требуется в приложении вам может быть достаточно 1 части полной компиляции. Поехали

3.1.Распаковка ресурсов

3.1.1. Откройте консоль в созданной папке Decomp. Если не знаете как это сделать, выйдите с этой папки на 1 уровень выше, затем с зажатым SHIFT нажмите по папке правой кнопкой мыши и в появившемся списке выберите Открыть окно команд .

3.1.2. Теперь необходимо ввести команду вида:

apktool d путь_к_apk_файлу папка_куда распакуются_ресурсы

Т.е. в нашем случае, если мы хотим декомпилировать приложение mygame.apk, команда получится такой:

apktool d apk/mygame.apk mygame

Если в пути к apk файлу содержаться пробелы или он сам в своём названии содержит пробелы заключайте путь в кавычки!

После выполнения команды в папке Decomp должна появиться папка куда распакуются ресурсы.

3.2. Распаковка исходников

3.2.1. Откройте консоль таким образом, как указывалось в пункте 3.1.1.

3.2.2 Введите команду:

dex2jar apk/mygame.apk , где mygame.apk имя вашего приложения, которое лежит у вас в папке apk.

После выполнения этой команды в папке apk появится файл с расширением jar. И примерно с таким именем: mygame_dex2jar.jar .

3.2.3. Откройте папку jd-gui-0.3.5.windows и запустите приложение jd-gui , в котором откройте созданный нами на предыдущем шаге файл.

3.2.4. После открытия файла сохраните все ресурсы. File -> Save All Sources .

3.2.5 Создаём папку src в папке куда распаковывали ресурсы на пункте 3.1.2. И помещаем в созданную папку содержимое архива, который получили на предыдущем шаге в результате сохранения.

Всё, на этом полная компиляция приложения Android будь то программа игра с расширением apk завершена. Спасибо за внимание.

О том, как декомпилировать приложения для Android, то Вы знаете, что остановился я на том, как собрать все файлы, которые получились при разборке приложения, обратно в APK.

Лирическое отступление

К сборке рекомендуется папка с файлами, полученная в результате декомпиляции с помощью apktool. Файлы кода, которые представляют из себя набор инструкций для виртуальной машины Dalvik, собираются обратно в архив классов без каких-либо проблем. В то время как преобразование из Dalvik в Java и обратно может привести к проблемам несовместимости. Как следствие, программа будет работать некорректно. Поэтому для успешной модификации программ, а не только ради исследования, Вам необходимо изучить инструкции Dalvik .

Сборка

Собрать такие файлы обратно в APK достаточно просто. Для этого необходимо запустить apktool с соответствующим флагом сборки и передать ему путь к папке с декомпилированным приложением внутри. Например, если у нас есть папка app, которая размещена в том же каталоге, что и apktool, то команда будет выглядеть так:

Shell

java -jar apktool.jar b app

java - jar apktool .jar b app

После сборки готовый APK файл будет лежать в каталоге app/build . Далее необходимо подписать APK. Делается это для того, чтобы приложение работало на устройствах, где запрещена отладка. То есть, запуск неподписанных приложений на таких устройствах запрещен. Подробнее, о цифровых сертификатах и процедуре подписывания файлов можно прочитать здесь.

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

Shell

java -jar signapk.jar testkey.x509.pem testkey.pk8 *.apk apk_signed.apk

java - jar signapk .jar testkey .x509 .pem testkey .pk8 * .apk apk_signed .apk

Где же взять такой сертификат, спросите Вы? Сертификаты можно найти в Интернет. Либо сгенерировать самому. Подробную инструкцию о настройке и генерации всех необходимых файлов можно найти, например, .

Заключение

Как видите, декомпиляция и сборка APK файлов достаточно простой процесс, который вдобавок можно автоматизировать, облегчая работу исследователю. Сама виртуальная машина Dalvik также проста в освоении и открыта, что, с одной стороны, снижает порог вхождения для разработчиков, с другой – является основной причиной столько большого процента пиратства именно на платформе Android. Отчасти поэтому разработчики, например, игр в основном не заинтересованы в выпуске интересных игр с сюжетом. Намного выгоднее при нынешнем отношении пользователей клепать поразительно похожие друг на друга фермы с донатом. Поэтому, покупаем приложения, поддерживаем разработчиков и в итоге получаем интересный контент. А вот донатить совершенно не нужно!

Всем спасибо, до новых встреч.

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

В статье будет рассказано о том, как подключить отладчик к Android-приложению и пошагово пройти через вызываемые методы, используя информацию, полученную после декомпиляции приложения. Хорошая новость в том, что для отладки не требуются привилегии суперпользователя. Описанные техники могут быть очень кстати во время пентестов мобильных приложений, поскольку мы можем «проникнуть» в код во время работы программы, получить и записать информацию, к которой обычно у нас нет доступа. Например, можно перехватить трафик перед шифрованием и на лету получить ключи, пароли и любую другую ценную информацию. Статья будет полезна пентестерам и разработчикам мобильных приложений, желающих получить более глубокие знания о возможных атаках на платформе Android.

Требования к тестовой среде:

• Операционная система: Windows / Mac OS X / Linux
• Java (рекомендуется версия 1.7)
• IDE (Eclipse, IntelliJ IDEA, Android Studio)
• Android SDK (https://developer.android.com/sdk/index.html?hl=i)
• APKTool (https://code.google.com/p/android-apktool/)/APK Studio (http://apkstudio.codeplex.com)
• Устройство / эмулятор на базе Android

В статье будет использоваться следующая конфигурация: Windows 8, Android Studio и IntelliJ IDEA. Устройство: Nexus 4 с Android версии 4.4.4. Рекомендую все утилиты добавить в переменную окружения PATH, чтобы облегчить и ускорить доступ к этим инструментам.

Android application package (APK), используемый в статье, можно скачать отсюда: com.netspi.egruber.test.apk .

Настройка устройства

Инструкция ниже поможет вам подготовить устройство для экспериментов.

Активация раздела Developer Options

Для начала на Android-устройстве должна быть разрешена отладка через USB (опция USB debugging), что позволит «общаться» с девайсом при помощи инструментов из набора Android SDK. Однако перед этим необходимо активировать раздел Developer options. На устройстве зайдите в раздел Settings > About Phone и кликните несколько раз на пункт Build Number, после чего должно появиться сообщение о том, что раздел Developer options активирован.

Рисунок 1: Для того чтобы активировать раздел Developer options, необходимо несколько раз кликнуть на Build number

Разрешение отладки через USB

Чтобы разрешить отладку через USB-порт, зайдите в раздел Settings > Developer options и отметьте флажок напротив USB debugging.

Рисунок 2: Включение опции USB debugging

Подключение устройства и запуск ADB

После подключение устройства к компьютеру через USB-порт, должно появиться сообщение «USB debugging connected on the device». Также следует проверить, можно ли подключиться к устройству при помощи приложения Android Debug Bridge (ADB), входящего в состав Android SDK (пакет Android SDK Platform-tools). В командной строке введите следующую команду:

Устройство должно отобразиться в списке.

Рисунок 3: Список подключенных устройств

Если устройство не отобразилось в списке, то наиболее вероятная причина в некорректно установленных драйверах (в Windows). В зависимости от устройства драйвер можно найти либо в Android SDK, либо на сайте производителя.

Проверка приложения на возможность отладки

Перед отладкой Android-приложений вначале необходимо проверить, есть ли такая возможность. Проверку можно выполнить несколькими способами.

Первый способ - запустить Android Device Monitor , входящий в состав Android SDK (в папке tools). В Windows файл называется monitor.bat. При открытии Android Device Monitor устройство отобразится в разделе Devices.

Рисунок 4: Приложение Android Device Monitor

Если какое-либо приложение на устройстве можно отлаживать, это приложение также отобразится в списке. Я создал тестовую программу, но список пуст, поскольку программу отлаживать нельзя.

Второй способ проверить приложение на возможность отладки – исследовать файл AndroidManifest.xml из пакета приложения (APK, Android application package). APK представляет собой zip-архив, содержащий всю информацию, необходимую для запуска приложения на Android-устройстве.

Всякий раз, когда приложения загружается из Google Play Store, также загружается и пакет приложения. Все загруженные APK-файлы обычно хранятся на устройстве в папке /data/app. Если у вас нет прав суперпользователя, вы не сможете получить список файлов из директории /data/app. Хотя, если вы знаете имя APK-файла, можете скопировать его при помощи утилиты adb . Чтобы узнать имя APK-файла, введите следующую команду:

Появится командная строка устройства. Затем введите следующую команду:

pm list packages -f

Отобразится список всех пакетов на устройстве.

Рисунок 5: Перечень пакетов на устройстве

Глядя на список, находим тестовое приложение.

Рисунок 6: Пакет созданного тестового приложения (выделено белым)

Теперь необходимо скопировать файл пакета. Открываем шелл и вводим следующую команду:

adb pull /data/app/[.apk file]

Рисунок 7: Копируем APK-файл с устройства в систему

Теперь нужно открыть файл пакета и исследовать содержимое AndroidManifest.xml. К сожалению, мы не можем просто так распаковать архив, поскольку APK-файл закодирован в бинарном формате. Для раскодировки чаще всего используется утилита apktool , хотя я использую APK Studio , поскольку у этого приложения дружелюбный графический интерфейс. Далее в статье будет рассказываться об APK Studio.

В APK Studio кликните на маленькую зеленую иконку, задайте имя проекту и укажите путь к APK файлу. Затем укажите пусть для сохранения проекта.

Рисунок 8: Создание нового проекта в APK Studio

После открытия APK выберите файл AndroidManifest.xml и посмотрите параметры тега application. Если флаг android:debuggable отсутствует (или присутствует, но установлено значение false), значит, приложение отлаживать нельзя.

Рисунок 9: Содержимое файла AndroidManifest.xml

Модификация файла AndroidManifest.xml

При помощи утилиты apktool или APK Studio мы можем модифицировать файлы и упаковывать содержимое обратно в пакет. Сейчас мы изменим файл AndroidManifest.xml так, чтобы приложение можно было отлаживать. Добавляем внутрь тега application строчку android:debuggable="true".

Рисунок 10: Изменяем содержимое тега application

После добавления флага кликаем на иконку «молоток» и заново собираем пакет. Пересобранный пакет будет находиться в директории build/apk.

Рисунок 11: Повторная сборка пакета завершилась успешно

После пересборки пакет подписывается и его можно заново установить на устройстве (все Android-приложения должны быть подписаны). Большинство приложений не проверяет сертификат, при помощи которого происходит подпись. В противном случае необходимо изменить код, выполняющий эту проверку.

Теперь нужно установить пересобранный пакет. Вначале удаляем старое приложение при помощи следующей команды:

adb pm uninstall

Затем устанавливаем новый пакет:

adb install [.apk file]

Также можно удалить и установить пакет одной командой:

adb install -r [.apk file]

Рисунок 12: Установка пересобранного пакета

Проверьте, чтобы переустановленное приложение корректно запускалось на устройстве. Если все работает, переходим обратно в Android Device Monitor, где должно появиться тестовое приложение.

Рисунок 13: Теперь пересобранное приложение можно отлаживать

Настройка среды разработки (IDE)

Теперь к пересобранному приложению можно подцепить отладчик, но вначале нужно создать проект в среде разработки (в статье используется IntelliJ IDEA). Создаем новый проект. В поле Application name указываем произвольное имя. В поле Package name указываем имя, в точности совпадающее с иерархией папок пересобранного пакета.

Рисунок 14: Создание нового проекта в IntelliJ IDEA

Обычно имя APK-файла совпадает со структурой папок, хотя, если вы не уверены, в APK Studio проверьте иерархию директорий до папки, где находятся файлы приложений. В моем случае имя и структура папок полностью совпадают (com.netspi.egruber.test).

Рисунок 15: Иерархия директорий тестового приложения

Снимите флажок «Create Hello World Activity» и завершите создание проекта (все остальные параметры остаются по умолчанию). Новый проект должен выглядеть примерно так:

Рисунок 16: Иерархия папок и файлов нового проекта

После создания проекта нужно добавить исходный код из APK-файла для того, чтобы отладчик «знал» имена символов, методов, переменных и т. д. Хорошая новость в том, что Android-приложения можно декомпилировать практически без потери качества (исходный код будет совпадать с оригиналом). После декомпиляции исходный текст импортируется в среду разработки (IDE).

Получение исходных текстов из пакета приложения

Для начала необходимо преобразовать APK в jar-файл. Затем мы при помощи java-декомпилятора получим исходный текст приложения. Преобразование в jar будем делать при помощи утилиты dex2jar . У dex2jar есть файл d2j-dex2jar.bat, используемый для конвертирования APK в jar. Синтаксис команды довольно прост:

d2j-dex2jar.bat [.apk file]

Рисунок 17: Преобразование APK в jar

Затем открываем или перетаскиваем полученный файл в JD-GUI (это java-декомпилятор).

Рисунок 18: Структура jar-файла

Jar-файл должен отобразиться в виде иерархической структуры, внутри которой находятся java-файлы с читабельным исходным кодом. Заходим в File > Save All Sources, чтобы упаковать все исходные тексты в zip-архив.

Рисунок 19: Сохранение исходных текстов декомпилированного файла

После сохранения исходных текстов распаковываем архив в отдельную директорию.

Рисунок 20: Распакованный архив

Теперь нужно импортировать обе директории в созданный ранее проект в IDE. В IntelliJ заходим в папку src и копируем туда содержимое распакованного архива (две директории).

Рисунок 21: Обе папки скопированы в директорию src

Возвращаясь в Intellij, видим обновленный проект.

Рисунок 22: В проекте появились исходные тексты

Если мы кликнем на какой-нибудь элемент из списка, то увидим исходный текст. Как видно на скриншоте ниже (исходный текст класса LoginActivity), исходный код обфусцирован при помощи ProGuard.

Рисунок 23: Обфусцированный исходный текст класса LoginActivity

Подключение отладчика

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

Рисунок 24: Поставлена точка останова на обфусцированный метод

Как только появилась точка останова, подключаем отладчик к процессу на устройстве, кликнув на иконку с экраном в правом верхнем углу (на вашей IDE иконка может отличаться).

Рисунок 25: Подключаем отладчик к процессу

Рисунок 26: Перечень процессов для подключения отладчика

После выбора процесса отладчик подсоединится к устройству.

Рисунок 27: Отладчик подключен к процессу, запущенному на устройстве

В текстовое поле я буду вводить число 42 (если помните, на соответствующем методе стоит точка останова).

Рисунок 28: В текстовое поле вводим число 42

После нажатия на кнопку «Enter Code» выполнение приложения прервется на точке останова, поскольку отладчик «осведомлен», какой метод вызывается на устройстве. Скомпилированное Android-приложение содержит отладочную информацию (например, имена переменных), доступную любому отладчику, совместимому с Java Debug Wire Protocol (JDWP). Если в приложении разрешена отладка, отладчик, совместимый с JDWP (в эту категорию попадает большинство отладчиков идущих в составе сред разработки для Java), сможет подсоединиться к виртуальной машине Android-приложения, а затем считывать и выполнять отладочные команды.

Рисунок 29: Сработала точка останова

На скриншоте ниже видно число, которое ранее мы ввели в текстовом поле.

Рисунок 30: Перечень переменных текущего экземпляра класса

Заключение

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

Бывает после релиза приложения его исходники куда-то деваются. Правда ведь, такое постоянно случается? И ничего не остается кроме как декомпилировать его и подправить несколько сотен строк кода и все это нужно сделать максимально быстро.

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

Декомпиляция

Для Android"а существуют следующие утилиты:

• ApkTool для декомпиляции ресурсов.
• Dex2Jar для преобразования dex в jar.
• JD-GUI для получения исходников из jar.
• еще рекомендую JAD , некоторые места лучше декомпилирует чем JD-GUI.

Информации по их использованию в интернете достаточно.

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

На этом можно было и закончить эксперименты с декомпиляцией, но лень двигатель прогресса и родился новый способ.

Переопределение классов

Итак, jar это библиотека, так почему бы просто не подключить ее к новому проекту? Кидаем ее в папку libs, наследуемся от главной активити и компилируем. Все работает, главное чтоб не совпадали имена классов, поэтому названия пакетов должно отличаться иначе как минимум совпадут сгенерированные BuildConfig и R.

Таким способом можно отнаследоваться от Activity, Service, BroadcastReceiver и, возможно, некоторых других классов объявляемых в манифесте, так же в манифесте нужно будет указать новые имена классов, иначе они не будут использоваться.

Теперь можно переопределить виртуальные функции, но и только, тем более ключевое слово final не позволит это сделать и отнаследоваться тоже, поэтому идем дальше.

Замена классов

Разархивировав jar библиотеку получим class файлы, это скомпилированные классы, заметим, что при сборке проекта в папке bin/classes лежат те же class файлы, а что если подсунуть туда файлы из библиотеки…

Не все так просто, для начала нужно скомпилировать проект. Чтобы использовать классы исходного приложения нужно его как-то присоединить к проекту, но при этом не экспортировать. Делается это просто: из папки libs Эклипс сам экспортирует библиотеки, поэтому перемещаем jar библиотеку в папку lib и подключаем к проекту, в Эклипсе это Project->Preferences->Java Build Path->Libraries->Add Jars… далее во вкладке Order and Export нужно убедиться, что не установлен чекбокс, потому что экспортировать библиотеку нам не нужно, все будет в class файлах.

Теперь берем какой-нибудь класс из декомпилированных исходников приложения, исправляем в нем ошибки компиляции, добавляем, например, показ диалога, чтоб убедиться, что используется именно новый класс. Далее очищаем проект, в Эклипсе это Project->Clean, копируем class файлы в папку bin/classes, собираем проект и все работает!

При следующих сборках проекта нет необходимости его очищать, так что использовать такой способ достаточно удобно. Для облегчения исправления ошибок после декомпиляции я использовал исходники полученные из JD-GUI и JAD, обычно этого было достаточно.

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

Заключение

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

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

Бывает после релиза приложения его исходники куда-то деваются. Правда ведь, такое постоянно случается? И ничего не остается кроме как декомпилировать его и подправить несколько сотен строк кода и все это нужно сделать максимально быстро.

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

Декомпиляция

Для Android"а существуют следующие утилиты:

• ApkTool для декомпиляции ресурсов.
• Dex2Jar для преобразования dex в jar.
• JD-GUI для получения исходников из jar.
• еще рекомендую JAD , некоторые места лучше декомпилирует чем JD-GUI.

Информации по их использованию в интернете достаточно.

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

На этом можно было и закончить эксперименты с декомпиляцией, но лень двигатель прогресса и родился новый способ.

Переопределение классов

Итак, jar это библиотека, так почему бы просто не подключить ее к новому проекту? Кидаем ее в папку libs, наследуемся от главной активити и компилируем. Все работает, главное чтоб не совпадали имена классов, поэтому названия пакетов должно отличаться иначе как минимум совпадут сгенерированные BuildConfig и R.

Таким способом можно отнаследоваться от Activity, Service, BroadcastReceiver и, возможно, некоторых других классов объявляемых в манифесте, так же в манифесте нужно будет указать новые имена классов, иначе они не будут использоваться.

Теперь можно переопределить виртуальные функции, но и только, тем более ключевое слово final не позволит это сделать и отнаследоваться тоже, поэтому идем дальше.

Замена классов

Разархивировав jar библиотеку получим class файлы, это скомпилированные классы, заметим, что при сборке проекта в папке bin/classes лежат те же class файлы, а что если подсунуть туда файлы из библиотеки…

Не все так просто, для начала нужно скомпилировать проект. Чтобы использовать классы исходного приложения нужно его как-то присоединить к проекту, но при этом не экспортировать. Делается это просто: из папки libs Эклипс сам экспортирует библиотеки, поэтому перемещаем jar библиотеку в папку lib и подключаем к проекту, в Эклипсе это Project->Preferences->Java Build Path->Libraries->Add Jars… далее во вкладке Order and Export нужно убедиться, что не установлен чекбокс, потому что экспортировать библиотеку нам не нужно, все будет в class файлах.

Теперь берем какой-нибудь класс из декомпилированных исходников приложения, исправляем в нем ошибки компиляции, добавляем, например, показ диалога, чтоб убедиться, что используется именно новый класс. Далее очищаем проект, в Эклипсе это Project->Clean, копируем class файлы в папку bin/classes, собираем проект и все работает!

При следующих сборках проекта нет необходимости его очищать, так что использовать такой способ достаточно удобно. Для облегчения исправления ошибок после декомпиляции я использовал исходники полученные из JD-GUI и JAD, обычно этого было достаточно.

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

Заключение

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

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