Basics of Android Reverse Engineering

Basics of Android Reverse Engineering

According to a report by grandviewresearch, the mobile application market was evaluated at 154.05 billion USD in 2019 and it is growing faster than ever.

To compete better in the market, most application developers have to finish the development in a fixed time frame. This is to make sure production cost of the application is at the minimum while increasing the throughput. In this race of developing applications faster, most applications developers forget about one most important component of application, i.e. Security.

Most Applications still use insecure methods of storing as well as transmitting data over the network. In this article, we will look into techniques of reverse engineering an android application to extract sensitive data which can deal damage to the business.

Mobile Security Framework

Mobile Security framework is an all in one automated tool to analyze and reverse engineer android, ios and windows applications. It is able to perform both static and dynamic analysis on mobile app binaries and zipped source codes. Advanced users can also take advantage of the REST api provided by the MobSf to seamlessly integrate MobSf to DevOps pipeline or CI/CD

Installation

We will install the Mobile Security Framework on a linux distribution with provided installation scripts.

First, we need to grab a copy of the framework, we can use git clone tool in command line or download the zipped version from the github repository of the mobile security framework

Type the following command in your terminal to download the repository

git clone github.com/MobSF/Mobile-Security-Framework-..

You can also download zip as following

image.png After repository is cloned, run the setup script with bash

Bash setup.sh

You will get output Installation complete once setup is done

image.png Now you can simply execute the run.sh script to get the mobsf up and running

image.png

As you can see, a local GUI has been started at http://0.0.0.0:8000 for Mobile Security Framework. We can open the URL in the browser to get started.

image.png We will be analyzing the Damn Insecure and Vulnerable Application by Aseem Jhakar from Payatu. You can find more details about the application on payaty's blog.

Application can be downloaded from this url

Once Downloaded, you would need to extract the downloaded tar.gz file and get the apk file.

Next step would be to go to the mobsf home page and upload the apk file.

image.png Once uploaded and analyzed, mobsf will present you with the dashboard containing results of the analysis.

As you can see, the dashboard provides a lot of useful information. In addition to providing file and app information, mobsf also calculates CVSS and security score based on the underlying implementations. MobSF works by first unzipping the apk file, then converting the APK to JAVA and DEX to SMALI, so this can benefit you if you want to analyze the underlying source code that has been reverse engineered by mobsf as well as you can download Java, Smali and the APK manifest file

image.png In the Manifest Analysis section, we can see certain settings enabled for the insecure application with detailed information on the severity of that configuration with full details.

We can see that Debug is enabled for the application with android:debuggable=True. This makes the task of attaching a dynamic hooking engine such as Frida to the application so we can dump a stack trace and extract the sensitive data hiding inside the application.

After taking a look at the report generated, the first step of reversing an android application should be to open the main activity file and try to understand the logic behind the application.

Source can be opened with clicking on View Source section of the dashboard

image.png On the left section of the page, whole decompiled source code tree can be seen

image.png Click on MainActivity.java to open it on the right pane

This file contains many functions and their definitions. If we scroll to the bottom of the file we see a startChallenge() function which starts an Activity depending on the View

image.png

Out of all Activities, HardcodeActivity stands out, so we will open the HardcodeActivity.java file for analysis.

image.png

As we can see, there is one access function which compares the entered secret key and if the entered secret key is correct, access is granted. But for the purpose of comparison, developer has hardcoded the secret key, which is "vendorsecretkey" which an attacker can use to easily bypass the access protection.

Hardcoding sensitive information is one of the top OWASP Top Mobile vulnerabilities. This is why to ensure better security, credentials should never be stored in plain text inside the application

Same as Hard coding Credentials, many developers hardcode API keys inside their mobile applications, which allows any attacker to have unauthorized access to remote api and the data handled by the api service.

To better understand the API vulnerabilities, we can analyze the ApiCredsActivity.java file

image.png As we can see, both the Api key and username:password are stored in plaintext inside the source file.

Another Activity that should be analyzed is SQLInjection activity

image.png Sql injection is one of the most interesting vulnerabilities to find in an android application as most mobile developers choose to ignore secure sql implementations as implementation is quite different from what is usually found in web applications.

At first, the activity sets up a database and creates a table to enter few columns containing username, password and credit card number

After building up the table, we can see a sql query built with username extracted from the user input with srchtxt.getText().toString. The whole query is then directly executed. Attackers can simply provide their malicious sql payload and backend application will execute the query returning the output.

image.png Conclusion

While seeming complicated at first, it is possible to correctly reverse engineer an android application. In addition to the potential leak of application logic, it can also deal much larger damage if an attacker discovers potential vulnerabilities. It should be always preferred to test for owasp mobile top 10 as well as put proper anti-reversing techniques in place