Please check the first part of this series on Android 101, if you want to check the necessary tools and how to prepare for the app assessment.
Lesson6Activity (Encryption vs Encraption)
As the title suggests, this lesson is about encryption. Specifically, it concentrates difficulties with key management and why relying on client-side encryption to generate secrets may not be a good idea. As you look through the list of methods in the Lesson6Activity class, “encryptNumberWithAES()” looks interesting. Looking at this method closely, we see the algorithm used for encryption is AES, with the key hard coded into the code. Since AES is a symmetric encryption algorythm, we can use this key to encrypt new data or decrypt any data that has been previously encrypted. Using this key, encrypt the number displayed in the app using AES and output it to a readable form using Base64 encoding (you’ll need Base64 output to type your answer into the challenge). The following is a sample Java code snippet to do this:
Lesson7Activity (Providers shared with the world):
Mercury is an Android assessment framework which helps identify vulnerabilities in your app. Content providers are quite simply backend databases where the app can store and retrieve data for later use. Insecure storage often leads to data leakage, which is the focus of this lesson. Mercury allows you to display the information about the Content provider a particular app is using. The following figure shows you the information regarding the provider for the Learner app. As you can see it lists the various permissions and the Authority of the provider for this app.
In order to access the data in a provider, you need to know its Content URI. A content URI is one that identifies data in a provider. It is of the form
Looking at the decompiled files of the app we find its content URI.
You can run a query in Mercury to display the data of the provider using the Content URI just discovered.
Lesson8Activity (Malcious Intents)
In this lesson we are going to use apktool as we did in lesson 5. This is once again because apktool converts the dalvik binary into a language called Smali, which is translated directly from the binary itself. A key benefit of this is that it allows you to change code or any other resources and convert the changed code back into a functional .apk file. jd-gui doesn’t allow you to do that. Smali may be confusing at first but once you get familiar with the code style, it’s pretty easy. The goal of this lesson is to manipulate an Intent so that a hidden activity gets displayed. So ,we need to figure out how the intent is parsed and what checks are being performed. In order to read the code easily, we will start with jd-gui when we look at Lesson8AuxApp’s MinActivity class. There, we see that an Intent is being prepared and sent when the user clicks the send button.
Let’s look at Lesson8AuxActivity class from Ig-Learner and see what it is doing with the intent.
getAction() needs to be equal to something that is being referenced by a constant “2131099692”, which cannot be dereferenced and this is where apktool is very helpful. Before we get into apktool, we will try to understand what is being passed. getAction() will get whatever was set using setAction() in the MainActivity class. putExtra() sends additional parameters in the form of a dictionary
Note that we won’t have any information regarding the extra parameters associated with the intent. The other way is to manually search for the string constant’s id identifier in the resources in the disassembled apk directory. Checking this out with help you to get more familiar with the files present in that directory. In the res/values/ folder you will need to map the above int value to string using the public.xml and strings.xml file.
Now we know, what our action string should be, we also know that key should be current date, so now decompile Lesson8AuxApp, figure out where the strings are being assigned and change them to the ones we just discovered.
Assemble the package back to .apk file, you can get this information from the instructions in “Preparing for App assessment.” Don’t forget to push the auxiliary app back to the device. That’s it! With everything done correctly, you should see the following screen.