Add support for okhttp3

[Journeyman111]

Hi, this method doesn't work on the app i'm trying to bypass the ssl pinning.
is there way for you to add "okhttp3" - support PLEASE?
or make separate module supports "okhttp3 certificate pinner"
there is a old module called : sslUnpinning - it says it support it -but it doesn't work....
since i'm kind of noob to programming - i'm just scratching the surface so many ways without a depth :(. and failing - not lack of trying though...
when i patched the app then recompiled & signed it - after installing it - when i tried to start it - it crashes... also tested it just de-compiled & recompiled without any modification - same issue... - i'm guess some kind of tamper - protection placed on it....
also tried Frida, after injecting the script (it says spawned) then- it immediately crashes....
also tried writing the xposed module myself..... :)) --- probably it would be very laughable for You if you saw how i went about it... so don't even need to mention any further...
Probably this is child play for You since You have a wealth of knowledge.

I'm in great need for module contains similar functions to script below..... Would You please please please help?!

"var CertificatePinner = Java.use('okhttp3.CertificatePinner');
CertificatePinner.check.overload('java.lang.String', 'java.util.List').implementation = function (str) {
console.log('! Intercepted okhttp3: ' + str);
return;
};"

[ViRb3]

Hey, thanks for reporting. I am heavily short on time right now, but I will try to get back to this as soon as I can.

[ViRb3]

I almost have this working, the only thing I am missing is a way to enumerate all loaded classes. Any ideas? Maybe using the ClassLoader somehow?

[jpstotz]

Can you elaborate your approach a bit and why you need a list of all loaded classes?

[ViRb3]

Basically, okhttp3 performs SSL verification independent of any system code. Since it is embedded as a library in every application and often obfuscated (ProGuard), you cannot find and hook the right class and method by name anymore. I created a set of rules to compare any method and figure out if it's the okhttp3 SSL check method. But to do this, I have to enumerate all loaded classes in an app.

[dererror33]

https://github.com/Hamz-a/jeb2frida need use..

[ViRb3]

This still requires a computer and decompilation. I already created a 'universal' signature, I just need a way to search for it in an app using Xposed Framework.

[jpstotz]

@lurumdare JEB2 is a little bit expensive (1k USD / year). However at least a manual TrustMeAlready module configuration option for entering the class and method name of Okhttp3 CertificatePinner.check method would be good.

@ViRb3 I see two possibilities (have not tested any of the proposed methods yet):

1. Hooking the classloader loadClass method to get the class names(s) when each class is loaded
2. Check what actual type the classloader is and check if there are internal fields available which contain the list of loaded classes. This has two disadvantages: (1) it may not work on all Android versions the same way and (2) you only get the list of loaded classes, therefore it is a question when to enumerate the classes.

I have a third approach in mind which could be used for a semi-automatic approach:
Hook the constructor of javax.net.ssl.SSLPeerUnverifiedException which is thrown by the CertificatePinner.check(...) method.
Once this hook fires it should be possible to get the stack-trace and identify the class and method name of the CertificatePinner.check(...) method. It could then be added to the TrustMeAlready configuration as okhttp3 method to be hooked.
Unfortunately I don't think that it is possible to suppress this first thrown SSLPeerUnverifiedException, as we can't "disarm" the exception in it's constructor.

[ViRb3]

I tried hooking ClassLoader.loadClass, but in Zygote (system) mode I get no results, while in application mode I only dynamically loaded classes.
I also tried some method posted in Chinese forums that traverse the Dex file and parse the classes from there, but then I get exceptions that the classes haven't been loaded yet.
The third approach is interesting, but there's no reason to do it so hackily if we can do it in a cleaner way.
Any proof of concept code is very welcome!