Deep dive into the DIVA audit (Exercises 9 to 13). We transition from basic storage errors to the core of Android architecture: Inter-Process Communication (IPC) vulnerabilities and native code (C/C++) exploitation via the NDK.
If developers forget to protect an Activity, any app can invoke it.
# 1. Identify the exported component in the Manifest.
# 2. Invoke the activity directly via ADB:
am start -n jakhar.aseem.diva/.APICreds1Activity
Developers sometimes try to protect activities using Intent parameters. We can inject our own extras to bypass checks.
# Inject a boolean extra to disable PIN verification:
am start -n jakhar.aseem.diva/.APICreds2Activity --ez check_pin false
While analyzing another banking app, you discover the cryptographic key repository is shared system-wide through a misconfigured URI. Use the Android query tool to dump the data.
>_ START CTF 26 CHALLENGEContent Providers share databases with other apps. If exported without signature permissions, it's catastrophic.
# Query the exported Content Provider:
content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes
Developers mistakenly believe compiling keys into C/C++ shared libraries (.so files) hides them.
# Extract printable strings from the binary:
strings libdivajni.so | grep -i "secret"
Java apps are immune to buffer overflows, but when using unsafe JNI C/C++ functions (like strcpy), native vulnerabilities emerge.
Entering more than 20 characters overwrites the instruction pointer on the stack, causing an immediate crash (SEGFAULT / DoS). Advanced attackers could use this to achieve Arbitrary Code Execution via ROP chains.