Data Reliability - VW MIB2STD: ISP Methods & Parking Durations

Introduction

The accuracy and reliability of data stored within vehicle infotainment systems are critical in serious crime and collision investigations, especially when examining GNSS journey history and parking events on this module. The Delphi MIB2STD, commonly found in Volkswagen vehicles between 2016 and 2020, is frequently encountered in criminal cases due to its ability to store journey data and parking durations. As a Vehicle Systems Forensics investigator, it is important to understand how this system records and retains these events to ensure proper analysis during investigations.

This study focuses on examining the journey history and parking duration data stored in the Delphi MIB2STD module using a 2019 VW Tiguan, with real world journeys and parking events conducted in May 2021. The goal is to verify the general accuracy of the recorded GNSS data, ensuring that Vehicle Systems Forensics examiners can rely on it during criminal investigations. However, this study does not delve into the finite details of GNSS location accuracy. Instead, the general locations over long journeys are examined.

In forensic cases, GNSS data analysis should always be considered with its inherent limitations in mind. By understanding the limitations and strengths of the journey and parking data recorded by this system, investigators can better interpret findings during forensic examinations and reporting, contributing to a more accurate understanding of the vehicle's usage and movements.

This reference material will be useful for the Vehicle Systems Forensics community, particularly those seeking the truth as well as those looking at ISO accreditation for digital forensics, by providing insights into the data stored within the system and its practical investigative applications. Other data types are stored on this system but not discussed here.

MIB2STD Infotainment System Overview

The MIB2STD is seen across the VW range; VW, Skoda & Seat. NOTE - this module is NOT in the Audi and Porsche Vehicles, there are slightly different internal architecture in the MIB2 (Scale) module.

The system is known as the Discover Pro Navigation System which is an advanced infotainment system with integrated satellite navigation (Sat Nav). Here are some general features and information about the VW Discover Pro Sat Nav:

1. Navigation System: The Discover Pro Sat Nav comes equipped with a GPS-based navigation system, providing real-time guidance and mapping. It includes detailed maps, points of interest, route planning, and turn-by-turn directions.

2. Touchscreen Display: The system features a user-friendly, high-resolution touchscreen display. This allows for easy access to various functions and settings, including navigation, multimedia, and vehicle information.

3. Connectivity: The Discover Pro offers various connectivity options, such as Bluetooth, USB, and auxiliary input, allowing users to connect their smartphones, media devices, or external storage to access and control multimedia content.

4. Voice Control: To enhance safety and convenience, the system often includes voice control functionality. This enables drivers to use voice commands for tasks like making phone calls, changing radio stations, or setting destinations for the navigation system.

5. App Integration: Depending on the specific model and software version, the Discover Pro may offer integration with popular smartphone apps, such as Apple CarPlay and Android Auto. This allows users to mirror their phone's interface on the infotainment display and access compatible apps.

6. Media Playback: The system supports various media formats, including audio and video files. It can play music from CDs, SD cards, USB drives, and other compatible devices.

7. Multimedia Features: In addition to the navigation and media playback capabilities, Discover Pro may include other multimedia features like FM/AM radio, DAB (Digital Audio Broadcasting), internet radio, and in some models, premium sound system options.

8. Updates: VW periodically releases software updates to improve system performance, add new features, and update navigation maps. These updates may be available through authorised VW dealerships or official VW websites.

9. Integration with Vehicle Systems: Depending on the vehicle model and features, the Discover Pro may integrate with other vehicle systems, providing access to vehicle settings, diagnostics, and maintenance information.

The above image shows the main touch screen user interface as it presents in the vehicle. A separate module is located in the glove box with an optical drive and 2 x SD slots. See further image below. Please note if the module is from an Audi vehicle despite being manufactured by the same tier one (Delphi) these do not have the same internal architecture and can be completely different with regards to what data is stored.

Data Acquisition Methods

The data of interest on the MIB2STD system is stored on an eMMC chip located on the module's printed circuit board (PCB). Choosing the right acquisition method is crucial to preserving the integrity of the data while minimising the risk of overwriting or damaging the module itself. In 2021 at the time of these tests, I was aware of two primary acquisition methods:

1. Chip-Off Method — This method involves physically removing the eMMC chip from the PCB to read it directly. While effective, it is what we would consider a destructive process that renders the module unusable. Given the cost of replacing these modules (around £3,000) this method is far from ideal. However, thanks to Melissa Bisla from Leicestershire Police, who authorised a chip-off in 2018 during a criminal investigation, we were able to use the opportunity to explore alternative methods. That chip-off procedure directly led to the development of a non-destructive acquisition process. Melissa's contribution has meant from that point forwards we no longer had to remove the chips from the printed circuit boards to preserve the data on the many other units we have examined since.

2. In-System Programming (ISP) / Direct eMMC Access — As a result of the knowledge gained from the chip-off method, we developed a non-destructive acquisition process that remains our preferred approach. This method, known as in-system programming (ISP) or direct eMMC access, allows us to connect to the eMMC chip while it is still attached to the PCB, avoiding the need to remove the chip. Key benefits of this method include: No need to power the vehicle: The module can be removed without activating the vehicle's systems, reducing the risk of data being overwritten during power cycles. Preservation of hardware: This approach ensures the module remains intact and functional for future use or defence examinations. Reduced risk of overwriting data: As this research will highlight, powering the vehicle poses the risk of triggering processes that could overwrite data.

Since 2021, additional acquisition methods have emerged. However, both alternatives involve powering on the vehicle, which can introduce risks of data loss: 3. Root Access Method: This approach involves connecting a laptop via USB-to-Ethernet to gain root access to the system, provided the correct passwords for the specific software version are known. While this allows for imaging of the eMMC chip, it requires a functional vehicle which if still connected to other networks on the vehicle could result in data being altered.

4. Berla iVe SD Card Solution: Berla's solution, which uses an SD card to interface with their iVe software and then the module when it is powered in the vehicle, offers another method for data extraction. However, this process also requires powering the vehicle, which can lead to the same risk of data overwriting by powering the vehicle on if the module is connected to the rest of the vehicle networks.

While these solutions offer convenience and are quicker than the ISP/Direct eMMC method, they still carry the risk of data loss, even with a single power cycle. Additionally, if the module or the vehicle is damaged and cannot be powered, these methods are not viable options. Therefore, the non-destructive direct eMMC access method remains the most reliable and our preferred method of acquisition of this unit. This technique protects the integrity of the data and I have used this approach on some of the most serious of cases here in the UK over the last few years where this module has been seen in vehicles of interest in those cases for this very reason.

I would again like to express my gratitude to those who have allowed chip-off procedures in all the cases we deal with involving eMMC chips, as each instance has enabled us to refine techniques that benefit the entire Vehicle Systems Forensics field. By reducing the need for destructive methods, we can better preserve evidence for future investigations while minimising costs and equipment loss which is expensive in automotive.

User Data

This research focuses on two primary types of user data stored in the MIB2STD infotainment system: GNSS (Global Navigation Satellite System) journey records and parking events. These data points are stored in an SQLite database titled `pnav`. The following outlines the structure and considerations for interpreting this data, with a focus on investigative use.

Each journey is assigned a unique trip ID, which serves as the primary identifier for the journey. The system records basic GNSS data, including latitude, longitude, and time stamps, but the frequency of these records is irregular. Time intervals between logged points can range from seconds to several minutes in some instances.

Whilst the GNSS data includes latitude, longitude, and time stamps (Epoch Time), it does not log additional GNSS information such as altitude or speed. This suggests that the system applies filtering before storing data, potentially omitting some details.

Upon export, the database records are not in chronological order and must be sorted by time stamp for accurate interpretation. Failure to do so can lead to incorrect analysis of the vehicle's movement.

Due to the irregular intervals between GNSS records, caution should be exercised when attempting to calculate average speed between successive fixes. The data is unreliable for precise speed calculations in urban or stop-and-go driving environments, although it may be more dependable in consistent, high-speed environments such as motorways. Each case should be assessed individually.

The recorded GNSS data appears to be raw, uncorrected location fixes rather than map-matched data. When plotted, it sometimes shows positions slightly off-road, indicating the system does not perform location correction before storing the data. This further reinforces the need for careful interpretation if requiring pin point accuracy rather than just general journey analysis.

If the vehicle does not immediately acquire a GNSS fix at the beginning of a journey (trip), gaps in the data may occur. This could result in missing location points between the end of a parking event and the first valid fix of the subsequent trip, leaving fine-grained movements unrecorded during this period.

Parking events are also recorded in the same database, providing details on when and where the vehicle was stationary, as well as the duration of each event. Each event generally corresponds with the final GNSS location recorded in the last trip. Parking events include the time, date, location, and duration (in minutes). These events can provide a timeline of when the vehicle was stationary, offering valuable insight for investigative analysis of vehicle movements and a timeline of events.

Parking events typically align with the last recorded GNSS point of the associated trip, helping investigators confirm where the vehicle was parked at the end of a journey. It is considered that a powering down of the vehicle is required for a parking event to be triggered and a subsequent powering up event for the duration to be calculated.

Investigators should exercise caution when interpreting parking durations. In previous case work, I have encountered instances where a parking event on these systems was logged for a duration that lasted over multiple days, however the vehicle was being used during that period (verified by other investigative means – CCTV witness testimony etc.). While this was not observed during the testing for this study, it has been noted in real-world investigations, such as a murder case I worked on in 2019. This could occur when conditions required to log a trip are not met, but in the referenced case and others the records still maintain sequential trip IDs. This is a crucial factor for investigators, as it can lead to misinterpretation of vehicle usage during such periods.

In summary, while the data stored in the MIB2STD system provides valuable insight into vehicle journeys and parking events, its limitations must be understood. GNSS data irregularities and potential issues with parking event logging necessitate a cautious approach to analysis.

Testing

Testing was carried out over three days in May 2021 using a VW Tiguan equipped with an MIB2STD infotainment system. The purpose of the test was to assess how the system logs GNSS journey data and parking events. No additional equipment was installed for corroborative data, as the journeys were conducted as part of routine daily work. Handwritten records were kept of the locations visited and the times of arrival and departure. Most of the journeys took place on the motorway network, involving long-distance travel across the UK, visiting recovery yards to examine vehicles and stopping at service stations for refreshments and breaks.

The module was examined on the 8th of May 2021 using the ISP (In-System Programming) method, and the user data captured from the previous three days (and earlier) was extracted. This method was chosen to preserve data integrity while minimising the risk of overwriting any stored data during the acquisition process.

All the data extracted from the system was then examined using Geotime by Duanne Watkins of JTOL. Duanne's assistance was invaluable, as manually processing and analysing such large datasets would have been highly challenging. Geotime's ability to handle and visualise complex data sets quickly is unmatched, and Duanne has helped us integrate some of these advanced analysis techniques into our data analysis course. A detailed walkthrough of the data is available in a PowerPoint presentation created by Duanne, though it is not publicly available due to the inclusion of private GNSS data. Please contact us for further details if needed.

On May 5th, 2021, a total of seven parking events were recorded, both in the real world and by the system. The durations logged by the system matched the actual times the vehicle was parked, and the journey routes recorded by the module (GNSS fixes) were consistent with the actual routes taken during testing. This shows that on this day, the system logged all journey and parking data accurately.

On May 7th, 2021, five parking events occurred in the real world, but only three were seen in the database. Below is a breakdown of the missing data: This analysis revealed missing data, specifically from Journey 2 and Journey 3, where either the data was not logged or had been deleted or overwritten by future use. Journey 3 was partially recovered from deleted records, suggesting that it had been present but was overwritten by subsequent usage of the vehicle. There was no data recovered for Journey 2, making it unclear whether this journey was logged at all or overwritten.

The complete data for Journeys 4, 5, and 6 indicates that the vehicle's use during these trips may have affected earlier stored data, particularly since data was not acquired immediately after each journey. It is worth noting that all data from May 5th was intact, suggesting that the system may not use a straightforward FIFO (First In, First Out) method for data management. Instead, newer data may selectively overwrite older records. We also saw some data from 2020 suggesting that historic data may still be present on the systems longer than one may expect and that older records may remain intact.

This finding reinforces the importance of carefully managing the acquisition process to avoid overwriting crucial historic evidence, particularly in serious crime investigations. Powering the vehicle during acquisition, for example, could inadvertently result in the loss of critical data depending on the needs of each case and times of interest.

Conclusion

This research demonstrates both the strengths and limitations of the MIB2STD infotainment system in logging GNSS journey data and parking events. Data extracted through the ISP method from the testing period showed that on May 5th, 2021, the system accurately stored all seven parking events and corresponding journeys. However, on May 7th, 2021, only three of the five real-world parking events were found, highlighting potential issues with data loss or overwriting.

A notable issue observed in real-world cases, though not during this test, is the occurrence of parking anomalies. In previous investigations, such as a 2019 murder case, the system logged parking durations spanning several days, even though the vehicle was known to have been in use during that time despite sequential records in the data making it appear it was not in use. This suggests that parking events may not always reflect actual vehicle usage, which is a crucial factor for Vehicle Systems forensic investigators to consider and those proceeding to use this in the criminal justice system.

Analysis of vehicle data is rarely straightforward, especially given potential gaps or inconsistencies in how data is stored and retained. This study demonstrates that while the MIB2STD system is reliable in many respects, investigators need to be mindful of its limitations, particularly regarding data that may be missing, overwritten, or inaccurately recorded. Consideration should also be given to the acquisition method used on this system as it is evident that data can be overwritten and it is unclear what may trigger new events to be recorded that would cause existing data to be deleted but if you do not wish to take any chances then ISP would be our favoured technique on this system.

Our hope is that the insights gained from this research, combined will contribute to the broader vehicle systems forensic community. We aim to provide valuable data interpretation techniques and share findings to help investigators navigate the complexities of vehicle systems forensics in their work.