Disassembling the APK

Setting the “android:debuggable” Flag

Reassembling and Signing the APK

After this, we have to repackage the APK. To do this, we have to build and sign it. If you have already set up your Android Studio with your keystore, then skip this section, but if not, follow along. In Android Studio, start a new Empty Activity project. Then on the Build menu, select Generate Signed Bundle / APK…. You should see a window asking whether you want to build an Android App Bundle or APK. Select APK and then you should see a dialog similar to Figure 7-1.

Next, click the Create new… button and fill in the fields in the subsequent dialog as show in Figure 7-2.

Make sure to select a path and file name that you remember. Then fill in a password for the keystore and for the private key that we’re calling key0. You can rename it if you wish. By default, Android Studio selects a validity period of 25 years; I have brought that down to 1 year as you can see. I have also added my first and last name to the corresponding field. Now click OK. You should be taken back to the prior dialog with the corresponding fields filled in. Click Next to move along. You will be asked to select a Build Variant. Pick debug, then click the V1 (Jar Signature) checkbox, and click Finish.

Android Studio will do its thing and build and sign your APK. It should also build you a nice keystore file in the directory you selected.

Now you may be wondering why the hell I asked you to build an Empty Activity project just so you get the side effect of building a keystore, and you would not be wrong in thinking I’m trying to waste more page space, but let me explain. The alternative is to build the keystore from the command line. Before you do that, however, you will need to have the latest Java Development Kit (JDK) installed.

Install the JDK by visiting this URL: www.oracle.com/java/technologies/javase-jdk14-downloads.html.

You will have to pick the correct installer for your platform. The preceding link contains a link to JDK version 14, which was current as of writing this book.

Going back to why I asked you to build the keystore with Android Studio, it’s a lot easier – especially if you’re still struggling with the JDK. After we have repacked our edited app, we have to sign it. If not, we can’t install it on an emulator or device. To sign, we can use either apksigner or jarsigner. Because you accused me earlier of wasting page space, I’m going to show you both. So there.

Debugging with JEB

Let’s continue with the Crossword app that we just changed to enable debugging. Fire up JEB and open the com.nytimes.crossword.apk file. JEB works like how you would do a lazy load of images on an ecommerce site. Only load the resources as needed when you get to that point. This is good because when decompiling an APK, it can get pretty big on disk, and it is a lot of stuff to keep in memory. JEB will always tell you if your APK has a lot of resources to process and will ask you whether to load it now. I usually say no to this because it just gets loaded later on anyway when necessary. Figure 7-3 shows this message.

After JEB processes and loads up the file, you will see the main workspace area. The part that takes the front and center is the bytecode which was just disassembled from the APK. This is Dalvik bytecode which you can find more information about here: https://developer.android.com/reference/dalvik/bytecode/package-summary.

On the left panes, you will see the package explorer as well as the hierarchy of how the package is structured within the app. This is handy with which to navigate from. Each left pane also has a “filter” text entry field that you can type in a search string into, and the pane will only display items that have this text. This is very useful for narrowing down classes when moving back and forth within large apps. On the bottom and bottom right, you will find the logging, terminal, and the callgraph generator. I don’t use the callgraph generator much, but it allows you to visually look at how specific packages or classes are called and how they fit in with the rest of the code. My JEB layout looks like the one in Figure 7-4.

Here, JEB tells you how many classes, methods, and fields there are in total including all third-party libraries. It also tells you that the app is debuggable (yes, we made that happen). Then it tells you the starting activity that loads up when a user opens the app – MainActivity. You will notice that the MainActivity word is clickable. Most of the classes and methods in JEB are clickable and will take you to the declaration of that specific method or field. This is extremely convenient when navigating static code. I remember in days gone by, your deadlisting of code was just straight up lines of text that you had to scroll through. Generally, we used to print out pages and pages of disassembled code and make notes on them. While fun, I would never want to go back to those days when disassembling a modern Android app.

The ellipses are there to spare you of the field declarations and other code. I included some code as well so you can see what the bytecode looks like. I made one line of code bold to show you the format of Dalvik opcode. The first column is the address of the instruction; the second column is the opcode – in this case, iput-boolean. The third column contains the operands. So how the iput-boolean opcode works is by taking the value in v0 and putting it into an instance field. In this case, the instance field is MainActivity->E:Z. The actual instance that contains this instance field is referenced by p0. Now we can take a closer look at what that means by setting a breakpoint on it and then running the program in the debugger. I’ll show you that in more detail soon, but for now, let’s look at the operands in detail. Figure 7-5 shows the variables being accessed at the time that we stopped on our breakpoint. So, in this case, you can see that p0 is referencing the MainActivity. Essentially, we’re setting a 0 into v0 which resides in the MainActivity.

Would you look at that? We are setting a 0 (false) into MainActivity->E – just as described through the Dalvik opcode.

Now obviously, you may want to browse your code only through the decompiled Java code which is perfectly fine. You can do the same clicking and following around classes, methods, and fields to your heart’s content. JEB is seriously useful for Android reverse engineering.

The next set of steps is quite unique to the researcher or hacker. Often it involves trying to solve a puzzle and hit the correct cluster of code that is triggered at a specific action in the app. What does this mean? Well, think about the app that fetches some profile data from a server and presents it to you in a dialog window. If you want to know exactly when the network call was fired, then one way to find that part of the code, especially if the source is obfuscated, is to find the bit of code that pops open the dialog window and then work backward from there. Usually, that involves looking for Android Activity classes. One thing to note about Activity classes is that if mentioned in the AndroidManifest.xml file, the names are left intact by obfuscators like ProGuard. If, in the manifest file, the additional android:exported="true" is present, then again the obfuscators will not touch them as they are considered public APIs that must remain callable from outside the app. There are commercial and more complex obfuscators like DexGuard and Arxan that we will cover separately and we can take a look at. These obfuscators handle the obfuscation in a different manner that sometimes even includes manifest files.

Needless to say, this part of the analysis can take a while. Let’s turn our attention back to the Crossword app. You will notice that within the app, there is a mechanism to check each square or word that you have entered in the crossword to determine if it is correct. Looking at this, there obviously has to be a way that the answers to the crossword are also delivered or at least fetched. Let’s try to make that a goal for this app. Let’s try to find out what the answers are to a puzzle. If you look further at the app, you will see that there’s a leaderboard and several factors that help you score. One factor is whether you have checked any squares or words. Another is the time. Technically, you could move yourself to the top of the leaderboard by getting all the answers beforehand and then filling them in very fast. So, the goal of this part is to find the routines or the code within the app that gives you all the answers to the crossword. Awesome. Let’s do this!

The first thing I want to do is to look through the classes and methods belonging to the app. The first part is to figure out what the app-specific code is. This is among the myriad of third-party libraries that are usually the norm for Android apps these days. Scrolling through the class hierarchy, I notice two packages: com.nytimes.crossword and com.nytimes.crosswordlib. I usually browse through each of the packages to see if there are group names that reveal the purpose of that package. Figure 7-6 has a picture of our app package hierarchy. Some interesting packages to examine are the activity, game, gamestate, and models ones.

The activity package as expected contains all the activities that get launched when you interact with the app. For example, when you click the settings hamburger menu, the SettingsActivity is launched, and the setting screen is displayed. Similarly, when you click About, the AboutActivity is displayed. Let’s make a note to come back to this later and keep looking for more interesting things. The approach that I take is to look through every package first so I can draw up a plan of areas I want to revisit and then prioritize them. So, let’s move on.

This is most likely where the game timer is started and stopped. That’s extremely interesting. We should verify that later. Let’s move on for now.

The gamestate package looks similar with only a few classes. The most notable one looks like the ArchiveDataSource class. It contains some string references to DAOs or Data Access Objects. That may be something we should follow at some point.

This is getting more interesting by the minute. You know what we should do? We should set a breakpoint on getAnswers() and see what we get! So let’s set a breakpoint at the return this.answers; line and see what we get. In JEB, you set the breakpoints on the bytecode component. On the decompiled Java code, go to the line where you want to set the breakpoint, hit Tab, and JEB takes you back to the bytecode equivalent of that line. Then you can set the breakpoint. After setting the breakpoint, start the debugger. You will see a dialog that looks like Figure 7-7 which shows you the available devices (in my case, I am running it on an emulator) and then the process id for your debuggable APK.

One thing to note with the JEB debugger is that you have to have the app that you’re debugging launched. If not, JEB won’t be able to find it in the running processes. Now that the breakpoint is set, go ahead and click a puzzle to see if our breakpoint gets hit.

Oh my. Would you look at that in Figure 7-8? This is what my JEB screen showed me. On the left, you will see the highlighted line of text next to the circle (which is our breakpoint). The highlighted line is the line of code where the app execution stopped. On the right is the pane that allows you to inspect your breakpoints, local variables, and the threads running. Generally, we’re almost always interested in the values section and with good reason. I’ve gone ahead and expanded the values for you to see. PuzzleData contains the List answers. Expanding answers shows us that each item in this list is a PotentialRebusType class. Expanding each one, you will see its structure. But more importantly, you will see a list of all the letters in each of the answers. I think there’s absolutely nothing wrong for you to take some time and say out loud: Jackpot!

I try out some of the answers, and sure enough, they work a treat. So, I guess we accomplished our mission of finding out the answers to the puzzle before we attempt it.

Debugging for Free

I know by now you have two questions in your head. Number 1, “Sheran, you’re an ass. Why do you have to show us this on a tool that costs a lot of money?” and number 2, “Your solution seems very clunky especially to be able to read the answers off the debugger like that. Can’t you pretty print the answers?”

Allow me to answer those questions. For number 1, I anticipated you would ask me this which is why I’m writing this part of the chapter. For number 2, all I can say is: Stop whining! Nothing about app reverse engineering and debugging is pretty. But let’s see what we can do all the same.

What we’re doing line by line is connecting to the emulator, then switching over to the root shell.

If your su command fails, then you may have to restart your adb server to support switching to the root user. Execute adb root first before you try to use adb shell.

We can test if Frida server is running fine on the emulator by starting up Frida and attaching to the Crossword app. We can then run some commands to show the process id, for example, or the current platform it is running on. Frida has command completion which is really useful. For the full set of JavaScript API calls that you can execute on the console, see here: https://frida.re/docs/javascript-api/.

As a quick check to see if you have got everything up and running, you can run

frida-ps -U

Frida’s Interesting Tricks

I would have liked to title that Frida’s Interesting Trick, because frankly it does one thing really well which is to allow you to hook functions either native or Java. It does a lot more than just that, but I will now show you how we can use exactly this technique to do something fun with this Crossword app.

What we’re going to do is to hook the Java HashMap class’ put() method to intercept the data that is being placed into a HashMap. Why do this? Let me show you in Figure 7-9. You will notice that we’re looking at a class called CHARIOTSOFFIRE. This class is initiated with the Game object. Within this Game object lies not just the clues to the crossword but also the related answers. You will see the line of code that I have highlighted is the one where the answer is put into a HashMap. If we can successfully hook the HashMap's put method, then we can see each key and value that is being stored by this line of code.

We can hook functions using Frida in many ways. I will show you how to do it using Frida and a bit of JavaScript code. Let’s go over the code first:

 1: Java.perform(function(){

 2:

 3:        const hashMap = Java.use('java.util.HashMap');

 4:        const clue = Java.use('com.nytimes.crosswordlib.models.BROKENPROMISE');

 5:        const clueList = Java.use('com.nytimes.crosswordlib.models.ClueList');

 6:        const arrayList = Java.use('java.util.List');

 7:        const javaStr = Java.use('java.lang.String');

 8:        const answerLetter = Java.use('com.nytimes.crosswordlib.models.CONNOTES');

 9:        const clazz = Java.use('java.lang.Class');

10:

11:        hashMap.put.overload('java.lang.Object','java.lang.Object').implementation = function(k,v){

12:               if ((v != null) && (v.$className == 'com.nytimes.crosswordlib.models.ClueList')){

13:                      var vClueList = Java.cast(v,clueList);

14:                      var it = vClueList.iterator();

15:                      while(it.hasNext()){

16:                             var cl = Java.cast(it.next(),clue);

17:                             var clueText = cl.c();

18:                             console.log(clueText);

19:                             var ans = Java.cast(cl.h(),arrayList);

20:                             var iit = ans.iterator();

21:                             var finalAns = [];

22:                             while(iit.hasNext()){

23:                                    var ans = Java.cast(iit.next(),answerLetter);

24:                                    var ansLetterClass = Java.cast(ans.getClass(),clazz);

25:                                    var c_field = ansLetterClass.getDeclaredField('c');

26:               c_field.setAccessible(true);

27:               var cArrayList = Java.cast(c_field.get(ans),arrayList);

28:               finalAns.push(Java.cast(cArrayList.get(0),javaStr));

29:                             }

30:                             console.log(finalAns.join(''));

31:

32:                      }

33:               }

34:               return this.put(k,v); // Execute the actual HashMap.put() function

35:        }

36:

37: });

This script, which we saved as intercept.js, hooks the put() method of the HashMap class. We first instantiate the HashMap class in this script using Frida’s Java.use() method (line 3) and then overwrite the implementation of the put() method in line 11. This means that we now control the put() method . The first thing I want to ensure is that we do not interrupt how the actual HashMap.put() method works. So we execute the default put() method in line 34. OK, now we must find the HashMap.put() method that is called with the value type of com.nytimes.crosswordlib.models.ClueList. We check that in line 12. Then, we proceed to iterate over the ClueList to find BROKENPROMISE objects, which I have named as Clue objects. Within Clue objects are the answers and the text of the clue. This is what we’re after. Since the app deals with crosswords, the answers themselves will not be stored as full strings. Instead, they are stored to mimic how letters would look on a crossword and thus are stored a character at a time usually in a Java ArrayList. The h() method that I call in line 19 is actually equivalent to a getAnswers() method . Once again, I have to iterate over the answers because, remember, they are stored as a list of characters; in this case, they are stored as a list of CONNOTES objects which I named as an AnswerLetter (line 23). This object then contains another ArrayList of the letter of the answer. The letter seems to be always stored in the first element of the ArrayList. To get this ArrayList, we have to access a private field called c. I had to do some Java trickery to get the field, because there were two other methods also named c which made things ambiguous. This happens after code obfuscation. This happens on lines 25–28.

This is all an elaborate way of saying: Watch the HashMap.put() method, and when a list of clues is seen, take note of the clue text and the answers and print them out to the console. Simple enough right? Well, let’s find out by running it.

(p3) ➔  frida -U -l intercept.js -f com.nytimes.crossword --no-pause

This tells Frida to connect to a USB device, in this case, the emulator. Then it says execute the code in the intercept.js file as soon as you attach to the process. Frida usually always pauses the process as soon as it starts, so we turn off the pause functionality. We then select a crossword to play, and the script begins to execute. The results are pretty cool and can be seen in Figure 7-10.

What we can see is the clue text followed by an all caps version of the answer to that clue – all printed out even before you attempt the crossword. Fantastic! Now all that’s left is to play the crossword with our answers. See Figures 7-11 and 7-12. I averaged almost 4 minutes to play a puzzle with about 60 clues. Slow, I know, but my excuse was that I was playing on an emulator and I had to use the emulator keyboard and not my own hardware keyboard.

Where do we go from here? Well, the sky is the limit of course. We can play around with the chronometer and basically stop the clock, do the puzzle, then start it up again to post some ridiculously implausible time. I highly recommend that you purchase and subscribe to the NYTimes Crossword puzzle app. It’s really great to pass the time with.

We’ve seen how we can debug (kinda) an app for free using Frida. We also figured out how to print the answers in a marginally prettier manner. As for the deadlisting of code, you can generate that with some of the free decompilers out there like JADX, dex2jar together with JD-GUI, or even Android Studio. But it is essential that you have some form of view of the code as well to make things smoother. You could possibly do it with only Frida, but I think this may take you a little longer to finish up as you may have to trial and error your way through. Some other cool things you can do would be to hook network calls so that you can see traffic going back and forth between the app and the server. Essentially, if you can think it up, then you can most likely get it done using JEB and Frida. A word to the wise: Don’t be mean and don’t be destructive. App developers spend considerable time, effort, and even money writing apps. We should be respectful in our use of apps (except for those goddamned spyware-laden ones), and if we like an app and find it useful, then we should always pay for it.