Inside HEXVulnMob: A Complete Walkthrough of OWASP MASVS Vulnerabilities

Your hands-on guide to exploiting and understanding mobile security flaws in a safe lab environment

Introduction

Mobile application security is more critical than ever, but finding safe, legal ways to practice identifying vulnerabilities can be challenging. Enter HEXVulnMob – an intentionally vulnerable Android training application developed by the Research and Development Team at Hiesen Cybersecurity.

Whether you’re a security professional sharpening your skills, a developer wanting to understand mobile vulnerabilities, or a student learning application security, this walkthrough will guide you through every vulnerability category, explain the implementation details, and show you how to extract flags safely.

Remember: This guide is for educational purposes only. Always practice in isolated lab environments with applications you own or have explicit permission to test.

How HEXVulnMob Works

Before diving into specific vulnerabilities, let’s understand the application architecture:

Core Components

Challenge Catalog – All test cases are defined in app/src/main/assets/mstg_test_cases.json
Category Engines – Each vulnerability category has its own engine (e.g., CryptoChallengeEngine.kt) that handles instructions, actions, and validation
Flag Generation – Flags follow a consistent pattern:

HEXFLAG{challengeId-first12hex(sha256(install_seed:challengeId:proofToken))}

Where:
- install_seed is unique per installation (stored in shared_prefs/hexvulnmob_flags.xml)
- proofToken is extracted from code, resources, or runtime behavior

Recommended Solving Workflow

Open a challenge and read the description carefully
If a “Run Action” button exists, execute it once
Collect evidence from the appropriate surface:
- Network traffic (parameters, responses)
- Application files (databases, shared preferences)
- Logcat output
- UI elements (WebView, notifications, input fields)
- Runtime hooks (RuntimeFlagSink.emit)
For static tests, extract the proof token and derive the flag using the installation seed
Submit your recovered flag

Vulnerability Deep Dive by Category

Let’s explore each vulnerability category, what makes it vulnerable, and how to extract the flag.

MASVS-CODE: Code Quality and Build Settings

These challenges focus on compilation protections and dependency management.

MASTG-TEST-0222 – Position Independent Code (PIC) Not Enabled

What makes it vulnerable? The native library lacks position-independent code, making memory addresses predictable and exploitation easier.

Implementation: A static seed (NativeProtectionNotes.picDisabledSeed) in NativeProtectionNotes.kt serves as the proof token.

How to solve: Extract the seed value through static analysis, combine with your installation seed, and derive the flag using the formula.

MASTG-TEST-0223 – Stack Canaries Not Enabled

What makes it vulnerable? Missing stack canaries means buffer overflows won’t be detected at runtime.

Implementation: Static seed NativeProtectionNotes.stackCanarySeed in the same file.

How to solve: Same approach – static extraction plus flag derivation.

MASTG-TEST-0245 – References to Platform Version APIs

What makes it vulnerable? Contains references to APIs that may behave differently across Android versions, potentially leading to compatibility issues.

Implementation: BuildVersionReferences.platformApiSeed provides the proof token.

How to solve: Extract the seed statically and derive.

MASTG-TEST-0272/0274 – Known Vulnerable Dependencies

What makes it vulnerable? Intentionally outdated dependencies with known CVEs appear in both project references and SBOM (Software Bill of Materials).

Implementation: DependencyNotes.depsSeed and DependencyNotes.sbomSeed in DependencyNotes.kt

How to solve: Static extraction of these seeds, then flag derivation.

MASVS-CRYPTO: Cryptographic Failures

This is where we see common cryptographic mistakes in mobile applications.

MASTG-TEST-0204/0205 – Insecure Randomness

What makes it vulnerable? Using Random() (a weak PRNG) or System.currentTimeMillis() for cryptographic purposes instead of SecureRandom.

Implementation: CryptoActionRunner.useInsecureRandom() and useNonRandomSource()

How to solve: Run the action and either read the output directly or hook into RuntimeFlagSink.emit() to capture the flag as it’s generated.

MASTG-TEST-0208 – Insufficient Key Sizes

What makes it vulnerable? RSA key generation with only 1024 bits (considered weak since 2015).

Implementation: KeyPairGenerator initialized with 1024 in generateWeakKey()

How to solve: Execute the action and capture the emitted flag.

MASTG-TEST-0212 – Hardcoded Cryptographic Keys

What makes it vulnerable? AES keys derived from flag bytes and hardcoded IVs in CryptoArtifacts.kt

How to solve: Hook RuntimeFlagSink.emit or intercept cipher API calls during action execution.

MASTG-TEST-0221/0232 – Broken Algorithms and Modes

What makes it vulnerable?

TEST-0221: Using DES (Data Encryption Standard) which is obsolete
TEST-0232: Using ECB mode which leaks patterns in encrypted data

Implementation:

Cipher.getInstance("DES/ECB/PKCS5Padding") for TEST-0221
Cipher.getInstance("AES/ECB/PKCS5Padding") for TEST-0232

How to solve: Run the action and capture the runtime-emitted flag.

MASTG-TEST-0307/0308 – Multi-purpose Asymmetric Keys

What makes it vulnerable? Using the same key pair for both signing and encryption violates cryptographic best practices.

Implementation:

TEST-0307: Reference implementation with null flag
TEST-0308: Runtime-seeded implementation using SecureRandom(flag)

How to solve: Run action and capture emitted flag.

MASTG-TEST-0309/0310 – Reused IVs

What makes it vulnerable? Initialization vectors (IVs) should be unique per encryption operation. Reusing them weakens the encryption.

Implementation:

TEST-0309: Static IV from HardcodedKeys.reusedIv
TEST-0310: Predictable IV from flag bytes

How to solve: Execute action and capture runtime flag.

MASTG-TEST-0312 – Explicit Crypto Provider

What makes it vulnerable? Hardcoding “AndroidOpenSSL” as the provider reduces portability and may bypass security updates.

Implementation: Cipher.getInstance(..., "AndroidOpenSSL") in useExplicitProvider()

How to solve: Run action, capture emitted flag.

MASVS-NETWORK: Network Communication Vulnerabilities

Network-related flaws are among the most common in mobile applications.

MASTG-TEST-0217/0218 – Insecure TLS Protocols

What makes it vulnerable? Enabling TLSv1 and TLSv1.1 (both deprecated due to known vulnerabilities like POODLE, BEAST).

Implementation:

TEST-0217: Static configuration in InsecureTlsConfig.allowedProtocols
TEST-0218: Runtime probe using SSLContext.getInstance("TLSv1")

How to solve:

TEST-0217: Extract InsecureTlsConfig.proofToken statically, derive flag
TEST-0218: Run probe, hook runtime emit

MASTG-TEST-0233/0235/0236/0238 – Cleartext Traffic

What makes it vulnerable? HTTP usage instead of HTTPS, exposing data to network sniffing.

Implementation: Multiple variations:

TEST-0233: Hardcoded HTTP URL in HardcodedEndpoints.httpBaseUrl
TEST-0235: Manifest setting android:usesCleartextTraffic="true" and NSC configuration
TEST-0236: Login over HTTP with flag in query parameter
TEST-0238: Runtime telemetry over HTTP

How to solve:

Intercept network requests (look for ?flag= parameters)
Check manifest and network security config for tokens
Hook runtime emit

MASTG-TEST-0234/0239 – Socket-level Vulnerabilities

What makes it vulnerable? Bypassing higher-level secure APIs:

TEST-0234: Raw SSL sockets without hostname verification
TEST-0239: Custom HTTP implementation over raw sockets

How to solve:

TEST-0234: Extract InsecureSslSocketClient.proofToken statically
TEST-0239: Intercept the flag in HTTP requests or hook runtime

MASTG-TEST-0242/0243/0244 – Certificate Pinning Failures

What makes it vulnerable?

TEST-0242: Missing pinning entirely for a domain
TEST-0243: Expired pin-set with fallback behavior
TEST-0244: Runtime HTTPS client without pinning

Implementation: Network Security Configuration (NSC) files and custom HTTP clients

How to solve:

Inspect NSC XML files for tokens
Intercept HTTPS traffic to observe unpinned requests
Static token extraction for expired pins

MASTG-TEST-0282/0283/0284 – Trust Manager Vulnerabilities

What makes it vulnerable?

TEST-0282: Trust-all certificate manager accepting any certificate
TEST-0283: Permissive hostname verifier accepting any host containing “hexvulnmob”
TEST-0284: WebView ignoring SSL errors

How to solve: Extract proof tokens statically from the implementing classes and derive flags.

MASVS-PLATFORM: Platform Interaction Vulnerabilities

These challenges focus on how the app interacts with the Android platform.

MASTG-TEST-0250/0251 – Content Provider Access in WebViews

What makes it vulnerable? WebViews with content provider access can expose sensitive app data to web content.

Implementation:

TEST-0250: Reference implementation with JavaScript alert containing flag
TEST-0251: Runtime implementation with flag in URL query parameter

How to solve:

TEST-0250: Run action, read the alert value
TEST-0251: Inspect WebView URL or intercept traffic

MASTG-TEST-0252/0253 – Local File Access in WebViews

What makes it vulnerable? WebViews that can access local files may expose sensitive application data.

Implementation: HTML files written to app directory at startup containing flags

How to solve: Read the generated HTML files from the app’s files directory or hook runtime emit.

MASTG-TEST-0258/0289/0291/0292/0293/0294 – UI and Screenshot Protections

What makes it vulnerable? Missing protections against:

Keyboard caching of sensitive input (0258)
Screenshots when app is backgrounded (0289)
Recents screen showing sensitive data (0292)
SurfaceView capture (0293)
Compose dialog capture (0294)

How to solve: Most emit flags via RuntimeFlagSink.emit() during action execution. Hook this method or observe the UI behavior.

MASTG-TEST-0315/0316 – Sensitive Data Leakage

What makes it vulnerable?

TEST-0315: Sensitive data in notifications (visible on lock screen)
TEST-0316: Plaintext sensitive values in input fields

How to solve:

TEST-0315: Run action, read notification content
TEST-0316: Run action, read the displayed field value

MASVS-PRIVACY: Privacy Violations

MASTG-TEST-0206 – Undeclared PII in Traffic

What makes it vulnerable? Sending personally identifiable information (email addresses) over cleartext without disclosure.

Implementation: Request to /api/privacy/pii?email=...&flag=...

How to solve: Intercept network traffic or hook runtime emit.

MASTG-TEST-0254/0255/0256/0257 – Permission Issues

What makes it vulnerable?

0254: Requesting dangerous permissions without justification
0255: Overbroad permission requests
0256: Missing rationale before requesting sensitive permissions
0257: Not resetting unused permissions

How to solve: Most write flags to files or emit at runtime. Check files/privacy_permissions.txt or hook runtime emit.

MASTG-TEST-0318/0319 – Sensitive SDK Usage

What makes it vulnerable? References to and runtime usage of SDKs that collect sensitive data.

Implementation: PrivacyTrackingSdk with static token and runtime collection

How to solve:

0318: Extract PrivacyTrackingSdk.sdkReferenceToken statically
0319: Run action, hook runtime emit

MASVS-RESILIENCE: Reverse Engineering Protections

MASTG-TEST-0224/0225 – Signature Issues

What makes it vulnerable? Weak APK signing schemes and key sizes.

Implementation: Writes reports to files/signing_report.txt and files/signing_keysize.txt

How to solve: Run actions and read the generated files.

MASTG-TEST-0226/0227 – Debugging Enabled

What makes it vulnerable?

0226: App debuggable flag set in manifest
0227: WebView debugging explicitly enabled

How to solve:

0226: Extract ResilienceProofs.debuggableToken statically
0227: Run action, hook runtime emit

MASTG-TEST-0247/0249 – Screen Lock Detection

What makes it vulnerable? Reference to and runtime checking of device lock status can leak information about security state.

How to solve:

0247: Extract ResilienceProofs.secureLockRefToken statically
0249: Run action, read output or hook runtime

MASTG-TEST-0263/0264/0265 – StrictMode Issues

What makes it vulnerable? StrictMode violations can leak sensitive flow markers through logs.

How to solve: Run actions and capture output or hook runtime emit. For 0265, extract static token.

MASTG-TEST-0288 – Debug Symbols in Native Binaries

What makes it vulnerable? Native libraries compiled with debug symbols保留 sensitive function names and line numbers.

Implementation: Writes report to files/native_symbols.txt

How to solve: Run action and read the generated file.

MASVS-STORAGE: Data Storage Vulnerabilities

MASTG-TEST-0200/0201/0202 – External Storage

What makes it vulnerable? Writing sensitive data to external storage where other apps can read it.

Implementation:

0200: App-specific external directory (external_flag.txt)
0201/0202: Public external storage (/sdcard/Download/public_flag.txt)

How to solve: Run actions and read the files or hook runtime emit.

MASTG-TEST-0203/0231 – Logging

What makes it vulnerable? Writing sensitive data to logcat where any app with READ_LOGS permission can access.

Implementation: logSensitiveData() writes flags to logcat

How to solve: Run actions and monitor logcat output.

MASTG-TEST-0207 – Unencrypted Internal Storage

What makes it vulnerable? Even internal storage is vulnerable if the device is rooted or compromised.

Implementation: Writes files/internal_flag.txt

How to solve: Run action, read file or hook runtime.

MASTG-TEST-0216/0262 – Backup Vulnerabilities

What makes it vulnerable? Sensitive data included in Android backups (ADB backup) without exclusion.

Implementation: Shared preferences in backup_prefs.xml with flags

How to solve: Run actions, inspect the backup prefs file, or check manifest for backup configuration tokens.

MASTG-TEST-0287 – SharedPreferences

What makes it vulnerable? Plaintext secrets in XML preference files.

Implementation: storage_prefs.xml with key “flag”

How to solve: Run action, inspect the generated prefs file.

MASTG-TEST-0304/0305/0306 – Database Storage

What makes it vulnerable? Plaintext secrets in various database formats:

0304: SQLite database (storage_plain.db)
0305: DataStore (storage_datastore.preferences_pb)
0306: Room database (storage_room.db)

How to solve: Run actions, then inspect the database files using SQLite browser or appropriate tools.

Key Source Code Locations

For those wanting to dive deeper into the implementation:

Challenge Definitions: app/src/main/assets/mstg_test_cases.json
Flag Logic: app/src/main/java/com/hexvulnmob/data/FlagEngine.kt
Category Engines:
- Code: CodeChallengeEngine.kt
- Crypto: CryptoChallengeEngine.kt
- Network: network/NetworkChallengeEngine.kt
- Platform: PlatformChallengeEngine.kt
- Privacy: PrivacyChallengeEngine.kt
- Resilience: ResilienceChallengeEngine.kt
- Storage: storage/StorageChallengeEngine.kt

Ethical Considerations

HEXVulnMob is designed as a safe learning environment. As you work through these challenges, remember:

✅ DO use this in isolated lab environments
✅ DO practice ethical hacking principles
✅ DO learn to identify these patterns in your own applications
❌ DON’T apply these techniques to applications you don’t own
❌ DON’T use this knowledge for unauthorized testing
❌ DON’T share flags or solutions in ways that enable cheating

The goal is to understand vulnerabilities so you can prevent them, not exploit them in the wild.