Как отключить проверку приложения при установке на Android
В Android при установке приложения вы можете увидеть сообщение о Google, проверяющем ваше приложение, особенно когда мы устанавливаем приложения из файлов APK. Посмотрите, как отключить это сообщение и отсканировать приложение.
Google, чтобы лучше защитить своих пользователей, предлагает сканирование приложений и проверку их соответствия. Мы можем заметить, что после установки приложения появляется сообщение с просьбой принять проверку. После принятия каждого приложения, которое мы устанавливаем, будут проверены и проверены.
Если мы не хотим, чтобы Google отсканировал наши приложения, мы можем отключить его. Опция сканирования и проверки доступна в двух местах.
Мы отключили проверку и проверку установленных приложений на Android
1. Перейдите в приложение «Настройки» на Android, а затем на вкладку «Безопасность».
2. В настройках безопасности найдите опцию «Проверить приложения». По умолчанию эта опция выбрана — снимите флажок. После снятия флажка Android не будет блокировать установку приложений, которые будут обнаружены как потенциально опасные.
3. Выйдите из системных настроек и в списке приложений теперь найдите параметр «Настройки Google». Запустите его.
4. Отобразятся настройки, связанные с совместной работой Android с службами Google. Перейдите на вкладку «Безопасность».
5. Перейдите в самое нижнее положение настроек безопасности. Вы найдете раздел «Проверка приложений» и в нем параметры «Устройство сканирования» и «Улучшить обнаружение вредоносных приложений».
6. Отмените выбор обоих параметров, чтобы отключить сканирование и проверить приложение.
И это все, теперь, после выхода из настроек, наш Android больше не будет проверяться Google при установке новых приложений.
Источник
Русские Блоги
Обход проверки подписи APK
0x01 Механизм подписи Android
Переименуйте APK в zip-файл, и тогда вы увидите папку META-INF с тремя файлами с именами MANIFEST.MF, CERT.SF и CERT.RSA. Это подписи, созданные с помощью signapk.jar. файл.
1. Файл MANIFEST.MF:
Программа просматривает все записи в пакете update.apk и генерирует информацию цифровой подписи SHA1 одну за другой для файлов, которые не являются папками и файлами без подписи, а затем кодирует их с помощью Base64. См. Этот метод для конкретного кода:
Затем запишите сгенерированную подпись в файл MANIFEST.MF. Код ключа следующий:
2. Создайте файл CERT.SF:
Для манифеста, созданного на предыдущем шаге, используйте алгоритм SHA1-RSA и подпишите с помощью закрытого ключа. Код ключа следующий:
3. Создайте файл CERT.RSA:
Никакая ключевая информация не использовалась для создания MANIFEST.MF, а файл закрытого ключа использовался для создания CERT.SF. Тогда мы можем легко догадаться, что создание файла CERT.RSA должно быть связано с открытым ключом. В файле CERT.RSA сохраняется такая информация, как открытый ключ и используемый алгоритм шифрования. Основной код выглядит следующим образом:
При получении подписи APK в программе получите ее с помощью метода подписи следующим образом:
Итак, общая программа состоит в том, чтобы судить, был ли переупакован APK, по значению подписи в коде.
0x02 метод обхода подписи
Прежде чем говорить о методе обхода подписи, необходимо уточнить DEX-проверку и проверку подписи:
1. Откройте apk в виде сжатого пакета и удалите исходную подпись, а затем подпишите его. Установка может быть открыта нормально, но IDE (то есть apk изменен, он автоматически декомпилирует dex) инструмент для вторичной упаковки, но возникают ненормальные условия , Например: возвратиться назад / всплыть неподлинное окно подсказки. Можно определить, что это проверка файла dex
2. Откройте apk в виде сжатого пакета, удалите исходную подпись и снова подпишите.Если он открывается после установки, в принципе можно сделать вывод, что это проверка подписи. Если есть исключения, когда сеть отключена, это проверка локальной подписи; если первое, что появляется, это то, что сеть не подключена, это проверка подписи на стороне сервера.
2.1. Проверка уровня Java
Способы получения информации о подписи и проверки написаны на уровне Java Android. Вот примеры:
1. Используйте APKIDE для декомпиляции APK без каких-либо операций, затем вернитесь к непосредственной компиляции и запустите после установки, запрос будет следующим:
2. Найдите подписи (или найдите сообщения об ошибках) в APKIDE и найдите код для проверки подписи.
3. Здесь нужно получить подпись, а затем найти место, где программа оценивает подпись, и изменить его, как показано на рисунке ниже, если-nez — это место для оценки, измените ne на eq. То есть if-eqz v2,: cond_0. Тогда программа сможет обойти локальную транзакцию подписи.
2.2. Проверка НДК
Введите код ключа в так, получите информацию о подписи и проверьте ее внизу. Поскольку методы получения и проверки заключены в более безопасную библиотеку so, она может играть защитную роль в определенном смысле. Вот примеры:
1. Используйте APKIDE для декомпиляции APK без каких-либо операций, а затем вернитесь к непосредственной компиляции, запустите после установки, и программа выйдет сразу без запроса.
2. Найдите подписи (или найдите сообщения об ошибках) в APKIDE и найдите код для проверки подписи.
3. Используйте JD-GUI, чтобы открыть AppActivity, вы можете видеть, что здесь нужно получить имя пакета, а затем выполнить расчет MD5.
4. Найдите в программе getSignature и обнаружите, что нет места для вызова этой функции.Угадайте в файле so, найдите loadLibrary.
5. Вы можете найти это в коде, вы можете обнаружить, что это libcocos2dcpp.so
6. Используйте IDA для открытия libcocos2dcpp.so, затем выполните поиск в getSiganture, чтобы найти место для вызова этой функции.
Как видно из кода, эта функция вызывает org.cocos2dx.cpp.AppActivity.getSignature
7. Проверьте код F5 и обнаружите, что эта функция является функцией оценки подписи. Затем мы дважды щелкаем вызывающий объект этой функции. Часть кода выглядит следующим образом.
8. Как видно из приведенного выше рисунка, нужно только изменить BEQ loc_11F754, чтобы он не переходил к ошибке jjni ——>, и проверку подписи можно было обойти. Отметьте HEX, используйте редактор 010 для перехода к 0011F73E, измените D0 на D1. Проверка подписи была успешно обойдена.
2.3. Проверка сервера
Получите информацию о подписи на уровне Java Android, и сервер загрузки подписывается на сервере и возвращает результат проверки.
Как показано на рисунке ниже, во время проверки сети, если сеть не подключена, обычно отображается ошибка.
Поскольку это сетевая проверка, информация о проверке должна быть отправлена на сервер, а затем проверена. Давайте сначала рассмотрим простой пример, а в следующий раз будет сложный.
1. Телефон настроен на захват пакета, а затем на захват пакета. Первое изображение — это пакет данных обычного APK, а второе изображение — пакет данных декомпилированного APK. Путем сравнения обнаружено, что public_key в файле cookie отличается. Затем мы заменяем его и обнаруживаем, что функция APK может использоваться в обычном режиме. Вверх.
2. Добавьте правильный public_key в APK. Откройте декомпилированный код, найдите подписи и найдите подписанный код.
Как видите, код передает значение подписи в V4, а затем передает его в функцию Utils-> mPublicKey, поэтому мы передаем правильный public_key в V4.
Потом перепаковать и переустановить.
0x03. Резюме
Проверка уровня java может быть легко взломана, а проверка на уровне so относительно труднее анализировать.Однако, если сетевая проверка представляет собой только сравнение строк, ее также легко взломать.
Кодовый код слишком утомлен. .
Позже есть несколько статей, в том числе анализ и так далее.
Источник
Отключение проверок состояния среды исполнения в Android-приложении
В прошлой статье я делал обзор на OWASP Mobile TOP 10 и тогда у меня не было годного кейса для демонстрации необходимости защиты исходного кода. Интересный кейс для демонстрации появился только недавно и кому интересно посмотреть на наш опыт обхода проверок состояния среды, давайте под кат.
При проведении оценки работы одного из проектов, наша команда, сразу поняла, что кейс не будет лёгким. Разработчики хорошо подошли к вопросу защиты информации в программе и внедрили проверки состояния среды исполнения. Приложение не запускалось при любом из следующих условий:
- аппарат был рутованным;
- использовался эмулятор;
- наличие подключения через USB;
- использование режима разработчика.
Разработчики не обфуцировали исходный код и не была встроена проверка на модификацию кода, что позволило мне проанализировать способы, которыми выполнялись проверки и выполнить необходимые манипуляции с ними.
Итак, начнём. Согласно OWASP Mobile TOP 10, который мы используем в качестве базовой методологии тестирования в компании Hacken анализ исходного кода (Reverse Engineering) — эта уязвимость включает в себя анализ бинарных файлов для определения исходного кода, библиотек, алгоритмов и т.д. Программное обеспечение, такое как IDA Pro, Hopper, otool и другие инструменты реверс-инжиниринга могут дать представление о внутренней работе приложения. Это может быть использовано для поиска уязвимостей приложения, извлечения критичной информации, такой как бэкенд-сервера, ключей шифрования или интеллектуальной собственности.
Для проведения базового статического анализа я использовал такой интересный инструмент, как MobSF, который выполнил декомпиляцию и базовый статический анализ. После декомпиляции меня интересовал java- и smali-коды программы. Java-код нужен для анализа, а в smali-код будем вносить изменения. Более подробно, как smali и java соотносятся можно прочитать здесь.
Просмотрев список классов, я обнаружил файл, который отвечает за проверку рутованности телефона (см. Рис. 1) — rootingcheck/RootBeerNative.java.
Рис. 1. Список классов приложения
Проанализировав класс, стало понятно, что нужно дальше искать вызовы функций checkForRoot() и setLogDebugMessage() (см. Рис. 2).
Рис. 2. Исходный код класса проверки на рутованость
С помощью команды grep получим следующие результаты, которые нам показывают, в каких файлах есть вызов методов checkForRoot() и setLogDebugMessage().
Результаты выполнения поиска:
root@kali:
/Desktop# grep -nr ‘RootBeerNative’ ********_v_0.9.2/
/Desktop# grep -nr ‘setLogDebugMessages’ ********_v_0.9.2/
Но это были не все проверки. Проанализировав класс MainActivity.java, был найдены вызовы функций, куда передаются строки “su”, “test-keys” и “which”, c помощью которых проводится проверка (см. Рис. 3).
Рис.3. Проверки на рутованость
И снова командой grep ищем в smali-файлах проверки рутованости:
Результаты выполнения поиска:
root@kali:
/Desktop# grep -nr ‘su’ ********_v_0.9.2/
/Desktop# grep -nr ‘test-keys’ ********_v_0.9.2/
/Desktop# grep -nr ‘which’ ********_v_0.9.2/
В статье я покажу лишь одну из найденных модификаций проверок рутованности. После небольшой манипуляции, а именно смены 1 на 0 — проверки на рутованность убраны.
Рис. 4. Значение переменной равно единице, если телефон рутованый
Рис. 5. Теперь значение переменной равно нулю, если телефон рутованный
После этого — программу можно собрать, подписать своим релизным ключом и запустить на мобильном телефоне. Но если-бы не два НО! А именно:
- проверка подключения к USB;
- проверка включения Developer mode — подключение к USB и включенный Developer mode позволяют проводить динамический анализ.
Проверка Developer mode выключается тем же путём, что и проверка рутованости — сменой в проверках единицу на ноль
В классе MainActivity.java находим строку, которая отвечает за проверку Developer mode (см. Рис 6). После этого grep-ом ищем файлы в которых присутствует строка “development_settings_enabled” и модифицируем проверку — меняем 1 на 0 (см. Рис. 7 и 8).
Рис. 6. Проверка, включён ли Developer mode на телефоне
Результаты выполнения поиска:
grep -nr «development_settings_enabled» ********_v_0.9.2\
Рис. 7. Место где нужно провести модификацию
Рис. 8. Модификация
После всех манипуляций можно запускать программу в режиме Developer mode.
Дальше отключаем проверку подключения по USB. Эта проверка находится в классе MainActivity.java (см. Рис. 9). Без применения grep, находим строку в MainActivity.smali, находим строку, которая содержит строку с проверкой USB — android.hardware.usb.action.USB_STATE. После этого, в smali-коде модифицируем строку на любой другой permissions, который возвращает “false” (см. Рис. 10).
Рис. 9. Проверка на подключение USB в коде MainActivity.java
Рис. 10. Строка кодa, которую нужно удалить в MainActivity.smali
Теперь осталось сгенерировать свой релизный ключ и подписать им приложение. Это делается следующим образом:
- Нужно установить два приложения: Keytool и Jarsinger.
- Выполнить команду на собрание приложения:
- apktool b C:\Users\User\Desktop\********
- Далее:cd ********\dist\
- Далее: Keytool.exe -genkey -alias key.keystore -keyalg RSA -validity 20000 -keystore key.keystore
- Далее:Jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore key.keystore ********.apk key.keystore
- Далее:jarsigner -verify -verbose -certs ********.apk
Вот в принципе все манипуляции и закончены. Теперь устанавливаем приложение на телефон с помощью adb install или из директории смартфона и можно проводить динамическое тестирование на уязвимости.
После установки приложения запускаем его (см. Рис. 11 и Рис. 12).
| |
| Рис. 11. Включаем режим Developer mode и подключаем USB | Рис. 12. Запуск приложения |
На практическом примере я показал, как можно отключить некоторые проверки состояния среды исполнения. Дальше уже с помощью других тулзов провели анализ на уязвимость, но это другая история…
К чему может привести халатное отношение к защите кода:
- это обхождения тех или иных проверок, которые вложены в программу
- внедрение стороннего кода, после чего программа может быть опубликована и использоваться как вредоносная
Как можно защититься? Мы в ByteCode решили не изобретать велосипед и предложили клиенту обфусцировать исходный код и использовать функции которые проверяют модификацию исходного кода.
Можно использовать более продвинутый способ анализа — это smali debugging. Более подробнее можно почитать об этом в мануале.
Немного для справки, я сформулировал список строк который применяется для проверки на рутованость:
Источник
