Android - Roles and Permissions (Android 10/11)

 Well it's a bit since I've been able to update, so I thought I'd change that. I've been working on some new research for a class I'm building and it's been giving me a chance to deep dive into some fun stuff for both iOS and Android.  I'm usually very interested to figure out preferences, permissions, and default applications on platforms as it can help shape the user's behavioral patterns. Because of this, I want to talk about where you can go look for this information in Android as it's been shaken up a bit thanks to Android 10 and 11. 

Once place to go look for installed applications on Android is the packages.xml and packages.list files that can be found within an Android's /data/system/ directory. Using the packages.list file can allow an examiner to see what applications are installed, where the data is stored within the file system, what SDK API the application is using, and some version number information. It should be noted that when a path references /data/user/0/[package name] they're referencing the /data/data/[package name] directory as Android sets up a symbolic link between the two for the default user. Additional users will be listed out there with their own user paths.

 The packages.xml file will list out all of the packages but also the permissions that each package is using. In addition to this, it will also store some good information about where the application is being stored (the apk file) as well as the installing package. If the package is com.android.vending then it came from the Google Play store. However, applications that are side loaded by another method such as ADB or downloading from the web will have a different "installer" and "installInitiator" value. 

App Installed from Google Play: 

App Installed via ADB: 

You can see above that the installer for Snapchat was com.android.vending while the Magisk Manager was installed by com.google.android.packageinstaller. 

The packages.xml file also shows which permissions have been granted by the user and requested by the application. This can help an examiner determine what functions an application may have. In addition to the package information here, there are other files which track permissions referred to as runtime permissions. For more information on the runtime-permissions.xml file and what gets stored in there I'm going to refer you over to Josh Hickman's blog on it here: https://thebinaryhick.blog/2021/01/26/androids-dangerous-permissions/. Josh was awesome in helping me test some stuff out with this. Definitely go read Josh's post on the runtime-permissions file as these are dangerous permissions that are very crucial to an investigation. 

In addition to the runtime-permissions.xml file there is also a roles.xml file. The roles.xml file is part of the Role Manager that Android added with version 10. This allows you as an examiner to figure out what the default set application is for specific functions in Android. Previously this was divided out into the settings_global, setttings_secure, and settings_system.xml files within the /data/system/users/#/ directory. The roles.xml file can be crucial in determining what application has been set by the user (or system) to perform a function, thus telling an examiner where to go look for data. Here's an example from a Samsung phone running Android 10. This file can be found in /data/system/users/0/

You can see above that most of the Samsung default applications have replaced some of the core Android functions for tasks like SMS, Dialer, Launcher, and Browser. So on this device, in addition to looking for SMS data in the standard mmssms.db file, we would need to look in the /data/data/com.samsung.android.messaging/databases directory for information. 

In Android 11, the path of the roles.xml and runtime-permissions.xml have moved. Now, they can be found in the /data/misc_de/0/apexdata/com.android.permission. If a device ran Android 10 and was then upgraded to 11, files will be present in both locations but the new location will be used for changes made after the shift to 11. By comparing the two, examiners may be able to learn historical information.

 

Curious, why ever would a calculator application need access to Camera and to write to external storage? Yeah, I think we all know the answer here. The crucial takeaway is that these permissions are NOT stored as part of the packages.xml file. 

Because these files are stored in the directories they are, they should be available even in BFU style images where only the DE (device encrypted) containers have been decrypted. 

Understanding permissions and preferences can be crucial to learning how a target behaved on their device as well trying to key in on other places where data may be duplicated. Understanding the permissions applications request can help an examiner find things that might seem out of the ordinary. In addition, anyone doing Malware investigations on Android devices should pay special attention to several of the files mentioned here to figure out where applications came from, what permissions they requested, and if they've taken over functions of the device for the user. 

Big thanks to both Josh Hickman @josh_hickman1 and Kevin Pagano @KevinPagano3 for helping me test this stuff!