January 19, 2026 / by Fortify Labs / In technical, connected vehicles, vehicles, privacy, Ford Ranger, data analysis, forensics

Behind the Dashboard: Part 3A
Where Bluetooth Data Lives

Welcome to the third post in our blog series:

Behind the Dashboard: Where the Data Lives – Inside the SYNC® 3 Filesystem – Ford Ranger

In Part 1, we kicked things off by walking through the project and how we approached this privacy demonstration. In Part 2, we dug into the data we pulled from the Ranger’s SYNC® 3 head unit — the one we picked up from a wrecked vehicle.

Now, in Part 3, we take a technical turn, examining how data is stored inside the SYNC® 3 system, where specific information resides, and what we uncovered as we dug through the filesystem layer by layer.

Because Part 3 contains a substantial amount of material, we’ve separated it into two sections:

• 3A: How and where we found Bluetooth data.
• 3B: How and where we found GPS and driving data.

To keep things clear and focused, here’s the series timeline:

---

A Note on Our Intended Audience

Our earlier blog posts were written with a broad audience in mind and intentionally kept accessible for readers without a technical background. This post, however, goes deeper. It includes command‑line examples, raw log output, and details about the automation we used to analyze the information we uncovered. As a result, it’s admittedly more technical.

In keeping with our commitment to an evidence‑based approach, the more detailed sections that follow serve as a guide for anyone interested in reproducing our results or understanding the full path we took.

Table Of Contents

• A Note on Our Intended Audience
• Table Of Contents
• What’s Inside the SYNC® 3 Filesystem?
• First, a bit of Background
• How We Located the Data
  • 1. Where we Started
  • 2. Head Unit Bluetooth Address Found
  • 3. Found Bluetooth Log File
  • 4. Found Connected Bluetooth Device MAC Addresses
  • 5. Five Bluetooth Profile Files for Five Phones
  • 6. Seaching by First \& Last Names
  • 7. Looking at the btpersist Database File
  • 8. Looking at the btpbk Database File
  • 9. Nuance - SQLite File Analysis
  • 10. Determining the Owner using Bluetooth Connection Data
• Files Of Interest - Table
• Conclusion - End of Part 3A
• Next Up
• Disclaimer

What’s Inside the SYNC® 3 Filesystem?

To get started here’s a visual map of the type of data that was revelead from the analysis:

This post will go into a deeper technical analysis of where this data was found and how we interpreted it to gain a picture of the previous owner and users.

---

First, a bit of Background

Before diving into the technical details, we felt it would be helpful to provide some foundational background information.

The SYNC® 3 infotainment system runs on QNX, and the data partitions from the memory chip image use a QNX filesystem. All the data referenced in this blog post was found on one of these data partitions.

Note: Extracting the separate QNX partitions — and identifying which partition was of interest — is not covered in this post. Stay tuned for a future write‑up on that subject.

---

What is QNX?

QNX is a commercial real-time operating system made by BlackBerry®. It’s designed for systems that must respond quickly and predictably, like cars and industrial devices.

It uses an Operating System that is very small and stable. Items like drivers and networking run separately, which means that if something crashes, it usually doesn’t bring the whole system down.

Why it’s used:

• Real-time performance: responses happen when they’re supposed to;
• Reliable: failures are isolated and easier to recover from;
• Unix-like: familiar Unix-like tools and programming interface;
• Common in safety-critical systems like automotive infotainment, driver assistance, industrial controls, medical devices, and aerospace systems.

Note: For more information, visit the QNX website.

---

How We Located the Data

This section provides an overview of the methodology we followed as we navigated the file system to locate the relevant Blueooth related data.

1. Where we Started

Once the data was extracted and made accessible on our analysis systems, we were able to explore it just like any standard file directory — similar to what you’d see in any graphical file explorer:

---

2. Head Unit Bluetooth Address Found

From the root of the extracted filesystem, one file immediately stood out:

• BEZEL_DIAGNOSTICS_LOG.txt

Diagnostic logs often contain internal system details intended for engineers or technicians, including items such as MAC addresses, device identifiers, error traces, and other hardware‑level information. Inside this file, we quickly located what appeared to be the head unit’s Bluetooth MAC address.

This was significant for two main reasons:

• Bluetooth was of particular interest because it is the primary method by which users pair their mobile devices with vehicles.
• Discovering this address gave us a highly specific search term we could use to locate related log entries elsewhere across the system.

The screenshot below shows a redacted portion of this file:

From the MAC address, we could also determine the Bluetooth chipset manufacturer. The first three bytes of a MAC address — known as the OUI (Organizationally Unique Identifier) — correspond to a specific vendor. In this case, the OUI belongs to Texas Instruments (TI), indicating that the SYNC® 3 unit uses a TI Bluetooth chipset.

Below is the matching entry from the IEEE standards website (https://standards-oui.ieee.org/):

Note: The detailed connection logs and device metadata we recovered were almost certainly generated by the SYNC® 3 software rather than the TI chipset itself. However, identifying the Texas Instruments Bluetooth chipset gives useful context as it could reveal the chip’s native capabilities, and point us toward the right technical resources if deeper, hardware‑level analysis is ever required.

---

3. Found Bluetooth Log File

Armed with the head unit’s Bluetooth MAC address, we used it as a search term to find all related occurrences across the partition.

• Using the Linux grep utility, we recursively searched all directories and files:
  • Command: $ grep -rni "cc:33:31:xx:xx:xx"

This search returned 27 files containing references to the head unit’s Bluetooth address.

A quick scan of the results revealed several log files in the ./fordlogs/BTLogs directory.

Given that the folder name appeared to reference Ford’s Bluetooth logs, we began examining the files inside it, starting with:

• ./fordlogs/BTLogs/osapi_01.log

4. Found Connected Bluetooth Device MAC Addresses

The osapi_01.log file was plain text, allowing us to open and inspect it directly. Once inside, we searched for occurrences of the head unit’s Bluetooth MAC address.

• The head unit’s address was located within the log.
• Nearby, we found references to what appeared to be four additional MAC addresses. These were listed alongside the head unit’s address, suggesting they might belong to devices that had previously connected to the system.

The screenshot below shows the relevant portion of the log (MAC addresses redacted):

These newly discovered MAC addresses gave us several additional search terms to continue our investigation deeper into the file system. Specifically, we identified the following four candidates:

No.	Potential MAC Address
1	44:4A:DB:xx:xx:xx
2	88:A4:79:xx:xx:xx
3	FC:31:5D:xx:xx:01
4	FC:31:5D:xx:xx:02

---

5. Five Bluetooth Profile Files for Five Phones

With additional MAC addresses now available as search terms, we expanded our search using the first MAC address in our list. As before, we used the Linux grep utility to recursively search the entire directory structure:

• Command: $ grep -rni "44:4A:DB:xx:xx:xx"

This search returned 32 files containing references to what appeared to be MAC addresses belonging to individual phones previously connected to the system.

A quick review of the results showed numerous log files. One in particular stood out as it contained the Bluetooth MAC address directly in its filename — which immediately signaled that it warranted closer inspection.

Navigating into that folder and listing the files with $ ls -1, revealed a total of five files that used the same naming format:

This was promising — each filename contained one of the four MAC addresses we had identified in Step 4, plus one additional MAC address. This strongly indicated that these files represented individual Bluetooth‑paired devices.

When we opened these files, the contents confirmed that these logs captured detailed profile information about previously connected phones.

Looking at the devlog_44_4a_db_xx_xx_xx.txt file, we could see:

• The phone’s Bluetooth Address: REDACTED
• The phone Manufacturer: Apple
• The phone Model: iPhone12,3 - Which translates to an iPhone 11 Pro
• The phone number: REDACTED
• The cellular provider: Telstra
• The iPhone’s software version: Version 18.5 (Build 22F76)
• The Device Friendly Name: Firstname Lastname's iPhone

Opening the remaining four files provided additional data about the other devices. Altogether, we now knew:

• BT MAC addresses for five devices that connected to the head unit.
• Four phone numbers.
• One full name.
• Two additional first names.
• Evidence suggesting device upgrades:
  • Two of the devices shared the same name and phone number (likely an older device replaced with a new one).
  • Two shared the same name but only one included a phone number (possibly an upgrade where the number wasn’t recorded or that the older device was not connected to the cellular network).

At this stage, we had our first clear connection between raw data and real individuals.

From a data‑analysis perspective, these logs provided new, highly specific identifiers — allowing us to continue searching for additional files containing personal or device-related information.

6. Seaching by First & Last Names

Continuing with our strategy of using targeted search terms, we next searched for the Device Friendly Name extracted from the devlog_44_4a_db_xx_xx_xx.txt file.

• Command: $ grep -rli "Firstname Lastname's iPhone"

This search returned 152 files containing references to the exact Device Friendly Name. Included below is a redacted view of the results (the whole list was too long to include fully):

The highlighted file btpersist was located in the same directory as our Device Log files, and therefore seemed interesting. As it did not have a file extentsion, we used the file Linux utility to see if we could determine what type of file it was:

• Command: $ file btpersist

The command indicated that the file was an SQLite 3 database file, which is extremely common on mobile platforms to store structured data. This provided us with enough information to warrant a closer look.

---

7. Looking at the btpersist Database File

Being an SQLite 3 database file, we opened it using a tool that displays the data in a graphical interface, making it easier to review and understand.

The database file contained several internal tables, and as we selected each table to view the data, we found one that contained interesting information.

Note: All SQLite databases were viewed using DB Browser for SQLite, available free at https://sqlitebrowser.org/.

Note: The screen shot above has personal information REDACTED and the names replaced with the results of the rest of our analysis. How we determined who the Male Owner and Adult Children were is covered throughout the blog series.

The table below summarises the key details:

Item	Name	Note
Filename	btpersist
Database Table	PairedDevInfo	Contained similar information associated to the three names found in the Device Log files found in Step 5

Considering we found multiple files referencing phones that connected to the head unit in this folder, we took a step back and had a look at some of the other files in the ./BT folder. A directory listing showed that there was another similarly named file (with no file extension) in the same directory that was larger in size than the btpersist database file. This made us wonder if we might have another database file to examine.

• Command: ./BT$ ls -l

As we did above, we determined what type of file that btpbk might be with:

• Command: $ file btbpk

With this we confirmed that another SQLite 3 database file existed in this directory. Next we opened the file.

---

8. Looking at the btpbk Database File

We opened the btpbk database using the same DB Browser for SQLite tool from Step 7. Inside, we found dozens of tables, as shown in the screenshots below:

While the database contained numerous tables, most were empty.

Understanding btpbk Table Contents

Opening each populated table revealed that tables appeared in numeric groups (DialCall3, DialCall4, etc.). The content broke down as follows:

Table	Contents
Combined1 –> Combined12 (inclusive)	Combined list of missed, dialed, and received calls (per phone).
DialCall1 –> DialCall12 (inclusive)	List of dialed called (per phone).
InCall1 –> InCall12 (inclusive)	List of received calls (per phone).
MissCall1 –> MissCall12 (inclusive)	List of missed calls (per phone).
PhoneBook1 –> PhoneBook12 (inclusive)	Phonebook entries (per phone).

Only the sets ending in 3 and 4 contained entries. We theorized that each of these database sets represented data from the same phone.

To validate this, we compared the number of records across the call-log tables:

• For each device index, the total number of entries in the Combined* table matched the sum of the entries from the DialCall*, InCall*, and MissCall* tables.
• We found one discrepancy in the Combined4 table (57 entries vs. a total of 56 in the three individual call tables), which was explained by a single duplicate entry.

We also performed a deeper review of the table contents (not fully detailed here), and in every instance, the records within the individual call log tables (DialCall*, InCall* and MissCall*) matched the entries in the corresponding Combined* table. This confirmed that the data corresponded to two — and only two — distinct phones.

This cross‑validation confirmed that:

• Tables ending in 3 belonged to one phone.
• Tables ending in 4 belonged to another.

Linking Each Table Group to a Specific Phone

Our next goal was to map each numeric table set (*3 and *4) to the actual phones we identified in Step 5.

The simplest and most reliable indicator came from the PhoneBook3 and PhoneBook4 tables. Each included an entry labelled My Number.

Here is what that entry looked like:

By comparing these My Number values to the subscriberNum fields found in the devlog_xx_xx_xx_xx_xx_xx.txt files we examined in Step 5, we could definitively associate each table set with a specific phone.

As further confirmation, the ordering of devices in the btpersist database (shown in Step 7) matched the numbering here (3, 4).

We could now confidently associate each group of tables with a specific device:

Phone Name
Child 1	Combined3 DialCall3 InCall3 MissCall3 Phonebook3
Child 2	Combined4 DialCall4 InCall4 MissCall4 Phonebook4

Summary of Findings for Each Phone

Below is a summary of the data recovered for each device.

Field	Value
Filename	btbpk
Association	Child 1
Number of Call Log Records	63 (includes Dialed, Received, and Missed)
Database Table	Combined3

Screenshot:

---

Field	Value
Filename	btbpk
Association	Child 1
Number of Phonebook entries	48 (includes own phone number)
Database Table	PhoneBook3

Screenshot:

---

Field	Value
Filename	btbpk
Association	Child 2
Number of Call Log Records	56 (includes Dialed, Received, and Missed) Note that there was a total of 57 entries, but one was found to be a duplicate entry, resulting in an actual total of 56.
Database Table	Combined4

Screenshot:

---

Field	Value
Filename	btbpk
Association	Child 2
Number of Phonebook entries	106 (includes own phone number)
Database Table	PhoneBook4

Screenshot:

---

This completed our analysis of the btpbk database and solidified the relationships between the head unit’s internal databases, the device logs, and the individuals whose phones had been paired with the system.

With the success in analyzing SQLite databases, we returned to the search results from Step 6 (where the device name “Firstname Lastname’s iPhone” appeared in several files).

We examine these findings in the next step.

---

9. Nuance - SQLite File Analysis

Let’s recall the search results from Step 6. Below are some of the files that contained hits to “Firstname Lastname’s iPhone”:

Several files with .sqlite and .sqlite3 extensions appeared. We began with device.sqlite in the ./Nuance/NuanceVCAdb directory.

What is Nuance?

We investigated what Nuance might refer to in the context of Ford or their infotainment units. Search results returned references to “Nuance Communications”, which have provided speech‑recognition and text‑to‑speech services used in Ford SYNC® 3 infotainment systems.

Relevant references include:

• Ford’s Media Centre: Describes how SYNC’s speech‑recognition system works and is continually improved through language models and decoder software; does not mention Nuance.
• SAE International (Formerly “Society of Automotive Engineers”): Confirms that SYNC 3’s voice‑recognition was upgraded by Nuance, enabling more natural, conversational commands
• Nuance Communication’s official website.

Nuance Folder Contents

Nagivating to the ./Nuance/NuanceVCAdb folder , we found several SQLite databases saved to the same folder as the device.sqlite we found in our search hits. Here we see the folder’s contents listed with the ls -1 command:

Nuance - device.sqlite

Opening device.sqlite revealed a t_device table containing device entries that included references to “Device Friendly Names”. Three of these matched names seen in earlier steps, while one new entry — a female name’s iPhone — appeared, later identified as belonging to the main owner’s partner.

Note: We demonstrate how we associated the family relationships later in our blog series.

We also noted the following key associations:

• ID 1001 is associated with Child 2’s device.
• ID 1004 is associated with Child 1’s device.

In the same directory, we noticed two files named Phone1001.sqlite and Phone1004.sqlite. The filenames suggested that they might store data for the corresponding devices found in the t_device table.

Using the same process as with all other SQLite files we examined the Phone1001.sqlite and Phone1004.sqlite files next.

Phone1001.sqlite

The t_phone_number table contained 122 phonebook entries associated with Child 2’s iPhone.

Field	Value
Filename	Phone1001.sqlite
Association	Child 2
Number of Phonebook entries	122 (includes own phone number)
Database Table	t_phone_number

---

Phone1004.sqlite

The t_phone_number table contained 57 entries associated with Child 1’s iPhone.

Field	Value
Filename	Phone1004.sqlite
Association	Child 1
Number of Phonebook entries	57 (includes own phone number)
Database Table	t_phone_number

---

As with the btpbk database in Step 8, the presence of each device’s own phone number within these phonebooks confirmed the associations.

Note: We did not analyze why the number of entries differed between these databases and the btpbk phonebooks. It is likely that different SYNC® 3 subsystems (e.g., hands‑free calling, voice recognition, dial pad) maintain separate databases that update independently based on feature usage.

---

10. Determining the Owner using Bluetooth Connection Data

In Step 6, our search for references to “Firstname Lastname’s iPhone” returned 152 files. As we continued to examine the results, two more files in the /fordlogs/BTLogs directory stood out as potential logs related to the system’s Bluetooth service as the filenames included references to BT and Service:

• NET_BT_Service.log
• NET_BT_Service.log.1

Both files were plain‑text log files that could be opened and read easily:

As we examined them, we observed:

• Timestamps down to millisecond precision.
• The keyword CONNECTION.
• Bluetooth‑profile connection events, including:
  • HFP (Hands-Free Profile)
  • A2DP (Advanced Audio Distribution Profile)
  • AVRCP (Audio/Video Remote Control Profile)
  • MAP (Message Access Profile)
• Device names already seen in earlier steps.

Note: The Bluetooth Special Interest Group (SIG) provides specifications referencing these connection event types here: https://www.bluetooth.com/specifications/specs/.

These files appeared to log every instance when Bluetooth‑paired devices connected to the SYNC® 3 system.

Timestamps

By reviewing the timestamp headers on each log entry, we confirmed:

• The two files form a continuous timeline.
• NET_BT_Service.log.1 is the older file:
  • Begins: 12 April 2025
  • Ends: 15 July 2025
• NET_BT_Service.log is the newer .
  • Continued from: 15 July 2025
  • Ends: early August 2025, matching the approximate accident timeframe (discussed later)

Note: We know from our analysis throughout this blog series that the vehicle was in an accident in August 2025. While other logs and GPS data confirmed the vehicle was powered on after the accident, no further Bluetooth connections occurred in these logs. This supports the theory that none of the known devices were present near the vehicle after the crash.

Determining the Main User / Owner

To identify the most likely primary driver, we examined which device connected to the head unit most frequently.

Our assumption: the most frequently connected device represents the primary user.

At this point we had:

• Full timestamped Bluetooth connection history.
• Approximately 3.5 months of log data.

This allowed us to quantify which user’s device connected the most.

Bluetooth Connection Events

While scrolling through the logs, we noticed that HFP (Hands‑Free Profile) events were typically the earliest — or among the earliest — entries for each connection sequence.

To simplify the analysis, we focused exclusively on HFP events.

We provide a random sample of the log file’s data with the HFP connections highlighted below:

We copied the two files to a working directory and ran the following grep Linux command:

• grep -h "CONNECTION:HFP_CONNECTION" ./NET_BT_Service.log.1 ./NET_BT_Service.log > NET-BT-Service_HFP-Connection-Logs.log

The output file now contained only HFP events:

Next, we counted the number of HFP connection events per device using:

• grep -oP '<SD2>\K[^<]+' NET-BT-Service_HFP-Connection-Logs.log | sort | uniq -c | sort -rn

Results: Who Was the Main User?

By analysing the extracted events over the ~3.5‑month period, we found:

• Firstname Lastname’s Device: 280 connections
• Child 1’s Device: 41 connections
• Child 2’s Device: 33 connections

The connection frequency overwhelmingly pointed to the Main User’s iPhone as the primary driver of the vehicle.

---

Additional Insights (Not Performed, But Possible)

Although we focused only on connection counts, these logs could also have supported further analysis, such as:

• Identifying the vehicle’s usage patterns by examining:
  • The days of the week on which the vehicle was typically used.
  • What times of day the vehicle was used.
• Matching specific users to specific trips by correlating Bluetooth connection timestamps with GPS log data.

These steps were not necessary for our core objective but remain possible extensions.

---

Files Of Interest - Table

The files listed below represent the data sources we examined throughout our analysis of the vehicle’s Bluetooth data. They are presented in the order in which they were discovered.

Filename	Directory Path	File Type	Information Contained
BEZEL_DIAGNOSTICS_LOG.txt	./	Text File	SYNC® 3 System MAC Address
osapi_01.log*	./fordlogs/BTLogs	Log / Text File	Connected Device BT MAC Addresses
devlog_xx_xx_xx_xx_xx_xx.txt	./BT	SQLite 3 Database	Bluetooth Pairing and Profile Information for Indivdual Phones
btpersist	./BT	SQLite 3 Database	Contains information on connected phones such as: - Device Friendly Name - Phone Number - BT MAC Access - Make, Model, SW Version - Device order in btpbk - etc.
btpbk	./BT	SQLite 3 Database	Phone Data: - Call Logs - Phonebook Entries
device.sqlite	./Nuance/NuanceVCAdb	SQLite 3 Database	Contains: - Connected Device Friendly Names - ID Associations of Connected devices
PhoneXXXX.sqlite	./Nuance/NuanceVCAdb	SQLite 3 Database	- XXXX refers to the ID found in the device.sqlite file. - Contains phonebook entries for that device
NET_BT_Service.log	./fordlogs/BTLogs	Log / Text File	Bluetooth Connection Events - Newer File
NET_BT_Service.log.1	./fordlogs/BTLogs	Log / Text File	Bluetooth Connection Events - Older File

---

Conclusion - End of Part 3A

Our examination of the SYNC® 3 filesystem has revealed just how much Bluetooth‑related data modern vehicles quietly accumulate. From device identifiers and phonebook entries to call logs and detailed connection histories, the Ranger’s head unit stored enough information to reconstruct not only which devices paired with the system, but who they likely belonged to and how often each person used the vehicle.

Across multiple independent sources — raw log files, device‑specific SQLite databases, Nuance voice‑recognition data, and system‑level pairing records — we consistently observed a rich and overlapping picture of the vehicle’s digital relationships. This cross‑correlation enabled us to clearly identify the primary driver, differentiate between secondary users, and confirm which individuals were associated with each dataset.

Part 3A demonstrates how an evidence‑based, methodical approach can surface deeply personal artifacts from what many would assume is simply an “infotainment system.” In reality, these systems behave much more like forensic recorders, logging data that persists long after the vehicle changes hands.

---

Next Up

In Part 3B, we turn to our next categories of stored data: GPS, WiFi and driving information.

We’ll examine where location trails, trip logs, vehicle‑state data, and movement history live within the SYNC® 3 filesystem — and how these artifacts can reveal detailed patterns about past journeys, routes, behaviours, and even their home, work, and other frequently visited locations and how it was linked to WiFi networks recorded by the SYNC® 3 system.

This next section reveals just how detailed and long‑lived the Ranger’s location data is, and how easily it can be tied back to real individuals and their daily routines.

---

Disclaimer

This analysis is based on our professional experience and represents our best interpretation of the available log entries. It should not be considered definitive evidence for legal proceedings without independent verification of the data and validation of any assumptions made during the analysis.

We have made every attempt to obfuscate any information that could reveal any information that could help identify the previous owner(s) or their devices.

In the interest of brevity, the screenshots included do not reflect all the files or folders that exist on the head unit’s filesystem. We have made every attempt to include the locations and files that we used in our analysis.

---