javax.net.ssl.SSLPeerUnverifiedException: Hostname not verified about apk-mitm HOT 14 CLOSED

@shroudedcode I can confirm that v0.11.1 works out-of-the-box for same app

from apk-mitm.

@anilatx

seemingly there is some pinning that was missed by the apk-mitm (I noticed that briefly it has shown "no pinning detected")

That could very well be the case. apk-mitm currently only patches pinning logic that's using the javax.net.ssl.X509TrustManager interface by searching for the three relevant methods in all *.smali files.

javax.net.ssl.SSLPeerUnverifiedException: Hostname foo.com not verified:

This exception also comes from the javax.net.ssl package, but there's no mention of the X509TrustManager interface anywhere, so that doesn't seem to be involved here at all.

at okhttp3.internal.connection.RealConnection.b(SourceFile:22)

The app is using the OkHttp library, which has its own way of setting up certificate pinning. I found this guide on circumventing it, so maybe you could give that a try. The --wait flag could come in helpful for that.

from apk-mitm.

Thanks! I started with simple ignoring exception in okhttp3.Handshake class, changing
.catch Ljavax/net/ssl/SSLPeerUnverifiedException; {:try_start_0 .. :try_end_0} ::catch_0
into
.catch Ljavax/net/ssl/SSLPeerUnverifiedException; {:try_start_0 .. :try_end_0} :goto_0
But I get
zygote : Rejecting re-init on previously-failed class java.lang.Class<okhttp3.Handshake>: java.lang.VerifyError: Verifier rejected class okhttp3.Handshake: okhttp3.Handshake okhttp3.Handshake.get(javax.net.ssl.SSLSession) failed to verify: okhttp3.Handshake okhttp3.Handshake.get(javax.net.ssl.SSLSession): [0x2A] type Conflict unexpected as arg to if-eqz/if-nez (declaration of 'okhttp3.Handshake' appears in /data/app/com.myapp-fxq0DA7v3ZpYEHcw8McmXg==/base.apk:classes27.dex)
This is the only Handshake class in the sourcecode. Am I doing something wrong? Or could they have some tough protection that stores duplicates of key classes in binary data or downloads them from a server?

from apk-mitm.

Verifier rejected class

This probably means that your changes to the Smali code were invalid (see relevant SO answer). Smali is a representation of Java bytecode, so it can be difficult to make changes without breaking things. (That's why apk-mitm is replacing entire methods instead of making more "precise" changes.)

Could you create a secret Gist with the relevant Smali files (Handshake and CertificatePinner if it exists) and post it here?

from apk-mitm.

@shroudedcode
https://gist.github.com/anilatx/e6fd8d166baaecb5e1a4efbf0720aecb

Also: original pinner java source might be useful https://android.googlesource.com/platform/external/okhttp/+/bad0a11146d43955d3f3b949aa277f0dd7cc3abb/okhttp/src/main/java/com/squareup/okhttp/CertificatePinner.java

I'll keep searching for smali modification that works

from apk-mitm.

The check method on the CertificatePinner class doesn't return anything when the verification is successful, so maybe you could try replacing the entire method with this (the equivalent of return; in Java):

.method public check(Ljava/lang/String;Ljava/util/List;)V
    .locals 0
    return-void
.end method

from apk-mitm.

Apparently this is not the only place, https://github.com/1184893257/okhttp/blob/master/okhttp/src/main/java/com/squareup/okhttp/internal/io/RealConnection.java can also throw this SSLPeerUnverifiedException (and it does, when I fixed CertificatePinner). I managed to get the MITM to work replacing two verify() in connectTls: https://gist.github.com/anilatx/23ac1c41a2ad8301087d78ce51ae00b9
I suspect that to prevent random disabled fuctionalities, it might be necessary to disarm similarly other instances of javax.net.ssl.SSLPeerUnverifiedException, there are plenty https://gist.github.com/anilatx/9ab259f89b7d12a555319f69dbc59380

from apk-mitm.

I managed to get the MITM to work replacing two verify() in connectTls

That's great news! OkHttp is pretty popular, so if we manage to find a way to apply these changes automatically we'd be able to make many more apps patchable using apk-mitm.

I suspect that to prevent random disabled fuctionalities, it might be necessary to disarm similarly other instances of javax.net.ssl.SSLPeerUnverifiedException

Good point. It would be best if we could remove all "throws" of that exception using a single rule regardless of the library, but I doubt there's a way to do that reliably. Putting together a list of function signatures for OkHttp (similar to what I've already put together for X509TrustManager) would probably be good enough though.

To do that I would need an APK to investigate. I see you've censored the name of the app you're trying to patch in your comment, but could you privately share that APK (or a link to it on a site like APKPure) with me via Telegram or email (see my GitHub profile)? If that's not possible, could you find another APK that also uses OkHttp and has similar protections enabled?

from apk-mitm.

I've received your email, so I can now take a look at all the Smali sources.

I managed to get the MITM to work replacing two verify() in connectTls

Can you clarify what you mean by that? What did you replace these calls with? Also, did you make these changes in the Smali code or in Java (using something like jadx or smali2java)?

from apk-mitm.

The email included modified two already modified smali (I can upload them/diff somewhere public in the evening), I basically replaced calls to verify with setting unused variable to 0, directly in smali (I read Java code only as roadmap )

from apk-mitm.

The email included modified two already modified smali

Whoops, totally missed the attachments. 😅 I'll take a look at your changes!

from apk-mitm.

I've taken a look at your changes and I even found a slightly more robust way to disable host name verification (which involves patching the verify method on implementations of the javax.net.ssl.HostnameVerifier interface). The question is though: Is this something apk-mitm should even do? I was testing the APK using the Charles and even without the host name verification changes I was able to look at all the traffic.

I suspect that SandroProxy, which you seem to be using, might not correctly generate its certificates to include the "Common Name" and "Alternative Names" the verification logic is looking for. You could see if this is the case by opening a website in Chrome on Android (Firefox would probably work too) and viewing the certificate information before and after you've enabled the proxy. The domains in the two fields I mentioned should be the same in both cases.

from apk-mitm.

@anilatx Any updates on this? I'd be happy to implement a fix to disable host name verification, but I want to make sure I actually understand the issue and its cause first.

from apk-mitm.

This was fixed in 0f85c10.

from apk-mitm.