Структура приложений Android

Приложение Android поставляется как APK (пакет Android). На самом деле это ZIP-архив, содержащий скомпилированный код, ресурсы и метаданные.

Поскольку это ZIP-архив, его можно просто распаковать и изучить содержимое — это первый шаг при тестировании безопасности мобильных приложений.

Распакованный APK содержит:

• AndroidManifest.xml: конфигурацию приложения.
• classes.dex: скомпилированный байткод.
• res/ и resources.arsc: ресурсы.
• lib/: нативные библиотеки.
• META-INF/: сведения о подписи.

AndroidManifest.xml объявляет компоненты, разрешения и конфигурацию приложения. В APK он представлен в двоичном формате XML, который инструменты могут декодировать.

Это самый важный файл для понимания поверхности атаки приложения.

Исходный код Java/Kotlin компилируется в байткод DEX (Dalvik Executable), который хранится в classes.dex. Современный Android выполняет его с помощью ART (Android Runtime).

DEX можно преобразовать обратно в код, близкий к читаемому, чем и пользуется статический анализ APK.

Приложения Android состоят из четырёх типов компонентов:

• Activity: экраны и пользовательский интерфейс.
• Сервисы: фоновые задачи.
• Приёмники широковещательных сообщений: реагируют на системные события.
• Поставщики содержимого: предоставляют данные другим приложениям.

Компонент с атрибутом android:exported="true" может быть вызван другими приложениями. Если такой компонент выполняет чувствительные действия без проверок, он становится поверхностью атаки.

Специалисты по тестированию безопасности ищут экспортируемые Activity, сервисы и поставщики, которые раскрывают данные или выполняют привилегированные действия.

Приложения запрашивают разрешения в манифесте (например, INTERNET, READ_SMS, ACCESS_FINE_LOCATION).

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

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

Уязвимости возникают, когда приложения ослабляют эту границу, например создавая доступные всем файлы или открытые поставщики содержимого.

Установленное приложение хранит личные данные в /data/data/<package>/: базы данных, общие настройки и файлы.

На устройстве с root-доступом или через резервные копии специалист по тестированию безопасности изучает этот каталог в поисках небезопасно хранящихся секретов. Этой теме посвящён один из следующих уроков.

Каждый APK имеет цифровую подпись; она находится в META-INF/. Android проверяет её при установке и обновлении.

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

Критичная для производительности или обфусцированная логика может находиться в нативных библиотеках (файлах .so) в каталоге lib/; они скомпилированы из C/C++.

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

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

Теперь Вы понимаете структуру приложений Android:

• APK — это ZIP-архив, содержащий AndroidManifest.xml, classes.dex, ресурсы и данные подписи.
• В приложениях используются четыре компонента; экспортируемые компоненты являются поверхностью атаки.
• Разрешения и отдельная для каждого приложения песочница регулируют доступ; личные данные находятся в /data/data/.
• APK подписываются, чтобы обнаруживать вмешательство.

Далее Вы выполните декомпиляцию APK в рамках статического анализа.