Ищем API Пикабу. Часть 2. Подбор инструментария для исследования кода приложения
Первая часть: Сказ о том, как Рыцарь свежего смог достучаться до самого сердечка ИЛИ ищем API Пикабу
Предыдущая часть: Ищем API Пикабу. Часть 1.5. Интермедия
Жил-был маленький Программист, который смог. И вот однажды в глубине интернета он переходил на вражеские сайты — клик-клик-клик-клик, клик-клик-клик-клик, бляяять-бляяять! Программисту был дан приказ найти инструменты для распаковки APK и скачать их на компьютер, который оборонял Windows Defender. Надо ли говорить, что вирусов кругом была тьма тьмущая. Думаешь, это остановило Программиста, который Смог? Да черта с два! Он гуглил себе и гуглил — клик-клик-клик-клик, клик-клик-клик-клик, бляяять-бляяять! Даже когда он скидывал скриншоты местного GUI на Java знакомым Qt-девелоперам и они задыхались от увиденного. У тех из глаз кровища течет вперемешку с соплями. Но, думаешь, это остановило Программиста? Правильно! Он так и гуглил дальше — клик-клик-клик-клик, клик-клик-клик-клик, бляяять-бляяять!
И всё бы ничего… Да гуки выложили на сайте два плагина для IDE. И как раз когда Программист установил его и начал исследовать код — БААМ!!! Не декомпилировалось! Кругом программное месиво, ассемблерный листинг повсюду разбросан, и тут откуда-то выползает мой друг-фронтэндщик Буба в Slack. Ему больно! Но он пишет мне:
— tmax! Я UI/UX не чувствую…
А я ему:
— Буба, у них его нет!
Гляжу, а культи у него дергаются быстро-быстро, вот так! Я говорю:
— Буба! До ближайшего code review 30 недель. Если не можешь позвонить и наорать на них матом, значит нам пизда!
И тут вдруг отовсюду ответные задачи как повыскакивают, а у меня из IDE один блокнот. Но делать то нечего… Надо прорываться! Ааааааааааааааааааааааааааааааааааааааааааааааааааааа!!!!!!!!!
Pull, падла, pull! Мидл tmax живым не сдается! Commit, это тебе за моего друга! Commit! Commit!
Предыдущая мажорная часть закончилась на том, что были перехвачены пакеты между приложением Пикабу на Android и серверами Пикабу. В минорной версии я рассмотрел плюсы и минусы разных способов распарсить содержимое страниц, и остановился на приватном API приложения Пикабу.
В каждом JSON запросе (по крайней мере в тех, которыми грузятся посты) всегда используется четыре ключа - id, hash, token, и new_sort. id всегда равен "iws". Существует несколько аббревиатур, не знаю, что именно означает эта, но сейчас это и не важно. Главное, что она не меняется и она едина для всех запросов. token - это время формирования запроса в миллисекундах, записанное в строку. new_sort всегда равен 1, это похоже на баг, пока я не вижу смысла включать этот ключ в каждый формируемый запрос, но он есть и придётся с этим смириться. Остается только hash, значение которого является закодированным base64 MD5 хешем, например "NWQ2MDRjYmMxY2FhZjNlYmE0MmU4NjA1ZTgzM2Q1NDM=". Да, это спойлер, доказательства будут приведены в конце статьи.
Дальше надо определить, как формируются входные данные для вычисления хеша. Простые комбинации имеющихся в запросе данных к результату не привели, придется реверсить приложение и искать алгоритм формирования исходных данных. Если что, то я вообще не умею в Android, но имею небольшой опыт обратной разработки и анализа приложений, собранных с помощью C/С++ с использованием IDA Pro. Так как IDA является именно интерактивным дизассемблером (Interactive Disassember), то я бы хотел получить исходники в любом виде, при условии, что у меня будет возможность переименовывать функции, переменные, параметры функций, конструкторы, классы и оставлять комментарии. Ну, собственно, не очень много требований, правда?
Хуй там плавал. Спойлер - я не нашел ни одной полноценной утилиты, которая покрыла бы все мои потребности на 100%. Но пиздеть - не мешки ворочать, поехали разбираться. Что делает программист, когда ныряет в свежее неизвестную область? Правильно, идет яростно гуглить, гуглить вдвойне - за ноябрь и за декабрь.
(С учетом вышеприведенной ссылки, данный мем выглядит чуть-чуть по-другому. Одобрям-с)
Немного расскажу про APKTool, которым я перепаковывал APK. Да, эта маленькая утилитка полностью декомпилировала APK и позволила собрать его назад. Однако, весь код приложения, который хранится в .dex файлах в виде инструкций для виртуальной машины Dalvik, она преобразовала в формат smali – это те же самые инструкции, только в текстовом виде ибо smali – местный ассемблер. Ассемблерный листинг - это пиздец, товарищи. Нет, он, разумеется, ощутимо проще ассемблера x86/x86_64, но использовать его для какого-либо продвинутого анализа могут только отцы. У меня на это нет ни времени, ни желания, хотя в конце первой статьи я написал, что надо в нем разобраться. Оказалось, что один из способов пропатчить код приложения - это ручками писать на smali, а затем результат упаковывать назад. Лучше, чем байткод напрямую править (а байткод - это единственный способ патчить native приложения/библиотеки). Пока разбирался, то нагуглил Java Decompiler и понеслась душа в рай. Вместо этой статьи должен был выйти туториал по анализу на основе smali, но ну его на хер, есть же гораздо более читаемый Java :> Правда, анализ пока немного не согласован с начальством, да и вообще, сабж вызвал горение жопы, так что я обязан вам все рассказать. Что вы там кричите с галёрки? Есть еще способы? Frida? Meh, оставьте себе эту хипстерскую дрянь перспективную штучку (я нашёл её много позже и не пробовал).
Вот в этом месте раньше начинался подробный разбор всех утилит, что я перекачал/пересобрал/перепробовал. Я рассмотрел примерно 2/3 заготовленных программ и за каким-то хуем решил прогуглить, вдруг, на Пикабу уже был подобный разбор приложений. И знаете, что? Правильно, я наткнулся на статью на Дзене и вбил в гугл одно рандомное предложение из той статьи.
А я-то такой, весь из себя в Дольче и Габбане, ковырял англоязычные статьи, думал «какой же я сейчас охуенный контент подвезу, почти подробный разбор найденного мной ПО для декомпиляции на русском». Пиздец (лиса продолжает игнорировать слово "пиздец" и предлагает заменить его на "эпизодец". В этом что-то есть...). Выделенная статья на скриншоте является исходником и доступна в вебархиве. Она датируется 05.2016, потом её спиздили на imhacker, потом на bhf и только потом этот дремучий баян-бабаян три года спустя оказался на Дзене. С минимальными изменениями и ссылками на файлы в сети TOR, где она и родилась, лол. И что теперь, предлагаете моё изложение написать сюда? Чем этот пост лучше? Ничем, увы. Всё ПО, что я попробовал, так или иначе встречается там. Более того, в статье упоминается другой декомпилятор dex, enjarify. Я с ним не сталкивался, но проверю его за кадром. Если он окажется лучше, заберу себе вместо dex2jar. Фана ради стоит заметить, что последние правки dex2jar свежее, чем у enjarify, хотя в той статье ситуация как раз наоборот, надо протестировать. Вот так я словил дизмораль и к хуям снёс всё, что касалось разбора приложений.
_____________________________
Что дальше? Я нашел две рабочие конфигурации. Первая:
- консольная jadx, которая сразу выплёвывает .java, но делает это не на все 100%;
- Eclipse. Нахуй-нахуй-нахуй, тьфу блять. Хватит ебать труп, оставьте его! Бох накажэт, накааажэт!
- IntelliJ IDEA. IDE богов с нормально работающим рефакторингом с возможностью вести разработку Android приложений.
Вторая конфигурация:
- 7-zip, чтобы вытащить .dex файлы;
- dex2jar, чтобы из .dex файлов получить .jar-архивы с .сlass;
- Опять 7-zip, чтобы объединить полученные .jar-архивы в один, ибо декомпилятор должен работать сразу со всеми .class файлами, чтобы не возникало проблем с вызовом отсутствующих функций вследствие независимой обработки одного .jar за раз (я на эту проблему не наткнулся, так как сразу начал упаковывать в один файл по этой надуманной причине);
- fernflower, декомпилятор, поддерживаемый Jet Brains и встроенный в IntelliJ IDEA, но который можно скачать и собрать отдельно, чтобы была возможность запускать на пачке файлов (IDE позволяет работать только с одним файлом за раз в режиме read-only). Преобразует .jar с .class-ами на борту в .jar с .java;
- IntelliJ IDEA.
Первая конфигурация лайтовая, но jadx умеет читать метаданные Kotlin (кот с лампой, гы), что в случае нашего приложения дает такой нехуёвый результат в виде большого числа декодированных имен классов. Вторая же конфигурация длиннее, сложнее и требует сборки fernflower вручную (которая без костылей не обошлась, блять), но дает более качественный код, декомпилируя те методы, которые не взял jadx.
Ну и, собственно, пара скриншотов, чтобы вы не думали, что я пиздобол. Вытащенные из .apk .dex-файлы + полученные из них .jar-архивы. combined.jar содержит в себе все содержимое из прочих .jar-архивов.
Параметры для запуска fernflower, которые я использовал на combined.jar (да, компилятор зависал на каких-то функциях, я ему урезал время обработки до 30 секунд):
java -jar fernflower.jar -dgs=1 -mpm=30 -ren=1 combined.jar fernflower_out
Ну и скриншот функции, в которой собирается запрос (уже отрефакторенный):
А еще я оказался прав. Хеш считается как MD5 + base64:
На момент написания вот ЭТОГО слова я полностью знаю, как формировать структуру данных для алгоритма хеширования. Только что я удалил ту часть статьи, о которой упоминал выше, время было потрачено впустую на никому не нужный анализ ПО, горящая жопа была потушена дизморалью (рекомендую), настроение ниже плинтуса.
Благодарю за внимание, знаю, что читать длиннопосты сложно. Я стараюсь сжимать инфу. Чуточку доброты не помешает никому.