MASPTv2.5 LocatingSecrets
MASPTv2.5 LocatingSecrets
LAB Topics
Reverse Engineering APKs
LAB OBJECTIVES
The objective of this lab is to highlight the importance of reverse engineering while
performing a mobile application penetration test. A large amount of critical information can
be extracted through reverse engineering a mobile application, such as hard-coded
information, API calls and insufficiently secure implementations in general.
LEARNING OBJECTIVES
The learning objective of this lab is to build on your hands-on experience in reversing APKs
and to reinforce your knowledge of different tools and techniques to reach your goal.
RECOMMENDED TOOLS
Apktool
dex2jar
JD-GUI
Smali/Baksmali
1. Windows 10 Machine:
Running:
2. Tools Installed
Apktool-2.2.2
dex2jar-2.0
JD-GUI-1.4.0
TASKS
TASK 1. INSTALL THE APPLICATION AND REVIEW ITS
FUNCTIONALITY
Install the supplied application in your device and review its functionality.
Start at the package com.els.locatingsecrets and exam the class Access. Follow the code to
see how the activity is created.
Are you able to find the username, password and code to access the hidden files?
*In the case of using a physical device, please make sure that you have authorized your
device, after you have connected it to your machine, so that it is accessible via ADB.
To install the supplied application, first open a terminal and navigate to the path:
your_drive:\Users\your_username\AppData\Local\Android\sdk\platform-
tools
adb.exe install
your_drive:\path_of_extracted_zip\LocatingSecrets\app\build\outputs\apk\app-debug.apk
Please note that if you are using different devices concurrently, you must use the -s switch
to select a specific device.
This simple Android application seems to retrieve a list of files from a remote server and
prompts for a password on the device. Depending on the code different lists of file will be
displayed.
As described in the first lab, you can decode the APK using Apktool as follows.
apktool d
your_drive:\path_of_extracted_zip\LocatingSecrets\app\build\outputs\apk\app-debug.apk
d2j-dex2jar.bat
your_drive:\path_of_extracted_zip\LocatingSecrets\app\build\outputs\apk\app-debug.apk
–o out_LocatingSecrets.jar
Now, you can use JD-GUI tool to view the file out_LocatingSecrets.jar.
You can now open the AndroidManifest.xml file and get some basic information about the
application.
1. The application needs the INTERNET permission. This indicates that the application
is communicating with a remote server, probably to retrieve a list of remote files.
2. The application provides two activities. The activity named Access is the MAIN
activity (the one that will be displayed when the application starts), while the
activity named Files is probably an activity which is linked to the first one.
Go back to JD-GUI tool and open the out_LocatingSecrets.jar file that you created on Task
2.
Now check the contents of the package com.els.locatingsecrets. There, you will find the
two activities declared on the application’s manifest file.
As usual, you can find the onCreate method. This one will build the layout of the activity.
There you will also see the resource id (2130968602) in use. You can check its value
(activity_access) by opening the R file.
You can now go to the folder created by Apktool and search for this name. It is stored in
res -> layout folder (the name of the class) in the file named activity_access.xml.
You can see in the node Button that when the button is tapped, it calls the method access.
The access method defines the instructions that will be executed when the button is tapped.
This simple code gets and stores a variable in the code: the value from the box. After that, it
calls and sends this value to the activity named Files.
Now that you identified how the first activity works, move on to Files for further
investigation.
The code provided by the user must be verified in some way. If this process is done by the
application (and not remotely), you might be able to understand how it works and retrieve
it.
At the beginning there are some variable declarations and right after that you can find the
onCreate method. As usual, the first bits of code create the layout of the activity.
The values of username and password are stored separately from the source code.
Try to read these values from the resources. First, you have to check in the R.class file
which is the resource that stores the credentials.
An interesting part of the source code to continue your analysis is where the program
compares the localObject2 with the string 5v3f4g and if it results in true, a new pair
(priv/admin) is added to localObject1 (used before to add the parameters username and
password). As you have seen before, localObject2 contains the code provided by the user
in the previous activity.
Use the code you just discovered and see what happens.
So far, you have been able to discover hard-coded credentials and a passcode that allows
you to access restricted files. You can continue to analyze the mobile application to
understand where else those credentials are used.