1

I'm trying to intercept traffic from an Andriod app.

I've forwarded ports 80, 443, 6699 and 6698 on Kali to a listener port and set up arp-spoofing. I'm using BurpSuite on the same computer to listen and intercept (invisible proxy).

Certificates have been installed properly on both host and device and are working for all traffic except the app I'm interested in.

Using Frida I've tried various SSL pinning bypass scripts (the most popular) and none have been successful, Burp continues to report a TLS fatal exception ca_unknown and the app's function remains restricted.

The app in question is a ISP router companion app, you use it to get live information about the internet connection and can use it to change settings on the router. The traffic is local, using TCP port 6699 but can also use 6698.

Are there any clues I can look for in the apk which may point me towards the SSL methods being employed by the app? I've had a look and can see directories for OKHTTP3 and BouncyCastle.

The parts of the app that communicate remotely (cloud API calls) can be intercepted without issue.

Could the problem be something entirely different than SSL pinning given this particular issue is solely based on local communication? My train of thought being, why employ SSL pinning for traffic that'll only ever be local?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Doby
  • 11
  • 2
  • The anti-pinning scripts I know only work for OkHttp if the class names are not obfuscated. If they are in your APK you may need to manually identify the class the pinning takes place and modify the anti-pinning hook script. – Robert Jul 23 '21 at 01:39
  • I've seen mentions of certificate pinning in the the code (using jadx-gui) so presumably that's the problem. The certificates are kept in .bks keystores. Would it be crazy to look for the keystore passwords in the code so I can replace them with my own? I'd imagine it usually shouldn't be that easy (if they're easily identifiable). – Doby Jul 23 '21 at 09:35
  • A keystore for certificate pinning is pretty unusual. I would suspect that the keystore content is a custom root-ca certificate or alternatively a client certificate + key. The keystore password should be easy to get if you use `frida` for hooking the keystore related methods that get the password as parameter. May be this is even possible using `frida-trace`. AFAIR Objection should already contain hooking scripts for Java KeyStore class. – Robert Jul 23 '21 at 09:44
  • You may have to write a custom bypass with Frida. – multithr3at3d Jul 24 '21 at 13:47
  • So it turns out the .BKS keystores (there's multiple) don't have passwords. Presumably I can add to them and/or extract from them to find a solution? I really need to read up about root certificates because I don't understand how they work. – Doby Jul 24 '21 at 23:30

0 Answers0