Extracting a Saved Session Token From an Android App Sandbox

Every Android app gets a private storage sandbox at /data/data/<package>. Inside it, the shared_prefs folder holds the app's SharedPreferences - simple key/value settings written out as plain XML files. Apps use this store for everything from a dark-mode flag to, less wisely, a logged-in session token. The directory is private in the sense that other apps cannot read it, but it is still just files on disk.

That distinction matters the moment someone has file-level access. A rooted device, an unencrypted backup, a forensic image, or - as here - an adb shell can all walk into /data/data/com.acme.bank/shared_prefs and open auth.xml. The banking app saved its session there as <string name="session">sess_4f91c2ad7e_prod</string>. Nothing about reading it requires breaking the app; the value is sitting in clear text alongside the username.

A session token is a bearer credential: presenting it is enough to act as the logged-in user, no password required. So a token recovered from local storage can often be replayed straight against the app's API to hijack the account. That is why storing a live session in plaintext preferences is treated as a real vulnerability rather than a cosmetic one - the sandbox boundary protects against other apps, not against someone holding the device's filesystem.

• Looking in the databases folder first. The token here is in shared_prefs/auth.xml, not the SQLite accounts.db - prefs are the simplest place an app stashes a session.
• Reading the wrong app's sandbox. com.android.systemui is system UI, not the bank; the target package is com.acme.bank.
• Opening settings.xml instead of auth.xml. settings.xml holds theme and locale; the login session lives in auth.xml.
• Assuming the token is encrypted. It is stored as a plain string the app reads back verbatim, so reading the file is enough.

Local app storage is not a safe place for a bearer credential. The fixes keep the token out of readable files and limit the damage if storage is exposed:

• Store session tokens with the Android Keystore or EncryptedSharedPreferences so the value on disk is encrypted at rest, not plain XML.
• Keep session tokens short-lived and bind them to the device so a copied token expires quickly and cannot be replayed elsewhere.
• Exclude sensitive files from backups (set android:allowBackup="false" or use backup rules) so the token is not exported in a cleartext backup.
• Detect rooted or tampered devices and refuse to persist long-lived credentials on them.

If a session token has been exposed on disk, invalidate that session server-side and force re-authentication - a leaked bearer token is usable until the server stops honouring it.