Android 12’s arrival brought a few new things to the platform. While the most notable was the re-design of the user interface (Material You), there was the addition of Privacy Dashboard, which is Google’s offering to users to garner “trust” in the Android platform through transparency.
Google decided to implement Privacy Dashboard in response to users’ request to understand what data is being accessed or used by their apps, which is not an unreasonable request. Knowing what your phone is doing is always a good thing, including what it’s doing when you aren’t actively using it or what it’s doing in the background while you are. Android (and iOS) devices are constantly generating, collecting, and using our data from a variety of categories (e.g. our locations, our contacts, etc.), most of it behind the scenes. OEMs/operating system developers do this to provide a better user experience. As users, we consent to this (blindly?) when we agree to the terms of service prior to using our devices. There is a level of paranoia out there when it comes to “big tech,” though, and Privacy Dashboard looks to calm the fears of Android users by offering them a glimpse into location, camera, and microphone activity ocurring on their phones.
I decided to take a look at Privacy Dashboard to see if there was any way to forensically examine the data that was captured by the feature. Knowing an app used a phone’s location, camera, or microphone can be helpful during an examination in a couple of ways. For starters, examinations involving mobile malware could benefit from knowing that a suspicious app was accessing a phone’s microphone when the app’s reported purpose has nothing to do with recording audio. Or, an app allegedly never used by a phone’s owner has entries in the Camera portion of Privacy Dashboard. These are just two examples, of course. I am sure creative examiners/investigators can think of other ways to apply this data.
For testing I used my Pixel 3 running Android 12 with the October patch (I totally lied about AirTags being the last time I used it). I also used the latest versions of WhatsApp (2.21.24.22) and AirTracker (1.1.0) as third party apps.
Taking A Peek
Right now Privacy Dashboard is an Android 12-only feature. It is not found on devices running Android 11 or below. It is enabled by default. Privacy Dashboard looks very similar to Digital Wellbeing from a user’s perspective. It can be found by going to Settings > Privacy > Privacy Dashboard. The UI has as circle that shows the breakdown of Location, Camera, and Microphone (LCM) usage over the past 24 hours. See Figure 1.
One note about the time limit. Google states that users do not recollect their activities beyond 24 hours, which explains the 24 hour limit.
Below the circle, a user can press on one of the three categories to get more information about apps using said category (red box – Figure 1). Figure 2 shows Location.
Figure 2 shows apps that have used the phone’s location along with a timeline of when the location was used. All of this is presented in a nice chronological format. Pressing the three dots in the upper right hand corner presents the user with the option to show system apps that have used location. Figure 3 shows roughly the same timeframe as Figure 2, but with the added system apps.
Interestingly enough, Camera and Location do not offer the ability to see system apps that have used them.
There is a section underneath the red box in Figure 1: “See other permissions.” Expanding it shows additional permissions such as Phone, Call Logs, Body Sensors, and Files & Media. Privacy Dashboard does not track those permissions at the time of this article, but maybe it will at some later date.
Figures 4 & 5 show how Camera and Microphone usage looks in the UI.
From the user’s perspective, that’s it. It is very simple.
Pulling Back the Curtain
Unfortunately, the forensics behind Privacy Dashboard are not quite as simple as the UI. Privacy Dashboard stores its data in the USERDATA/system/appops/discrete directory path. See Figure 6.
I have observed files being created anywhere between eight (8) and seventeen (17) minutes in the directory. This is just my observation; the frequency could be lower or higher depending on phone usage. An examiner should expect to find a substantial amount of files in this directory unless an app has recently been uninstalled (more on this later). The aggregate of the files found in this directory path represents 24-hours of usage. Each file is named in a specific format starting with the Unix Epoch timestamp of when the file is created followed by the letters “tl.” While the files are extension-less, they are XML files. And, they’re not just any XML files, they are Android Binary XML files. Android 12 has started using a new binary format for some of its XML files, and these files are in the new format. If you are interested in knowing more about the format, see this article by Alex Caithness. Needless to say, there is some decoding that has to occur before examining them, or the forensic tool being used needs to be able to interpret the format. At the time I was writing this article, there are two tools I am aware that are able to decode these files: Alexis Brignoni’s ALEAPP and Cellebrite Physical Analyzer 7.52 (I have not tested 7.52 yet but I have it on good authority it can decode them ). For quick decoding, I used Alex Caithness’ ABX Python module to convert the files into human-readable form. I highly recommend downloading the module for quick decoding; Alex did an outstanding job with it. Figure 7 shows one of the files after decoding with the module.
Alex’s module decodes the file into a stream without any formatting. For purposes of this article, I have formatted the decoded XML files for easier reading.
Privacy Dashboard is part of AppOps, which does several things, including tracking when apps leverage a phone’s runtime (dangerous) permissions. If you’re not familiar with Android’s dangerous permissions, I wrote an article about them last year that you can read here. Dangerous permissions include permissions that grant an app the use of a phone’s location, camera, or microphone. So, if you’ve ever looked at the file appops.xml (USERDATA/system/) then some of the contents of the files in Privacy Dashboard will look familiar.
There are multiple apps represented in file depicted in Figure 7, each with their own information. To help understand how an app is represented, Figure 8 shows the entry for just one app, AirTracker.
The entry in Figure 8 represents a single entry in Privacy Dashboard. There are three XML values that are pertinent to this entry. The first is “pn” (package name – red box), which represents the app that leveraged the LCM. Next is the value “op” (likely represents “operation” – blue box). This represents which LCM was used. In this entry, location was used (op=1) by AirTracker. Because Privacy Dashboard is tracking three things (location, camera, and microphone) there are three “op” values examiners can expect to see here:
1 = Location
26 = Camera
27 = Microphone
The final value of importance in Figure 8 is “nt” (green box). While I was not able to determine exactly what “nt” represents, I suspect it is “note time,” which is related to noteOps. Regardless of what it means, the timestamp associated with “nt=” represents when the phone’s location was used by AirTracker.
Figure 9 shows how this is viewed in the Privacy Dashboard UI (with the same color-coding). Note that the times displayed in Privacy Dashboard are in local time (UTC -0500).
One important thing to note. The entry represented in Figures 8 and 9 were the result of AirTracker running automatically in the background. Examiners should understand that Privacy Dashboard (and the underlying files it writes to storage) will contain information related to both user activity and system/automated activity. Examiners should corroborate artifacts here with others found on the device when trying to attribute Privacy Dashboard entries with user activity.
Figure 8 was a simple entry. Figure 10 shows a more complicated entry. It represents a video I took with Google Camera that was approximately two minutes in length.
When creating the video, Camera leveraged the phone’s location, the camera (obviously), and the microphone. Figure 10 has the previous XML values seen in Figure 8 (pn, op, and nt) and one additional value. This entry can be broken up into three parts, each representing a LCM. The orange arrows mark the beginning of each new section. At the top of Figure 10 we have package name (red box), the location usage (op=1 – top blue box), and the time the location was used (nt – top green box).
Below that entry we have a second operation (op=26 – middle blue box) and second timestamp (middle green box). op=26 represents the camera usage. While there are multiple timestamps (nt values) underneath that operation, the first timestamp under the operation (middle green box) is the one displayed in the Privacy Dashboard UI. The value seen in purple box (nd=133443) represents the duration (“d”) of the camera usage in milliseconds. Note that while my video was approximately two minutes, the camera was in use for a short time before and short time after the actual video was taken.
The final part of the entry at the bottom starts with the XML value op=27 (bottom blue box), which represents the microphone usage by the camera while I was taking the video. Note the timestamp (bottom green box) is close to that of the timestamp associated with the camera usage. The duration of microphone usage in milliseconds is seen in the bottom purple box (nd=126022).
Figures 11, 12, and 13 represent Figure 10 in the Privacy Dashboard UI (times in UTC -0500). While the duration of microphone usage seen in Figure 13 is “3 minutes,” the duration value (nd) for the microphone usage seen in Figure 10 is accurate.
Figures 8 and 10 show single actions by an app within one of the XML files. There will be instances where the same app is used multiple times and is represented as such within a single XML file. See Figure 14.
Figure 14 shows Google Camera leveraging the phone’s location (red box) and camera (blue box) several times within a short time span. Now, see Figures 15 and 16.
Based on the findings here, it appears Privacy Dashboard will, in cases of frequent usage within a short time frame, display the time last used and an aggregate duration of usage to a user in the UI. When this occurs, it is a good idea to look at the duration values (nd=) for indications of substantial usage.
One additional XML value that examiners may find are attribution tags, or “at.” See the red box in Figure 17.
From what I have been able to determine, it appears that attribution tags allow app developers to provide context around the operation(s) they are performing. App developers are not required to provide an attribution tag, but Google encourages it in the developer documentation.
Deleted App Usage? Nope.
Unfortunately, Privacy Dashboard does not keep data about deleted app usage. To test this I used WhatsApp to record a video that was approximately 38 seconds in length, and then pulled the corresponding XML file from the USERDATA/system/appops/discrete folder. See Figure 18.
In Figure 18 the package name (red box) camera usage (blue box), microphone usage (green box), and duration of both (purple boxes) can be seen. The entry is also seen in the Privacy Dashboard UI. See Figures 19 and 20.
I uninstalled WhatsApp and went back to the USERDATA/system/appops/discrete folder and found some interesting behavior. See Figure 21.
The green box in Figure 21 is the last bit of the file listing from the USERDATA/system/appops/discrete folder before I uninstalled WhatsApp. The red box represents the same folder after I uninstalled WhatsApp. After installation the entire folder was flushed, leaving no files left behind. However, about a minute or so later a new file was created (blue box – Figure 21). I also noticed that Privacy Dashboard UI retained its data on app usage, except for the data about WhatsApp. I pulled the single new file from USERDATA/system/appops/discrete (ending in 4300tl) and decoded it. See Figure 22.
It appears that when an app is uninstalled, the USERDATA/system/appops/discrete folder is flushed, the usage data about the remaining apps is dumped into a single XML file which is placed back into the USERDATA/system/appops/discrete folder, and Privacy Dashboard starts creating new XML files from that point forward. I searched the new single file but did not find any reference to WhatsApp. References to WhatsApp were also removed from the Privacy Dashboard UI. See Figures 23 and 24.
A Note About Samsungs
As of the time of this blog post Samsung phones running Android 12 were a bit scarce. Samsung had been rolling Android 12 out to select devices, but no one in my DFIR circle had one that could be forensically examined (I am chasing down one, though, with some help). I was, however, able to find a screenshot of what privacy dashboard functionality looks like on Samsung. Spoiler alert: it looks different than what was seen in vanilla Android. See Figure 25.
While Samsung will have this functionality, they have changed the name to “Privacy usage history.” I suspect the name will not be the only difference; the forensics behind Samsungs will likely differ than what has been described in this blog post. I hope that I am wrong, but, if history has taught us anything in mobile device forensics, it is more likely Samsung’s spin on this functionality will cause the forensics to change.
Once I get a chance to have a look at a Samsung phone on Android 12 I will update this blog post with the additional information.
Closing the Curtain
With Android 12, Google gave Android users a tool to track which apps were using their phone’s location, camera, and microphone in the name of transparency. It is great for users and it is also great for examiners as it gives us yet another “thing” that is tracking application usage across the device. Leveraging the data in Privacy Dashboard can help with malware investigations or application usage. As with all things, though, examiners should corroborate the data found in Privacy Dashboard with other forensic evidence on the device in order to differentiate between background activity and hands-on user activity.
Alexis Brignoni has done what he normally does, and has already tooled ALEAPP to parse Privacy Dashboard data. Head to Alexis’ GitHub repo to download the latest version.
One thought on “Snooping on Android 12’s Privacy Dashboard”