Тут обычно никаких проблем нет. Банк в любом случае заключает договор с разработчиками приложения, которые обязаны не встраивать бэкдор в банковское ПО. В добавок к этому, банк может заказать дополнительный аудит у сторонней компании. Она может выявить потенциальные проблемы.
Если я неправильно понял ваш вопрос, то поправьте меня.
Я там предложил два варианта, один из них как раз взять сгенерированный APK-файл и изучить его. Как это делать, мне кажется, не имеет значения. У каждого свой способ. Я, например, использую утилиту apkx (которая все переводит в Java из коробки). Пример с APKTOOL был взят, потому что он каноничный + там могут быть атрибуты, которые из Java (после jadx) могут быть не видны.
Про R8 не читал, как я понял, это быстрый ProGuard. Мне кажется, в мире обфускации он погоды не сделает, как минимум сейчас.
Про JS все верно. В статье я говорю про Android-приложения, потому что в техническом плане они могут много всего интересного сделать (SSL, потоки, NFC, WiFi и т.д.), чем обычные Web-страницы. Поэтому тут и появляется важная авторская логика кода (хотя и далеко не всегда) :)
Про 15 минут, часов, дней. Выше писал, что «уровень защищенности приложения должен быть всегда выше, чем ценность взлома самого приложения». Многие просто не станут тратить 15 дней своего времени на ваше приложение. Это и есть одна из целей обфускации.
Идея в том, что затраченные усилия должны соответствовать результату. Или перефразируя: уровень защищенности приложения должен быть всегда выше, чем ценность взлома самого приложения. Поэтому, с одной стороны, приложение взломать всегда можно (в случае с Denuvo), с другой стороны — нельзя ни для кого быть «открытой книгой для изучения». Это и есть цель статьи.
В случае со сниффингом трафика, можно внедрить pinning-сертификата или генерацию подписи тела. Вы отсеите значительную часть реверсеров, которые будут пытаться прослушивать запросы.
Так, эта история была бы у mcdonalds и у вас. Сейчас же она у всего habr-а. Может быть у этой «франшизы» просто нет ресурсов и программистов закрыть ее, может быть люди не имеют необходимых знаний для понимания этой уязвимости. Боюсь, что эта история не закончится увольнением рядовых администраторов сайта (что уже достаточно печально).
Кстати, если нужно делать js на странице, то TamperMonkey может помочь чем-нибудь. Тут речь идет об исполнении js-кода на странице по фильтру.
Проект открытый, поэтому может написать расширение для перехвата fetch или подобного функционала? WebWorkers с этим вполне могут работать. Уверен, что Chrome на это способен.
Лучше не стоит писать подобный код. Здесь может помочь злоумышленнику "Атака удлинением сообщения". То есть ваш secret_key просто «проигнорируется» при проверке.
Статья действительно интересная. Но мне кажется, что данную задачу можно выполнить раза в 2 быстрее, если использовать Burp.
Я думаю, что инструмент для дебага, для «трудных» авторизаций. Жду продолжения. :)
Мы рассказали немного в статье о безопасности. Кстати, Eddystone отличается от других продуктов как раз своим применением шифров. Нельзя будет просто взять и подделать маячок, так как он для других передает кучу «кракозябр».
Если я неправильно понял ваш вопрос, то поправьте меня.
Я там предложил два варианта, один из них как раз взять сгенерированный APK-файл и изучить его. Как это делать, мне кажется, не имеет значения. У каждого свой способ. Я, например, использую утилиту apkx (которая все переводит в Java из коробки). Пример с APKTOOL был взят, потому что он каноничный + там могут быть атрибуты, которые из Java (после jadx) могут быть не видны.
Про R8 не читал, как я понял, это быстрый ProGuard. Мне кажется, в мире обфускации он погоды не сделает, как минимум сейчас.
И, кстати, если приложение «фонарик» обфусцировано, то это как минимум подозрительно.
Про 15 минут, часов, дней. Выше писал, что «уровень защищенности приложения должен быть всегда выше, чем ценность взлома самого приложения». Многие просто не станут тратить 15 дней своего времени на ваше приложение. Это и есть одна из целей обфускации.
А так да, все достается.
Но в данном кейсе больше маневров для антиреверса. Плюс такой способ спрятать менее очевидный.
В случае со сниффингом трафика, можно внедрить pinning-сертификата или генерацию подписи тела. Вы отсеите значительную часть реверсеров, которые будут пытаться прослушивать запросы.
Тут конечно очень странная ситуация со «взломом». Может было лучше, если никто бы об этом не знал?
Проект открытый, поэтому может написать расширение для перехвата fetch или подобного функционала? WebWorkers с этим вполне могут работать. Уверен, что Chrome на это способен.
Я думаю, что инструмент для дебага, для «трудных» авторизаций. Жду продолжения. :)
А так, очень достойная реализация идеи с маячками.