Android Studio

One-stop shop comes to mind when considering Android Studio. Launched in 2014, it was an IDE that was designed and built specifically for Android development. The platform uses the IntelliJ IDEA software base that was built by JetBrains. It contains a suite of features to help Android developers get started on their apps quickly and is a firm favorite of mine to use. Versions exist for MacOS, Linux, Windows, and even Chrome OS if you want to do some app development on Google Chromebooks. I use MacOS, so my discussions will be centered around that.

I used to use Android Studio for my Android app development. Now I mostly use it for the AVD, which is the Android Virtual Device Manager, and for writing up snippets of code to compile and then eventually decompile so that I can become familiar with how specific types of Android source code looks like in bytecode when reverse engineered. The AVD is a really useful tool to me because it allows the creation and control of multiple emulated Android devices. I like it because it allows me to rapidly test apps or configurations on emulated devices without the need of having a specific hardware testing device. It is also great for continuity because you can have multiple emulators saved in your AVD in a paused state. When you work on an emulator and then pause it, the state is saved so you can switch to a different task and then return to the emulator and pick up where you left off. My current AVD looks like the one shown in Figure 6-2. You can invoke it from the Tools ➤ AVD Manager menu on MacOS when you have a project open; otherwise, use the button Configure ➤ AVD Manager on the Welcome screen.

Each virtual device that you create will need you to tell it a specific Android version to run. Android Studio’s SDKs date as early as Android 2.1 (Eclair) API level 7. If you want to geek out with the numbers, you can find a list of codenames, tags, and build numbers on the Android source website at this URL: https://source.android.com/setup/start/build-numbers.

Having older SDKs is really great not just from a developer standpoint but also from a debugging or security standpoint. As a developer, you will be aware that the rate of adoption of newer Android versions is painfully slow. So those cool new features Google released can’t always be used in your app until a lot more people adopt the new version. As a hacker, that usually works in your favor because older versions may have vulnerabilities, and a user’s reluctance to upgrade is ideal for your preying hands to take advantage of. Google releases a distribution dashboard that shows the percentage distribution of each Android version here: https://developer.android.com/about/dashboards. The data on that page was up to 7 May 2019 and showed that Android version 9 (Pie) had a 10.4% distribution. As a comparison, Android Pie was released in August of 2018. Thus, after a ten-month period from release, there was a 10.4% adoption rate.

My Android Studio Tweaks

With my Android Studio, I don’t do much extra. I will first make sure I have the latest Android version downloaded so that I can create a virtual device using that SDK. If I need older SDKs, then I will use the SDK Manager (Figure 6-3) and download the older version.

Access the SDK Manager by using either Tools ➤ SDK Manager if already in an open project or the button Configure ➤ SDK Manager if on the Android Studio Welcome screen (Figure 6-4).

Creating a Virtual Device

Let’s go through the steps of creating a virtual device so that I can address one topic – the Google Play Store. Let’s fire up the SDK Manager first and get us a new SDK. If you’re on the Welcome screen, then hit the Configure button and select the SDK Manager (Figure 6-4). This should then bring up the SDK Manager that looks like Figure 6-3. Next, we select an SDK of our choosing. For this example, I will choose SDK version 9 (Pie), API level 28. Click the checkbox in the leftmost column of the SDK Manager in line with the SDK version of your choosing. You will see a little download icon highlighted next to it as in Figure 6-5.

When you’re done, click the OK button, and Android Studio will prompt you to confirm your request. It will also let you know how big the download is and how much space it will take up on your disk so you can be prepared for that as well (Figure 6-6).

You will see a progress indicator window where you can track the progress of the download and install of the SDK. Any errors taking place will also be visible there. Once the download and installation complete successfully, you can dismiss the window by clicking the Finish button. If all went according to plan, you will have the Android version 9 SDK downloaded and installed on your Mac. The next step is to open up the AVD Manager and create a new virtual device with this SDK. Let’s go back to the Android Studio Welcome screen and click the Configure button and this time choose AVD Manager. This brings up the AVD window where you will see a list of previously created virtual devices. If this is the first time you installed Android Studio, then you won’t see any virtual devices. Click the + Create Virtual Device button and a window will pop up asking you to select your hardware as in Figure 6-7.

You will notice on the second column named “Play Store” some devices have a Google Play Store icon. These devices are special in that they have the Google Play Store and all other accompanying Google services, collectively known as Google Play Services, installed. This means that you can use your Gmail account or any other Google registered account to log in and configure that device just like you would a physical device. What this also means is that the virtual device will not be rooted. Therefore, you cannot use the Android Debug Bridge (ADB) to execute programs as the root user, nor can you freely look through the Android filesystem through ADB. Google says the following on their site:

To ensure app security and a consistent experience with physical devices, system images with the Google Play Store included are signed with a release key, which means that you cannot get elevated privileges (root) with these images. If you require elevated privileges (root) to aid with your app troubleshooting, you can use the Android Open Source Project (AOSP) system images that do not include Google apps or services.

The AOSP images that they refer to are the ones without the Google Play icon. They do not contain any of the Google Play Services. This isn’t a hindrance in any way; if I need to run an app on a rooted emulator, I will install the AOSP image instead. In Figure 6-7, you will notice that Pixel 2 is a system image that has Google Play Store installed which will be non-rooted. If you want a similar device as that but with root, install the Pixel 2 XL image.

Let’s finish up installing this virtual device. Select the Pixel 2 XL image and click the Next button. Then you get to select the Android version that you want. This should be the SDK image that you downloaded earlier, so select Pie. Sometimes, you will also need to download a system image and accept the end-user license agreement. If the Release Name column has a “Download” link there, click the link, then read and accept the license agreement on the next window, and then click the Next button as shown in Figure 6-8.

When the download is done, click the Finish button, then select the Android Pie system image, and click the Next button. You will then see a window that looks like Figure 6-9. From here, you can select things like the device orientation when it starts up (whether landscape or portrait), what type of graphics, and whether to show a frame around the emulator that looks like an Android device. There are also several advanced options that allow you to select the number of cores on the CPU, memory and storage sizes, where the SD card resides, and the network type and speed (which is useful for simulating 3G networks at varying speeds). For now, leave the settings as they are and click the Finish button.

You will then be returned to the list of your virtual devices (Figure 6-2), and you will see your newly created AVD listed there. We won’t fire it up now, but there will be plenty of instances when we will.

As far as emulators go, there are a few others out there including Genymotion and BlueStacks that offer differing solutions, especially if you want to run the virtual devices in a large group. For the purposes that I need, I find that the Android Studio emulator is a good fit.

Burp Suite – Web Application Security Test Kit

What can I say about my oldest friend Burp Suite (https://portswigger.net/burp)? I was using it when all it was was a proxy and the Windows app icon was a badly drawn face of a guy that looked like he was burping. Good times. Burp Suite today can easily be described as a testing framework for web application servers. At its core lies a very good crawling engine that helps gather all possible URLs in a web application and its man-in-the-middle (MiTM) proxy. I use Burp to test web applications mostly, and given my familiarity with it, I use it when I want to test what Android apps send back and forth to their back-end servers. I do this primarily by using the Burp Proxy, and then I can use the HTTP inspector to see real-time HTTP requests going back and forth between the app and the server as shown in Figure 6-11. This is one tool that I can recommend that you purchase. The Professional version offers a lot more features that allow for a very seamless testing session and also includes more tools like the Burp Scanner which does automated scanning for web applications. Having said this, since we only need the proxy functionality, you should be able to get by with the Community version. But I would say, do yourself a favor and buy the Professional version.

One question that you may have is “Can I see TLS traffic?” and the answer is yes and no. Let’s quickly revisit what an MiTM attack is. Figure 6-12 shows what it looks like when network traffic is directed to its intended server with one hop in between. This hop is called the man in the middle. Essentially, the job of the MiTM device or server is to receive any data that arrives via its server port and pass it on to the intended destination. It does this for every single network packet. You could say that all traffic going back and forth between the client and the server passes via this proxy.

That’s step one. When you know that all the network traffic passes through this proxy, the owner of the proxy (hopefully you) can take a look at all this traffic that is going back and forth. This means that the data traveling between the client and the server isn’t private. This is especially true if the client and the server are not part of your infrastructure or organization and belonged to a third party. You would be able to view all messages going between the two talkers which means you have compromised the confidentiality of that data. Now if you chose to, you could also compromise the integrity of those messages. Let’s say the client sends a chat message from one user to another via the server. You could watch for some keywords of this chat message, and when you intercept these keywords, you can change the text and then pass it along to the server. You can do this because you are receiving the message and you are also forwarding it on behalf of the party you receive the message from. Now you have compromised the integrity of that message as well. If you look back over your old information security notes on the CIA Triad, no, not the CIA with the Triads, the CIA Triad. The triangle with the three words forming the acronym CIA: Confidentiality, Integrity, and Availability. You will see that through this attack, we have managed to compromise two of the three concepts. Of course, presently, information security is far more nuanced and complex, but if we simplify into the triad, we can see that the MiTM attack is quite an effective one.

Why does this work? Ultimately, it is because we have installed our CA certificate and marked it as trusted on the client. When we do this, the client will trust any certificate issued under that CA implicitly. Therefore, with this setup, we are able to see even encrypted TLS traffic that passes between the client and the server and, yes, even edit the data.

Let’s address the “no” part of this answer to the same question “Can I see TLS Traffic?” I said no because of the prerequisites that we need to fulfill prior to getting a successful TLS traffic dump between the client and the server. We would have to successfully convince the client to send all his traffic to us so that we can forward it along to the intended recipient. That isn’t hard by itself. We could easily do that if we were sitting on the same network as our client. We can run an ARP Spoofing attack on the client and trick him into believing that we are his next hop gateway rather than just another client. Today, however, there are many ways to prevent ARP Spoofing attacks, and to make things more complex, an ARP Spoofing attack, if not done correctly, can have some catastrophic results.

Speaking of ARP Spoofing, I remember a long time ago, an ex-colleague of mine once forgot that he had an active ARP Spoofing attack running on his laptop during an assessment where essentially about 30 servers on the same subnet were sending his modestly powered device all their traffic. Surprisingly, his laptop was able to cope with the data, and everything went well. At least until it was time for him to head to a meeting to update the customer on the progress of our security assessment thus far. Having forgotten the ongoing attack, he swiftly closed the lid of his laptop, unplugged the Ethernet cable, and proceeded to head to the meeting that never took place. About 2 minutes after he removed his laptop from the network, alarms began to go off, and we saw nervous and confused looks all around as customer employees began shouting and running around. Basically, the result of unplugging the laptop from the network of servers that all thought you were the gateway or the router meant that all of the servers were sending traffic to a nonexistent device. The attack had overwritten the ARP address of the actual router, and so, it only knew this one hardware address to send data to: my colleague’s laptop which was no longer there. No traffic was sent or received correctly on that production network subnet for sufficient time that the customer’s major services went straight down and stopped responding. We had to immediately plug his laptop back in and re-ARP or tell all the servers that the real router was at the correct hardware address. A restart of all servers would have also worked, but we were in no way willing to trust that the restart of 30 servers would go off without a hitch. So we had to re-ARP which we did, and gradually everyone began to relax as the services all came back up again. So, be extra careful if you want to try ARP Spoofing these days, but I am fairly certain that the ARP Spoofing attack is a thing of the past.

The next challenge would be to get the user of the client PC to install and trust our CA certificate. The best way to do this would be when he leaves his PC unlocked and walks away to go get a snack or visit the toilet. Otherwise, you’re looking at complex hacking attempts on his PC to mimic how he would download, install, and trust the CA certificate, and this would take considerable time and carry lower probabilities that it would succeed. With these kinds of odds, you can see why I would bring in the “no” answer to that question. I guess the real answer is “It depends” – in the context that in this scenario, we have little to no control over the client and what it is doing. The only real way we could succeed at breaking TLS traffic is if we were to fully and completely own the client. Humor me and follow this train of thought on context. What scenario gives us complete control over the client device where we could introduce and trust our own CA certificate on the client device? Well the answer is simple: It’s on our mobile phones that run third-party Android apps. We have complete and total control over our mobile phone. We can install the fake CA certificate, mark it as trusted, and then route all the traffic from a third-party app through our proxy to the ultimate destination and back.

Attacks like this are the reason why SSL Pinning was created. SSL Pinning is a technique where certain specific and trusted certificates from the app creator are embedded within the app. The app will run a comparison on whether the certificate presented to it when connecting to a server matches the one embedded within the app. If it does not, then the connection is terminated so that no traffic flows between the client and the server. No data means anyone watching will be sorely disappointed. But as you all may or may not know, SSL Pinning has also been defeated, and the exact mechanism of breaking SSL Pinning will be discussed in several chapters later in the book.

Frida – Dynamic Instrumentation Toolkit

Frida (https://frida.re/) is an awe-inspiring toolkit. Written by Ole André Vadla Ravnås, it is one of the few truly complete and extensible toolkits that allow both developers and security researchers access to some very powerful features. I personally feel that it is generally left alone by people that do not favor working on the command line. Frida is all command line, all the time. Look at Figure 6-13. I did my best to conceptualize what Frida does. Now, Frida can run on a multitude of devices and provide you with direct access to view and modify processes running on that device. For the purposes of this book, we will only cover the Android capabilities of Frida.

Frida has two components. First is the server component that runs on the Android device and hooks into the Android OS directly. Then it has the command-line tools component or client. The Frida client will send commands to the Frida server which can then oblige us by sending back instrumentation data, allow us to hook into different library calls or functions in the OS, trace private application code, or even allow us to replace and inject our own code into running apps. This sounds like a dream, and to be honest, you will feel that way when you can rip apart any Android app with ease and look into its innards – which APIs it talks to, what different servers it communicates with, what are the actual HTTP parameters being used – and look at what goes on behind the encrypted layer of TLS even if SSL Pinning has been implemented. I think many in the information security profession owe Ole a debt of gratitude for the tremendous tool that he has built and released for free. Thank you Ole!

Let’s go a little bit deeper than just the surface here for Frida. I want to show you how simple it is to get going with Frida. In the later chapters on breaking SSL Pinning, we will be getting very detailed with how we use Frida, but for now just a taste .

Installing Frida on Macos

OS X comes bundled with Python 2.7, and for this exercise, I will use that. I recommend you switch to Python 3. It is good. Use it. We will cover how to install it and get up and running with Frida on Python 3 later. For this example, we will use Python 2.7.

First, fire up your OS X Terminal.

1. 1.

   Open Finder.

    
2. 2.

   Click Applications in the left pane.

    
3. 3.

   Scroll down in the right pane and open Utilities.

    
4. 4.

   Scroll down in the right pane and open Terminal.

    

You should then see your Terminal window as in Figure 6-14.

Let’s now follow the steps you can see typed into the Terminal window.

1. 1.

   Check and make sure you are in your home directory by entering pwd. You should see /Users/<name you are currently logged on as>. In my case, it was sheran. If you are not in the correct directory, you can type in cd /Users/<name you are currently logged on as>. Therefore, if you were logged in as sheran, you would type cd /Users/sheran.

    
2. 2.

   Next, create a test directory that we will use to install our Python virtual environment and any files we want to keep there. Do this by issuing the mkdir frida_test command and pressing Enter.

    
3. 3.

   Then, change to this directory by issuing the cd frida_test command and pressing Enter.

    
4. 4.

   Lastly, we check to see what version of Python we have installed. Issue the command python –version and press Enter. If you receive anything that looks like Python 2.x.yy, then you have Python 2 installed.

    
5. 5.
   Let’s now install our Python virtual environment so that we don’t affect the entire base Python installation. It is generally good practice to run your Python programs in its own virtual environment where you can independently manage requirements on a per project basis. To install the Python virtual environment with Python 2, type in virtualenv -p /usr/bin/python2 python. This should execute as shown in Figure 6-15 and return a new directory in your current one called python. In some cases, you may find that you don’t have virtualenv installed on your system. If this is the case, then you can install it with: pip install virtualenv.

   

    

1. 6.

   Now we have to activate our new Python 2 environment so that we can install Frida and any relevant requirements. Type in . ./python/bin/activate to activate the virtualenv. Pay close attention to the fact that there are two period characters. If this looks confusing, then as an alternative use source /python/bin/activate.

    
2. 7.
   Then let’s install Frida by typing in pip install frida-tools. That’s it!

   

    

Next steps will usually involve copying the Frida server onto the Android device, starting the server, and then communicating to the server from the client. This will be covered in a later chapter.

JEB – Android Decompiler

I stumbled onto JEB (www.pnfsoftware.com/) by complete accident when I was researching how I could reverse engineer Android DEX files. In the early days, JEB was usable even if there were some features to be desired. You could use the external scripting module and write your own scripts to improve your workflow or automate tasks. Modern-day JEB is vastly improved with support for disassembling, debugging, and graphing that can show how an app’s execution flows.

Now JEB isn’t what you would call affordable for the masses. The JEB Pro version that I use will cost you about US $1800 for a 12-month license for one user. That is quite an expensive piece of kit. There is also a JEB Android license that you can get for $1080 per year, or if you prefer, you could get the monthly pay option for $120. While there are some limitations on this edition, it gives you all you need to work on Android decompiling. Now if you are only keen on breaking SSL Pinning or altering the code flow of a specific app, then I think you can manage with Burp, Frida, and the Android emulator or a rooted Android phone. I do, however, think that JEB completes our Tool Bag very nicely, closing off the final gaps in visibility we have of an Android app that we have not written and have no clue of. JEB can give you direct insight into how the code is written and can even go as far as deobfuscate some obfuscated Android apps. We will touch on this in our other chapters, but first let’s take an example where JEB can prove useful.

Note Step 3 and how we changed it so that we would get access even if we provided the wrong serial number. By altering the app flow in this way, and entering an incorrect, possibly random serial number, we can gain access to the new Activity. Since the majority of cases of guessing involved getting the answer wrong, the app execution flow will never even hit line 4. This is because it will receive the wrong serial number and still grant access to the next Activity.

There is one problem, however. We do not know the name of the function that is calling this Step 3 comparison check. How would we get it? Well there are several different ways that can also include a debugger like Frida where you run the app until the prompt comes up and then pauses the execution so that you can literally step through each line of code and see how the variables of the app change and react. Another way would be to fire up JEB and disassemble the app and look for the code where the comparison takes place. When reverse engineered, it should be possible to more easily and closely locate the function that is of interest to us in altering the execution flow. After this is found, we can directly reference it in Frida and alter the program flow to always grant access even if an incorrect serial number were used.