Как только почти все сообщество iOS разработчиков переключилось с Objective-C на Swift, изменились и наши предпочтения в библиотеках и сетях.
С распространением Swift мы стали все чаще использовать сетевую библиотеку Alamofire. В отличии от AFNetworking Alamofire обрабатывает запросы иначе. Ни одна из них не будет фатальной, но у разработчика появляется возможность выбрать лучший метод.
Два метода пиннинга (фиксирования)
Пока AFNetworking обращается только к серверам, чьи сертификаты вы указали, Alamofire работает иначе – вы привязываете сертификат к домену, в дальнейшем проверка сертификата будет проходить только, когда вы указываете лист заранее выбранных доменов. Все другие домены проверяться не будут. С другой стороны, AFNetworking будет блокировать все обращения, которые не прошли проверку сертификатов, закрепленных в вашем приложении.
Возможно, сначала реализация Alamofire может показаться странной, но такой вид пиннинга (фиксирования) дает огромную свободу, когда вы определяете различные принципы для разных доменов. Например, самоподписывающийся сертификат для вашей среды разработки можно легко настроить отдельно от вашей среды промышленной эксплуатации без каких-либо макроопределений препроцессора или общей методики Objective-C.
007. SSL Pinning для мобильных приложений Яндекса — Ростислав Алиферович
Однако, для некоторых приложений, например, для приложений мобильных банков, разработчики могут указать только определенные конечные точки, которые будут общаться со всеми доверительными сертификатами. В этом случае вам придется выполнить часть работы вручную, чтобы вернуть обратно поведение, похожее на AFNetworking.
Инструкция по применения SSL пиннига (фиксирования)
Ваше приложение уже почти готово, и вы хотите добавить еще один уровень безопасности с SSL-пининнгом.
Получение сертификата
Если ваше приложение уже рабочее, вы можете легко считать сертификат самостоятельно. Firefox предлагает отличную возможность экспортировать их используя UI:
Альтернативный способ, когда вы используете openssl из командной строки и получаете сертификат таким способом:
openssl s_client — showcerts — connect www . infinum . co : 443 < / dev / null | openssl x509 — outform DER >infinumco . cer
Пиннинг с Swift и Alamofire
Пример политики безопасности для Alamofire и пиннинг (фиксирование) может выглядеть примерно так:
1
2
3
4
5
6
7
8
9
10
11
12
13
let serverTrustPolicies : [ String : ServerTrustPolicy ] = [
«infinum.co» : . pinPublicKeys (
publicKeys : ServerTrustPolicy . publicKeys ( ) ,
validateCertificateChain : true ,
validateHost : true
)
]
let sessionManager = SessionManager ( // Make sure you keep a reference of this guy somewhere
serverTrustPolicyManager : ServerTrustPolicyManager (
policies : serverTrustPolicies
)
)
В этом примере мы фиксируем публичные ключи от сертификатов. Вы можете закрепить сами сертификаты (в этом случае вы сопоставляете байт с байтными данными) или сравнить публичные ключи в сертификатах. У публичных ключей есть преимущество – они более надежные. Сертификат сервера может быть обновлен сохраненным публичным ключом, поэтому обновление приложения не требуется для замены сертификатов. Для практики это не типичный кейс, но дальше мы расскажем об этом подробнее.
SSL pinning. Инструкция по применению — Анна Сентякова, 65apps
Чтобы имитировать поведение AFNetworking, к которому мы прибегали ранее, вам придется разделить на подклассы Server Trust Policy Manager и отменить (аннулировать) реализация по умолчанию. Пример, как легко остановить в приложении коммуникацию, если не были зафиксированы сертификаты, может выглядеть примерно так:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
import UIKit
import Alamofire
class CustomServerTrustPolicyManager : ServerTrustPolicyManager {
override func serverTrustPolicy ( forHost host : String ) -> ServerTrustPolicy ? {
// Check if we have a policy already defined, otherwise just kill the connection
if let policy = super . serverTrustPolicy ( forHost : host ) {
print ( policy )
return policy
} else {
return . customEvaluation ( { ( _ , _ ) -> Bool in
return false
} )
}
}
Все то же самое, как при реализации привязки по умолчанию, за исключением необходимости использования вместо этого класса.
Если в вашем проекте по умолчанию используется сеть, вы можете вообще не пользоваться AFNetworking или Alamofire, а реализовать привязку на уровне NSURLSession. Так будет проще, чем мучиться с Alamofire. Поскольку этот способ более гибкий и не будет ломаться в случае изменений Alamofire API в будущем.
Вы можете установить сертификат:
// Compare the server certificate with our own stored
if let serverCertificate = SecTrustGetCertificateAtIndex ( trust , 0 ) {
let serverCertificateData = SecCertificateCopyData ( serverCertificate ) as Data
if pinnedCertificates ( ) . contains ( serverCertificateData ) {
completionHandler ( . useCredential , URLCredential ( trust : trust ) )
return
}
}
Или публичный ключ:
// Or, compare the public keys
if let serverCertificate = SecTrustGetCertificateAtIndex ( trust , 0 ) , let serverCertificateKey = publicKey ( for : serverCertificate ) {
if pinnedKeys ( ) . contains ( serverCertificateKey ) {
completionHandler ( . useCredential , URLCredential ( trust : trust ) )
return
}
}
Наконец, вы можете использовать вместе URLSessionDelegate и Alamofire, поскольку SessionDelegate – это открытый класс. В этом случае вам следует создать подклассы SessionDelegate с вашим собственным классом и использовать код из предыдущего примера в переменной sessionDidReceiveChallengeWithCompletion:
1
2
3
4
5
6
7
8
9
10
11
12
class CustomSessionDelegate : SessionDelegate {
// Note that this is the almost the same implementation as in the ViewController.swift
override init ( ) {
super . init ( )
// Alamofire uses a block var here
sessionDidReceiveChallengeWithCompletion = { session , challenge , completion in
// See above, or check the code example
}
}
}
Смотрите полный пример кода по ссылке
Распространенные ошибки
Тестирование пин
Если при тестировании софта вы захотите проверить, что работает, то для пиннинга (фиксирования) вам также важно знать, что не работает. При этом вам надо проверить, что ваше приложение отменяет потенциально небезопасные соединения. Пока настройка атаки через посредника может быть излишней, есть более простой способ тестирования в зависимости от используемого типа пина.
Если в приложении связь возможна только с конечными точками, тогда тестирование проходит также же просто как запрос GET к произвольному сайту (только убедитесь в наличии сертификата). Приложение должно отменить соединение, и запрос должен завершиться неудачно. Дополнительно убедитесь, что API работает, как ожидалось, и вы готовы к работе.
Тестирование случая, описанного выше, будет сложнее, если ваше приложение привязывает сертификат к домену, поскольку произвольный запрос к другому домену будет успешно завершен, как ожидалось. В этом случае вам необходимо привязать сертификат от другого домена и пытаться связаться с API, но снова неуспешно. В сумме с успешным тестированием соответствующего сертификата и успешной связью с API этого будет достаточно.
Получайте новости первыми
Изменение сертификата/обновление
Хотя обновление сертификата для домена может сохранить связку пары ключей персональный — публичный (значит, ваше приложение сможет продолжать функционировать), обычно так не делают. К счастью, если вы планируете цикл обновлений верно, то сможете избежать простоя для конечных пользователей.
Прежде, чем новый сертификат станет активным на веб-сайте, вам нужно указать его в своем приложении вместе с действующим активным сертификатом и опубликовать обновление. Возможно сразу подключить несколько сертификатов, как это показано в примере кода выше. В этом случае не забывайте, что вы конвертируете сертификат в соответствующий двоичный формат DER.
Если возможно, то быстро протестируйте приложение с новым сертификатом. В этом случае разработчики, обрабатывающие сертификат на API, должны временно использовать новый сертификат и тестировать ваше приложение с двумя закрепленными сертификации. Если все работает, то до обновления приложения требуется использовать старый сертификат.
Напутствие
В конце мне еще раз хочется посоветовать вам всегда, где это возможно, использовать SSL-пиннинг, хотя это и бесполезно. Некоторым приложениям не требуются дополнительные меры безопасности, но для приложений, обрабатывающих персональные данные, дополнительный уровень защиты никогда не будет лишним. В этом случае, я надеюсь, что статья была для вас полезной.
Источник: www.roxiemobile.ru
Что такое безопасность соединения или включите SSL-pinning в вашем мобильном приложении прямо сейчас
В этой статье я кратко расскажу, что означает «безопасное соединение» между клиентом и сервером, что такое SSL-pinning, для чего он нужен и когда его использовать. Так же объясню от каких угроз мы защищаемся с его помощью.
Безопасность соединения
Представим, что у нас есть сайт или мобильное приложение (оба подпадают под определение клиента). При обращении сайта или мобильного приложения к бекенду (сервер) безопасность соединения обеспечивается с помощью протокола SSL (Secure Socket Layer), а если быть точнее, TLS (Transport Layer Security). TLS ставит своей целью создание между двумя узлами сети защищённого от прослушивания и подмены информации канала связи, а также проверку того, что обмен данными происходит между именно теми узлами, т.е. обеспечение конфиденциальности, целостности и аутентификации. Под узлами можно понимать сервер и мобильное приложение, либо сервер и веб-браузер.
Немного истории про SSL/TLS
Изначально SSL был разработан компанией Netscape для своего одноименного браузера в середине 90-х. Позднее на основании SSL 3.0 был принят RFC-стандарт TLS 1.0. Рекомендованными для применения в 2019 году являются версии TLS не ниже 1.2 (актуальная версия на сегодня — 1.3). На странице в википедии можно посмотреть поддержку версии TLS у всех популярных браузеров.
Человек посередине
MITM (Man in the middle) — данный вид атаки направлен на «прослушку» или изменение трафика между двумя узлами (клиентом и сервером). В случае использования незащищенного HTTP это не составляет труда, тогда как в случае HTTPS (HTTP + SSL, или HTTP secure) данные зашифрованы и обычный просмотр пакетов трафика не даст никакой полезной информации злоумышленникам об их содержании. О том, каким образом шифруются данные, поговорим дальше.
Симметричное, ассиметричное шифрование
Симметричное шифрование — вид шифрования, при котором для шифрования и дешифрования будет использоваться один и тот же ключ. Наиболее стойким на данный момент является шифр AES (Advanced Encryption Standard), длина ключа может быть 128, 192 или 256 бит. Из минусов симметричного шифрования — проблема передача ключа, ведь в случае его утери, им может воспользоваться злоумышленник.
В случае TLS используется ассиметричное шифрование — когда для шифрования используется публичный ключ, а для дешифрования приватный. Публичный ключ передаётся от узла 1 к узлу 2, и даже в случае его перехвата злоумышленником, содержимое данных невозможно расшифровать, т.к. закрытый ключ не передается между узлами.
Наиболее распространённый шифр этого типа — RSA (Rivest — Shamir — Adleman), размер ключа от 1024 до 4096 бит. Удобство ассиметричных шифров так же в том, что публичный ключ может быть передан большому количеству узлов без угрозы его утечки, как в случае ключа симметричного шифра. Из минусов — асимметричные шифры значительно медленнее симметричных.
Поэтому в TLS используется смешанный подход — все данные шифруются симметрично, а набор ключей асимметрично. Но так как узлы шлют информацию в обе стороны, необходимо шифровать трафик с двух сторон. На помощь приходит протокол Диффи-Хеллмана. Первые 2 минуты видео достаточно понятно объясняют принцип его работы. Если мы хотим защитить соединение по HTTP, здесь стоит подумать о SSL-сертификате.
Сертификат X.509
В качестве удостоверяющего хост документа выступает сертификат стандарта X.509. Под сертификатом можно понимать файл, в котором содержится следующая информация:
- Название
- Публичный ключ
- Серийный номер
- Алгоритм сертификата
- Цифровая подпись и др.
При нажатии на иконку замка в строке сайта
Сертификаты не существую сами по себе — их выпускают центры сертификации (Certificate Authority), в цепочке сертификатов самым первым является сертификат CA, его еще называют корневой. CA являются общеизвестными и ключи, которые они выпускают являются доверенными по умолчанию. Корневые сертификаты как правило “зашиваются” в операционную систему и обновляются при следующих обновлениях. Сертификаты выстраиваются в цепочку, можно так же назвать термин дерево: сертификаты первого уровня (выпущенные CA), так же могут выпускать сертификаты следующих уровней. В случае компрометации сертификата, он может быть отозван, и тогда автоматически отзываются все дочерние сертификаты.
Человек посередине по TLS
Кажется, что TLS решает атаку MITM. Тем не менее, возможен вариант, когда между узлами окажется самоподписанный корневой сертификат злоумышленника и каким-то образом этот сертификат попадёт к нам на устройство. Например, если пользователь недостаточно технически образован и ему предлагается установить сертификат для пользования сетью Wi-Fi. После этого данные шифруются сертификатом злоумышленника (которые он легко расшифровывает) и мы не подозреваем о подмене. В данном случае злоумышленник выступает неким прокси-сервером между нашими узлами.
SSL-pinning
Если мы реализуем проверку сертификата на клиенте, то можем отловить ситуацию, когда сертификат между узлами неподлинный. Технически это выглядит следующим образом: при установлении соединения с хостом на клиенте проверяется, соответствует ли сертификат от сервера тому сертификату, о котором знает клиент. Если нет — соединение считается небезопасным и обмен данных с хостом прекращается. Помимо прослушивания трафика, SSL-pinning так же не раскрывает спецификацию запросов API, что может пригодиться при атаках как на сервер, так и на клиент.
Схема работы SSL-pinning
Как проверять сертификат или виды SSL-pinning
По тому, какой сертификат проверяем:
- Цепочка сертификатов — можно проверять данные каждого из сертификатов в цепочке.
- Конечный сертификат — наиболее распространённый вариант на практике, проверяется сертификат самого нижнего уровня.
- Корневой или промежуточный сертификат. Например, несколько наших хостов имеют один родительский сертификат, можем проверять только его вместо нескольких проверок.
По тому, какие данные из сертификата проверяем:
- Фингерпринт. Это хэш от данных сертификата (можно выбрать, например из SHA-1, SHA-256). Фингерпринт видно в окне браузера при просмотре сертификата. Подход достаточно прост в реализации и обычно в SDK уже есть API по вычислению фингерпринта сертификата. Но к минусам такого подхода могу отнести то, что при истечении сертификата прежний фингерпринт становится невалидным, и его необходимо обновить на клиенте. Невалидным он становится, т.к. у нового сертификата как минимум будет новый приватный ключ.
- Публичный ключ. Данный вид лишён недостатка о перевыпуске сертификата, т.к. если в вашем распоряжении имеется прежний сертификат (пара публичный-приватный ключ), то вы сможете выпустить новый сертификат с тем же публичным ключом даже у другого CA. После истечения текущего не придётся обновлять информацию на клиенте. К недостаткам можно отнести, во-первых, что публичный ключ извлекается чуть сложнее, чем фингерпринт, и во-вторых, сам по себе факт того, что ключ не будет меняется долгое время.
Фингерпринт виден в том же окне просмотра сертификата в Safari
Когда SSL-pinning не нужен
- Хосты сторонних сервисов — сертификат может измениться без нашего ведома. Например, Google-аналитика.
- Нет чувствительных данных — нет никакой угрозы, что данные будут получены третьей стороной. Например, любые открытые сервисы (текущее время, погода).
Вместо вывода
Раз уж мы обсудили SSL-pinning в контексте мобильных приложений, почему бы не сделать тоже самое с веб-сайтами? Ответ достаточно прост — браузер посещает большое количество сайтов, ровно как и каждый день появляется много новых, и это достаточно проблематично обладать информацией обо всех них.
Мобильное приложение же, как правило, обращается к конечному числу доменов, информация о сертификатах хранится внутри него. В 99% случаев не нужно придумывать свои способы шифрования, TLS + SSL-pinning обеспечивают достаточный высокий уровень безопасности для передачи чувствительных данных по сети. Примеры приложений, где SSL-pinning является по-моему мнению обязательным — это мобильные приложения банков, другие приложения из финансового и страхового сектора. Для более подробного погружения в схему работы TLS советую данный ресурс.
Источник: medium.com
Откручивание SLL пиннинга в Android приложениях
В процессе тестирования на проникновение мобильных приложений на Android часто необходимо выяснить, каким образом приложение общается с сервером, с какими адресами происходит взаимодействие, как выглядят запросы, какие данные передаются. Но не всегда это удается сделать.
В наше время для взаимодействия компонентов веб-приложений используется протокол HTTPS, в основе которого лежат протоколы HTTP и TLS. Просто так перехватить трафик приложения не выйдет, т.к. он зашифрован. Можно, конечно, использовать прокси сервер, который с помощью своего сертификата сможет расшифровать трафик приложения и увидеть все запросы. Однако и средства защиты приложений не стоят на месте. Многие мобильные приложения используют SSL Pinning.
SSL Pinning – это внедрение SSL сертификата, который используется на сервере в код мобильного приложения. Таким образом, приложение не использует хранилище сертификатов устройства и не будет работать с сертификатом, который мы ему подсунули.
Способы защиты приложений
Для того чтобы понять, как обходить защиту, необходимо сначала разобраться, какими средствами эта защита осуществляется. Для этого существуют несколько способов.
Для данного способа необходимо добавить файл сертификата в файлы приложения, затем создать KeyStore и добавить в него наш сертификат.
После этого создаем сам TrustManager, который будет работать с нашим KeyStore, в котором находится нужный сертификат.
Далее создается SSLContext, который использует наш TrustManager. Затем указываем для URLConnetction SocketFactory из созданного SSLContext.
Основная суть этого метода в том, что мы используем непосредственно сам файл сертификата в проекте, а затем создаем TrustManager, который будет работать только с этим сертификатом.
Данная реализация работает непосредственно с API на достаточно низком уровне, поэтому этот способ надо использовать осторожно.
- OkHttp CertificatePinner
Вторым способом является использование библиотеки OkHttp. В ней есть удобный CertificatePinner, который с помощью своего конструктора закрепляет за доменом определенный fingerprint сертификата.
Этот fingerprint высчитывается из сертификата, с которым должно работать приложение, а затем пишется непосредственно в код.
Можно указать несколько сертификатов для разных доменов.
- Network Security Configuration
С версии Android 7.0 стала возможна настройка конфигурации сети. В папке res/xml/ создается файл network_security_config.xml, в котором прописываются правила и указываются fingerprints, как в случае с OkHttp.
Затем в AndroidManifest.xml прописывается использование данного файла в качестве android:networkSecurityConfig.
Этот способ позволяет редактировать сертификаты, не меняя исходный код приложения.
Способы обхода механизмов защиты
Frida – инструмент для динамического внедрения кода в приложение. Утилита прямо в процессе работы приложения способна отслеживать вызовы методов приложения, модифицировать методы приложения, обращаться к памяти выполняемого приложения и многое другое.
Для обхода SSL Pinning с помощью Frida есть несколько готовых скриптов, создающих кастомный TrustManager, который будет доверять нашему сертификату. Рассмотрим скрипт.
CertificateFactory и X509Certificate нужны для создания экземпляра сертификата из считанного файла.
FileInputStream и BufferedInputStream используются для считывания файла сертификата.
KeyStore – наш кастомный KeyStore, в который положим наш сертификат.
TrustManagerFactory создает экземпляр TrustManager, который будет работать с нашим KeyStore.
SSLcontext – реализация протокола SSL, которая выступает как factory для sslSocketFactory.
Считываем сертификат cert-der.crt, который мы предварительно поместили на устройство, и создаем экземпляр этого сертификата.
Создаем keyStore, в который складываем наш сертификат.
Создаем trustManager, который доверяет keyStore с нашим сертификатом.
Вот здесь начинается настоящее использование Frida. Данный фрагмент перезаписывает метод SSLContext. Теперь при вызове приложением метода сначала будет вызываться информационный лог в консоль, затем выполнится исходный метод, который мы перезаписываем. Но он вызовется не просто так.
Вместо второго параметра, который будет передан в функцию, новая функция подставляет кастомный TrustManager с нашим сертификатом. И в конце снова информационный лог в консоль о том, что все прошло удачно.
Таким образом, данный скрипт готовит TrustManager, а затем использует его в методе вместо того, который передается (переменные a и с передаются в вызов исходной функции, а вот переменная b заменяется на кастомный TrustManager).
Frida позволяет переопределять методы, выполнять собственные скрипты. Поэтому с помощью Frida можно обойти защиту, реализованную через OkHttp CertificatePinner.
Главное преимущество этого метода – отсутствие необходимости патчить исходный код apk и пересобирать приложение. А так как нам не нужно пересобирать приложение, значит этому способу не помешают методы защиты приложения от пересборки.
С другой стороны, для данного метода необходимо подключить телефон к устройству с Frida, установить frida-server на телефон, а это не всегда удобно.
- Изменение исходного кода и пересборка apk
В случае, если мы хотим один раз произвести обход средств защиты и получить приложение, в котором не будет SSL Pinning, необходимо изменить сам код приложения.
Для этого сначала нужно декомпилировать apk файл. Декомпилируется он в smali код. Smali – ассемблер для android-приложений. Все изменения будут производиться в .smali файлах, так как именно из них будет пересобираться приложение.
Для декомпиляции можно воспользоваться удобной утилитой apktool. Также для декомпиляции работы с разобранным apk, а затем и для сборки можно использовать удобное расширение для Visual Studio Code ApkLab.
Чтобы не копаться в трудночитаемых исходных кодах smali, вышеперечисленные утилиты умеют преобразовывать их в Java-код, который уже гораздо удобнее изучать. Также утилиты предоставляют функциональность деобфускации, которая очень помогает в изучении исходного кода.
ApkLab предоставляет также автоматизированный поиск необходимых участков кода. Рассмотрим что и почему он изменяет.
В первом файле утилита закомментировала исполнение следующих методов: checkClientTrusted, checkServerTrusted, getAcceptedIssuers.
По названиям методов можно предположить, что первый проверяет, является ли клиент доверенным, второй проверяет, является ли сервер доверенным, а третий получает лист доверенных сертификатов. Но не будем гадать и перейдем к Java-коду данных методов.
Теперь мы можем уже с пониманием рассмотреть, почему утилита закомментировала эти фрагменты. Первые два метода внутри ничем не отличаются и вызывают новый метод mo9499a (такое название из-за деобфускации), который слишком большой, чтобы вставлять его здесь. Но, судя по документации, этот метод строит цепочку сертификатов до корневого сертификата, а потом проверяет, можно ли ему доверять. В данном методе при ошибке будет выброшено исключение. Но мы закомментировали вызов данной функции, поэтому никаких проверок сертификат проходить не будет, и поэтому исключений мы не получим.
Метод getAcceptedIssuers должен возвращать массив доверенных сертификатов. Но дальнейшая реализация и использование данного метода работает таким образом, что если мы вернем пустой массив, то программа будет доверять любому сертификату. Именно это и сделала утилита: закомментировала код, в котором происходит получение сертификатов из keyStore (это происходит в методе m7931a), а вместо этого просто возвращается пустой массив.
Автоматический редактор кода заменяет эти фрагменты, т.к. они используются в проверке сертификата. Поэтому, если необходимо самому изменить какие-то фрагменты проверки, сначала лучше изучить, как работают те или иные методы, а затем уже вручную менять их в smali. К тому же обычно не приходится писать много кода вместо методов. В рассмотренном выше примере не делается ничего сложнее комментирования основной функциональности и создания каких-либо переменных-заглушек.
Также можно рассмотреть OkHttp CertificatePinner. В обзоре реализации был представлен фрагмент кода, где в OkHttpClient передается CertificatePinner. Найдя в smali соответствующий метод, можно убрать строчку, в которой CertificatePinner складывается в поле объекта OkHttpClient.
- Изменение NSC (Network Security Configuration)
Самый простой способ обхода SSL Pinning.
В случае, если в приложении присутствует NSC, необходимо его изменить. В файле NSC могут быть прописаны base-config и domain-config.
В base-config может быть указано, каким сертификатам приложение может доверять.
В domain-config настраиваются домены.
Для обхода защиты достаточно лишь убрать весь блок .
ApkLab также умеет делать автоматическое изменение NSC файла.
В случае отсутствия файла в проекте утилита создает его с указанным выше содержимым, а также прописывает его в AndroidManifest.xml.
- Подмена файла сертификата
В случае, когда защита реализована с помощью TrustManager, использующего KeyStore, в котором лежит доверенный сертификат. Обычно KeyStore вшит в приложение. В .apk KeyStore обычно лежит либо в /res/raw, либо /assets.
Поэтому можно просто положить туда свой сертификат вместо того, который установили туда разработчики.
Итог
В связи с тем, что SSL Pinning может быть реализован множеством разных способов, от различных библиотек, до кастомных реализаций привязки сертификата, задача его обхода не всегда простая и очевидная. Каждый раз, рассматривая новое приложение, нужно изучить, какие методы используются, а затем уже применять соответствующие способы обхода, которые тоже не всегда удобны и работоспособны.
Frida достаточно сильный инструмент, но возникает неудобство в виде постоянного подключения телефона к устройству, предварительной конфигурации и прочего. А если в интернете нет готового скрипта для нужных целей, то написание собственного требует хорошего понимания работы Frida.
Непосредственный патчинг apk хорош тем, что его можно сделать всего раз и на выходе будет приложение без SSL Pinning. Однако на этом пути может помешать защита приложения от пересборки. Конечно и ее можно попытаться обойти, раз мы имеем исходный код приложения, но это потребует больше времени и сил.
Изменение Network Security Configuration достаточно простой и рабочий способ, но редко когда приложения ограничиваются только этим способом защиты. Поэтому знание обхода этого способа SSL Pinning необходимо, но недостаточно.
Подмена KeyStore с доверенным сертификатом в файлах приложения тоже легко реализуется. Но опять же данный способ может не сработать в случае, если приложение при запуске проверяет, не было ли каких-либо изменений в файлах приложения (например, высчитывает чек-сумму).
Способ обхода
Способы защиты, которые можно обойти
TrustManager, OkHttp CertificatePinner
Источник: temofeev.ru