Tesla Log Data Analysis Approach from a Digital Forensics Perspective

Abstract

Modern vehicles are equipped with various electronic control units (ECUs) for safety, entertainment, and autonomous driving. These ECUs operate independently according to their respective roles and generate considerable data. However, owing to capacity and security concerns, most of these data are not stored. In contrast, Tesla vehicles, equipped with multiple sensors and designed under the software-defined vehicle (SDV) concept, collect, store, and periodically transmit data to dedicated servers. The data stored inside and outside the vehicle by the manufacturer can be used for various purposes and can provide numerous insights to digital forensics researchers investigating incidents/accidents. In this study, various data stored inside and outside of Tesla vehicles are described sequentially from a digital forensics perspective. First, we identify the location and range of the obtainable storage media. Second, we explain how the data are acquired. Third, we describe how the acquired data are analyzed. Fourth, we verify the analyzed data by comparing them with one another. Finally, the cross-analysis of various data obtained from the actual accident vehicles and the data provided by the manufacturer revealed consistent trends across the datasets. Although the number of data points recorded during the same timeframe differed, the overall patterns remained consistent. This process enhanced the reliability of the vehicle data and improved the accuracy of the accident investigation.

1. Introduction

Unlike analyzing a new phone or operating system, analyzing a vehicle for digital forensics is a difficult task, in terms of both software and hardware because the software of various electronic control units (ECUs) controls the hardware according to the assigned roles. As each ECU operates independently, determining the location and the form of the recorded data is difficult. Therefore, digital forensics research on vehicles has been limited to individual ECUs [1,2,3].

• Inspection of event data recorder (EDR) for traffic accidents;
• Analysis of dashcam to identify accident/incident videos;
• Examination of telematics and infotainment systems to understand accident/incident conditions.

However, there has been a paradigm shift in the vehicle industry owing to various environmental regulations, new business and service models, and new competitors from IT companies. To handle these changes effectively, the software must manage each ECU through an integrated approach, and connectivity between the vehicle and back-end services is crucial [4]. The application of these concepts manifests as software-defined vehicles. Digital forensic investigators should be able to investigate incidents/accidents through integrated and controlled software-defined vehicle (SDV) modules and external connectivity [5,6,7]. Manufacturers must assist in this process, and clear incident investigation and resolution are required to establish credibility with consumers. Specifically, SDV-enabled vehicles require an appropriate structure to collect and record data related to safety, driver assistance, entertainment, and autonomous driving [8,9,10]. Depending on the manufacturer’s policy, the data can be recorded inside the vehicle or, in certain situations, transmitted to a dedicated server over a wireless network [4,11].

Therefore, these data are crucial for solving crimes involving vehicles, determining the causes of vehicle accidents, and reconstructing accidents. Furthermore, because this information is recorded on multiple storage devices inside the vehicle, it can be cross-checked and verified to increase the reliability of the information. Event data recorders (EDRs), which involve the current generation of accident recording devices, are designed to investigate vehicle accidents and store data using the vehicle’s impact sensors or airbag modules. EDRs were mandated by the NHTSA’s 49 code of federal regulations (CFR) part 563 in 2006, which defines the accuracy, collectability, storage, and survivability of crash event data [12]. Furthermore, 49 CFR Part 563.7 emphasizes that obtaining and analyzing EDR data does not require the support of the vehicle manufacturer. This ensures transparency and objectivity of the data during the accident investigation process, mirroring the principles of integrity and verification that are crucial in digital forensics. However, the data recorded by EDR are limited to accidents with large impacts that cause airbags to deploy, and the data stored are limited to approximately 5 to 10 s of driving-related data just before the accident. Furthermore, vehicles equipped with autonomous driving functions are equipped with various sensors and record considerable data [13], but the data recorded in the EDR are limited. To address these problems, the development of a data storage system for automated driving (DSSAD) is being discussed [14], and regulations are being redefined through standardization [15]. Tesla vehicles, equipped with various ECUs for autonomous driving, feature a centralized electrical/electronic (E/E) architecture instead of the traditional design. This centralized E/E architecture provides the advantage of centralized control of the individual vehicle ECUs and is well-suited to the application of IT technologies such as over-the-air (OTA) functions [8,16,17].

The module operating Tesla’s centralized E/E architecture is the media control unit (MCU), which collects and controls various data related to autonomous driving, including DSSAD. MCUs incorporate functions related to air control, body control, infotainment, and OTA, enabling digital forensic investigators to access various data [18,19]. In this study, we have limited access to data storage locations inside Tesla vehicles and used public reports from Tesla for analyzing the stored data. Additionally, in situations wherein it is challenging to obtain data according to the manufacturer’s manual because of fire or impact, existing digital forensic techniques were used for analysis. Various log data from ECUs and external servers were obtained, as depicted in Figure 1.

• Restraints control module (RCM);
• Media control unit (MCU);

  –

  eMMC memory (Onboard);

  –

  MicroSDHC (Insert);

• Over-the-air (OTA)-Tesla Server.

Among the acquired data, OTA data can be documented by processing information periodically sent by the MCU to the dedicated server. This server-stored data serves as the sole record when data retrieval from internal storage media is hindered due to a major collision. Apart from these scenarios, we verified that the storage media of the MCU, serving as the centralized E/E architecture, records logs that can cross-validate data received from the restraint control module (RCM) and Tesla server. The remainder of this paper is structured as follows: Section 2 outlines the locations, characteristics, and analysis methods of the data stored in each ECU. In Section 3, a case study is presented to demonstrate the reliability of the analyzed data by comparing them with the data from each ECU. Finally, the findings, accompanied by an in-depth discussion and conclusions, are presented in Section 4.

2. Materials and Methods

Tesla vehicles (designed with a centralized E/E architecture), like mobile phones, receive periodic software updates for introducing new features or changing the structure of logs [20]. Therefore, the structure of the acquired data changes depending on the model and year of release as well as the last software update. Figure 2 illustrates various log data recorded in Tesla vehicles. The green boxes represent data that can be obtained from the manufacturer, while the orange boxes indicate data analyzed using the methodology proposed in this study. This section describes the features of each set of data to be analyzed and the process of data acquisition.

2.1. Restraints Control Module

As EDR may be mandated in each country; upon detecting a collision, the vehicle is required to store information from up to 5 s before the collision event. To extract data from the restraints control module (RCM) that comprises recorded EDRs, we used Tesla’s dedicated extraction cable and software. Two extraction methods are suggested by the manufacturer [21]. First, if the vehicle has normal power, then the data cable is connected to the RCM module in the vehicle, and the data are extracted. Second, if the vehicle does not receive power normally, the RCM module is detached from the vehicle, and the 12 V power and data cable are connected to extract the data. Next, the data are uploaded to Tesla’s server and analyzed in the form of a PDF report [21]. However, this method of analysis is problematic for digital forensic researchers. First, if the RCM is damaged due to various reasons, such as fire, flooding, or a major collision, extracting normal EDR data becomes challenging. Second, the reliability of the extracted data cannot be guaranteed because the data analysis is dependent on a dedicated server.

2.1.1. Extracting Data from a Corrupt RCM

In the case of electric vehicles with RCM modules, a high probability exists that a fire will occur in a large collision [22], and the fire as well as fire extinguishing will damage the RCM, as depicted in Figure 3. Therefore, digital forensic techniques are necessary to extract data from the RCM’s memory. The RCM memory used by Tesla, manufactured by Bosch, is electrically erasable programmable read-only memory (EEPROM). EEPROM is a nonvolatile memory device that retains data for long periods, even in the absence of electricity, rendering it an ideal memory method for EDRs. If the RCM’s printed circuit board (PCB) is damaged because of a fire, Tesla’s RCM extraction tool cannot acquire data. From a digital forensics perspective, two options are available: repair the damaged board or connect directly to the memory area. In the case of the automotive RCM, we connect directly to the memory rather than repairing the damaged board because of the wide range of damage and complexity of the board configuration. The EEPROM used by RCM incorporates a 64 Kbit serial SPI bus [23]. We extract the data after connecting to memory according to the interface-specific functions such as power, ground, clock, data I/O, etc., as depicted in Figure 4.

The extracted data were 64 Kbit, and the extension was changed to *.edr; then, the data were uploaded to the dedicated server. However, we could not receive the analyzed report from the dedicated server. It is assumed that the data extracted through the EDR-only extraction tool and the data extracted directly from memory are different in structure, which is the reason why analytics reports are not generated on the server. We analyzed the extracted 64 Kbit data in binary form and determined that the binary data were recorded in Little-Endian form in 6-byte units, which could be reversed to determine the vehicle identification number (VIN) of the vehicle, as depicted in Figure 5.

2.1.2. EDR Data Validation

As described in Section 2.1, to extract EDR data from the RCM it must first be ensured that the vehicle is powered and functioning appropriately. Next, the RCM must be connected using the PCAN-USB cable and the Tesla retrieval cable; further, the Tesla EDR program must be executed on a Windows PC with the PCAN-USB driver installed. The Tesla EDR program checks for connectivity and subsequently acquires EDR data by clicking the “Run EDR Retrieval button”. At this time, the acquired data are created as an *.edr file. Finally, the *.edr file is uploaded to the Tesla Analytics Server to download the analysis report [24]. A sample of EDR reports obtained from these Tesla vehicles is published on the “EDR kit for Tesla vehicles” web page [24], and the final page of the Tesla report discloses hexadecimal data. This disclosure of data adds credibility to the analyzed results and increases the driver trustworthiness from a manufacturer’s standpoint. To analyze EDR data from the acquired data, we analyzed the publicly available Tesla reports using reverse engineering techniques [25,26] and matched the EDR data. For validation, we compared the results with the reports analyzed by the Tesla dedicated extraction tool and system. Section 3 details the values of each module for the matched cases.

2.2. Media Control Unit

The media control unit (MCU), the primary system of a Tesla vehicle, performs various functions, such as connecting to external networks (using 4/5G Simcard), driver settings, infotainment, dashcam, and navigation [27]. Furthermore, MCUs function as integrated controllers in a centralized E/E architecture, and many different types exist depending on the model and year of the vehicle. These MCUs differ not only in hardware but also in software. However, they perform the same task: recording various log data. The MCU has two types of storage media: the primary embedded multi-media card (eMMC), which is attached to the PCB, and MicroSDHC, which is an external storage media. In the eMMC, the memory is logically partitioned into system areas and major functions using a Debian-based Linux system as the operating system. In this study, eMMC memory is not covered, and data recorded on a MicroSDHC mounted on the MCU were acquired and analyzed.

Figure 6 details the folder structure of a microSDHC card installed in two Model X vehicles, with some folders having the same structure (DTC folder: vehicle diagnostics, LOG folder: vehicle log data) and others with a different structure (RCM folder: EDR data, chg-wvfm folder: charging records). The DTC folder contains the manufacturer’s vehicle diagnostic codes serially recorded with time information, and the chg-wvfm folder contains logs related to battery charging. Thus, this is not discussed in depth.

2.2.1. Analyze EDR Folders

An RCM folder is recorded under the EDR folder on the MicroSDHC, and its subfolders are assigned folder names with an 8-digit number and alphabet combination. An analysis of the folder name reveals that the folder name is 4-byte POSIX time information, recorded as the collision time the EDR data were recorded. This folder contains one *.log file and several *.bin files, and the *.log file records when the *.bin information is created. Most *.bin files are less than 20 bytes of data and contain information about what is assumed to be the serial number of each sensor. The bin files with 4-digit filenames, such as the hex data described in Section 2.1.2, have 4 Kb of data. We compared the files in this folder to the hex values in the EDR report extracted from the physical RCM and determined that they were the same. Thus, the data recorded in the physical RCM were also recorded in the MCU, and the data could be analyzed similarly to that analyzed in Section 2.1.2.

2.2.2. Various Bin Files Extracted from the EDR Folder

In the EDR folder, a number of BIN files are written with a 4-byte hex value, as presented in Section 2.2.1. The hex values of each bin file are presented in

Table 1. BIN file names recorded in the EDR folder.

Vehicle Type	File Name
ModelX-2020	f014	f015	f190	fd00	fd52	fd60	fd61	fd62	fd63
	fd64	fd65	fd66	fd67	fd68	fd69	5817	5818	-
ModelS-2017	-	-	-	-	-	-	-	-	-
	-	-	-	-	-	-	-	-	-
Model3-2018 *	f014	f015	f190	fd60	fd61	fd62	fd63	fd64	fd65
	fd66	fd67	fd68	fd69	5817	5818	-	-	-
ModelY-2020 *	f014	f015	f190	fe01	fe02	fe04	fe05	fe06	fe07
	fe0c	fe0d	fe0e	fe0f	5817	5818	-	-	-

* Reference of the Tesla EDR reports [24].

and vary depending on the model and software version of the vehicle. The names of the bin files are written in a form similar to that of the protocol values defined in ISO 14229-1 (Road Vehicle-Unified Diagnostic Services (UDS)) [28], which is a communication protocol between automotive ECUs for diagnostics, firmware updates, tests, logs, etc. The UDS is used as a protocol at the application layer, the highest level of the Open Systems Interconnection (OSI) seven-layer model [29]. The request data parameter of UDS has a data identifier (DID), defined as presented in

Table 2. List of parts of data identifiers (DIDs) of ISO 14229 standard [28].

UDS DID Data Identifier	DID Name	DID Description
0x0100 1-0xA5FF 1	Vehicle Manufacturer Specific	This range of values shall be used to reference vehicle manufacturer specific record data
0xF010 1-0xF0FF 1	Vehicle Manufacturer Specific	This range of values shall be used to reference vehicle manufacturer specific record data
0xF190 1	VIN Data Identifier	This value shall be used to reference the VIN number
0xFD00 1-0xFEFF 1	System Supplier Specific	This range of values shall be used to reference the record data identifiers and input/output identifiers within the server

¹ Hexadecimal Value.

, which matches the name of the extracted bin file. Therefore, the bin files written to the EDR folder are assumed to be the DID of each UDS request parameter value. For example, 0xF190 indicates vehicle identification number (VIN) information, which is the unique number of a vehicle, and the extracted “F190.bin” file contains the VIN information as a hex value.

2.2.3. Analyze LOG Folders

The “LOG” folder on the MicroSDHC contains a single *.txt file and multiple 300 Mb or smaller *.log files. The *.txt file records the maximum size of a single log file (300 Mb) and the maximum number of log files (5), along with the offset and filename of the most recently recorded log. To analyze the data in the LOG folder of the MicroSDHC, we used “TeslaLogs” developed by NFI [30]. “TeslaLogs” incorporates reverse engineering techniques to analyze log data from Tesla vehicles (Model X, Y, and 3). The directory changes depending on the year of the vehicle, and the analysis capabilities vary depending on the autopilot (AP) version. However, the paper published by NFI did not identify any inconsistencies between the data provided by Tesla and the log data [31]. Furthermore, a comparison of the recorded logs in the LOG folder and the EDR folder reveals that the data recorded in the EDR folder for the same period and entry are high-resolution logs (HRL), whereas the log files in the LOG folder contain HRL and low-resolution logs (LRL) at various periods. Therefore, the MicroSDHC, where the LOG folder is stored, can store considerable data by sampling the data input to the MCU. MicroSDHC also optionally stores HRLs in case the vehicle is involved in a collision or as determined by the AP system [32].

2.3. OTA-TESLA Server

The manuals that Tesla provides to drivers contain information about various connectivity features. For example, a Bluetooth module connects with the driver’s cell phone, and a Wi-Fi module updates software or maps [27]. Furthermore, the MCUs have a national carrier’s SIM card inserted for operating 4/5G networks. This connection enables the periodic transmission of log data recorded in the vehicle to a dedicated server, as well as nonperiodic transmission of HRL data when the AP function is activated or an event such as an external impact occurs. To obtain data transmitted to Tesla’s servers, law enforcement agencies must submit a request to the manufacturer following proper legal procedures. Data acquired through this process is characterized by its limited time frame and parameters. In this study, we requested the OTA report corresponding to the time of the incident. Furthermore, if the vehicle is involved in an accident, the manufacturer can provide a time-of-accident report on a limited scale to law enforcement, in accordance with manufacturer policy [21]. The information provided is detailed with the signal name, signal description, unit, and values. From a digital forensics perspective, the data provided by the manufacturer can be cross-checked with the data inside the vehicle for reliable accident/incident analysis.

3. Implementation of the Forensic Process on a Vehicle

We analyzed two Model X vehicles from a digital forensics perspective. The first accident involved a Model X colliding at high speed with a wall in an underground parking lot and catching fire. The key issue in this case was that the driver was the designated driver at the time and claimed to have pressed the brake pedal, but the vehicle experienced an unintentional rapid acceleration. The first Model X vehicle could not receive EDR reports because the RCM was damaged, and we compared the RCM folder and LOG folder of the MicroSDHC mounted on the MCU with the OTA reports provided by the manufacturer. The second accident also involved a Model X vehicle that collided with a wall at high speed on a downhill slope in a parking lot. However, unlike the first case, no fire occurred. The driver claimed that the vehicle experienced sudden unintended acceleration. The second Model X was a normal RCM, and fortunately, we could verify the EDR report. However, the RCM folder in MicroSDHC did not exist, and we could only compare the LOG folder and OTA report from the manufacturer. Furthermore, the comparison focused on items in the log data that were recorded periodically as values, rather than items where data are recorded aperiodically; both sets of items are detailed in

Table 3. Types of logs recorded by SDV-enabled vehicles.

Periodically Log	Aperiodically Log
Vehicle Speed	AEB State
Accelerator Pedal Pressure	Cruise State 1
Steering Wheel Angle	Front Crash
Torque Motor	Auto Pilot State
Longitudinal/Later Acceleration	Auto Park Ready
Longitudinal/Lateral Delta-V data	Gear Poison

¹ This value determines how often logs are written.

.

3.1. Damaged Model X Log Data from a Digital Forensics Perspective-I

The Model X vehicle analyzed in this study was involved in a fire accident that damaged the PCB inside the RCM, rendering it difficult to obtain normal EDR reports. The MCU module was severely damaged and would not power up normally. The MCU contained an 8 Gb MicroSDHC, and the “RCM” folder and “LOG folder” were checked in the memory. We analyzed the extension bin file written in the RCM folder and the last recorded log file written in the offsets.txt file in the LOG folder. We conducted an evaluation of the analyzed data against the OTA report obtained from the Tesla server. The MCU’s MicroSDHC memory in the vehicle, with its two folders, and the processed OTA report from Tesla’s server demonstrate the characteristics of a software-defined vehicle (SDV). First, log records from the same timeframe are recorded both internally within the vehicle and externally on the server. Second, while the two folders on the MicroSDHC memory store data from different ECUs, they are physically stored on a single memory unit.

3.1.1. Comparison of LOG Folder and OTA Report

Figure 7 presents a comparison of the analyzed values from the MCU’s LOG folder with the OTA report’s vehicle speed and accelerator pedal press for the same period and entry. Figure 7 details data from approximately 10 min before the accident, and the data analyzed from the LOG folder in the front and the OTA report in the back were almost equal. However, although the data were logged periodically, there were periods with no values logged. This is assumed to be caused by millisecond packet delays when sending data from the sensors of each ECU to the central E/E architecture, the MCU through the CAN network, or by the calculation process of the MCU. This is why multiple values of the same item are stored simultaneously. In this case, just before the collision the driver pressed the accelerator pedal hard, and the speed increased rapidly just before the collision. Analysis reveals that the vehicle maintained a high speed despite minimal accelerator input between 500 and 600 s prior to the collision. This observation may be attributed to external factors, such as downhill road conditions. Generally, a proportional relationship between accelerator pressure and vehicle speed is observed.

3.1.2. Comparison of RCM Folder, LOG Folder, and OTA Report

The graph on the left in Figure 8 presents a comparison of the steering wheel angle in the LOG folder and the OTA report for the same period. As depicted in Figure 7, the same values are shown for most of the time. The figure on the left shows the steering wheel angle for the 10 min before the collision. The right side of the steering wheel is represented by positive values and the left side by negative values. The large change in values from 100 s before the collision is likely due to the increased steering angle as the car enters the parking lot. The right graph in Figure 8 depicts three types of steering wheel data: RCM folder data, LOG folder data, and OTA report. The data from the RCM folder at the back detailed the most HRL, whereas the LOG folder and OTA reports were represented by LRL. However, all three data types depicted the same trend: the driver steered approximately 20° to the left and right just before the collision. In this case study, the RCM module was found to be damaged, and no manufacturer’s report was available. However, comparison with data from the RCM folder in the memory mounted on the MCU suggests that the data in the RCM device and the RCM folder are identical. Additionally, it was observed that the RCM folder data contains fewer stored items but offers higher resolution in recorded values. Conversely, data in the LOG folder and OTA report contains a greater number of stored items, albeit at a lower resolution.

In addition to the three data types presented in the research report, the pre-collision data analyzed from Model X includes dozens of additional parameters stored at both periodically and aperiodically. From a digital forensics perspective, interpreting data from various modules using multiple methods, as in this case, enhances reliability. This approach enables more accurate accident investigations through an evaluation against traditional methods that rely solely on manufacturer reports.

3.2. Damaged Model X Log Data from a Digital Forensics Perspective-II

The vehicle analyzed in this section was produced in 2022, two years after the vehicle discussed in Section 3.1, and because the EDR was not damaged we could generate an EDR report. However, the RCM folder on the MicroSDHC mounted on the MCU did not exist. The MicroSDHC mounted in the MCU did not have an RCM folder; instead, it comprised a CHG-WVFM folder in which the charging history could be viewed, as depicted on the right in Figure 6. Therefore, this section presents a comparison of three types of data: the log folder on the MicroSDHC, the OTA report, and the EDR report. A key characteristic of the software-defined vehicle (SDV) observed in this vehicle is that the configuration of stored data can vary depending on the software version. SDVs frequently receive software updates via OTA, which can introduce new features or, as in this case, alter the method of log recording.

3.2.1. Comparison of the LOG Folder and OTA Report

Figure 9 depicts a graph comparing the LOG folder and the OTA report for two items (vehicle speed, accelerator pedal), matching the data in the LOG folder to the OTA report approximately 3 min before the accident. The OTA report provided by the manufacturer details more period data than the EDR data, but less period data than the data recorded in the LOG folder. Additionally, the data displays information from different time periods depending on the activation of autopilot and engine start times specific to each incident. This, similar to the vehicle analyzed in the previous Section 3.1, indicates an apparent proportional relationship between accelerator pedal pressure and vehicle speed. Notably, however, in the 60 to 100 s prior to the collision, vehicle speed consistently increases despite minimal pedal pressure, which may be attributed to road characteristics such as a downhill slope.

The steering wheel angle and longitudinal acceleration values in Figure 10 depict positive values on the right and negative values on the left. The two values are consistent with most data, with the accelerator pedal in Figure 9 being pressed just before the collision to increase speed, which increases the longitudinal acceleration value.

3.2.2. Comparison of the OTA Report and EDR Report

The comparisons between data received from OTA reports and data obtained from the vehicle’s EDR are shown. Most data recorded by the EDR are those recorded 5 s before the accident, but some items have values recorded from 300 s before the accident, such as longitudinal acceleration values, as depicted in Figure 11. Additionally, the resolution of values recorded in the OTA report varies depending on the vehicle’s autopilot status, with only two values for longitudinal acceleration recorded in the five minutes leading up to the collision. The values demonstrate similar trends for the steering wheel, accelerator pedal, and vehicle speed, as presented in Figure 12.

Figure 12 below compares pedal pressed values and vehicle speed data from the OTA report and EDR data. Notably, OTA report data is recorded aperiodically, whereas EDR data is logged periodically. This discrepancy arises because the OTA report data is first collected from various sensors within the vehicle, then converted to text by the MCU, and subsequently packetized for transmission. During this process, values from each sensor are sampled before storage, which likely results in non-continuous data logging. In contrast, EDR data appears to be recorded periodically, as it is gathered through the vehicle’s CAN network, where sensor values are received and stored at regular intervals.

3.3. Discussion

The data analyzed by all three methods demonstrate several characteristics. The bin files recorded in the RCM folder store data from 5 s before the incident for a limited number of items. The data in the LOG folder and the data in the OTA report have mostly the same values for the same items at the same time. Even items that are logged periodically in the LOG folder and OTA reports are not recorded every second, and time lag exists. The data recorded in the RCM folder has a higher resolution than the LOG folder and OTA reports. There are a higher number of parameters analyzed in the data recorded in the LOG folder than in the OTA report, and saved parameters vary depending on the CAN communication network that is grouped. Finally, the data stored vary depending on the software version, and similar to mobile phones, software updates occur frequently. In this study, only four parameters of data are described, but dozens of parameters of data are stored in the pre-crash analysis data of Model X, both periodically and aperiodically. In terms of digital forensics, reliability can be increased by interpreting data in various ways in various modules, as in this case. This also allows for more accurate accident investigation than relying solely on manufacturer reports. Finally, various data recorded in the vehicle include personal information, and the collection and analysis of such information require lawful legal procedures. We obtained the data through lawful procedures with the consent of the owner. Furthermore, personal information, such as the vehicle identification number (VIN), was anonymized to ensure that the data could not be used to identify individuals before its disclosure. The OTA reports described in the data can also be requested only by the vehicle owner or legally authorized entities under restricted conditions. Careful and cautious handling of such information is essential.

4. Conclusions

In this study, various log files recorded in Tesla vehicles were identified, acquired, analyzed, and validated from a digital forensics perspective. From a digital forensics perspective, accessing the data in the vehicle is difficult, and limited data are stored. However, in the case of recent vehicles designed as SDVs, log data must be stored in one place because of the central E/E architecture, and this study confirmed that the MCU of Tesla vehicles demonstrates this capability. Through this process, a more accurate investigation of accidents and incidents is anticipated by cross-referencing traditional event data from EDR with OTA and central controller logs. Furthermore, although not addressed in the current study, future research is planned to include additional analysis of the MCU main embedded memory and the autopilot system.