对于绕过ssl pinning的产品有很多，其中最著名的当属JustTrustMe。其他的sslUnPinning产品思想很多都是从JustTrustMe那里抄来的，由于JustTrustMe原作者也不更新了但是反sslUnPinning技术一直在前进，所以我决定用1一个月的业余时间来重新打造一款实用的sslUnPinning产品。

JustTrustMe我是很认可他的插桩点位的思路的。但是，本人是不认可xposed的。xposed的hook机制从设计之初就走了一条“不归路”，因为xposed有太多的特征可以被app检测。主要是xposed必须基于替换受精卵进程来实现，并且还要安装对应的app来管理插件，而且插件开发也要是单独的android工程。这个对于被攻击app来讲非常好从多个维度去检测xposed的存在，只是人家不想搞的这么明显大多不会强制退出app罢了。比如微信大家去jadx搜索代码，里面妥妥去检测了xposed，人家早就把你标记了。有些小team拿着官方已经停止更新的xposed改改包名，然后称之为魔改过反检测。其实，我要检测你，你怎么改都反不了。你包名改掉，但是你自定义的包名依然在调用栈里面。通过对比纯净android系统的正常堆栈，你立马被标记为灰度用户。还可以通过扫描已经安装的app列表，发现类似justtrustme之类的应用立马标记。还有你xposed管理本身也是一个app，你怎么隐藏？ 改操作系统吗？但是，话又回来了，你都可以改操作系统了那你为什么不直接在framework层直接嵌入hook机制呢？因为，你技术还没到那一步，你只是停留在andorid项目改改包名的阶段，只能靠着这个去收割一些新人的韭菜。不好意思阿，我这人说话就是这么直！你费劲巴拉的搞一个大型项目，完了效果并不是真的全面反检测。我觉得没必要去做。

我想xposed的作者rovo89也是看到了这一点，所以没有再对xposed进行更新了。大庄家都不玩了，我们这些蝼蚁就要认清局势。该废弃的技术废弃，要舍得抛弃陈旧的技术这样你才能不断进步。我要把JustTrustMe用frida实现一版。所以先出一篇JustTrustMe源码分析，等大家熟悉了JustTrustMe源码我再带着大家用frida去搞一个"JustTrustMe"：

请大家先打开JustTrustMe的Main.java，我下面会一一列举JustTrustMe的每个方法，以及它的作用和对应java的伪代码。

分析：三个构造方法的目的都是在new DefaultHttpClient之后替换connManager参数。而getSCCM()方法就是返回一个不安全的ClientConnectionManager。
getSCCM()和getCCM()实现如下：

那么，由此我们得到经过hook之后三个方法的伪代码逻辑。

分析：X509TrustManagerExtensions原方法会进行一系列的效应证书和服务器是否可信。这里xposed用了XC_MethodReplacement直接替换方法的执行体。
那么，伪代码逻辑如下：

分析：原NetworkSecurityTrustManager类的checkPins方法List参数原型是List<X509Certificate>。校验X509Certificate集合是否合法，如果不合法就会抛CertificateException。这里xposed用了XC_MethodReplacement直接替换方法的执行体，并且什么都没做。
那么，伪代码逻辑如下：

分析：这个稍微有点复杂，但目的很简单。就是为了替换TrustManager，而TrustManager不可以直接传进来，是内部创建一个sslcontext来包装一个TrustManager[]。所以要new一个自定义的sslcontext然后把ImSureItsLegitTrustManager传进去。sslcontext对象要进行init()所以整个代码看起来比较多。

给你看伪代码，那逻辑将一目了然：

分析：很好理解
伪代码：

分析：强制让isSecure返回true
伪代码：

分析：如果存在com.android.org.conscrypt.TrustManagerImpl这个类的，并且返回的TrustManager[]的长度大于0，并且TrustManager[]第0个是com.android.org.conscrypt.TrustManagerImpl实例，则什么都不操作。否则直接把返回值改成TrustManager[]{new ImSureItsLegitTrustManager()}

伪代码：

分析：让setDefaultHostnameVerifier方法失效，让setSSLSocketFactory失效，让setHostnameVerifier失效
伪代码：

分析：不用第0和低2个参数，而第1个参数使用TrustManager[]{new ImSureItsLegitTrustManager()}

伪代码：

分析：由于xposed基于zygote进程孵化app进程，hook非常早。所以如果它想对应用层的类进行hook的话，必须等Application的attach调用之后才能拿到应用级的ClassLoader。那么在attach之后他又进行了processOkHttp、processHttpClientAndroidLib、processXutils方法的调用，分别对应okhttp库的hook、httpclientandroidlib库的hook、org.xutils.http的hook。这三个是应用喜欢用的三方http库。
伪代码：

分析okhttp包名不统一问题：由于okhttp 2.x和3.x包名相差比较大。所以这里第一个hook你可以看到justTrustMe试图去找com.squareup.okhttp.CertificatePinner类，这是为了尽量兼容老安卓项目。

分析CertificatePinner.check：无论是okhttp2.x还是3.x、4.x都是有CertificatePinner.check(String str, List<Certificate> list)这个方法的。可以上面第一二个hook做的是XC_MethodReplacement，并且什么都不操作。对比原check方法，我们知道这个目的是为了阻止check抛SSLPeerUnverifiedException异常。
CertificatePinner.check伪代码：

分析：第三四个hook OkHostnameVerifier.verify()，校验hostname是否合法最终会调用verify(str, (X509Certificate) sSLSession.getPeerCertificates()[0]);说明还是对远程服务证书进行了校验，这里直接用return true替代了原来的逻辑。

分析：一个冷门http库的hook
伪代码：

分析：一个冷门http库的hook
伪代码：

到目前为止，我们已经把JustTrustMe所有的hook点位全部分析了一遍。中间如果大家还是有不解的地方可以去查看每个类对应的源码，下列我帮大家找了一些

JustTrustMe Main.java

apache http DefaultHttpClient.java

android framework X509TrustManagerExtensions.java

android framework NetworkSecurityTrustManager.java

apache http SSLSocketFactory.java

javax TrustManagerFactory.java

javax HttpsURLConnection.java

javax SSLContext.java

android framework TrustManagerImpl.java

okhttp3 CertificatePinner.java

okhttp3 OkHostnameVerifier.java

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！