Recently we received an email at work asking about a video clip the author had seen on their local television station. The clip showed a forensic examiner examining a file on a Samsung phone that indicated someone had turned the phone off. As it turns out the clip was a bit deceptive (TV never shows anything that isn’t true, right?), but, as it turns out, I was familiar with that file, which is how I knew the phone being examined was a Samsung. The point of the video was that the file indicated the phone had been likely powered off by a person, and not by something else like a dead battery or a system update.
As far as I know, there is no blog post about this specific file (or its siblings), so I thought a brief post was in order. I will note that this post will center around Samsung phones, but if there is a vanilla Android equivalent, I will point it out.
My colleagues The Barnharts (Heather & Jared) will be presenting much more on the topic of powered off phones at Techno Security East 2024, so I will take care in this post to not trample on their outstanding work. It is, however, important to know about these files.
Button, button. Who’s Got the Button?
When discussing powering off an Android phone it’s important to understand how that works for users. If you are a modern iPhone user, you know that you hold the side button and Volume Down for a few seconds, and are then given the opportunity to swipe left. Depending on your model of phone, this can work slightly differently for Android. Like the iPhone, when you press and hold the correct button combination for a few seconds, you’re given a few options. See Figures 1 and 2.
The options are similar, but the way I got to them is less so. In order to invoke the power options, I have to hold down at least one button. On the Pixel, it is a matter of holding down the top single button. For the Samsung, though, invoking the power options screen is more like iPhone. In addition to holding down the bottom single button (AKA the “Bixby” button), I also have to hold down the Volume Down button at the same time. This button combination is done to protect the user from inadvertent powering events.
From here a user can choose which power option they want, make an emergency call, or cancel the operation.
The Files
When Digital Wellbeing was introduced in 2019/2020 examiners got a new artifact that showed powering events. Sure, there were other artifacts an examiner could use to see powering events, but Digital Wellbeing was more explicit. The problem with Digital Wellbeing is that it does not tell an examiner why the power down event occurred. Was it due to a system update, dead battery, or a person? The why here can be extremely important from an investigative point of view.
Samsung phones have an artifact that compliments Digital Wellbeing, and is, in my opinion, also as explicit. It has the added benefit of showing why the power down event occurred. The file is eRR.p and can be found in USERDATA/system/users/service/data/, and, because of its location, it is only available in a full file system extraction. If this file sounds familiar it may be because it is one of a few files that can be used when evaluating when an Android device was last wiped . I have seen eRR.p in Android versions as early as Android 9, but it could very well be earlier. My testing and the screenshots below show how things look in Android 13, but I will add the same behavior was observed in Android 12.
eRR.p does not render well in the forensic tools I tested. I found the most optimal method to view it was using Visual Studio Code. See Figure 3.
The best way to read the entries in eRR.p varies depending on what happened. Starting with something simple, see Figure 4.
The area in the red box in Figure 4 represents a single event: the phone was powered off by me using the correct button sequence on the phone (Volume Down + Bixby > Select Power Off). You have the time the shutdown occurred, 09:47:14, the event SHUTDOWN and the reason, userrequested. The nice thing about eRR.p is that it will give you the time zone offset of the timestamp, which can be seen in all of the screenshots here. While anything is a possibility, the chances of the correct sequence being done accidentally are quite low. Knowing a phone was powered off in this fashion can have investigative value.
Taking things one step further, read the entry in Figure 4 plus the next entry. See Figure 5.
In Figure 5 there is a wider event. The power off event seen in Figure 4 is present, but the following power on event is seen with it. At 09:52:22 the Samsung phone was powered on using the Bixby button, and that is reflected here. Following the timestamp, we have ON followed by the value NP. While I have not been able to find any documentation supporting my thoughts here, I suspect NP stands for “no power.” The device came from a “no power” state to the powered on state. Following NP we have the model of the phone (S901B), and beyond that we have two fields, OFFSRC and ONSRC. The value in the former field is PWRHOLD, which is indicative of my following the correct button sequence (maybe “power hold”). The latter, ONSRC has the value PWRON which is indicative of my having held the Bixby button to turn on the phone.
An additional note about ONSRC. I also observed the values ACOKB and INST_ACOK. Both appear when the phone was on a charger at the time but I have not been able to determine the difference between the two values. At first I thought it may have something to do with how the device was being charged (e.g., on a wall charger versus on a USB of a computer), but my results were inconsistent so more testing is needed here.
Reading the two entries in Figure 5 as a pair helps to better understand what happened. Someone likely powered off the phone by using the correct button sequence, and it was subsequently powered on via the Bixby button. You could easily read each entry individually and come to the same conclusion, but I prefer having context around each event.
The next thing I did was reboot the phone using the correct button sequence (Volume Down + Bixby > Select Reboot). See Figure 6.
Here it is beneficial to read this event as a pair. I have the time of the event (09:54:04), the event REBOOT, and the reason (userrequested). The following line shows the device powering on as part of the reboot process. The time (09:55:05), the power on even ( value ON), and then the value RP. I suspect this value is “reboot power;” in other words, the device came to the ON state from a reboot. As with NP I have no documentation to confirm this. Continuing on, the field OFFSRC is blank, which makes sense as the phone never turned off but the ONSRC has the PWRON value.
What if the device owner is a more advanced user, one that has used ADB? Well, there are entries for that, too. See Figure 7 to start.
For purposes of this exercise I added some timestamps to my CLI. In the blue box, you can see I sent the command adb shell reboot -p, which is the command one can use to shutdown an Android device. In the red box you can see the time at which the next prompt was created in the CLI (when I pressed ENTER), which is indicative of when the command was sent to the phone. Now, see Figure 8.
The red box in Figure 8 represents the shutdown event. The timestamp is off by one second from the timestamp in the red box in Figure 7. Also note the REASON value: shell.
The two lines highlighted in the green box are interesting. After shutting down the device via ADB, I left the phone plugged in to the computer. The charging indicator came up on the screen and gave me a charge percentage of 81 (81%). Note that the timestamps for the two events in the green box are the same, and have changed their offset to UTC. I suspect this is because the phone does not know where it is located due to Android not running. Also note the NP value in the first line. It came to that state from a “no power” state. The OFFSRC value in the first line is also interesting in that I did not shutdown the device using the button sequence.
The next line in the green box only has a value of LPM. Without any documentation, I am left to speculate that this may represent “low power mode.”
A user may also need to boot in to fastboot or recovery modes. Figure 9 shows how those REASON values appear. Note that it is a reboot (e.g., adb reboot fastboot, adb reboot recovery).
LPM values also come in handy when a phone may have powered off due to a discharged battery. To see how that looks, see Figure 10.
I have highlighted two dead battery entries here. Each time after the battery died, we can see the NP – LPM sequence that we saw in Figure 8. In Figure 10 we see SHUTDOWN events with the REASON value of no power. The line following the shutdown show that the phone has lost the ability to determine what time it is (2021-01-01 12:00:07) and that the phone arrived in the state from a NP (again, no power) state. The end of the second lines show the battery percentage level of 0%, which makes sense seeing how the battery had died on both occasions. In both instances, I had plugged the phones into a wall charger. The third lines differ slightly. In the first instance the phone rebooted automatically, and you can see that by the RP value. In the second instance, I had to manually turn the phone on, and that can be seen by the NP value.
eRR.p will also show phone crashes (i.e., kernel panics). See Figure 11.
Kernel panics are interesting in eRR.p in that they do not have a preceding power off/reboot event. This makes sense due to the sudden nature of the power event; the phone shuts off in a non-expected, non-OS way. In each of the highlighted lines in Figure 11 we start with the timestamp followed by KP, which I suspect is “kernel panic.” At the end of each line you can see PANIC followed by Oops: Fatal exception. Another example with a slightly different message appears below in Figure 12.
The Other Files
Earlier I mentioned eRR.p has siblings. These files keep the same information as seen in eRR.p, but formatted in a slightly different manner. The formatting of these other two files makes it so forensic tools and a text viewer/editor can view the files. Their names are power_off_reset_reason.txt and power_off_reset_reason_backup.txt. Both are found in the USERDATA/log/ directory path. The latter extends the event horizon for the former. See Figure 13 for power_off_reset_reason.txt.
The best way I can describe this file (and power_off_reset_reason_backup.txt) is as a “formatted eRR.p.” The area highlighted in the red box contains the same timestamp as the highlighted area in Figure 4 as well as the reason for the shutdown, userrequested. The timestamp in the blue box is interesting. It’s approximately five (5) seconds before the shutdown event. Examining this file I found multiple entries like this where the earlier timestamp preceded the timestamp that also appeared in eRR.p by a few seconds. Additionally, power_off_reset_reason_backup.txt contains some of the preceding timestamps.
Figures 14 and 15 show the same powering events as seen in Figures 6 and 8, but as they appear in power_off_reset_reason.txt. Note the preceding timestamp in Figure 14.
Figure 16 shows the top dead battery event from Figure 10, but from power_off_reset_reason_backup.txt. This also has a preceding timestamp.
One additional note. An examiner may run across a recovery event in eRR.p, and may find additional context around that event in power_off_reset_reason.txt and power_off_reset_reason_backup.txt, so it is important to examine both files. Below is an example of this. Figure 17 shows a recovery event in eRR.p, and Figure 18 shows the corresponding entry in power_off_reset_reason_backup.txt.
This event was caused by the phone updating. Whether or not the update was automatic or triggered by a user is another matter. 🙂
Powering Off
Sometimes investigations can come down to the smallest of details, so having context around events is always valuable. Some detail may seem small or insignificant at first, but it could end up being the fulcrum of both an examination and investigation. Having context around phone operation is never a bad thing, regardless of how small the event may be. Knowing the why behind a powering event can come in handy, and Samsung provides the data to help examiners make that determination.
2 thoughts on “DeRR.p. Investigating Power Events on Samsung Devices”