[ollyfg]

Wow! How have I not heard of frida? This should make my normal process much simpler!

1) Decompile App -> smali

2) Decompile App -> Java (non-reversible, but easier to read)

3) Search the app for certificate pinning code (check for network_security.xml or grep for OKHttp pinning functions)

4) Find the code I just found in java, in the smali version

5) Remove the pinning code

6) Recompile smali -> apk

7) Fix whatever was causing the smail not to recompile

8) Recompile again

9) Pray

10) Install on device

11) Run app (that hopefully doesn't crash)

12) Pipe connection through Charles proxy

13) Read api calls!

I'll definitely give it a go.

In general I think there are nowhere near enough resources on decompilation, particularly on a purportedly "open" platform like Android. Really looking forward on the rest of the tutorial coming online.

[Lukas_Skywalker]

As an alternative, you could use the XPosed framework. It basically lets you overwrite App and System methods and classes by installing a small module. No need to modify your target apk. So you can just return true from the method that checks if the correct certificate is in use.

[ignoramous]

XposedMod is amazing but you could override methods with Frida, as well. Just that Frida works both with or without having to root the device.

[sonnyblarney]

"there are nowhere near enough resources on decompilation, particularly on a purportedly "open" platform like Android."

Most apps are definitely not 'open' and unfortunately most of 'reverse engineering' has nefarious intentions.

Once one has had key code stolen from them, it changes one's perspective a little.

[voltagex_]

Unless your APK is internal and not distributed outside a small circle, assume your code has been reverse engineered.

Surely if you're running something that has to be that "closed", most of the key code is server side and the client is just calling APIs.

Reverse engineers are not your enemy.

[sonnyblarney]

"Unless your APK is internal and not distributed outside a small circle, assume your code has been reverse engineered."

Of course, but doesn't obviate the illegality of stealing protected code.

"Reverse engineers are not your enemy."

Yes, many of them are.

Many of these resources and individuals are involved in illegal and immoral acts around stealing code and IP, and justify it to themselves on some kind of skewed logic.

Nobody really cares that folks are hacking code for fun, and nobody cares that people would use resources for this purpose. This is fine and possibly helpful.

But IP theft is a big deal, and it's very damaging.

"Surely if you're running something that has to be that "closed", most of the key code is server side and the client is just calling APIs"

Unfortunately, this isn't possible in a variety of cases, especially new and upcoming scenarios that require AI to be 'on device'. There are many other such scenarios.

It's very oppressive to a major class of innovation - particularly to those who've worked very hard to assemble something exceptional and useful.

[saagarjha]

Are you suggesting that reverse engineering resources not be made available because you feel it will lead to people stealing code?