Pull to refresh

Comments 15

В конечном итоге любая обфуcкация упирается в мотивированность реверсера, что неоднократно доказали взломы сложнейших защит, таких как Denuvo.
Да и если приложение не offline, то болшую часть информации можно получить сниффингом трафика.
Идея в том, что затраченные усилия должны соответствовать результату. Или перефразируя: уровень защищенности приложения должен быть всегда выше, чем ценность взлома самого приложения. Поэтому, с одной стороны, приложение взломать всегда можно (в случае с Denuvo), с другой стороны — нельзя ни для кого быть «открытой книгой для изучения». Это и есть цель статьи.

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

Но в данном кейсе больше маневров для антиреверса. Плюс такой способ спрятать менее очевидный.
Код приложений на Android смотрел мало, но вот за обфускацию-минификацию JS-скриптов в вебе очень хочется поотрывать руки. Бывает, упрёшься в какой-нибудь упакованный-минифицированный JS-файл — и час ковыряешься, чтобы понять, что это за зверь, что он делает и на кой чёрт он там нужен.

Думаю, если бы занимался Андроидом, то хотелось бы поотрывать руки и здешним обфускаторам.

Если у вас есть ОМГ ВАЖНАЯ СЕКРЕТНАЯ УТЮТЮТЮТЮ логика — так и вычисляйте её на бэкенде, нечего её на клиентскую часть пихать. А на клиенте оставьте прозрачный и простой код.

Однако, бывает, что бизнес-логика принуждает разработчиков к хранению токенов, ключей и специфических элементов логики кода внутри приложения. Надеюсь, эта статья поможет вам, если вы не хотите делиться такими чувствительными данными и быть “открытой книгой” для ресерчеров.
Так после обфускации все «токены, ключи и специфические элементы логики» по-прежнему остаются на клиенте. Просто вместо 15 минут нужно, скажем, 15 часов. Ну или 15 дней. Это как ключ от двери не рядом на гвоздик повесить, а положить под коврик.
Про JS все верно. В статье я говорю про Android-приложения, потому что в техническом плане они могут много всего интересного сделать (SSL, потоки, NFC, WiFi и т.д.), чем обычные Web-страницы. Поэтому тут и появляется важная авторская логика кода (хотя и далеко не всегда) :)

Про 15 минут, часов, дней. Выше писал, что «уровень защищенности приложения должен быть всегда выше, чем ценность взлома самого приложения». Многие просто не станут тратить 15 дней своего времени на ваше приложение. Это и есть одна из целей обфускации.

А так да, все достается.
Грустно, что становится всё сложнее определить, что это за непонятный кусок обфусцированного кода внутри приложения «фонарик» — то ли это разработчики очень пекутся о суперэффективных алгоритмах включения лампочки, то ли это злоумышленники бэкдор встроили или майнер. Опять же, у исследователей безопасности уходит куча времени на анализ этой фигни вместо разбора кода.

И всё ради сомнительно-призрачной возможности «а вдруг это нам поможет...».
Да, очень много времени тратится на анализ лишнего (суровая правда).

И, кстати, если приложение «фонарик» обфусцировано, то это как минимум подозрительно.
А если приложение «Пофигбанк» обфусцировано (и разработчик контрактный, а не сам банк)? Кому доверять?
Тут обычно никаких проблем нет. Банк в любом случае заключает договор с разработчиками приложения, которые обязаны не встраивать бэкдор в банковское ПО. В добавок к этому, банк может заказать дополнительный аудит у сторонней компании. Она может выявить потенциальные проблемы.

Если я неправильно понял ваш вопрос, то поправьте меня.
> Как изучать APK-файл
Вот это не понял. Зачем устанавливать апк, а потом его вытаскивать? Не проще взять исходный апк
Результат аналогичный, но быстрее и удобнее
И насчет smali тоже непонятно, зачем это ковырять, если проще посмотреть на декомпилированные исходники в том же jadx-gui
А так статья в целом интересная, спасибо, есть моменты, которые подчерпнул
Что думаете насчет R8 от гугл?
Спасибо, рад, что статья понравилась.

Я там предложил два варианта, один из них как раз взять сгенерированный APK-файл и изучить его. Как это делать, мне кажется, не имеет значения. У каждого свой способ. Я, например, использую утилиту apkx (которая все переводит в Java из коробки). Пример с APKTOOL был взят, потому что он каноничный + там могут быть атрибуты, которые из Java (после jadx) могут быть не видны.

Про R8 не читал, как я понял, это быстрый ProGuard. Мне кажется, в мире обфускации он погоды не сделает, как минимум сейчас.
что обычно прячут в приложениях.

Трояны?
А почему собственно и нет? :)
Эта строчка есть во многих opensource проектах. Она позволяет просматривать StackTrace при падении приложения. Однако, вытащив “.source” из smali-кода, мы получим всю иерархию проекта с полными названиями классов.

если написать так:
-keepattributes SourceFile
-renamesourcefileattribute SourceFile

то ничего из smali вы не вытащите из атрибута source

жаль что не рассматривали R8, интересно было бы прочитать вашу версию исследований
про него как раз недавно ходил сюда
habr.com/ru/company/redmadrobot/blog/437126

из последнего что изучал/смотрел на тему ProGuard и реверса (рекомендую)
www.youtube.com/watch?v=aBm5iYg7uJU
Sign up to leave a comment.

Articles