312-50 Question 396
Single answer▪ Hacking Android OSDuring an authorized mobile application assessment, you are testing an Android app that stores authentication data locally. The client wants to know whether a user with physical access to an unlocked, rooted test device could recover sensitive information from the app without attacking the server. Which action would be the most appropriate first step to verify whether the app is insecurely storing credentials on the device?
- A
Use adb shell to inspect the app's private data directory under /data/data/<package_name>/ and review SharedPreferences, SQLite databases, and files for plaintext tokens or credentials
- B
Capture the app's HTTPS traffic with Wireshark only; if no credentials appear in transit, local storage is secure
- C
Dump the device's bootloader partition and compare it with the factory image to identify credential storage weaknesses
- D
Review only the APK's AndroidManifest.xml permissions to determine whether the app stores credentials insecurely
Show answer and explanation
Correct answer: A
Explanation
For Android application security testing, a rooted test device enables direct inspection of the app's private storage area, typically located at /data/data/<package_name>/. This is a practical CEH-style technique for identifying insecure data storage issues such as plaintext credentials, reusable session tokens, API secrets, or sensitive cached content. Common locations include SharedPreferences, SQLite databases, WebView data, log files, and temporary files. Android security guidance and OWASP Mobile Application Security practices emphasize minimizing sensitive local storage and protecting any required data with platform-backed controls such as the Android Keystore rather than relying on obscurity. Network traffic inspection and manifest review are useful supplementary steps, but they do not replace direct examination of app data when the assessment objective is to verify local credential storage risk.
- A. Correct.
Correct. On a rooted Android test device, inspecting the application's sandbox under /data/data/<package_name>/ is the most direct and practical first step for assessing insecure local storage. Sensitive data is commonly found in SharedPreferences XML files, SQLite databases, cache files, or app-specific files. This aligns with standard Android app assessment methodology: verify whether secrets such as usernames, session tokens, API keys, or cached responses are stored in plaintext or with weak protection.
- B. Incorrect.
Incorrect. Intercepting HTTPS traffic can help identify sensitive data exposure in transit, but it does not answer the client's primary concern about local storage on the device. Even if traffic is properly encrypted and no credentials are visible on the network, the app may still store tokens or passwords insecurely on disk.
- C. Incorrect.
Incorrect. The bootloader partition is not the appropriate place to begin when assessing whether one specific application stores credentials insecurely. Dumping and comparing bootloader images is more relevant to device integrity, firmware analysis, or advanced persistence scenarios, not routine validation of app-level local data storage.
- D. Incorrect.
Incorrect. Manifest review is useful for understanding exported components, permissions, backup settings, and app behavior, but it cannot by itself prove whether credentials are actually stored insecurely. You need to inspect runtime artifacts such as files and databases created by the app.