3

I have been diving into an apk's source code, doing both static analysis with Jadx (same as dex2jar) and dynamic analysis with Frida.

I am trying to replicate the method that signs HTTP requests "signRequest". The thing is that it is only declared in an interface and nowhere in the code is there an actual implementation of that method. When I use Frida to get the instance that uses this method, I can run the method and make it work. The instance in question is like this: com.xxx.yyy.zzz@24d6bf8 but the thing is that the class com.xxx.yyy.zzz, and even the module com.xxx.yyy, do not exist in the source code.

Do you have any idea how this might happen?

EDIT: I've had a hunch and thought that maybe, since I had encountered "antidex2jar" classes in the source code, maybe there were protections against dex2jar making it throw errors, therefore preventing it from decompiling the classes, as I had read somewhere. However, even the smali code on Android-Studio doesn't contain the class.

Improve this question

1 Answer 1

Reset to default
5

There are multiple possibilities how this might happen.

  1. The code is loaded dynamically at run-time, e.g. for an [obfuscated/encrypted] dex file that is present in the APK file but does not follow the standard naming scheme /classes*.dex. In case the whole application code is located in such external code files most likely an "APK packer" tool (like DxShield, DexProtector, ..) has been applied on the application. You can try to use APKiD to identify the used packer.

  2. The code is downloaded from an web-server and then loaded dynamically.

  3. The code is generated on-the-fly at run-time. This can happen if e.g. based on an interface some proxy-classes are automatically generated using other code as base (e.g. for handling HTTP-[JSON]-RPC calls that are automatically translated to method calls). But usually this code is not located in a new package.

As your question includes the Frida tag you should try to use it (if it works on that application) and check the application at run-time what classes are loaded. You can hook the various classloader methods that allow to load (dex) byte code at run-time and dump/save the loaded byte code.

Alternatively there are some tools and tutorials online that claim to be able to defeat Android packers and dump all Dex classes.

Improve this answer
4
  • 1
    Thank you so much for your valuable and detailed answer Robert! I have done exactly what you prescribed. 1. I went through the source code and looked for occurences of the "loader" string which helped me find in the module of interest a function that returned a type of DexClassLoader, which is from the package dalvik.system.DexClassLoader. 2. I hooked the constructor of the class that initialized with this DexClassLoader, making it display it. It showed the class loader path. 3. With Java.openClassFile(classLoaderPath).getClassNames(), I found out if the class that interested me was in there.
    – Kévin
    May 8, 2020 at 13:14
  • I found out it was in one of them. 4. I used adb pull classLoaderPath to get the dex file in question. 5. I used jadx to decompile it and I finally found the implementation of my function signRequest. Thank you so much once again!
    – Kévin
    May 8, 2020 at 13:15
  • @Kévin Thanks for the feedback and your description what you did.
    – Robert
    May 8, 2020 at 13:30
  • Just to add: there is a simpler way than going through the code. Frida's Javascript API includes the function Java.enumerateClassLoaders(callbacks) on Android Nougat (v7) and beyond. It works like a charm.
    – Kévin
    May 8, 2020 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.