Accounts and passwords can be recovered by most commercial tools. In this slide, the User Accounts and Passwords, parsed by Physical Analyzer and listed in the Analyzed Data section of the tool, contain both usernames and passwords. Sometimes, the data may be nonsensical because of the encryption settings of the application or device. The USERDATA/system/accounts.db file may contain user account information for Google, third-party applications, and other online resources. This file was last leveraged in Nougat (OS 7). For newer Android devices you may see an accounts_de.db or accounts_ce.db, which will be discussed further in these notes.

If you have multiple users, you may also see user/10, user/11 or user/150. Always note that the primary user will be user/0. Use your forensic tools to identify what is being parsed and then do a logical search to ensure nothing is being overlooked. Some tools will parse the accounts files.  The passwords may be encrypted and are not easy to obtain, but some smartphone forensic tools can decrypt them. Some passwords may be stored at tokens and are not readable. 

Another location that stores account information is com.google.android.gms/shared_prefs/BackupAccount.xml. If the user sets a backup account for recovery, the email listed here will be different from the primary email in the accounts files. 

You will find many locations during the labs in this section that store account information. It honestly can be overwhelming. Finally, two fantastic places to go hunting for accounts and passwords is com.android.providers.settings/* and com.google.android.gms/databases/*.  Bottom line – usernames, passwords and account information are stored in many places on Android devices. A keyword search may help you hunt these artifacts down.

USERDATA/system_de/0/accounts_de.db and USERDATA/syste_ce/0/accounts_ce.db appear to track user accounts added to the device, even those used by some third-party apps. NOTE that not all user accounts will be placed here, which we found in our testing. You may have to examine the application preferences to uncover all.  Some third-party apps will be seen here, even though no user account was associated with the application. Some third-party apps that use a distinct user accounts may not list the account here but there will include an entry for the app. This requires further investigation by the examiner.

Some tables and columns worthy of mentioning include multiple “action types” in the table “debug_table” 

  •  action_add_account - can represent either the time of login (for apps that require it), or the first time an app is used (when a user did not log in or app doesn’t require it)  

  •  action_called_account_remove 

  •  action_account_remove 

NOTE: Only “action_add_account” is consistent.  The other two are not consistent enough to rely upon. 

SELECT 

accounts.type AS “App”, 

accounts.name AS “Account”, 

debug_table.action_type AS “Action”, 

debug_table.time AS “Action Time” 

FROM 

accounts 

JOIN debug_table ON debug_table._id=accounts._id 

NOTE: The times will vary.  If the Google account is added during the initial setup of the phone, the time added will be in UTC.  The remaining times in the database will be in local time.