Another summer has flown by. Vacations, court (yes!), classes (also, yes!), and of course the conference circuit were (and still are) all in full effect this year. Things are winding down a little and I finally have a chance to put fingers to keyboard and write about some things I have had in the works. It is getting increasingly difficult these days to find time to sit and write. I am hopeful, though, that this trend will change.
First up is Samsung. Specifically, Samsung Customization Services (aka Rubin) and Digital Wellbeing (DWB). I have had quite a few folks either contact me directly or via work asking questions about both and some of the strange behavior they exhibit, and I think strange is probably the best way to put it. This is Samsung, after all, and, when it comes to Android, they like to do things in their own unique way. It keeps examiners on their toes and adds a some variety into Android. Because Android forensics is lacking in variety, amirite?
During testing I had to contend with Samsung’s SPL’s and general updates, which made getting extractions tricky and frustrating. Sometimes I would get the necessary key material for Rubin, and other times I wouldn’t. It just depended on which way the wind was blowing when I was doing the extraction. Either way, the S22 got a great workout. It was running Android 15 (OneUI 7) with the December 2024 and April 2025 SPLs. I know there is a July SPL, but since I was already having a difficult time with the phone, I opted to hold what I had.
If you have not read up on Samsung’s implementation of DWB, you can read about it here. And, if you are not familiar with Samsung Rubin, Cellebrite has a few resources, all of which you can find here.
This will be my shortest post, by far, but it is important as it relates to data that may be missed.
Locks & Unlocks – Better Together
The heading really says it all. If an examiner encounters a phone using both Rubin and DWB these two items need to be examined together in order to get the best picture of what was happening on the device. The reason is that one bit of information that is traditionally kept by DWB is shuffled over to Rubin, when enabled: device unlocks. See Figure 1.
Above is an excerpt from the usageEvents table in dwbCommon.db. The timeframe covered by the screenshot above should have had two unlock events (eventType=18), but it did not. Just to double-check, I manually examined the usageEvents table and found no eventType=18 values at all, which begs the question: how does the phone know I unlocked it twice during this time period? As it turns out, Rubin had the data. See Figure 2.
The table screen_state_log in inferenceengine_logging.db contains information on both device unlocks and locks. In order to determine what records represents which action, the columns screen_state, user_present, use_keyguard, and time (I use this because I like UTC) or time_string (time local to the device at the time of the event) are used together. This table will also tell you when the screen is illuminated. I have observed the following combinations:
- Unlock (biometric or passcode)
screen_state = 1
user_present = 1
use_keyguard = 0 - Locked by side button push
screen_state = 0
user_present = 0
use_keyguard = 1 - Locked by reaching screen timeout threshold
screen_state = 0
user_present = 0
use_keyguard = 0 - Screen is illuminated, but no unlock occurs
screen_state = 1
user_present = 0
use_keyguard = 1
Again, these unlock events were not recorded in dwbCommon.db (or its -WAL). Interestingly enough, though, some of the lock events (eventType=17) were recorded in usageEvents (dwbCommon.db), but not all them and they were approximate to the same action documented in screen_state_log (inferenceengine_logging.db).
One additional note here: if a user turns Rubin off, this behavior above still applies. Unlocks are still logged to Rubin and will not show up in DWB.
Lazy Writes & Completed Boots
Samsung decided to implement their own version of DWB, which is permitted under Google’s Mobile Services contract. As a result, they have implemented and make use of a table named Logging in dwbCommon.db, and, as the name suggests, it is logging things, a couple of which can be useful from an examiner’s perspective. The first item is device boots, and, while we have been able to see this in the usageEvents table since the beginning, this exploratory brought a little more clarity to our understanding of what actually constitutes a “boot.” This is where I found some odd behavior. See Figures 3 and 4.
Figures 3 & 4 really bring the strange behavior to light, as I had this happen multiple times during testing. Figure 3 has the last two records in the Logging table, and there are two “BOOT_COMPLETED” entries. The interesting thing about these entries is their relationship to the last four entries in the usageEvents table: they post-date them by over 12 hours! This is interesting because there was activity on this phone that should have logged information in usageEvents that occurred on 4-August, including two boot actions, yet they are not in usageEvents. After a few more extractions a few hours later, though, the records finally appeared.
What we have here is an instance of lazy writes. What I mean by that is the usage data was not present in either the main database or the associated -WAL file, and it was not recorded to either for quite some time. In testing, I observed this behavior multiple times, and I have had other practitioners who have contacted me describe the same behavior. I saw records take anywhere from 1 hour to over 12 hours to write to either to the database or -WAL (I had a few instances where it took over a day for records to appear). I have scoured the S22 extractions and can not find where this data is being held until such time it is recorded. I initially suspected RAM, but reboots of the device did not seem to force the writes. What triggers the writes is still a mystery to me, but examiners should know it is possible that there could be records that have yet to be written, especially if they check the Logging table and see entries like those in Figure 3 that post-date the last entries in usageEvents by such a large time period.
This discovery also revealed something else: “BOOT_COMPLETED” entries in the Logging table are not as clear a statement as they seems to be. During testing, the S22 rebooted multiple times, but there were times where the timestamp associated with BOOT_COMPLETED records were well past when the device actually rebooted. Consider this: a user reboots their phone but instead of unlocking the phone right away, they let it sit for some time. Eventually, the user unlocks the phone so they can start using it. Figure 5 shows an example of this below.
There are two reboot events above. The first occurred on 2025-08-04 at 09:26 (UTC -0400), but the phone was not unlocked until 09:27 (UTC -0400). The second reboot occurred on 2025-08-04 at 19:20 (UTC -0400), but the phone was not unlocked until 2025-08-05 at 08:29 (UTC -0400). As seen above, the BOOT_COMPLETED entries coincide with with the phone was first unlocked. To confirm what I was seeing here, I looked in the file eRR.p (USERDATA/system/users/service/data/). Figure 6 below shows the relevant time frame, with the corresponding reboots in their respective color coding.
So what was (is) happening? When the S22 was being unlocked for the first time after a reboot, the screen showed “Phone is starting…” after I supplied the PIN. The phone, up until this point, was in a BFU state; it could do some things, but not all of the things it can do. Once I supplied the PIN, the phone “finished” its booting process and went into an AFU state. It appears, that, as far as DWB is concerned, the booting process was not complete until the phone entered an AFU state.
Note that the phone had crashed during the previous extraction, which explains the KP event (likely a kernel panic) seen in line 292 in Figure 6.
No Rubin? No Problem.
So far this discussion revolves around when Rubin and DWB were cohabitating on the phone. But what happens when a user does not use Rubin? To test this, I reset the S22, but did not sign into my Samsung account. I will go ahead and note that I still observed the lazy writing of records to the database in the same fashion as before. When it came to DWB, though, the story was slightly different. See Figure 7.
Without Rubin enabled, unlock events (eventType=18) returned to the usageEvents table. And, as before, the device startups records (eventType=27) were still indicative of the first time the phone was unlocked after a boot/reboot. Figure 8 shows the Logging table with the a BOOT_COMPLETED record highlighted. Note its time is approximate to record 855 (DEVICE_STARTUP) seen in Figure 7.
That Was Quick
While this is my shortest post…like ever…I thought it was important to highlight this on its own. Not only does a Rubin+DWB setup cause issues, but it can cause forensic tools to miss important data. Data that examiners have come to rely on over the past five years. Additionally, this habit of not writing records immediately can give examiners a false sense of security when not everything has been written. Records may be pending a write and not available (I still think this stuff is on disk somewhere – I’ll continue to look), and examiners may draw wrong conclusions due to a lack of data, so it is important to understand that this behavior exists.