[2] Perform static analysis to locate some functions of interest

Search…
To begin the static analysis phase, we will need a copy of our APK file to serve as our specimen. There are a number of ways to obtain this:
Extract a sample from the device directly (see guide here)
Work with the acquired device data.
Note the version from your acquired content and download a website (like APKPure)
In our lab, the specimen has already been obtained and can be found in the lab directory under "APKs".
Let's fire up jadx gui. This is a free reverse engineering tool for Android APKs. It requires the Java Runtime Environment (JRE) 8 installed, but is also available prepackaged in a version that includes it. The releases page for jadx can be found here. Look for the download ending with "-with-jre-windows.zip".
Once launched, it will give you the following Open File dialog. If you downloaded the lab kit, look in the folder called 'APKs'. Double click to open the APK.
Once loaded, you can begin browsing through the list of classes on the lefthand side. You will see lots of entries beginning with 'android', 'com.facebook' etc. A lot of these are from libraries used by the app. Rather than sifting through this list manually, we will use the clues we established in Lab 1 in order to point us in the right direction.
To open up the text search window, press CTRL+SHIFT+F or select it from the Navigation menu.
The first time you open the text search, it will take some time as the app has to perform APK-wide decompilation. When finished, we are ready to start searching for our suspects.
Let's search for some values from lab 1.2, starting with pin
So we do hits, but... 3k is a lot to go through and as you can see, there is significant false positives. So, what do we do? Well, in our case the key for pin is a string. In Java, strings are enclosed in double quotes. Let's modify our search to include double quotes and see how we do on results:
Much better. Now, instead of "android.support" (and many others) we are seeing only classes from within the "com.github.browep.privatephotovault" namespace and, if we look at the Code side of the view, we can see some super interesting stuff.
At this point, we have developed some leads to investigate using static analysis.
Looking at the list, in the class CryptoUtils, we see two calls to a function called pinsMatch, so let's check that out by double clicking on the result and then right clicking and choosing "go to declaration".
In this case, it turns out the target function is only a few lines away! But, Go to declaration is capable of looking across the whole APK and can be very useful.
Alright, so there's a couple of things happening here. However, rather than working to develop an understanding first, then testing later, let's dive in to some DBI to give us a bit of a roadmap to follow.
Unlike many APKs, this one is not obfuscated. Were it obfuscated, instead of seeing com.github.browep.privatephotovault.crypto.CryptoUtils.pinsMatch we might see a.b.a.c.d.d.a.
If this happens, all is not lost, we simply have more work to do in terms of static analysis. Dealing with obfuscation is out of scope for this lab, but rest assured it's still very doable.
[1.2] Review files in the app data directory
Next - Lab
[3] Deploy method hooks using frida REPL
Last modified 2yr ago
Copy link