Session 07 / 14 BugXploit Workshop

Day 7: Android Penetration Testing, Static Analysis with MobSF & JADX-GUI Decompilation

Report By: TheWH2 Instructors: Birendra Sah Bishal Shrestha Institute: BugXploit (Koteshwor) Read Time: ~20 mins

Security Notice & Lab Scope

This technical report documents official offensive and defensive security exercises conducted during Day 7 of the Ethical Hacking and Penetration Testing Workshop at BugXploit (Koteshwor, Kathmandu). All mobile application static security assessments were performed using open-source tools (MobSF and JADX-GUI) against DIVA (Damn Insecure and Vulnerable App), an intentionally vulnerable Android application designed strictly for educational testing, vulnerability research, and secure mobile coding practices.

1. Mobile Pentest Foundations: Static vs Dynamic Analysis

On Day 7 of the BugXploit workshop, the curriculum transitioned from network daemons and web applications to Android Mobile Application Penetration Testing. Mobile applications represent a distinct attack surface because the client-side binary (the APK file) runs directly on user hardware outside the security perimeter of the corporate datacenter.

The instructors introduced the two fundamental methodologies governing mobile security assessments:

SAST
Static Code Analysis

Evaluating the binary without executing it.

  • Decompiling APK packages to inspect AndroidManifest.xml, Java/Kotlin classes, and Smali bytecode.
  • Searching for hardcoded API keys, bearer tokens, private encryption keys, and internal backend URLs.
  • Auditing declared permissions, exported components (Activities, Services, Broadcast Receivers, Content Providers).
  • Reviewing code implementations for insecure storage, raw SQLite queries, and weak cryptography.
DAST
Dynamic Analysis

Evaluating the application while running on a device/emulator.

  • Intercepting HTTP/HTTPS traffic through a proxy (Burp Suite) and bypassing SSL Certificate Pinning.
  • Runtime manipulation and memory hooking using frameworks like Frida and Objection.
  • Inspecting device filesystems (/data/data/<package>/) for unencrypted SharedPreferences, databases, and logs.
  • Root detection and emulator detection bypasses.

Our focus on Day 7 centered on Static Code Analysis and Reconnaissance: understanding how threat actors extract source code from compiled APKs, run automated vulnerability scanners, identify hardcoded secrets, and pinpoint logic flaws before touching a physical Android device.

2. Essential Tooling & Direct Downloads (JDK 26 & JADX-GUI)

To decompile, inspect, and analyze Android applications locally, security researchers require a properly configured Java runtime environment alongside specialized decompilers. Below are direct official download links configured for immediate access:

Prerequisite Windows x64
Oracle JDK 26 (Windows)

Official 64-bit Java Development Kit executable installer required to run JADX-GUI, apktool, and Android toolchains.

Prerequisite macOS ARM64
Oracle JDK 26 (macOS)

Official Apple Silicon (M1/M2/M3/M4) Java Development Kit disk image installer for macOS security workstations.

Decompiler v1.5.6 Release
JADX-GUI (Windows ZIP)

Standalone DEX to Java decompiler with an interactive graphical user interface, code search, and syntax highlighting.

3. Target Profile: DivaApplication.apk Architecture

For our hands-on static analysis lab, we utilized DIVA (Damn Insecure and Vulnerable App), authored by Aseem Jakhar. DIVA is purposely engineered with intentional mobile vulnerabilities mirroring common flaws found in commercial Android apps.

Target Application Package Metadata
Application Name: Diva
Package Name: jakhar.aseem.diva
Main Activity: jakhar.aseem.diva.MainActivity
Binary File Size: 1.43 MB
Target SDK: 23 (Android 6.0 Marshmallow)
Minimum SDK: 15 (Android 4.0.3 Ice Cream Sandwich)
Version Name / Code: 1.0 / 1
MD5 Hash: 82ab8b2193b3cfb1c737e3a786be363a
SHA256 Hash: 5cefc51fce9bd760b92ab2340477f4dda84b4ae0c5d04a8c9493e4fe34fab7c5

4. Automated SAST with MobSF (Mobile Security Framework)

Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android / iOS / Windows) penetration testing, malware analysis, and security assessment framework. It is capable of performing both static and dynamic analysis.

During the lab session, we uploaded DivaApplication.apk to the live hosted instance at mobsf.live (MobSF v4.5.2). Within seconds, MobSF unpacked the APK, decoded binary XML resources, disassembled DEX bytecode into Java, audited shared libraries, and calculated overall risk scores:

36 / 100
MobSF Security Score (Severely Insecure)

A score of 36 reflects widespread high-severity manifest vulnerabilities, outdated API targets, and lack of code protection.

0 / 432
Trackers Detected

Zero embedded commercial ad, analytics, or behavioral telemetry tracking SDKs identified.

5. Signer Certificate & The Janus Vulnerability

MobSF immediately parsed the cryptographic signature of the APK file and flagged two critical vulnerabilities in the signing configuration:

MobSF Signer Certificate Audit Output
Binary is signed: True
v1 signature: True | v2 signature: False | v3 signature: False | v4 signature: False
X.509 Subject: C=US, O=Android, CN=Android Debug
Signature Algorithm: rsassa_pkcs1v15
Issuer: C=US, O=Android, CN=Android Debug
SHA256 Fingerprint: 35d7f7ad35dfb826b70fa4b73187ed478540e32c8b8c5653b86568029fcd5840
Certificate Vulnerabilities Detected HIGH RISK
1. Application Signed with Debug Certificate

The certificate issuer is CN=Android Debug. Debug certificates are generated automatically by Android Studio for local developer testing. Signing a build with a debug key signals that the binary was never intended for production, exposing private keys and invalidating application authenticity.

2. Vulnerable to Janus Vulnerability (CVE-2017-13156)

The binary is signed exclusively with the APK Signature Scheme v1 (JAR signing), while Schemes v2, v3, and v4 are disabled (v2: False). Because the v1 scheme only validates ZIP archive entries rather than the binary envelope, an attacker can prepend malicious DEX code to the APK file without invalidating the v1 signature. On vulnerable Android versions (Android 5.0 to 8.0), the Android runtime executes the prepended payload with the original application's identity and privileges.

6. Manifest Flaws: Debuggable Flag & Exported Components

The AndroidManifest.xml file is the root blueprint of an Android application. MobSF identified 6 critical issues across manifest configurations:

Configuration Flag Severity Vulnerability & Exploitation Impact
android:debuggable="true" HIGH Allows attackers or reverse engineers to attach a JDWP (Java Debug Wire Protocol) debugger using jdb or Android Studio over ADB. Attackers can halt application threads, dump memory, modify variable values at runtime, and extract cryptographic keys directly from heap memory.
android:allowBackup="true" WARNING Enables arbitrary application data backups via Android Debug Bridge (adb backup -f backup.ab jakhar.aseem.diva). Any individual with temporary USB physical access can clone the user's private application data, SharedPreferences, and SQLite databases without requiring root privileges.
minSdkVersion="15" HIGH Allows installation on Android 4.0.3 (Ice Cream Sandwich), an unpatched legacy operating system lacking modern ASLR, runtime permission sandboxing, and security patches.
Exported Activities:
APICredsActivity
APICreds2Activity
WARNING Contains intent-filters without android:exported="false". These activities are globally callable by any third-party malicious app installed on the same device via am start -n jakhar.aseem.diva/.APICredsActivity, bypassing authentication flows.
Exported Provider:
NotesProvider
WARNING jakhar.aseem.diva.NotesProvider is explicitly exported (android:exported=true) without read/write permission guards. Any unprivileged application can query, dump, or alter internal application notes via content:// URIs.

7. Uncovering Hardcoded Secrets: "notespin" Extraction

One of the primary goals of mobile application static code analysis is hunting for hardcoded credentials, secret keys, and configuration tokens. In production applications, developers frequently embed AWS secret keys, Firebase database credentials, Stripe tokens, and internal encryption passphrases directly in client-side code.

MobSF's automated secret scanner audited strings across the APK resources, bytecode, and compiled binaries, returning an immediate hit:

MobSF Hardcoded Secret Finding:
"pkey" : "notespin"

Located in source file: jakhar/aseem/diva/HardcodeActivity.java and referenced in shared libraries. The developer hardcoded the private encryption PIN directly into the client code rather than querying a remote authorization service or utilizing Android Keystore.

Furthermore, MobSF extracted backend communications indicating network activity to http://payatu.com inside APICreds2Activity.java.

8. Insecure Storage & SQLite Injection Vectors

MobSF flagged several high-risk code implementation patterns in the Java source:

Raw SQLite Execution & SQL Injection (CWE-89)

Vulnerable Files: SQLInjectionActivity.java, NotesProvider.java, and InsecureDataStorage2Activity.java.

The application executes raw SQL queries concatenating user input directly into SQLite statement buffers without parameterized queries or prepared statements (rawQuery("SELECT * FROM myuser WHERE user = '" + userInput + "'", null)). This enables local SQL injection, allowing an attacker or rogue app to dump stored user credentials and overwrite database tables.

Insecure Data Storage in External Storage (CWE-276)

Vulnerable Files: InsecureDataStorage4Activity.java and InsecureDataStorage3Activity.java.

The application requests READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions and writes temporary credential files to globally accessible SD card paths (e.g., /sdcard/). Data saved to external storage is globally readable by any application on the device with storage access.

9. Shared Library Binary Security (libdivajni.so)

Android applications frequently bundle compiled C/C++ native libraries via the Java Native Interface (JNI). MobSF performs binary analysis across all compiled .so shared objects (ARM, x86, MIPS) to verify whether compiler-level exploit mitigations were applied:

Mitigation Flag libdivajni.so Status Security Purpose
NX (No-Execute) Bit False (HIGH) Stack and heap memory pages remain executable. Attackers exploiting buffer overflows can execute shellcode directly on memory pages.
Stack Canary False (HIGH) Functions are compiled without -fstack-protector-all guard values, allowing standard stack buffer overflows to overwrite return addresses.
PIE (Position Independent) True (Enabled) Compiled with -fPIC, randomizing code base addresses and complicating Return-Oriented Programming (ROP) attacks.
RELRO (Relocation Read-Only) Full RELRO Global Offset Table (.got) is marked read-only after link resolution, preventing GOT overwrite exploitation.
Fortify Source False Missing -D_FORTIFY_SOURCE=2, leaving insecure C functions like strcpy and gets vulnerable to buffer overruns.

10. Manual Reverse Engineering with JADX-GUI

While automated scanners like MobSF provide rapid reconnaissance, an ethical hacker must perform manual source code verification using a decompiler to inspect program logic, understand call hierarchies, and confirm exploitability.

JADX-GUI is the premier open-source tool for decompiling Android DEX (Dalvik Executable) bytecode back into readable Java source code.

Launching JADX-GUI on Windows / Kali
# Windows PowerShell (inside extracted jadx-gui folder):
> .\bin\jadx-gui.bat DivaApplication.apk

# Kali Linux:
$ jadx-gui DivaApplication.apk

Step-by-Step JADX-GUI Code Auditing Workflow

  1. Open the APK: Load DivaApplication.apk in JADX-GUI. JADX instantly decompiles classes.dex into high-level Java packages under Source code > jakhar.aseem.diva.
  2. Global String Search (Ctrl + Shift + F): Search for keywords such as password, api_key, secret, token, http://, or DES.
  3. Inspect HardcodeActivity.java: Directly view the raw Java source code where the hardcoded key is compared:
    public class HardcodeActivity extends AppCompatActivity {
        public void dj(View view) {
            EditText editText = (EditText) findViewById(R.id.hcKey);
            // Direct plaintext string comparison against hardcoded vendor secret!
            if (editText.getText().toString().equals("vendorsecretkey")) {
                Toast.makeText(this, "Access granted! See you on the other side!", Toast.LENGTH_SHORT).show();
            } else {
                Toast.makeText(this, "Access denied! See you in hell!", Toast.LENGTH_SHORT).show();
            }
        }
    }
  4. Audit Exported Components: Inspect Resources > AndroidManifest.xml to identify exported activities and providers that can be invoked without authentication via the Android Debug Bridge (ADB).

11. Defensive Hardening: OWASP MASVS Compliance

Hardening Android applications against static analysis and reverse engineering requires adhering to the OWASP Mobile Application Security Verification Standard (MASVS):

  • MASVS-STORAGE (Insecure Storage): Never store sensitive tokens or user credentials in plaintext in SharedPreferences, external storage, or SQLite. Use the Android EncryptedSharedPreferences API and SQLCipher for transparent 256-bit AES database encryption.
  • MASVS-CRYPTO (Key Management): Eliminate hardcoded credentials entirely. Store cryptographic keys in the hardware-backed Android Keystore system, ensuring private keys cannot be extracted even from rooted devices.
  • MASVS-RESILIENCE (Anti-Reversing): Enable code obfuscation, dead code elimination, and symbol stripping using R8 / ProGuard in build.gradle. Obfuscation transforms recognizable class and variable names into unreadable characters (a.b.c), drastically increasing reverse-engineering difficulty.
  • Production Manifest Hardening: Ensure android:debuggable="false" and android:allowBackup="false" are strictly enforced on release builds. Explicitly mark all internal activities and content providers with android:exported="false".
  • Sign with Modern Schemes: Build releases using APK Signature Scheme v2 and v3 to protect against binary modifications and the Janus vulnerability.

12. Day 7 Summary & Key Takeaways

Core Insights from Day 7

  • The Client Binary is Completely Transparent: Any secret, key, or token embedded in an APK can be extracted within minutes using automated tools like MobSF or manual decompilers like JADX-GUI.
  • MobSF Dramatically Accelerates Initial Triage: Automating the deconstruction of manifest permissions, signer certificates, and binary flags provides a complete security posture in seconds.
  • Manifest Misconfigurations Are Lethal: Enabling android:debuggable="true" allows runtime thread hijacking, while unshielded exported components permit unauthorized third-party apps to bypass authentication.
  • Signatures Must Be Modernized: Relying exclusively on v1 JAR signatures leaves applications exposed to byte-level file prepending (Janus vulnerability).
  • Manual Verification with JADX-GUI is Essential: Automated tools highlight potential risks, but manual source-level code analysis is necessary to confirm true exploitability and business logic flaws.
WARNING: Strictly For Educational & Defensive Purposes Only

All mobile application security testing, decompilation exercises, and vulnerability analysis documented in this report were performed strictly within an authorized laboratory context using DIVA (Damn Insecure and Vulnerable App). Reverse engineering, tampering with, or extracting proprietary source code from third-party commercial applications without authorization is illegal under the Electronic Transactions Act (ETA) of Nepal and international copyright and computer crime laws. TheWH2 and BugXploit promote ethical, responsible mobile security engineering.