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

Behind the Dashboard: Part 3B
GPS, WiFi & Driving Data

Welcome to the fourth 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 our approach to this privacy demonstration. In Part 2, we dug into the data extracted from the Ranger’s SYNC® 3 head unit, the one salvaged from a wrecked vehicle.

From there, Part 3 takes a deeper technical turn, examining how data is stored inside the SYNC® 3 system, where specific information resides, and what we uncovered as we worked through the filesystem layer by layer.

Because Part 3 contains a substantial amount of material, we divided it into two standalone sections:

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

You’re now reading Part 3B, where we explore the GPS traces, location history, WiFi and driving related records that SYNC® 3 retains: what’s captured, where it’s stored, and how we analysed it.

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

A Note on Our Intended Audience

Similar to Part 3A, this post provides technical details such as command‑line examples, raw log output, and the methodology we used to uncover and analyse the information.

Because the GPS, WiFi and Driving Data files examined in this post are highly varied and contain a substantial volume of information, documenting every step in full isn’t practical. Instead, we’ve aimed to include enough detail to clearly convey our reasoning, workflow, and the overall approach we used to reach our results.

If you’d like to discuss any part of this analysis (or if you’re interested in a deeper, step‑by‑step breakdown in a dedicated follow‑up post) please feel free to contact us. We’d love to hear from you!

Use of AI to assist with analysis of logs

Although we have years of experience in extracting and analysing data from vehicles to assist law enforcement with their investigations, we deliberately incorporated the use of a popular AI tool (Claude - Anthropic’s AI assistant) to highlight that, even in the hands of relative novices, these tools can assist in processing and analysing the data extracted from a vehicle head unit.

This is important as it shows not only how much data is present and accessible, but also because it raises questions about how OEMs and vehicle manufacturers are making use of this data.

Files Of Interest - Table

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

Bluetooth Related Files

GPS, WiFi and driving data Related Files

Table Of Contents

• A Note on Our Intended Audience
• Use of AI to assist with analysis of logs
• Files Of Interest - Table
• Table Of Contents
• What’s Inside the SYNC® 3 Filesystem?
• Locating Relevant Data
  • 1. Where we Started - GPS Data
  • 2. Determining Home and Work Locations
  • 3. Extracted Detailed Trip Logs (Tracks)
  • 4. Analysing WiFi Data
  • 5. Saved WiFi Networks Names and Passwords
  • 6. Other Driving Data - Crash Event
  • 7. Where Driving Sessions and Vehicle State Data Lives (ccl)
• Conclusion - End of Part 3B
• Fortify Labs Github Repository
• Verfication of AI Script Results
• Next Up
• Disclaimer

What’s Inside the SYNC® 3 Filesystem?

To begin, here’s a visual summary of the type of data we revealed during our analysis:

Locating Relevant Data

This section outlines our methodology and analysis results.

1. Where we Started - GPS Data

We’ll begin with the GPS related artefacts and walk through how we found and analysed them.

Approaches to find GPS related files

In Part 3A, we demonstrated how the Linux grep utility helped us locate Bluetooth‑related artefacts across the extracted filesystem. We applied the same approach here for GPS data.

There are several ways to search for GPS‑relevant files. Below are examples of the commands we used, starting with broad searches and then narrowing the results:

• Search for common GPS‑related keywords across the filesystem:

  • Command: grep -rli 'gps\|latitude\|longitude\|coordinates'
  • Keyword hits in: 52 Files
  • Screenshot:

• Search specifically for gps:

  • Command: grep -rli "gps" .
  • Keyword hits in: 45 Files
  • Screenshot:

• Search for decimal‑degree coordinate patterns (e.g., -34.123456, 138.654321):

  • Command: grep -rl -E '\-?[0-9]{1,3}\.[0-9]{5,}.*\-?[0-9]{1,3}\.[0-9]{5,}' .
  • Keyword hits in: 29 Files
  • Screenshot:

GPS Files Chosen to Review

From these results, several files stood out:

• The pas_debug.log* files appeared in large sequential sets, suggesting they might contain a significant amount of information. Since their location (i.e. in the ./fordlogs/ directory) was the same as previously found artefacts relating to Bluetooth devices, we earmarked these for further investigation.
• The unifiedsearch.log was located in the ./NAV directory, indicating that it might contain navigation‑related data.

We began with unifiedsearch.log simply because it was a single file and therefore might be quicker to assess before moving on to the larger datasets.

2. Determining Home and Work Locations

Characterizing “unifiedsearch.log”

unifiedsearch.log was large in size (over 110 MB) suggesting it might contain logs covering extensive activity. When opened, we noticed that the log contained a repeating pattern where each sequence:

• Started with the text System:QNX.
• Contained timestamps (down to the second precision).
• Conained lines that included GPS coordinates along with keywords such as current_location and category.
• A line containing rgc=&current_location=-xx.xxxxxx,xxx.xxxxxx&lang=en-GB&Priority=17.

Below is a screen shot of one such full entry.

RGC here was taken to mean Reverse Geocoding, which is the process of converting raw GPS coordinates into human readable locations, such as street addresses or nearby points of interest (e.g., fuel stations, restaurants, parking areas).

Navigation systems rely on this information to help drivers quickly find relevant nearby services. For example, when your infotainment system detects low fuel, reverse geocoding allows it to identify nearby service stations based on your current coordinates.

For more details, see the Fundamentals of reverse geocoding post from Esri.

Determining File Timeframe

The timestamps appeared in sequential order, therefore determining the timeframe covered by the file simply required checking the first entry and scrolling to the end. From this, we found:

• First entry: 3 February 2022
• Last entry: 10 November 2025

Assuming that each log entry started with the keyword System:QNX, we could estimate the total number of entries by counting it’s occurrences. To do this, we ran:

• Command: grep -c "System:QNX" unifiedsearch.log

Based on that output, we can estimate that the log file contained a total of 8,886 entries spanning 3 years and 9 months.

As this Ranger was a 2022 Model Year, the file appears to represent a long term record capturing nearly every system boot sequence, providing almost four years of history showing details on when and where the Ranger was started.

Note: This analysis method may not reflect the actual number of full boot cycles, but it does provide a general characteraization of how many log entries the unifiedsearch.log file contains. Further analysis of this file would be required if an accurate determination of boot sequences was required.

Analysing “unifiedsearch.log”

Based on this finding, this appeared to be a very powerful file. Through further analysis we could reveal a great deal about the previous owner(s) & users, including home and work locations.

By analyzing this data over a period of time, we theorised that the most frequent startup locations would likely correspond to the vehicle owner’s home and work addresses.

To achieve this, we developed custom scripts to extract only the relevant data (GPS coordinates and timestamps). Because the log contained entries dating back to early 2022, we restricted our analysis to data from 2025. This was to avoid skewing results (in case the vehicle was purchased second-hand or the owner had moved or changed jobs since the vehicle was new).

The steps required to make use of this data were more complex than the earlier types of analysis we performed, where we could simply count entries or search for keywords and patterns. This time, we needed to:

• Process a larger volume of raw data,
• Identify and extract only the relevant parts, and
• Analyse those data points in a way that revealed meaningful patterns.

Adding to the challenge, analysing GPS points can naturally produce skewed or inconsistent results because:

• The vehicle may be parked a few metres differently each time, even though it’s still “at home” or “at work”,
• Consumer grade GPS is only accurate to roughly 5–15 metres, so slight shifts are completely normal, and
• Environmental factors such as trees or buildings can all cause small variations in the recorded location.

Creating “unifiedsearch.log” Analysis Script

We used the following prompt in Claude to create our Python script

Write a Python script that:
- parses a log file 
  - where each entry starts with "System:QNX"
  - contains timestamps in the following "YYYY-MM-DD HH:MM:SS"
  - contains Reverse Geocoding as the GPS position such as "rgc=&current_location=-xx.xxxxxx,xxx.xxxxxx&lang=en-GB&Priority=17"
- Considers only entries from 2025 and
  - Summarizes the top 3 locations (based on a radius of 100m)
  - For locations within the radius of 100m, calculate the centre point
- Provide a summary text file that looks like the attached output format
- Save all points (timestamp and original GPS position) from 2025 to an output file called "AI-analysis_unifiedsearch-log.log"
- An example of one log file entry is provided below

Note: Pasted the following in the prompt box:
- an example of the desired output format
- an example log file entry

Note: The same prompt can produce different results for different people as AI tools use conversation histories and settings to structure their answers.

Our AI assistant completed the task and performed the following:

• Created a Python script to our specifications.
• Created a README file that explains what the script does and how.
• Generated test data automatically and ran the created script against it.
• Provided test data results for the:
  • Summary text file.
  • Output file with extracted timestamps and GPS positions.

We ran our generated script against the unifiedsearch.log file and the script successfully generated the output files as instructed. Screenshots of these files can be seen below:

Example of the AI-analysis_unifiedsearch-log.log output File:

Example of the GPS_Location_Analysis_Report_2025.txt output File:

Note: GPS positions have been redacted or randomized in the screenshots above.

Observation: The last recorded visits to all three top locations occurred on the accident date in August 2025, but startup entries continued until 10 November 2025.

From those output files we could click on the generated Google Maps links and see:

• Location #1: This cluster corresponded to a point immediately outside a business.

Note: This was confirmed through publicly visible Facebook posts that this business was the correct workplace of the main user. The business name also appeared in one of the synced phonebooks.

• Location #2: This cluster centred directly on the driveway of a residential property. As it accounted for over 28% of all start events in 2025, it is very likely the owner’s home.

Note: This was confirmed through an Open Source search including the driveway address as well as the owner’s surname which uncovered a publicly listed record from a local council in 2017 referring to a shed and carport development application. This document included the land Lot number, street name, and last name of our family, supporting this conclusion.

• Location #3: While visited less frequently, this point appeared consistently enough to indicate a regular destination (potentially a secondary workplace, school, family member or friend’s residence, or recurring errand location).

Visualizing the Data

From here we used Claude to generate an additional script that enabled us to visualize the GPS point clusters of the three most common locations found in 2025. The script was instructed to:

• Ingest all GPS points saved in the previously generated output file (GPS_Location_Analysis_Report_2025.txt),
• Use the same logic used in the earlier script (parse_unifiedsearch_log.py) to calculate the three most common locations,
• Identify and group all GPS points within a 100m radius of the three most common locations, and
• Generate a KML file that can be ingested into a mapping program such as Google Maps so we could visualize the data.

We used the following AI prompt:

Write a Python script that:

- Takes in all the GPS Points from GPS_Location_Analysis_Report_2025.txt
- Use the same logic to calculate the three most common locations from a previous Python script
- Verify that the same number of points found matches the number of points represented in the output file generated from ```parse_unifiedsearch_log.py```, "```AI-analysis_unifiedsearch-log.log```".
- Generate an output KML file of all the points that correspond to those three most common locations that can be ingested in Google Maps.
      
Note: Copy/Pasted the following files into the Claude AI prompt box:
- GPS_Location_Analysis_Report_2025.txt
- AI-analysis_unifiedsearch-log.log
- parse_unifiedsearch_log.py

Note: A KML file stores geographic data (such as GPS points and paths) for display in mapping tools.

When the resulting script was run, it generated a KML file representing the cluster of points (or heat map) that could be imported into Google Maps as well as the following output:

This heat map provided an overview of all points within the top three clusters, while the summary output above provided the GPS position at the center of each cluster.

For privacy reasons, we are not publishing the actual heat map. Instead, we created an example using randomized coordinates across Sydney. While the locations are fictional, the point density reflects the real data:

Other Possible Analysis

Alhtough not performed in our analysis, we could have done further anlaysis to determine things such as:

• Categorizing vehicle use by time of day or day of week.
• Correlating GPS data with connected phone logs to determine which drivers were associated with specific locations.
• Detecting other frequent locations during different time periods (e.g., early entries showed points near a Ford dealership, likely where the vehicle was originally sold).
• Investigating potential ownership changes by comparing location patterns over time.

3. Extracted Detailed Trip Logs (Tracks)

Recalling our results from Step 1, we had a closer look at the other files we identified as interesting.

Characterizing “pas_debug.log*” Files

We can see from the partial fordlogs directory listing below that there were a total of 26 pas_debug.log* files, each distinguished only by the final number in the filename.

Each one of the files was very similar in size (approx. 10 MB). Considering this and the similar names, this appeared to be a series of rotating log files.

Looking inside the files and scrolling through the entries we noticed that each line contained:

• A timestamp (down to the second precision).
• A reference to what appeared to be related to specific services or functions, for example:
  • BT_Service,
  • NET_BT_Service,
  • NAV_FRAMEWORK_IF,
  • WIFI_MID,
  • WiFiHotspotMessageHandler,
  • SendGPSCanData,
  • etc.
• A large variety of log information.

Therefore, each pas_debug.log* file appeared to contain extensive information about SYNC® 3 system operations, including:

• Bluetooth services logs.
• Navigation/GPS data.
• Wi-Fi access point details.
• CAN bus communications.
• And more.

Below is an example snippet from one of these logs, with a GPS entry highlighted:

Zooming in on the GPS line of interest:

We observed two types of GPS output lines:

• DR (Dead Reckoning): Estimates position based on a previous known location and movement data.
• MM (Map Matching): Adjusts raw GPS or DR positions to the most likely location on a digital road map.

For more details, see Automotive Dead Reckoning - Ublox and A Survey on Map-Matching Algorithms - Paper - [P. Chao, Y. Xu, W. Hua, and X. Zhou, “A Survey on Map‑Matching Algorithms,” arXiv:1910.13635, 2019. [Online]. Available: https://arxiv.org/abs/1910.13635].

Here again, a script was created to extract these positions and generate separate KML files for DR and MM data.

After we performed a comparison of the two, MM positions proved more accurate, as they aligned better with actual road layouts in mapping platforms like Google Maps and Google Earth.

We used the following AI Prompt:

Develop a Python script that:
- Searches and assesses all files in a directory that begins with "pas_debug.log*"
- Ensure that a total of 26 files can be seen and opened.
- Look for lines that match the pattern pasted below

11/06/2025 18:04:34.551/248/23/NAV_FRAMEWORK_IF/SendGPSCanData/2187/=[DR Output: Lon.d:xxx  
Lon.m:xx.000000 Lon.s:0.xxxxxx Lat.d:-32  lat.m:xx.000000 lat.s:0.xxxxxx alt.Ft:xxx Hd:xx.xxxxxx], 
[signal_type:1 SatInView:17], [MM Output: Lon:xxxxxxxx.xxxxxx Lat:-xxxxxxx.xxxxxx 
Alt:xxx.000000 Hd:xx.000000]

- Extract the timestamp and GPS position (MM position only, not the DR position)
- Save the timestamp and GPS position to an output file called extracted_detailed_GPS_pas-debug.log

We copied the 26 pas_debug.log* files to a folder and ran the extracted script and observed the following output.

The extracted GPS information could now be examined in the script output file, extracted_detailed_GPS_pas-debug.log

Note: The output format of the file above is accurate, however, the timestamps and GPS positions randomized.

When scrolling through this data, we could see that GPS positions appeared to be taken every second while the Ranger was running. We theorized that if we could look for gaps in the timestamps of 120 seconds (2 mins), and count the next set of GPS points as a seperate trip, this would provide a reasonable estimation that this would represent different trips.

Using Claude we developed another script that would process this data.

Develop a Python script that:
- Opens and evaluates the data in all pas_debug.log.* files 
- Look for lines that match the pattern pasted below

11/06/2025 18:04:34.551/248/23/NAV_FRAMEWORK_IF/SendGPSCanData/2187/=[DR Output: Lon.d:xxx  
Lon.m:xx.000000 Lon.s:0.xxxxxx Lat.d:-32  lat.m:xx.000000 lat.s:0.xxxxxx alt.Ft:xxx Hd:xx.xxxxxx], 
[signal_type:1 SatInView:17], [MM Output: Lon:xxxxxxxx.xxxxxx Lat:-xxxxxxx.xxxxxx 
Alt:xxx.000000 Hd:xx.000000]

- Extract the timestamp and GPS position (MM position only, not the DR position)
- Analyses the timestamp information and seperates tracks if there is a difference of 
120 seconds between timestamps
- Exports each track in a different KML file named "output_YYYYMMDD-HHMMSS.kml into 
a subfolder called "gps-tracks_pas-debug".

Obtaining GPS Track Results

After running the generated script we received the following output:

From this script, we were able to obtain:

• 66 individual trip tracks.
• 44,709 GPS points.
• Information from a date range of 27 July 2025 to 10 November 2025.

The screenshot below demonstrates how a subset of the exported GPS points can be visualised in Google Maps/Google Earth to reconstruct the vehicle’s path.

Note: All geographic specifics have been deliberately obfuscated. Start and end points have been removed to avoid revealing any information about the previous owners or their locations.

Results of GPS Track Analysis

Using these logs, we were able to determine the date, time, and precise location of the accident that occurred in August of 2025.

After the accident, additional GPS data continued to appear, but with minimal movement. This would be consistent with the vehicle being powered on at repair facilities, tow yards, and eventually the wrecking yard.

As you can see from the track screenshot above, it provides very detailed information about the route taken and gave us a complete picture of the Ranger’s movements. These tracks demonstrate just how much detail modern vehicles record during everyday use.

Other Possible Analysis

While we did not analyze further, deeper examination could reveal:

• Common destinations and stop points.
• Travel patterns over time.
• Correlation with timestamps to determine routines.

Next, we’ll shift focus from GPS tracks to other types of data stored on the head unit to see what else we can uncover about our owner and the locations the vehicle travelled.

4. Analysing WiFi Data

From the work we did earlier with the pas_debug.log* file characterization, we noticed that there was also references to WiFi (as referenced in Step 3).

Analysis of WiFi Data

Continuing our searches through the pas_debug.log* files, we searched for the keyword wifi to identify potentially relevant log entries. By focusing on the lines that contained this keyword, and manually examining surrounding entries, we began to form an idea of the system’s behaviour with respect to WiFi.

We noticed several items as we scrolled through the data:

Scan Initiation

The text below was seen at the start of the WiFi scans.

11/06/2025 17:04:32.386  ScanAccessPoints: SCAN: command_SCAN called - try no 1, scan response = OK
11/06/2025 17:04:32.386  ScanAccessPoints: SCAN: SCAN is done. Querying results
11/06/2025 17:04:32.386  ScanAccessPoints: SCAN: scanCompletEvent wait time = 10

Scan Completion

The following log entries were seen as part of the WiFi scan cycle.

11/06/2025 17:04:35.597  WifiServiceNetworkScanResulthandle: SCAN: scan comeplete event received from wpa_supplicant!!
11/06/2025 17:04:36.395  ScanAccessPoints: SCAN: scanCompletEvent = TRUE
11/06/2025 17:04:36.498  SetScanBuffer: File /tmp/wifi_databkp.txt Opened successfully!!!. Writing data to file!

Note: We attempted to find the /tmp/wifi_databkp.txt file but it was not present in our memory image. As this file was located in the /tmp directory, it is plausible that this file was routinely deleted or saved in a directory that does not persist across reboots.

Access Points Detected

Below are specific log entries that reference the WiFi Access Points seen by the system.

Note: The BSSID (WiFi router’s MAC address) and SSID (WiFi network name) have been redacted for privacy.

11/06/2025 17:04:36.502  GetBssid: Extracted BSSID = 04:42:1a:xx:xx:xx
11/06/2025 17:04:36.502  populate_ap_info: SSID: REDACTED_SSID ; Signal Strength: 2

11/06/2025 17:04:36.502  GetBssid: Extracted BSSID = 36:60:f9:xx:xx:xx
11/06/2025 17:04:36.502  populate_ap_info: SSID: REDACTED_SSID ; Signal Strength: 2

Tying WiFi APs to Location

To associate the detected WiFi networks with specific locations, we examined the log entries immediately before and after each WiFi network detection cycle described above. We reasoned that if the system recorded it’s GPS locations within a few seconds of detecting the WiFi access points, we could reliably infer where the vehicle was when it detected the WiFi Networks.

This approach would allow us to narrow down which Wi‑Fi networks or devices were physically located near the previously identified Home and Work locations.

By searching for the keyword gps in the log file, we found the same type of log message we saw in Step 3 (seen below). We also saw that the GPS position was recorded less a second from when the WiFi scan took place. This strongly suggested that the detected WiFi neworks could be tied to specific locations.

11/06/2025 17:04:36.912/2702/23/NAV_FRAMEWORK_IF/SendGPSCanData/2187/=[DR Output: Lon.d:xxx  Lon.m:xx.xxxxxx Lon.s:x.xxxxxx Lat.d:-xx  lat.m:xx.xxxxxx lat.s:x.xxxxxx alt.Ft:xx Hd:xxx.xxxxxx], [signal_type:2 SatInView:20], [MM Output: Lon:xxxxxxxx.xxxxxx Lat:-xxxxxxx.xxxxxx Alt:xx.xxxxxx Hd:xxx.xxxxxx]

Script to Find WiFi at Work and Home

Since we knew the GPS coordinates of the Home and Work locations, we now had enough knowledge of what to look for within the pas_Debug.log* files to generate a scipt that would search the files and tie specific WiFi Networks to our locations of interest.

Develop a Python script that:
- Takes in GPS Coordinates from the user in the following format [xxx.xxxxxx, xxx.xxxxxx] (i.e. lat and long coordinates)
- Opens and evaluates the data in all pas_debug.log.* files located in the current directory
- Look for lines that match the patterns pasted below

11/06/2025 17:04:36.502  GetBssid: Extracted BSSID = xx:xx:xx:xx:xx:xx
11/06/2025 17:04:36.502  populate_ap_info: SSID: REDACTED_SSID ; Signal Strength: 2

- Extract the timestamp, BSSID, and SSID.
- Search the log file entries up to 2 seconds before and 2 seconds after the patterns containing "GetBssid: Extracted BSSID"
- Search for lines that match the following pattern that are within that 4 second window of the "GetBssid: Extracted BSSID" line:

11/06/2025 17:04:36.912/2702/23/NAV_FRAMEWORK_IF/SendGPSCanData/2187/=[DR Output: Lon.d:xxx  Lon.m:xx.xxxxxx Lon.s:x.xxxxxx Lat.d:-xx  lat.m:xx.xxxxxx lat.s:x.xxxxxx alt.Ft:xx Hd:xxx.xxxxxx], [signal_type:2 SatInView:20], [MM Output: Lon:xxxxxxxx.xxxxxx Lat:-xxxxxxx.xxxxxx Alt:xx.xxxxxx Hd:xxx.xxxxxx]

- Extract the GPS position (MM position only, not the DR position)
- If the GPS position is within 50 meters of the user entered GPS position, save the Timestamp, GPS position, BSSID, SSID, WiFi signal strength, distance between user provided and logged GPS position, to an output file of the user's choosing.
- In the summary output include:
  - Number of pas_debug.log* files found and analyzed
  - Total number of unique WiFi Networks found
  - Total number of WiFi Networks found within 50 meters of the user entered position
- The python script should be called as follows, "python3 match_wifi_to_GPS_location.py -g [xxx.xxxxxx, xxx.xxxxxx] -o outputfile.log

Finding WiFi at Work

After running the generated script we obtained the following output:

And if we examine the output file of this script we see results that include:

With those results we could now begin to make an exucated guess on which networks might belong to the work business and can also determine that there are likely WiFi based security cameras (i.e. ARLO security cameras) in the vicinity.

Finding WiFi at Home

As we did with the Work location, we re-ran the script with the Home’s GPS coordinates and obtained results that included the following:

While confirming the exact home WiFi network would require further analysis or on-site verification, our testing showed that if the Ranger had connected to any of these networks, the infotainment system would store the SSID and password in plain text. We’ll cover that in the next section.

5. Saved WiFi Networks Names and Passwords

Although we found no evidence that the Ranger’s SYNC® 3 system had previously connected to WiFi networks, we conducted a test to see what data would be stored if it had.

To do this, we booted the Ranger’s head unit and connected it to two separate WiFi networks requiring passwords. After confirming successful connections, we re-imaged the device’s memory and searched for files containing the network names used in the test.

We successfully located:

• Both WiFi network names.
• Passwords stored in plain text.
• Security methods used by the networks.
• The BSSID (MAC addresses) of the WiFi routers.

The information was found in:

• Folder: /storage/NPS/UserData/AllUserAppData/__ImmNotfn
• Filename: wifiRemeberedAPList_MY17WIFI_MID

Opening the file reveals raw contents:

Extracting the text provides a clearer view of the stored details:

6. Other Driving Data - Crash Event

Moving on from WiFi data, we next looked if the logs contained any other driving related data. Knowing that the vehicle had been in an accident in early August 2025, we return to using grep to try and find relevant data.

We started by casting a wide net, searching for the word “crash”. This resulted in hits across 53 files. As we reviewed the results we saw references to the pas_debug.log* files and as we already knew these files contained a great deal of information, we focused our attention on them.

As we knew the timestamp pattern in these files and knew the exact date and approximate time of the crash (from Step 3), we honed the search to look for the word “crash” that was on the same line as the date and starting hour of where we saw the crash.

• Command used:

grep -i "crash" pas_debug.log* | grep "08/xx/2025 xx"

We now had 153 lines to review. As we reviewed these lines we continued to try and narrow our search results to try and find a unique line that might indicate that the system detected a crash. Our next search included the word emergency:

• Command used:

grep -i "emergency" pas_debug.log* | grep "08/01/2025 17" | grep -i "crash"

This produced results of what we were looking for:

If we focus on the the second line in the results above, we can see that the EmergencyService logged Emergency crash event received in the pas_debug.log.5 file.

To determine if this was actually the crash event we ran a grep search across the file system to look speficially for Emergency crash event received. Only a single instance of this message was found and as such could therefore be confident that this was the actual crash event that was detected by the vehicle.

Emergency Service Receives Crash Event

Extracting this log event, we see From the about we could now see the Emergency Service module logging the crash event:

08/xx/2025 17:xx:09.931/186/23/EmergencyService/OnRCMStateHandler/11347/=Emergency crash event received. HFP status:1, HMI status:1, crash status:0

Location of the Crash

We knew from previous work that the system also logged it’s position every second while travelling. Using this, we searched for the same GPS position messages we found previously and found one that logged the vehicle’s position within a half second of the crash event detection.

08/xx/2025 17:xx:10.337/1407/23/NAV_FRAMEWORK_IF/SendGPSCanData/2187/=[DR Output: Lon.d:xxx  Lon.m:xx.xxxxxx Lon.s:xxx.xxxxxx Lat.d:-xxx  lat.m:xx.xxxxxx lat.s:xx.xxxxxx alt.Ft:xxx Hd:xxx.xxxxxx], [signal_type:2 SatInView:22], [MM Output: Lon:xxxxxxxxxx.xxxxxx Lat:-xxxxxxxxxx.xxxxxx Alt:xxx.xxxxxx Hd:xxx.xxxxxx]

Based on this we were now confident on being able to associate the crash event to a specific time and place.

7. Where Driving Sessions and Vehicle State Data Lives (ccl)

As we now had evidence that the vehicle logged events related to Emergency events, we performed an additional search to see if we could locate data realted to vehicle telematics such as speed, gear changes, door opening/closing, lock related functions, etc.

We started with the following keywords:

Gear
Transmission
Seatbelt
Fuel
Camera
Speed
Ignition

Based on our search results for gear we had files to examine further:

  $ grep -ril "Gear"
  ccl/00000.zip.(txt)
  ccl/00001.zip.(txt)
  ccl/00002.dat
  ccl/stringed.txt
  fordlogs/pas_debug.log
  ...REDACTED for Brevity...
  logs/9057.ns_perf.log
  logs/sys_slog_info
  slogs/9057.slog
  storage/sdl/policy

The first two files found ccl/00000.zip.(txt) and ccl/00001.zip.(txt) were text files that could be opened and examined and contained raw log data resembling:

As you can see, this raw data is difficult to interpret. To make it more readable, we converted it into a “pretty” JSON structured format using a Python script we created. This allowed us to identify key insights, including:

• Timestamps showing events from 6 - 10 November 2025.
• A URL that appears to be used by Ford for data uploads.
• References to the Ford’s internal specific identifiers for the vehicle and user.
• Detailed usage events such as:
  • Gear changes
  • Door open/close events
  • Lock/unlock actions
  • Ignition state changes

Note: The convert-to-json_ccl-files.py Python script to convert the (hard to read) “Minified JSON” found in these files to “Pretty” JSON is included in our GitHub repository.

The following images (redacted) illustrate how structuring the data enabled us to focus on specific events and build a picture of vehicle usage during this timeframe. If the vehicle had connected to WiFi (no evidence suggests this occurred), this data would likely have been transmitted to the manufacturer.

Example Insights:

• URL, Vehicle and User Identifiers, Mileage, and Fuel Level:

• Gear Changes:

• Ignition Events:

• Door events:

Creating a Script for CCL Information

With this information we instructed Claude to create a Python script that could parse this information and display it for easier digestion.

The prompt we used was:

Create a Python script that:
- Looks for and analyzes files that are specified by the user with the -i switch for input files
- Output filenames should be specified by the user using the -o switch
- It should parse the minified JSON in the file (indicate)
- organize events by boot session
- analyze each session for ignition states, gear changes, door activity, navigation usage, and speed
- Output should be a timeline report in markdown showing what happened during each boot session

We ran the script with each file and obtained a summary of the activity found in each file. An example is included in the tables below:

Boot Cycle No. 9049

Boot Cycle No. 9050

Boot Cycle No. 9051

Note: Interpretation of these fields involved informed assumptions based on log structure and behaviour. Additional controlled testing would be required to confirm the exact meaning of every event with full certainty.

A Note on Telemetry Data Sharing

Although this vehicle does not have a cellular modem to allow for “always connected” functionality, it does show how much data modern vehicles could transmit this information back to the manufacturer on a continual basis.

Conclusion - End of Part 3B

Our analysis of the SYNC® 3 filesystem has shown that its retention of GPS, WiFi, and driving‑related data is as extensive (and revealing) as the Bluetooth artefacts examined in Part 3A. Across log files, navigation records, WiFi scan data, telematics entries, the Ranger’s head unit preserved a detailed operational history of the vehicle spanning multiple years.

By correlating data from these sources, we were able to reconstruct daily travel patterns, identify home and work locations, map dozens of individual trips, tie WiFi networks to precise locations, and confirm the time and location of an accident with a great deal of precision. The files found in the ccl folder added detailed vehicle usage capturing ignition cycles, gear changes, door events, and other data that together formed a highly detailed timeline of the Ranger’s use.

Taken together, the GPS, WiFi, and driving‑state artefacts make clear that SYNC® 3 functions as far more than a navigation or entertainment interface. Like the Bluetooth datasets from Part 3A, these logs operate as long term records, silently accumulating behavioural, positional, and operational information that persists long after the vehicle changed hands.

Fortify Labs Github Repository

All Python scripts generated and used in this post are available in our Fortify Labs Automotive Forensics Github repository in the ford-sync folder.

Verfication of AI Script Results

As our analysis of GPS data relied heavily on AI generated scripts, we validated the results at each stage. For example we:

• Performed open source searches to verify that the home and work locations were accurately rendered.
• For each script output, we validated the results against the original log files by cross referencing timestamps and GPS coordinates.
• Where a specific number of records was extracted (for example, the total number of GPS points) we performed independent verification using grep commands to ensure consistency with the orginal log files.

Next Up

In Part 5, we will demonstrate how we took the Ranger’s SYNC® 3 head unit and powered it on outside the vehicle for testing purposes.

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.