Thread by @mame82

Comparison of

1) TikTok TLS connections with several Cert Pinning bypasses (targeting Java layer of common SSL implementations, not custom native implementations)
65% error

vs

2) CertPinning bypasses disabled (CA cert is still placed in Android's system store)
100% error

The "success to error ratio" of intercepted requests with CertPinning largely depends on the app and the respective SSL pinning implementation(s) in use. The 65% error of "TikTok" are the "worsed case".

Here's a broader look showing this ration for other apps (no captions)

Did additional event enrichment for failed connection (caused by client disconnect, likely CertPinning).

I want to share an idea for a generic Cert Pinning bypass, cause I have no time to implement it.

Here is a full event for a failed connection to 'api16-core-c-alisg.tiktokv.com'

First some details on the event, which mainly consists of data from @mitmproxy and associated data from the client device's process (Android device, connection associated based on TCP source IP/port)

...

The correctly associated request source is the "TikTok" app from the Android device "SM-G900F".

The target IP "104.96.1.32" was resolved by mitmproxy and enriched with GeoIP data from MaxMind databases (Netherlands)

The TLS handshake failed with an "sslv3 alert certificate unknown" error, which was collected by mitmproxy, but caused by the (app's) SLL client (CertPinning).

The request method is "CONNECT", because the proxy is not working transparently, and thus includes request headers.
...

The user-agent string from the request headers hints to "Cronet/TTNetVersion:d76f478b" ... which means Cronet was modded by TikTok.

Further down in the event data, under 'event.sockEvent', the information from the device's 'libc.so connect' syscall is included

The TCP connect syscall does not correspond to the actual SSL handshake, but the app code responsible should be closely related. I added in a stack trace for this syscall, which consists of native pointers and debug symbols (if available)

...

This stack trace, again, points to cronet - namely 'libcronet.so' which is shipped with TikTok's native libraries

(see screenshot from device console)

Now the common approach would be to use the known data as starting point for reversing of the 'libcronet.so' cert pinning implementation. To develop a bypass would be time consuming and only apply to this exact case

My idea is the following:

The error events could be further enriched with the public key of the legit TLS server certificate of the request target.

Whenever a TLS client error (like the one shown above) occurs, it gets extracted and forwarded to the @fridadotre which ...

...is instrumenting the associated process.

The Frida agent now could search the heap of the app process for the public key (which should be there, as it is needed for pin checks). Once found, the pinned key could be replaced with the one from the proxy generated certificate
..

...
This would allow successive connections to succeed (bypass cert pinning check). The "key replacement pattern" generated in this manor could further be stored persistently and ultimately be re-applied to process related to the app, right when they start (Frida spawn gating)...

... or once Frida attaches to the already running process.

Also reads on the memory addresses holding the keys could be traced, to ease up reversing of native code.

Not sure if this idea would work, butI am keen to hear some feedback

@leonjza @mobilesecurity_ @singe @oleavr