Секреты под защитой: как мы спрятали ключи приложения с помощью Gradle-плагина

[dkfbm]

Конечно это не серебряная пуля и при желании, проанализировав декомпилированный код, можно прочитать скрытые секреты в рантайме, вынеся их в другую среду исполнения

Да не нужно ничего анализировать и выносить. Трафик пропускается через любой прокси (Charles, Wireshark, whatever) и все ключи как на ладони. А если это веб, то DevTools в браузере открыть достаточно.

но это куда сложнее, если бы они лежали в открытом виде

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

[house2008]

Трафик пропускается через любой прокси

Да уже многие давно на пиннинге сидят, сами серты и новые домены подтягиваются по мере необходимости с сервера (если домен заблокировал провайдер или сертификат истек).

[LuigiVampa]

О, спасибо большое за интересную тему! Я довольно глубоко погружён в тему безопасности в Андроиде, и много игрался, в том числе, и с тем, чтобы насколько это возможно скрывать критически важные значения секретов внутри приложения, если их локального хранения никак нельзя избежать. Тоже горячо сам рекомендую всем скрывать значимые строки в приложениях, раз уж за нас этого не делает ни Гугл, ни proguard/r8, а работу реверсеров, автоматизаторов и разных других людей это упрощает на порядок.

Хотел набросить пару мыслей и вопросов по результатам прочтения статьи.

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

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

(2) Вторая мысль аналогична предыдущей, но только теперь по стороне ДЕкомпиляторов. Коммерческие декомпиляторы, например JEB, содержат целый ряд модулей которые также находят и оптимизируют уже прямо dex-байткод, если видят что он без сайдэффектов, и часто могут некоторые промежуточные значения безопасно предвычислить. Модули включают в себя раскрутчики безсайдэффектных методов возвращающих булеаны, строки, разные оптимизаторы, конкатенаторы, дерефлекторы, и т.д. Довольно нередко JEB может автоматически раскрутить подобные защиты, и реверсер даже не узнает что они были в приложении. Мне в своё время даже пришлось посидеть, подумать, попрорабатывать разные подходы для того, чтобы не давать работать по байткоду подобным оптимизаторам.

Интересно узнать, довелось ли вам проверить решение на устойчивость к подобным инструментам?

(3) Третья мысль, или скорее наивный вопрос - не думали насчёт того, чтобы воспользоваться готовыми решениями? Я вот пробовал и всем рекомендую https://github.com/LSPosed/LSParanoid - отличный простой и хорошо поддерживаемый gradle плагин, который работает полностью локально - сам модифицирует байткод, заменяя опкоды создания строковых констант на статические инвоуки к классу, который он генерит и вносит в декс сам. Получается, что ничего самому не нужно тянуть, собирать, подменять. Достаточно только отметить в конфиге и/или аннотациями строки, которые необходимо скрыть и всё. Результат - очень даже неплох.

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

Спасибо большое ещё раз за статью! Было бы здорово видеть на Хабре темы про безопасность мобилок почаще