httptoolkit/frida-interception-and-unpinning

SSLPeerUnverifiedException: Certificate transparency failed

flamecopper opened this issue · 1 comments

== System certificate trust injected ==
== Certificate unpinning completed ==
== Unpinning fallback auto-patcher installed ==
Manually intercepting connection to ::ffff:3.108.122.90:443
Manually intercepting connection to ::ffff:52.87.6.154:5047
Error: access violation accessing 0x0
at (/xxxxx/Pentest/frida-interception-and-unpinning/native-tls-hook.js:111)

!!! --- Unexpected TLS failure --- !!!
SSLPeerUnverifiedException: Certificate transparency failed
Thrown by s33->intercept
[ ] Unrecognized TLS error - this must be patched manually

!!! --- Unexpected TLS failure --- !!!
SSLPeerUnverifiedException: Certificate transparency failed
Thrown by s33->intercept

!!! --- Unexpected TLS failure --- !!!

!!! --- Unexpected TLS failure --- !!!

!!! --- Unexpected TLS failure --- !!!

!!! --- Unexpected TLS failure --- !!!

!!! --- Unexpected TLS failure --- !!!
SSLPeerUnverifiedException: Certificate transparency failed
Thrown by s33->intercept

!!! --- Unexpected TLS failure --- !!!
[ ] Unrecognized TLS error - this must be patched manually

!!! --- Unexpected TLS failure --- !!!
SSLPeerUnverifiedException: Certificate transparency failed
Thrown by s33->intercept
[ ] Unrecognized TLS error - this must be patched manually
SSLPeerUnverifiedException: Certificate transparency failed
Thrown by s33->intercept
SSLPeerUnverifiedException: Certificate transparency failed
Thrown by s33->intercept
SSLPeerUnverifiedException: Certificate transparenc

Hi @flamecopper. Is it possible to share the details of the app where you're seeing this?

The scripts here do include unpinning for various certificate transparency cases, but in this example it looks like the libraries being used have been obfuscated (the s33 for example suggests this). There is a fallback unpinning script which handles various specific obfuscated cases, but it doesn't focus on transparency issues yet.

In theory this is very possible though, we'd just need to know more about the internal content of the failing function here. If you could share a specific example so I can take a closer look then that would be helpful to work out how to handle this.

If you're interested in investigating and fixing this yourself in the meantime, I've written a guide you might find useful here: https://httptoolkit.com/blog/android-reverse-engineering/. Even if you can't share more details about the app in question, if you could share the decompiled code of the failing class (s33) via JADX, that might be enough to solve this.