Краткое изложение идей захвата пакетов Android


предисловие

Теперь большинство приложений будут защищаться от захвата, сегодня мы рассмотрим, как перехватывать пакеты, чтобы увидеть, каковы стратегии против захвата.
Обратите внимание, что в этой статье я не буду вводить конкретную операцию, я расскажу только о методе и идее захвата пакетов.Например, использование инструмента захвата пакетов агента Чарльза можно найти в Интернете на большой площади, поэтому я не буду говорить об этом здесь. Итак, чтобы прочитать следующее, вам необходимо понять следующие моменты знаний:

  • Использование инструментов Чарльза
  • Процесс установки зашифрованного соединения с HTTPS
  • Принцип закрепления SSL
  • Лучше всего иметь некоторые знания по обратному инжинирингу Android (например, использование Xposed).

1. Введение

Обычно в Android существует три типа сетевых запросов: HTTP, HTTPS и Socket.
Http и Https — это фреймворки верхнего уровня, основанные на инкапсуляции сокетов.Они обычно используются, но не исключено, что некоторые приложения с высокими требованиями к безопасности используют Socket для самостоятельной инкапсуляции сетевых запросов.Это более проблематично.Ключ в том, что анализировать данные непросто.

Два, захват HTTP-пакетов

Захват HTTP относительно прост, вы можете использовать Charles или Friddler для захвата.

3. Захват пакетов HTTPS

Перехват пакетов https без защиты тоже очень прост.Позвольте мне кратко объяснить принцип: Мы понимаем прокси-инструмент как посредника.Когда клиент отправляет данные на сервер, посредник притворяется сервером. Отправьте открытый ключ вашего собственного сертификата клиенту, а затем получите данные, отправленные клиентом, притворитесь клиентом и отправьте свой собственный открытый ключ сертификата на сервер. Наверное можно представить в роли двойного агента. Клиент притворяется сервером, а сервер притворяется клиентом.
А из-за особенностей https необходимо установить на мобильный телефон сертификат посредника, чтобы приложение могло доверять посреднику и расшифровывать передаваемые данные, а затем вы могли бы с радостью перехватить пакет. Но вы обнаружите, что большинство приложений по-прежнему не могут перехватывать пакеты после этого. Здесь есть два случая. Во- первых, сетевой запрос вообще не проходит через прокси-сервер. В это время, хотя приложение может нормально использоваться, прокси-инструмент не имеет никаких данных. Другой заключается в том, что прокси-инструмент может перехватить сетевой запрос, но запрос напрямую терпит неудачу. Давайте сначала проанализируем возможные причины сбоя отправки :

1. Системные ограничения Android

Система Android разделена на сертификаты, системные предустановленные сертификаты и сертификаты, установленные пользователем.

Среди них Android 6.0 (уровень API 23) и более ранние версии, предустановленный сертификат системы доверия по умолчанию для приложения и сертификат, установленный пользователем.

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
        <certificates src="user" />
    </trust-anchors>
</base-config>

Android 7.0 (уровень API 24) и более поздние версии по умолчанию будут доверять только предустановленному системному сертификату.

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

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


Одним из них является изменение приложения и переупаковка. Конкретная операция заключается в использовании apktools для декомпиляции установочного пакета, изменении конфигурации android:networkSecurityConfig, а затем переупаковки. Это может столкнуться со многими ловушками. Например, многие приложения будут выполнять проверку подписи приложения.
Второй — импортировать сертификат Charles в системный сертификат после рутирования мобильного телефона, чтобы независимо от того, как он настроен, он не влиял на захват пакетов. Здесь я кратко расскажу о процессе:

1. Рассчитайте имя сертификата:

  • openssl x509 -subject_hash_old -in charles-ssl-proxying-certificate_saved.pem
  • Вычислите значение, например 3a1074b3

2. Переименуйте файл сертификата

  • Затем измените исходный сертификат Charles charles-ssl-proxying-certificate_saved.pem на 3a1074b3.0.

3. Ставим в системный раздел

  • Поместите его в /system/etc/security/cacerts/

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

2. Проверка сертификата (закрепление SSL)

Хоть мы и поместили сертификат посредника в системный каталог, чтобы обойти проверку сертификата HTTPS, но если у приложения есть своя логика проверки сертификата сервера, то есть клиент будет проверять сертификат сервера после получения запроса, то посредник будет холоден.Говоря непрофессионалом, у клиента есть визитная карточка сервера.Когда посредник притворяется сервером, клиент его не узнает. Это проверка сертификата. Как это сломать?

Сервер проверки клиентов

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

В дополнение к некоторым общепринятым сетевым фреймворкам некоторые производители настраивают свои собственные фреймворки из соображений безопасности.Например, сетевым фреймворком Toutiao является волшебным образом модифицированный okhttp3, а проверка ssl внутри также заменена наboringssl(ветвь openssl от Google с открытым исходным кодом).В этом случае мы можем только проверить код, чтобы найти точку перехвата для модификации, что сложнее .

клиент проверки на стороне сервера

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

3. Случай неиспользования агента

Ранее мы говорили , что бывает ситуация, когда сетевой запрос не проходит через прокси, который обычно задается в коде.Один из способов — перехватить расположение настройки кода и изменить его на системный прокси; ), чтобы дроны могли управлять сетевым трафиком на всех мобильных телефонах и даже настраивать трафик разных приложений на мобильном телефоне отдельно . Чтобы узнать о конкретных методах использования, обратитесь к этой статье https://www.codeprj.com/blog/ada83a1.html.

Четыре, захват сокета

Просто скажите о пакете Socket.Во-первых, и Charles, и Fiddler разработаны на основе протокола HTTP, поэтому они не могут поймать пакет Socket.Они могут использовать только программное обеспечение, такое как Wireshark, чтобы напрямую ловить трафик сетевой карты.Во-вторых Данные проигравших зашифрованы, а пакеты, которые они поймали, также являются кучей искажений, поэтому я советую вам отказаться от этого приложения.Я очень хочу попробовать скомпилировать его исходный код для перехвата до того, как шифрование будет зашифровано.

Подведем итог

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

Supongo que te gusta

Origin blog.csdn.net/shanshui911587154/article/details/117508317
Recomendado
Clasificación