Recently tweeted on a bypass for Snapchat's cert pinning. It required monitoring 'android_dlopen_ext' to instrument the native target library directly after load.
Absence of 'adroid_dlopen_ext' on older Android SDKs raised some questions, so I'll share a partial solution.
1/n
Absence of 'adroid_dlopen_ext' on older Android SDKs raised some questions, so I'll share a partial solution.
1/n
The appended screenshot shows an alternative approach to monitor loading of dynamic modules for JNI based on 'JavaVMExt::LoadNativeLibrary'.
Below it is showcased with @fridadotre frida-trace (upper terminal) and a modified script for the frida-trace hook (lower terminal)
2/n
Below it is showcased with @fridadotre frida-trace (upper terminal) and a modified script for the frida-trace hook (lower terminal)
2/n
As pointed out in the comments, you have to deal with C++ mangled function names and the std::string implementation of the respective C++ library, to do it in this way (less clean than the 'android_dlopen_ext' approach).
3/n
3/n
No matter which approach you use, once you are sure the native library is loaded, you could hook it as needed, before returning execution to the instrumented Thread (in case of Snapchat, the target would be 'libclient<.>so' for example).
4/n
4/n
Also, one might think monitoring 'dlopen' directly could do the trick, but this would miss a decent amount of hot-loaded JNI modules. Also I often faced crashes when using Frida's Interceptor.attach on 'dlopen', which could be partially mitigated by using ...
5/n
5/n
... Interceptor.replace with a proxy function instead (see screenshot for an example).
That's it ... happy hooking friends!
6/6
That's it ... happy hooking friends!
6/6
• • •
Missing some Tweet in this thread? You can try to
force a refresh
