312-50 Question 398
Single answer▪ Hacking Android OSDuring an authorized mobile application assessment, you are testing an Android app used by field employees. The client suspects the app stores sensitive data insecurely on the device. You have physical access to a test phone with USB debugging enabled, but the device is not rooted. Which approach is the MOST appropriate first step to verify whether the app exposes sensitive files through Android Debug Bridge (ADB) backup functionality?
- A
Use adb backup against the target package and inspect the resulting backup to determine whether app data can be extracted without root access
- B
Unlock the bootloader and flash a custom recovery so you can dump the /data partition and review all application files
- C
Use adb shell to directly browse /data/data/<package_name>/ and copy the app's private files from the device
- D
Repackage the APK with additional logging code, reinstall it, and compare runtime output to identify stored secrets
Show answer and explanation
Correct answer: A
Explanation
The best answer is to first test whether the application exposes data through ADB backup because it is targeted, minimally invasive, and directly relevant to insecure local storage on Android. Historically, Android provided backup mechanisms that developers could control using the android:allowBackup attribute in the app manifest and related backup configuration. If backup is allowed and the platform supports it, application data may be retrievable without rooting the device. By contrast, direct access to /data/data requires elevated privileges because Android sandboxes each app under a distinct UID. More invasive actions such as unlocking the bootloader or modifying the APK should generally come later, if needed, because they can alter evidence, affect device integrity, or wipe data. This aligns with practical mobile assessment methodology and Android security design principles documented by Android Developers regarding app sandboxing and backup behavior.
- A. Correct.
Correct. On Android versions and app configurations where ADB backup is supported, testing whether the application permits backup is a practical, low-impact first step during an assessment of insecure local data storage. If the app allows backup and sensitive data is included, you may be able to extract application data without root. This directly addresses the client's concern while preserving the device state better than invasive methods. In CEH-style scenarios, choosing the least disruptive method that validates the risk is typically preferred.
- B. Incorrect.
Incorrect. Unlocking the bootloader and flashing a custom recovery is highly invasive, may wipe data on many devices, and changes the test conditions significantly. It is not the most appropriate first step when a lower-impact method such as checking ADB backup exposure may already answer the question. This option reflects a common mistake of jumping immediately to privileged device modification instead of testing available attack surface first.
- C. Incorrect.
Incorrect. On a non-rooted Android device, ADB shell does not normally allow access to another app's private directory under /data/data/<package_name>/. Android application sandboxing is specifically designed to prevent this. Someone might choose this option if they confuse shell access with privileged access, but standard ADB shell on a non-rooted device does not bypass app sandbox restrictions.
- D. Incorrect.
Incorrect. Repackaging and reinstalling the APK can be useful in some reverse-engineering or dynamic analysis situations, but it is not the most appropriate first step for verifying whether local app data is exposed through ADB backup. It also alters the app and environment, which can introduce side effects and move the test away from the specific question of insecure extraction via native Android mechanisms.