Я использую корневой эмулятор Magisk, целевой пакет — com.catdaddy.cat22. Системные http-инструменты CA установлены. HTTPS на стороне Java работает в обход TrustManagerImpl.verifyChain, но вызовы bobcatwweproduction.cdgsrv.com по-прежнему завершаются с ошибкой «сертификат отклонен». Я подозреваю, что критическим путем является собственный Cronet/BoringSSL.
Что я увидел:
libssl.so и libcrypto.so загружены. Нет libmbedtls.so. libcronet.so явно не присутствует, поэтому может быть статически связан/переименован
Списки экспорта содержат много символов: SSL_set_custom_verify, SSL_CTX_set_cert_verify_callback, SSL_set_verify, X509_check_, EVP_PKEY_verify, ... но: Module.findExportByName('libssl.so','SSL_get_verify_result'|'X509_verify_cert'|...) возвращает значение null или перехватчики никогда не срабатывают в потоке сбоя.
Подключенные компараторы в широком смысле memcmp/__memcmp_chk/bcmp/CRYPTO_memcmp/u_memcmp между модулями с фазовым шлюзом квитирования, чтобы не сравнивать попадания во время неудачного квитирования.
Подключена libc getaddrinfo/connect, и файл откроется* AAssetManager_open, поэтому для этого потока не читается .crt.
У меня есть вопросы:
В сборках Cronet/современных BoringSSL какие стабильные точки перехвата действительно принимают решения об имени хоста/сертификате/закреплении, если обычный экспорт X509_ / SSL_verify не срабатывает? Например, известные прокладки обратного вызова Cronet, пути QUIC или альтернативные верификаторы?
Почему символ может появиться в enumerateExports(), но быть неразрешимым с помощью findExportByName видимости/версионного символа/заглушки? Есть ли надежный способ подключить такие функции?
Если Cronet статически связан/переименован, какие символы или шаблоны мне следует искать, чтобы найти путь проверки TLS?
Цель: наблюдать, а не отключать точку принятия решения, чтобы понять, почему этот хост отклоняет сертификат при прохождении трафика Java. Наконец, чтобы увидеть запрос bobcatwweproduction.cdgsrv.com без блокировки сертификата.
Я использую корневой эмулятор Magisk, целевой пакет — com.catdaddy.cat22. Системные http-инструменты CA установлены. HTTPS на стороне Java работает в обход TrustManagerImpl.verifyChain, но вызовы bobcatwweproduction.cdgsrv.com по-прежнему завершаются с ошибкой «сертификат отклонен». Я подозреваю, что критическим путем является собственный Cronet/BoringSSL. Что я увидел: [list] [*]libssl.so и libcrypto.so загружены. Нет libmbedtls.so. libcronet.so явно не присутствует, поэтому может быть статически связан/переименован
[*]Списки экспорта содержат много символов: SSL_set_custom_verify, SSL_CTX_set_cert_verify_callback, SSL_set_verify, X509_check_, EVP_PKEY_verify, ... но: Module.findExportByName('libssl.so','SSL_get_verify_result'|'X509_verify_cert'|...) возвращает значение null или перехватчики никогда не срабатывают в потоке сбоя.
[*]Подключенные компараторы в широком смысле memcmp/__memcmp_chk/bcmp/CRYPTO_memcmp/u_memcmp между модулями с фазовым шлюзом квитирования, чтобы не сравнивать попадания во время неудачного квитирования.
[*]Подключена libc getaddrinfo/connect, и файл откроется* AAssetManager_open, поэтому для этого потока не читается .crt.
[/list] У меня есть вопросы: [list] [*]В сборках Cronet/современных BoringSSL какие стабильные точки перехвата действительно принимают решения об имени хоста/сертификате/закреплении, если обычный экспорт X509_ / SSL_verify не срабатывает? Например, известные прокладки обратного вызова Cronet, пути QUIC или альтернативные верификаторы?
[*]Почему символ может появиться в enumerateExports(), но быть неразрешимым с помощью findExportByName видимости/версионного символа/заглушки? Есть ли надежный способ подключить такие функции?
[*]Если Cronet статически связан/переименован, какие символы или шаблоны мне следует искать, чтобы найти путь проверки TLS?
[/list] Цель: наблюдать, а не отключать точку принятия решения, чтобы понять, почему этот хост отклоняет сертификат при прохождении трафика Java. Наконец, чтобы увидеть запрос bobcatwweproduction.cdgsrv.com без блокировки сертификата.