Road Trippin’ – Exploring Bluetooth Call Routes on Samsung Phones

Since I was already in the mood, I thought I would keep picking on Samsung. I have had the pleasure of assisting a few people with this question over the past year, and I thought a blog post was in order for the wider community. My colleague Heather Barnhart has a peer reviewed post about Bluetooth connections on Android phones and how they can be used to determine if a driver may have been potentially distracted during an incident. Knowing a user was concentrating on their phone instead of the road can be huge. If you work in law enforcement, evidence of distracted driving or a lack thereof can be the difference in the severity of criminal charges in a traffic collision incident, or no charges at all. If you are a consultant, knowing your client may or may not have been distracted during a traffic collision incident can have a large impact on civil proceedings. There could be other applications of this information as well. Regardless, this information could come in handy when needed.

For testing, I utilized a Samsung Galaxy S22 running One UI 6.0 (Android 14). The phone had three Bluetooth devices: a Galaxy Watch 6, a Bluetooth headset, and my car (Nissan Rogue).

Logs

The nice thing about Samsung phones is that they log a lot of stuff. Like, a lot. They actually have better logging than Google Pixels. Examiners can find all sorts of valuable information in them. While there is a concentration of logs files in the USERDATA/logs/ directory path, there are others scattered all throughout the file system. One log file that fits into the latter category is the subject of this post. It is subBuffer.log and it resides in USERDATA/misc/bluedroiddump/. While there are several things that can be derived from this file, one of the things it can tell an examiner is the route of Bluetooth audio during a phone call. In other words, where the phone sent the call audio during a phone call.

subBuffer.log is a straight text file. See Figure 1.

Four things to note about subBuffer.log. First, the timestamps do not include a year. Second, the timestamps are stored in local time, or, more specifically, what time the phone thinks it is. If there is a question about time zone settings, an examiner can check out persistent_properties in USERDATA/property/ to get the time zone setting of the phone. Third, subBuffer.log seems to keep a finite amount of data in it, and I have not been able to determine what triggers entries to fall off of the log. So, if an examiner suspects this information may be needed, it is recommended to do an extraction sooner rather than later. And lastly, this file is only available in a full file system extraction.

As previously mentioned, there were three Bluetooth devices paired with the phone. I tested the headset first. It has a friendly name of “G5.” To get a point of reference for the phone call, let’s take a look at calllog.db (USERDATA/data/com.samsung.android.providers.contacts/databases) first. See Figure 2.

The call entry highlighted in Figure 2 is the call I received and took with the headset. The timestamp is stored in Unix Epoch, but I converted it for purposes of this post (it is still in UTC). In order to make sense of subBuffer.log, a second file is needed: bonddevice.db. It resides in USERDATA/user_de/%PROFILE_NUMBER%/com.android.bluetooth/databases/. The table bonddevice has the needed information. See Figure 3.

bonddevice.db gives two pieces of information that can be helpful, the biggest one being the Bluetooth MAC address. The MAC address can be found elsewhere on the phone, but this database keeps a UUID for each device, which appears occasionally in subBuffer.log, so getting the information from one source in this exercise was convenient.

The first test involved receiving a phone call while the headset was already paired with the phone. Note that the call log reflected a call was received (“type” 1) by the phone on 2024-04-16 at 15:13:24 (UTC) (Figure 2). I will add that the Galaxy Watch 6 was also paired with the phone during this time. Now see Figure 4.

This is the portion of subBuffer.log that contains the call. I will say that the entries for BTCS-create and BTCS-onBind (highlighted in the green box at the top) were consistently present at the beginning of calls across my testing; they appear to be indicative of the establishment of some type of service (“onBind”) that is used to facilitate a connection to the currently connected Bluetooth devices. Note that the time is 11:13:24, which makes sense as the phone was UTC -0400. The entries in the red box in the middle represent me answering the call via the headset. Note that only the last two octets of the Bluetooth MAC address are showing. The bottom blue box represents when I hung up the phone. Note the string LOCAL at the end of the entry because that will come up again shortly.

Next, I took an incoming call using the Galaxy Watch 6. Figure 5 shows the record entry for the watch in bonddevice.db, and Figure 6 shows the calllog.db entry for the call.

Scrolling down a bit in subBuffer.log finds the call. See Figure 7.

As with the call with the headset, this call starts with the BTCS-create and BTCS-onBind log entries, and, as with the call received on the headset, they have approximately the same timestamp as the call in calllog.db. Things get slightly different from there. The entry highlighted in the red box is the best indicator I could find that shows the audio was routed to the watch (note the last two octets from the Bluetooth MAC address), and this was consistent across my testing. So, this is an instance where corroboration is paramount. Examiners should be doing this anyway, but especially here because, while this is indicative of when I answered the phone, it can be slightly deceptive, which will be discussed shortly. The entry in the blue box at the bottom shows the other party hung up the phone, hence the string REMOTE. This is in contrast to the string LOCAL that was seen earlier, so this is indicative of who terminated the call (the local phone or the person on the other end).

The next test run was using Android Auto. The interesting thing about Android Auto is that it requires a Bluetooth connection to the vehicle in order to make/receive phone calls. I paired the S22 to my car and received a phone call. See Figures 8 and 9 for the record entries in bonddevice.db and calllog.db, respectively. Note that Rogue is mispelled in bonddevice.db (“Rouge”).

Here calllog.db shows a call on 2024-04-16 at 21:01:02 UTC. Figure 10 shows the call in subBuffer.log.

What is notable here is that, for purposes of Android Auto, it appears my car is considered a Bluetooth head set (see the log entry just above the red box). Otherwise, this entry looks exactly like the one for the Galaxy Watch 6. The BTCS-create and BTCS-onBind log entries coincide with the timestamp for the call in calllog.db (green box at the top), the red box is indicative of when I answered the call, and the blue box at the bottom shows when the other party hung up the phone (string REMOTE).

Missed calls have the same information. See Figure 11 for a missed call (“type” 3). The subBuffer.log entry for the call is seen in Figure 12.

In Figure 12 all of the same log entries are here, including the entry in the red box. So, while the log entry in the red box appears as it does in the other scenarios where the calls were made/answered, this call was missed, which can be seen at the end of the log entry in the blue box (string MISSED. This could be further corroborated by the “3” value in the type column in calllog.db seen in Figure 11. Again, corroborate what you see in this log.

What happens when a user starts out on their headset but then transitions to their phone. Think of a scenario where the headset battery dies or a connection to a car is lost mid-call. I tested this scenario. Figure 13 shows the entry for this call in calllog.db, and Figure 14 shows how the call looked in subBuffer.log.

The usual suspects are here in the green, red, and blue boxes. However, the area highlighted in the purple box in Figure 14 is new. The entries indicate the phone stopped sending the audio to the headset. At that point during the call the audio was not routed anywhere and was only coming from the phone. I will note that while calllog.db indicates the call was 112 seconds in length, subBuffer.log seems to indicate it was 119 seconds based on the difference between the green box and blue box timestamps. For accuracy purposes I would stick with calllog.db as its main purpose is tracking call information and it does not appear to be the purpose of subBuffer.log.

The last scenario I tested was the opposite of the previous: a user starts a call on their phone but then transitions to their headset. See Figure 15 for the call information from calllog.db.

The information in subBuffer.log was spread out, so see Figures 16 and 17 for how the log entries look.

In Figure 16 the beginning of the call is seen in the green box. The purple box represents when I powered up the headset and it connected to the phone. In Figure 17, the red box represents when the audio started routing to the headset. The timing makes sense between the connection and the start of the audio routing as it took a second or two after the headset connected to the phone for the audio to start routing. As in the previous examples, the blue box is when the other party hung up the phone.

Back Home

Distracted driving is a thing, unfortunately. In 2022 the US National Highway Traffic Safety Administration (NHTSA) found that 3,308 people died as a result of distracted driving. I suspect there was a phone involved in a substantial number of those incidents.

Examiners have a few places on Android phones they can go to find device activity. There are artifacts that were already known, but examiners now have an additional artifact they can use to get an idea about the route of audio during a phone call on Samsung phones. While there are likely other applications, this artifact could certainly help find the truth in situations where there is a suspicion of distracted driving.