Как использование протекторов влияет на безопасность Android-приложений

Введение

Реверс-инжиниринг большинства Android-приложений по-прежнему остается относительно простой задачей: злоумышленнику достаточно воспользоваться бесплатными инструментами для декомпиляции, чтобы получить код, близкий к исходному, и анализировать его в поисках уязвимостей и других потенциальных рисков. Простота этого процесса открывает также широкие возможности для его автоматизации с помощью инструментов загрузки из магазинов приложений и сканеров уязвимостей, выполняющих статический анализ приложения. Усложнить реверс-инжиниринг в достаточной мере способны протекторы мобильных приложений, реализующие различные техники обфускации (запутывания кода), шифрования кода и файлов приложения. Однако на практике подобные механизмы защиты применяются крайне ограниченно, что играет на руку злоумышленникам.

В рамках данного исследования проанализирована эффективность протектора для сокрытия потенциальных уязвимостей и недостатков, а также применяемых защитных механизмов в Android-приложениях. Для анализа специалисты Positive Technologies отобрали 94 наиболее популярных мобильных приложения в отдельных категориях магазина RuStore за август 2025 года.

1. Методология анализа Android-приложений

Для проведения исследования использовались следующие инструменты:

• RuStore — источник приложений для формирования выборки;
• Apkdgo — утилита для загрузки APK-файлов из различных источников;
• Mobile Security Framework (MobSF) — мобильный сканер уязвимостей. Данная платформа завоевала доверие разработчиков и исследователей безопасности благодаря открытой лицензии, поддержке статического анализа, простоте развертывания и регулярным обновлениям. В состав MobSF входит модуль APKiD, который автоматически выполняет сигнатурную проверку на наличие защитных техник;
• PT MAZE — коммерческий протектор от Positive Technologies. Использовалась конфигурация со следующими защитными механизмами:
• обфускация идентификаторов ресурсов;
• обфускация нативной библиотеки;
• шифрование значений ресурсов;
• шифрование сторонних библиотек;
• шифрование строк;
• упаковка и шифрование DEX-файлов;
• усиление безопасности SSL/TLS-соединений;
• удаление метаданных Google/Huawei.

Также в данную конфигурацию входили техники RASP (Runtime Application
Self-Protection), направленные на противодействие динамическому анализу. Их влияние не рассматривалось, поскольку исследование сосредоточено на оценке эффективности противодействию статическому анализу.

Рисунок 1. BPMN-диаграмма этапов анализа мобильных приложений

В выборке из 94 приложений были выделены восемь категорий — «Финансы и платежи», «Доставка еды и продуктов», «Развлечения и контент» и другие. Наибольшую долю составила категория «Финансы и платежи» — 20% от общего числа. Такая классификация позволила проанализировать динамику применения защитных техник в разрезе отдельных групп и сравнить эффективность шилдинга в зависимости от категории приложения. Для корректности сравнения результатов ко всем категориям приложений шилдинг применялся с одинаковыми параметрами.

Термин «шилдинг» заимствован из английского выражения mobile application shielding и используется для обозначения защиты мобильных приложений от статического и динамического анализа, реверс-инжиниринга, создания вредоносных клонов и других угроз. Результатом является защищенное приложение.

2. Категории исследованных приложений

2. Анализ выявленных уязвимостей и оценка рисков

При оценке безопасности приложений сканером MobSF были выявлены уязвимости разного уровня риска, недостатки и корректно реализованные меры безопасности:

• High — уязвимости высокого уровня риска, эксплуатация которых может привести к утечке конфиденциальных данных, компрометации приложения или обходу механизмов безопасности. К этой категории относятся ошибки в криптографических алгоритмах, небезопасные сетевые конфигурации, уязвимые параметры приложения и неконтролируемый доступ к данным;

• Medium — уязвимости среднего уровня риска, которые указывают на небезопасные практики разработки и конфигурации, способные при определенных условиях привести к компрометации приложения или утечке данных. К ним относятся, например, использование слабых криптографических алгоритмов, небезопасные операции с файлами и базами данных, уязвимые реализации WebView;

• Info — предупреждения о недостатках, которые могут косвенно повлиять на безопасность, но не влияют на нее напрямую. Отражают детали реализации кода (работа с каталогами, буфером обмена, журналирование, использование криптографических библиотек), сетевых конфигураций и внешних сервисов;

• Secure — успешная реализация защитных мер. Включает проверки на root и отладку, защиту от tapjacking, контроль целостности среды (через специализированные API), SSL-пиннинг и безопасные параметры внешних сервисов.

Тестирование приложений в MobSF выполнялось локально на рабочих станциях специалистов Positive Technologies. Результаты анализа не сохранялись и не публиковались через общедоступный сканер mobsf.live в целях предотвращения возможного раскрытия конфиденциальной информации.

Стоит отметить, что MobSF может генерировать ложноположительные и ложноотрицательные срабатывания по ряду уязвимостей и недостатков. Полученные результаты автоматизированного анализа необходимо проверять вручную. В рамках исследования сравнивались только необработанные отчеты. Верификация обнаруженных уязвимостей не проводилась.

2.1. Динамика количества уязвимостей и мер безопасности

При повторном анализе приложений после использования протектора было выявлено значительное снижение числа обнаруживаемых уязвимостей для всех групп приложений. Хотя элементы категории Info не являются уязвимостями, MobSF учитывает их при расчете итоговой оценки безопасности. Поэтому при общем подсчете количества уязвимостей в выборку были включены категории High, Medium и Info.

Сравнительный анализ показал, что количество уязвимостей, обнаруженных с помощью MobSF, после применения шилдинга сократилось на 40%.

Количество выявляемых уязвимостей после применения шилдинга снизилось во всех категориях: High — на 67%, Medium — на 24%, Info — на 80%. Снижение числа выявляемых уязвимостей связано с повышением уровня защиты приложений: после применения шилдинга часть кода и ресурсов приложения становится недоступной для статического анализа, что затрудняет идентификацию потенциальных уязвимостей.

Рисунок 3. Среднее число выявляемых уязвимостей на одно приложение

Особое внимание следует уделить категории Secure, отражающей количество корректно реализованных мер безопасности. Чем больше обнаруженных элементов в этой категории, тем выше уровень защищенности приложения. После применения шилдинга количество обнаруживаемых защитных механизмов снижается, что связано с изменением их видимости для инструментов анализа. Это приводит к ложноотрицательным результатам в отчетах MobSF: меры безопасности сохраняются, но становятся менее доступными для статического анализа. В среднем зафиксировано сокращение элементов категории Secure на 67%.

Рисунок 4. Среднее число выявляемых механизмов защиты на одно приложение

Сравнительный анализ показал, что результат использования протектора при сокрытии уязвимостей зависит от категории приложения. Наиболее устойчивыми к рискам утечки конфиденциальной информации и компрометации оказались приложения из категорий «Телеком» и «Инструменты и утилиты». Доля уязвимостей высокого уровня риска здесь ниже, чем в других категориях, но не нулевая.

Категории «Маркетплейсы и объявления» и «Финансы и платежи» продемонстрировали умеренные значения по всем типам уязвимостей.

Рисунок 5. Эффективность протектора (доля скрытых уязвимостей)

Приложения из категории «Доставка еды и продуктов» показывают наибольший усредненный эффект сокрытия уязвимостей всех уровней риска — 46%.

Рисунок 6. Среднее количество уязвимостей до и после шилдинга

2.2. Изменение поверхности атаки

Для полноценной оценки защищенности приложений недостаточно учитывать только уязвимости. Помимо них сканер MobSF анализирует дополнительные метрики, формирующие потенциальные векторы атак:

• Hotspot — потенциально небезопасные практики разработки (домены, разрешения, сертификаты), требующие ручной проверки;
• результаты Code Analysis — участки кода приложения, в которых выявлены уязвимости и небезопасные методы;
• вызовы Android API — использование небезопасных функций;
• зависимости SBOM — сканирование сторонних библиотек на наличие известных уязвимостей;
• количество строковых значений;
• анализ поведения (Behavior Analysis) — потенциально опасное поведение приложения;
• обнаруженные секреты;
• обнаруженные домены;
• обнаруженные URL.

Эти метрики позволяют выявить в приложении слабые места и определить потенциальные угрозы безопасности.

Сравнительный анализ показал, что количество секретов, обнаруженных с помощью MobSF, после применения шилдинга сократилось на 71%.

При сокрытии секретов максимальная эффективность от применения протектора отмечена для приложений из категории «Инструменты и утилиты» — 100%, а наименьшая — для категорий «Путешествия и транспорт» и «Развлечения и контент» (81%).

Рисунок 7. Эффективность протектора (доля скрытых секретов)

В ходе анализа были зафиксированы отдельные аномальные случаи. В категориях «Доставка еды и продуктов» и «Соцсети и общение» выявлено по одному приложению, в которых после применения шилдинга количество обнаруженных секретов увеличилось вместо ожидаемого снижения. Такой результат объясняется особенностями работы инструмента MobSF: при наличии зашифрованных библиотек он некорректно читает их содержимое и ошибочно интерпретирует фрагменты кода как строковые значения. Это повышает вероятность ложных срабатываний при поиске секретов с помощью регулярных выражений.

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

Сравнительный анализ по остальным метрикам показал сопоставимую эффективность для всех категорий приложений: в среднем количество обнаруживаемых недостатков снизилось на 90%. Подробные результаты представлены в разделе «Выводы».

2.3. Обнаружение защитных техник

Первичный анализ APK-файлов с помощью встроенного модуля APKiD показал, что во всех исследуемых приложениях использовались следующие защитные техники:

• anti_debug — защита от отладки;
• anti_disassembly — защита от дизассемблирования;
• anti_vm — защита от запуска в виртуальных машинах;
• obfuscator — обфускация исходного кода.

Наличие сигнатур этих механизмов в исходных APK-файлах может снижать эффективность защиты. При их обнаружении злоумышленник получает возможность заранее подготовить инструменты и методы для обхода применяемых технологий. Использование протектора снижает видимость защитных техник и затрудняет статический анализ.

Сравнительный анализ показал, что количество обнаруженных с помощью MobSF защитных техник после применения шилдинга сократилось на 60%.

Максимальная эффективность отмечена для механизмов защиты от отладки и запуска в виртуальных машинах. Реализованные механизмы не удаляются, однако их обнаружение усложняется, что делает статический анализ приложения менее результативным.

Рисунок 8. Эффективность протектора (доля скрытых защитных техник)

3. Демонстрация методики анализа

На рисунках ниже представлены фрагменты отчетов MobSF до и после применения протектора на примере тестового приложения Crackme, использованного для иллюстрации методики анализа. Данное приложение не входило в исследуемую выборку.

Рисунок 9. Фрагмент отчета сканера MobSF для приложения Crackme (до шилдинга)

Рисунок 10. Фрагмент отчета сканера MobSF для приложения Crackme (после шилдинга)

Сравнительный анализ показал рост числа строковых значений в нативных библиотеках, их обфускацию, а также исчезновение обнаруженных секретов.

Выводы

Отдельно нужно отметить, что из-за ложноположительных срабатываний сканера число обнаруживаемых строковых значений в среднем увеличилось в 10,3 раза.

Таким образом, наибольший эффект достигается для небезопасных участков кода приложения, сторонних зависимостей, сетевых адресов, анализа поведения, а также для техник защиты от запуска в виртуальных машинах и от отладки. Для защиты от дизассемблирования и уязвимостей среднего уровня риска эффективность протектора выражена слабее.

Для разработчиков приложений

Исследование показало, что защитные техники, реализуемые с помощью протекторов Android-приложений, эффективно скрывают потенциальные уязвимости и недостатки, а также используемые механизмы защиты. Это существенно повышает устойчивость приложений к атакам, основанным на автоматизированной декомпиляции и статическом анализе. Таким образом, использование протекторов следует рассматривать как обязательную часть процесса разработки мобильных приложений. Применение подобных решений выстраивает критически важный дополнительный эшелон защиты, усложняющий реверс-инжиниринг и автоматизированный поиск уязвимостей. Это, в свою очередь, повышает уровень доверия со стороны пользователей, так как снижает риски массовой эксплуатации.

Александр Ананикян, аналитик сервиса PT MAZE, Positive Technologies

Олег Гусаинов, специалист Android Experts сервиса PT MAZE, Positive Technologies