В прошлых статьях (первая часть, вторая часть) мы узнали, насколько действительно легко взломать и модифицировать приложение для Android. Однако не всегда все бывает так просто. Иногда разработчики применяют обфускаторы и системы шифрования, которые могут существенно осложнить работу реверсера, поэтому сегодня мы поговорим о том, как разобраться в намеренно запутанном коде, а заодно взломаем еще одно приложение.
WARNING
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.Обфускаторы
На самом деле ты уже должен быть знаком как минимум с одним методом обфускации (запутывания) кода. В прошлой статье мы внедряли зловредную функциональность в WhatsApp, и если ты внимательно читал статью и сам пробовал декомпилировать WhatsApp, то наверняка заметил, что большинство классов приложения, почти все его методы и переменные имеют странные имена: aa, ab либо что-то вроде 2F323988C, если смотреть код с помощью декомпилятора jadx.
Это и есть обфускация, и я могу с полной уверенностью утверждать, что проделана она с помощью инструмента ProGuard из комплекта Android Studio. Именно он выдает на выходе такие странные имена классов, методов и переменных, а кроме того, удаляет неиспользуемый код и оптимизирует некоторые участки приложения с помощью инлайнинга методов.
Пропущенный через ProGuard код более компактен, занимает меньше памяти и намного более сложен для понимания. Но только в том случае, если это большое приложение. Разобраться, что делает простой обфусцированный код, очень легко:
public int a(int a, int b) {
return a + b;
}Но представь, если из подобных буквенных, цифровых или буквенно-цифровых обозначений (ProGuard позволяет использовать любой словарь для генерации идентификаторов) будет состоять громоздкое приложение в десятки тысяч строк кода:
if (this.f6259xa29f3207 != null) {
this.f6259xa29f3207.m9502x15f0e18c(false);
this.f6259xa29f3207 = null;
}
if (this.f6269x98c88933 != null) {
this.f6269x98c88933.m9388x97b0a138();
this.f6269x98c88933 = null;
}И так на тысячи строк вперед, а дальше твой декомпилятор может поперхнуться кодом и выдать вместо Java нечто вроде этого:
/* JADX WARNING: inconsistent code. */
/* Code decompiled incorrectly, please refer to instructions dump. */
private synchronized void m8713x6e6c3e67() {
/*
r16 = this;
r14 = 0;
r7 = 2;
r9 = 0;
r12 = 500; // 0x1f4 float:7.0E-43 double:2.47E-321;
r6 = 1;
...Недурно, не правда ли? А теперь представь, что эти строки состоят не из обычных символов алфавита, а из символов Unicode (так делает DexGuard, коммерческая версия ProGuard) или наборов вроде l1ll1, повторяющихся раз этак пятьдесят. Разработчик вполне может применить и более мощные средства обфускации, нашпиговав приложение бессмысленным кодом. Такой код не будет выполнять никаких полезных функций, но направит тебя совершенно не в ту сторону, что грозит как минимум потерей времени.
Не желая его терять, ты можешь начать с поиска строк, которые приведут тебя к цели: это могут быть различные идентификаторы, с помощью которых приложение регистрирует себя на сервере, строки, записываемые в конфиг при оплате, пароли и так далее. Однако вместо строк ты вполне можешь увидеть нечто вроде этого:
private static final byte[] zb = new byte[]{110, -49, 71, -112, 33, -6, -12, 12, -25, -8, -33, 47, 17, -4, -82, 82, 4, -74, 33, -35, 18, 7, -25, 31};Это зашифрованная строка, которая расшифровывается во время исполнения приложения. Такую защиту предлагают DexGuard, Allatory и многие другие обфускаторы. Она действительно способна остановить очень многих, но соль в том, что если есть зашифрованный текст, значит, в коде должен быть и дешифратор. Его очень легко найти с помощью поиска по имени переменной (в данном случае zb). При каждом ее использовании всегда будет вызываться метод, дешифрующий строку. Выглядеть это может примерно так:
a.a(zb)Здесь метод a() класса a и есть дешифратор. Поэтому, чтобы узнать, что внутри зашифрованной строки, нужно просто добавить в дизассемблированный код приложения вызов функции Log.d("DEBUG", a.a(zb)) и собрать его обратно (как это сделать, описано в первой статье цикла). После запуска приложение само выдаст в лог дешифрованную строку. Лог можно просмотреть либо подключив смартфон к компу и вызвав команду adb logcat, либо с помощью приложения CatLog для Android (требует root).
Нередко, правда, придется попотеть, чтобы найти дешифратор. Он может быть встроен во вполне безобидную функцию и дешифровать строку неявно, может состоять из нескольких функций, которые вызываются на разных этапах работы со строкой. Сама зашифрованная строка может быть разбита на несколько блоков, которые собираются вместе во время исполнения приложения. Но самый шик — это класс-дешифратор внутри массива!
DexGuard имеет функцию скрытия классов, которая работает следующим образом. Байт-код скрываемого класса извлекается из приложения, сжимается с помощью алгоритма Gzip и записывается обратно в приложение в форме массива байтов (byte[]). Далее в приложение внедряется загрузчик, который извлекает код класса из массива и с помощью рефлексии создает на его основе объект, а затем вызывает нужные методы. И конечно же, DexGuard использует этот трюк для скрытия дешифратора, а также кода других классов по желанию разработчика. Более того, скрытые в массивах классы могут быть зашифрованы с помощью скрытого в другом массиве дешифратора!
Так что, если ты имеешь дело с приложением, имена классов в котором написаны на китайском или языке смайликов, а по коду разбросаны странные массивы длиной от нескольких сот элементов до десятков тысяч, знай — здесь поработал DexGuard.
С рефлексией вместо прямого вызова методов объекта ты можешь столкнуться и в других обстоятельствах, не связанных со скрытием классов. Рефлексия может быть использована просто для обфускации (как в случае с обфускатором Allatory). Тогда вместо такого кода:
StatusBarManager a = (StatusBarManager) context.getSystemService("statusbar");
statusBarManager.expandNotificationsPanel();ты увидишь нечто вроде этого:
Object a = context.getSystemService("statusbar");
Class.forName("android.app.StatusBarManager");
Method c = b.getMethod("expandNotificationsPanel");
c.invoke(a);А если используется шифрование — это:
Object a = context.getSystemService(z.z("c3RhdHVzYmFyCg=="));
Class<?> b = Class.forName(z.z("YW5kcm9pZC5hcHAuU3RhdHVzQmFyTWFuYWdlcgo="));
Method c = b.getMethod(z.z(ZXhwYW5kTm90aWZpY2F0aW9uc1BhbmVsCg==));
c.invoke(a);В данном случае я закодировал строки в Base64, поэтому их легко «раскодировать» с помощью команды
$ echo строка | base64 -dНо в реальном приложении тебе, скорее всего, придется расшифровать все эти строки с помощью описанного выше способа просто для того, чтобы понять, какие объекты и методы вызывает приложение в своей работе.
Упаковщики
А еще есть упаковщики. Это другой вид защиты, основанный не на запутывании кода, а на его полном скрытии от глаз реверсера. Работает он так. Оригинальный файл classes.dex (содержащий код приложения) переименовывается, шифруется и перемещается в другой каталог внутри пакета APK (это может быть каталог assets, res или любой другой). Место оригинального classes.dex занимает распаковщик, задача которого — загрузить в память оригинальный classes.dex, расшифровать его и передать ему управление. Для усложнения жизни реверсера основная логика распаковщика реализуется на языке си, который компилируется в нативный код ARM с применением средств обфускации и защиты от отладки (gdb, ptrace).
Хороший упаковщик создает очень большие проблемы для анализа кода приложения. В ряде случаев единственный действенный вариант борьбы с ними — это снятие дампа памяти процесса и извлечение из него уже расшифрованного кода classes.dex. Но есть и хорошие новости: упаковщик накладывает серьезные ограничения на функциональность приложения, приводит к несовместимостям и увеличенному расходу памяти. Так что разработчики обычных приложений используют упаковщики редко, зато их очень любят создатели разного рода троянов и вирусов.
Вычислить наличие упаковщика в APK совсем нетрудно. Для этого достаточно взглянуть на содержимое каталога lib/armeabi. Если ты найдешь в нем файл libapkprotect2.so, значит, применен упаковщик ApkProtect, файл libsecexe.so — Bangle, libexecmain.so — ljiami.
Деобфускаторы
Как видишь, инструментов обмануть тебя и отбить желание расковыривать приложение у разработчиков предостаточно, поэтому и ты должен быть вооружен. В первую очередь нужен хороший декомпилятор. На всем протяжении цикла мы использовали бесплатный jadx, вполне неплохо справляющийся с этой задачей. Кроме этого, он имеет встроенный деобфускатор, трансформирующий идентификаторы вида a, az, l1l1l1l1... или состоящие из символов Unicode в цифро-буквенные идентификаторы, уникальные для всего приложения. Это позволяет никогда не спутать метод a() класса a с методом a() класса b и легко находить нужные идентификаторы с помощью глобального поиска.
Также тебе понадобится инструмент для дампа информации о пакете. Не такой информации, как его содержимое и дата сборки, а информации об используемых в пакете средствах обфускации и защиты. В первую очередь стоит обратить внимание на ApkDetecter. Также можно попробовать APKiD.
Оба инструмента должны показывать, был ли применен тот или иной обфускатор или упаковщик в отношении приложения, но часто не показывают ничего. Это вполне закономерно, обфускаторы эволюционируют, меняя логику своей работы, приемы обфускации и скрытия от подобных инструментов.
По этой же причине нередко оказываются бессильны и деобфускаторы, такие как Java Deobfuscator и Simplify. Но это совсем не значит, что их не стоит применять. Java Deobfuscator работает исключительно с байт-кодом Java, поэтому перед тем, как его использовать, APK нужно перегнать в JAR с помощью dex2jar.
Далее следует натравить на полученный JAR-файл Java Deobfuscator с указанием используемого «трансформера»:
$ java -jar deobfuscator.jar -input Приложение.jar -output Приложение_после_деобфускации.jar -transformer allatori.StringEncryptionTransformer - path ~/Android/android-sdk-linux/platforms/android-23/android.jarДанная команда применит к приложению трансформер allatori.StringEncryptionTransformer, расшифровывающий зашифрованные с помощью Allatory строки, и запишет результат в Приложениепоследеобфускации.jar. После этого приложение можно декомпилировать, но не с помощью jadx (он работает только с байт-кодом Android Dalvik), а, например, с помощью JD-GUI.
Java Deobfuscator поддерживает более десятка трансформеров, позволяющих расшифровывать строки, зашифрованные другими обфускаторами, конвертировать вызовы с помощью рефлексии в обычные, удалять мертвый код и так далее. Поэтому можно поэкспериментировать.
Если же Java Deobfuscator не дал результатов, стоит попробовать Simplify. Это так называемый динамический деобфускатор. Он не анализирует байт-код, пытаясь найти в нем следы работы обфускаторов и отменить внесенные ими изменения, как это делает Java Deobfuscator. Вместо этого он запускает дизассемблированный код smali внутри виртуальной машины, позволяя приложению самостоятельно расшифровать строки, затем удаляет мертвый неиспользуемый код и рефлексию. На выходе ты получишь dex-файл, который можно декомпилировать с помощью jadx.
Использовать Simplify довольно просто:
$ java -jar simplify.jar -i каталог_с_файлами_smali -o classes.dex
Но как быть с упаковщиками? Для этого есть инструмент Kisskiss. Для его работы нужен смартфон с правами root и активированным режимом отладки (ADB) в режиме root (в CyanogenMod можно включить в «Режиме для разработчиков»). Также на компе понадобится команда adb:
$ sudo apt-get install android-tools-adb
$ sudo adb devicesДалее Kisskiss необходимо установить на смартфон:
$ wget https://github.com/strazzere/android-unpacker/archive/master.zip
$ unzip master.zip
$ cd android-unpacker-master/native-unpacker
$ sudo apt-get install build-essential
$ make
$ make installЗапустить нужное приложение на смартфоне и выполнить команду (на компе)
$ adb shell /data/local/tmp/kisskiss имя.пакета.приложенияПосле этого Kisskiss сделает дамп памяти процесса и запишет его в odex-файл. Его можно сконвертировать в dex с помощью уже знакомого нам baksmali:
$ adb pull /system/framework/arm/boot.oat /tmp/framework/boot.oat
$ baksmali -c boot.oat -d /tmp/framework -x файл.odexИ декомпилировать с помощью jadx.
Небольшой (на самом деле большой) пример
Ну и в заключение приведу небольшой пример взлома обфусцированного приложения. Он не очень сложный, без шифрования и упаковки, но позволяет понять логику работы с кодом, по которому трудно ориентироваться из-за измененных идентификаторов. В этот раз мы будем работать с EZ Folder Player, а именно уберем из него рекламу.
Для начала установим приложение на смартфон и внимательно проследим за тем, в каких случаях и на каких экранах появляется реклама. Нетрудно заметить, что она есть только на экране выбора файла. Это важная информация, которая нам очень пригодится. Теперь попробуем включить режим полета, завершить приложение и вновь запустить его. Реклама полностью исчезает. Это тоже важно, приложение явно умеет самостоятельно включать и выключать показ рекламы, а значит, все, что нам требуется, — это просто найти данный код и либо удалить «включатель» рекламы, либо самостоятельно вызвать «выключатель».
Теперь скачиваем приложение на комп с помощью APKPure, кладем его в каталог ~/tmp и переименовываем в ez.apk для удобства работы. Открываем пакет в jadx-gui и видим множество каталогов (Java-пакетов). Нужный нам пакет носит имя самого приложения: com.dp.ezfolderplayer.free. Открываем его, внутри множество классов с именами вида C0770p, C0763i и так далее, почти все переменные и методы любого класса носят имена типа f2881, f2284:
Не внушает оптимизма, правда? Совсем непонятно, с чего начать. Точнее, было бы непонятно, если бы мы не знали, что реклама отображается исключительно на экране выбора файла. Проматываем вниз и видим нужный нам класс FilesActivity.
Но почему он не обфусцирован? По простой причине: каждый экран приложения в Android — это так называемая активность (activity), а все активности должны быть явно перечислены в манифесте приложения — Manifest.xml. Если бы обфускатор изменил имя класса-активности, Android просто не смог бы его найти и приложение вывалилось бы с ошибкой.
Открываем FilesActivity и сразу смотрим, работает ли он с провайдером рекламы напрямую (или же делает это через другой класс либо с помощью рефлексии). Для этого взглянем на директивы import:
import com.google.android.gms.ads.AdRequest.Builder;
import com.google.android.gms.ads.AdSize;
import com.google.android.gms.ads.AdView;
import com.google.android.gms.ads.search.SearchAdRequest;Да, класс явно вызывает методы пакета com.google.android.gms.ads (стандартный гугловский провайдер рекламы), иначе зачем бы ему его импортировать. Осталось найти место, где он это делает, и просто изменить или удалить код так, чтобы рекламы не было видно. Ближе к концу кода находим это:
private void m4989q() {
this.f2493K = new AdView(this);
this.f2493K.setAdUnitId("ca-app-pub-1006786053546700/8070576705");
this.f2493K.setAdSize(AdSize.SMART_BANNER);
this.f2493K.setVisibility(8);
this.f2493K.setAdListener(new C0766l(this));
((LinearLayout) findViewById(2131689639)).addView(this.f2493K);
this.f2493K.loadAd(new Builder().build());
}Несмотря на применение обфускации, код вполне понятный, мы видим нормальные имена классов (AdView, AdSize, LinearLyout) и методов (setAdUnitId, findViewById). Легко можем понять, что делает этот код: создает новый графический элемент (View) с рекламой, настраивает его вид, а затем загружает в него рекламное объявление. Вопрос только в том, почему мы это видим? Обфускатор настолько плох и не справляется со своей работой?
На самом деле все намного проще: обфускатор работает исключительно с кодом самого приложения и поэтому неспособен запутать код внешних для него классов (а это классы пакета com.google.android.gms.ads и все системные классы). Поэтому зачастую логику работы обфусцированного кода довольно легко проследить по вызовам внешних API. В случае с EZ Folder Player мы не знаем имя загружающего рекламу метода (m4989q) и имя объекта, хранящего View (f2394K), но видим все его методы и обращения к системным API (тот же findViewById), что позволяет сделать вывод о том, зачем весь этот код.
А теперь о том, как все это отключить. Самый простой вариант — просто удалить весь код метода, но это может привести к ошибкам в других участках кода, которые, возможно, обращаются к объекту f2493K. Вместо этого мы пойдем немного другим путем. Обрати внимание на пятую строку кода. Она вызывает метод setVisibility объекта f2493K, который, в свою очередь, хранит View рекламного блока. Метод setVisibility позволяет настраивать отображение View, указав одно из возможных состояний с помощью числа. Если мы взглянем на справку Android, то узнаем, что 8 означает: View должен быть полностью убран с экрана.
Другими словами, данный код формирует View с рекламным блоком, а затем сам же его убирает с экрана. Но зачем? Затем, что нет смысла показывать рекламный блок, если он еще не загружен (помнишь исчезновение рекламы в режиме полета?). Но как приложение узнает, что реклама загрузилась? Согласно документации — с помощью AdListener: разработчик создает класс-наследник AdListener, создает рекламный View, вызывает его метод setAdListener, в качестве аргумента передавая ему объект класса-наследника AdListener, и вызывает loadAd для загрузки рекламы. Когда реклама загрузится, будет вызван метод onAdLoaded() класса-наследника AdListener.
А теперь смотри на строку:
this.f2493K.setAdListener(new C0766l(this));C0766l не может быть ничем иным, кроме класса-наследника AdListener. Открываем его в jadx и видим:
public void onAdLoaded() {
this.f2868a.f2493K.setVisibility(0);
}Бинго! Всего одна строка кода, которая делает рекламный View видимым (значение 0). Если мы ее удалим, View останется невидим на все время работы приложения.
Но вот незадача: в дизассемблированном с помощью apktool коде smali нет класса C0766l. Такой идентификатор мы видим только в jadx, потому что он переименовал класс. Но зато он оставил для нас комментарий касательно настоящего имени класса:
Открываем ez/smali/com/dp/ezfolderplayer/free/l.smali и видим следующий код:
.method public onAdLoaded()V
.locals 2
.prologue
.line 927
iget-object v0, p0, Lcom/dp/ezfolderplayer/free/l;->a:Lcom/dp/ezfolderplayer/free/FilesActivity;
invoke-static {v0}, Lcom/dp/ezfolderplayer/free/FilesActivity;->p(Lcom/dp/ezfolderplayer/free/FilesActivity;)Lcom/google/android/gms/ads/AdView;
move-result-object v0
const/4 v1, 0x0
invoke-virtual {v0, v1}, Lcom/google/android/gms/ads/AdView;->setVisibility(I)V
.line 928
return-void
.end methodЭто и есть строка «this.f2868a.f2493K.setVisibility(0);». Чтобы убрать ее, необходимо удалить почти весь метод, оставив только четыре строки:
.method public onAdLoaded()V
.locals 0
return-void
.end methodОстается только собрать APK и установить на девайс:
$ cd ~/tmp
$ apktool b ez
$ mv ez/dist/ez.apk ez-noads.apk
$ sign ez-noads.s.apk
 |
 |
Выводы
Несмотря на существование большого количества обфускаторов и других средств защиты приложений, подавляющее большинство разработчиков используют исключительно встроенный в Android Studio ProGuard. Разобраться в коде приложения, обфусцированного с его помощью, совсем несложно, но и разбираться в работе более продвинутых обфускаторов тоже необходимо. Хотя бы для того, чтобы уметь реверсить вирусы. Ты же не собираешься заниматься варезом, правда?
