Tearing down a car telematic unit (and finding an accident on Facebook)

Introduction

Modern cars are highly connected electronic systems. Over the last decade, vehicles have seen a rapid increase in connectivity, with multiple ECUs communicating internally but also with external networks. Telematic units (TCUs) play a key role in this evolution, enabling cellular communication and emergency calls (eCall).

This rise in connectivity has been accompanied by changes in vehicle electronic architectures, moving from simple, isolated ECUs to complex, centralized or domain-based architectures. Such changes also introduce new security and privacy requirements. European regulations like UNECE R155 and R156 now push manufacturers to implement secure systems that can be updated remotely Over-The-Air updates (OTA) to address vulnerabilities and ensure safety compliance.

In this blog, we explain how we analyzed a TCU from a Chinese manufacturer (BYD), extracted its firmware, explored its stored data, and combined it with publicly available information. This story highlights how modern connected vehicles generate rich datasets and how combining embedded forensics with Open Source Intelligence (OSINT) can reveal unexpected insights.

Device acquisition

Acquiring a TCU can be done in several ways:

• Directly from the car manufacturer or Tier 1 suppliers;
• From a salvage yard, which requires patience, technical skills, and proper tools;
• From online second-hand marketplaces, which are often the most efficient.

For this investigation, we selected a TCU from a BYD vehicle, a Chinese manufacturer. Some Chinese vehicles have raised security concerns; for instance, Poland has banned certain models from its military bases.

The device was obtained second-hand, providing an opportunity to explore its firmware, configuration, and logs, and to understand how these units operate in real-world conditions.

Teardown

We were interested in analyzing a BYD Seal telematic unit, which is composed with the following main components :

• S32K144U MCU (for CAN communication)
• Flairmicro FLC-MCM63XG composed with:
  • Qualcomm MDM9628 from the Snapdragon X5 LTE Modem series: Modem CPU + Application CPU
  • Micron MCP MT29AZ5A3CHHTB: Nand flash + LPDRAM

TCU Main Components

In such a device, the system on chip usually stores a Linux-based filesystem which manages core functions. It often relies on a multiple chip package (MCP) memory, combining RAM and ROM in a single package. We decided to perform a chip off of the Micron MCP in order to obtain the full filesystem and to look for any interesting forensic data.

Dumping the flash

We removed the MCP memory chip from the board and dumped its content externally. As we did not have any adapter to handle the specific BGA 162package of the MCP memory, we used the Flashcat USB Mach1 along with a custom made adapter.

Without a dedicated NAND adapter, we used micro-soldering to attach thin wires directly to the chip’s pads. In this approach, we only connected to the essential NAND signals, such as CE, ALE, CLE, WE, RE, and I/O lines, which are sufficient to interface with the memory and perform a full dump.

Handling the micro-wires is delicate, and soldering them onto the landing pad matrix is particularly challenging due to their small size and fragility.

MCP Dump processing

Once the micro-wiring was completed, the chip was connected to the reader. Multiple read attempts were performed to ensure data consistency, which is especially important when working with NAND memory. After verification, we obtained a complete and reliable dump of the flash memory, ready for further analysis.

Data analysis

Binary reconstruction

Before looking at partitions or filesystems, we need to handle the raw NAND dump correctly. NAND memory is not just a sequence of bytes, it’s organized in pages, each containing data blocks and OOB (Out-Of-Band) metadata. On Qualcomm platforms, the OOB contains:

• ECC (BCH) for error detection and correction;
• Padding (always 0xFF);
• Additionally, each page ends with extra 0xFF bytes to ensure block alignment and maintain the page size.

A single page layout can be represented as:

The ECC is used to correct errors in each data block, while the padding must be ignored during extraction. Handling both correctly is essential: without ECC correction and padding removal, the extracted binary would be corrupted or unusable.

Our reconstruction process consists of:

• Identifying the data block layout;
• Correcting each data block using its ECC;
• Extracting only the data portions, ignoring the padding.

This produces a linear binary that matches what the system actually reads, ready for partition analysis and filesystem extraction.

From binary to complete file system

From there, we could identify the Qualcomm Partition Table:

$ python3 parser_qualcomm.py 
SMEM table find at offset 0x00281000  version=4  numparts=16

Name                 Offset(blocs)   Offset(bytes)    Size(blocs)     SIze(bytes)
------------------------------------------------------------------------------------------
0:0:SBL                   0 blocs  0x00000000          10 blocs  0x00280000
0:0:MIBIB                10 blocs  0x00280000          10 blocs  0x00280000
0:0:EFSG                 20 blocs  0x00500000          48 blocs  0x00c00000
0:0:EFS2                 68 blocs  0x01100000          48 blocs  0x00c00000
0:0:TZ                  116 blocs  0x01d00000           4 blocs  0x00100000
0:0:RPM                 120 blocs  0x01e00000           2 blocs  0x00080000
0:0:aboot               122 blocs  0x01e80000           3 blocs  0x000c0000
0:0:boot                125 blocs  0x01f40000          32 blocs  0x00800000
0:0:boot1               157 blocs  0x02740000          32 blocs  0x00800000
0:0:SCRUB               189 blocs  0x02f40000          48 blocs  0x00c00000
0:0:modem               237 blocs  0x03b40000         403 blocs  0x064c0000
0:0:misc                640 blocs  0x0a000000           6 blocs  0x00180000
0:0:fota                646 blocs  0x0a180000           6 blocs  0x00180000
0:0:sec                 652 blocs  0x0a300000           2 blocs  0x00080000
0:0:custapp             654 blocs  0x0a380000         257 blocs  0x04040000
0:0:system              911 blocs  0x0e3c0000        1137 blocs  0x11c40000
------------------------------------------------------------------------------------------
TOTAL                  2048 blocs  (512 MB)  ✓ = TOTAL_BLOCKS

Using binwalk, we determined that the UBI erase count header at 0x3B40000 marked the beginning of the modem partition. Extracting it was straightforward with dd:

$ dd if=nand_nand.bin of=nand.ubi bs=62128128 skip=1
7+1 enregistrements lus
7+1 enregistrements écrits
474742784 octets (475 MB, 453 MiB) copiés, 0,3833 s, 1,2 GB/s

From there, the ubireader tool allowed us to obtain the full filesystem for the modem, custapp, and system partitions:

$ ubireader_extract_files -iw nand.ubi -o extracted_FFS_Nand/
....
$ tree extracted_FFS_Nand/
....
555 directories, 5444 files

With the files extracted, we could focus our attention on the root filesystem (rootfs) and user space (usrfs) to look for interesting or hidden artifacts.

This stage marked the start of digging deeper into the TCU’s internals, where logs, configuration files, and traces of user activity could reveal interesting information.

File system analysis

We first analyzed the configuration files to better understand the boot process and identify potential security issues.

This initial review quickly revealed several obvious sensitive elements, including:

• Wi-Fi credentials stored in cleartext

c$ cat conf_fix/network.conf 
...
APSSID=q*******_wifi
APKEY=8******1

• User access available without authentication:

$ cat passwd | grep guest && cat shadow | grep guest
guest:x:2000:2000:default guest:/home/guest:/bin/sh
guest:*:19461:0:99999:7:::

• Root password is stored as a SHA-256 hash. While this makes it hard to recover, its presence on the device shows that privileged credentials are accessible:

$ cat shadow | grep root
root:$5$D0nfIV.JMhXbvCNa$n8lsXs***************17RWXvjrVHMDjVTKMdSpDA:19461:0:99999:7:::

• Configuration steps enabling services such as ADB, TCP, and Telnet

$ cat conf_fix/ex_interface.conf 
EX_LTE=1
EX_TBOX=0
FTPD_IFEN=0
TELNETD_IFEN=0
ADB_IFEN=0

We then shifted our focus to forensic data, by exploring all available log files. Among them, GNSS logs quickly stood out as particularly valuable.

Forensic analysis

By parsing the GNSS logs, we reconstructed the full life of the vehicle from its production in a factory in China, through its operational life in the United Kingdom, to its final dismantling in Poland. Every movement and stop along the way is captured in the logs, giving a complete picture of the vehicle's journey.

We extracted precise GPS positions over time:

$ cat fmc_gnss_srv.nmea.log | grep 2025-05-24_16:26
2025-05-24_16:26:00 Nmea:250524162558,(1,2),(5*******,1******,85),(23170,0),(13,10),(8,5,6)[0]
2025-05-24_16:26:00 Sv1/4:{1,28,135,30,1};{3,52,74,43,1};{4,68,154,29,1};{6,37,303,31,1}
2025-05-24_16:26:00 Sv2/4:{9,39,203,33,1};{11,5,307,29,1};{12,2,327,22,0};{17,33,227,39,1}
2025-05-24_16:26:00 Sv3/4:{19,41,261,40,1};{28,12,32,41,1};{31,23,57,41,1};{2,2,137,0,0}
2025-05-24_16:26:00 Sv4/4:{25,0,358,0,0};{0,0,0,0,0};{0,0,0,0,0};{0,0,0,0,0}
2025-05-24_16:26:01 Nmea:250524162559,(1,2),(5*******,1******,85),(23170,92),(13,10),(8,5,6)[0]
2025-05-24_16:26:01 Sv1/4:{1,28,135,31,1};{3,52,74,45,1};{4,68,154,33,1};{6,37,303,43,1}
2025-05-24_16:26:01 Sv2/4:{9,39,203,34,1};{11,5,307,35,1};{12,2,327,30,0};{17,33,227,39,1}
2025-05-24_16:26:01 Sv3/4:{19,41,261,38,1};{28,12,32,40,1};{31,23,57,41,1};{2,2,137,0,0}
2025-05-24_16:26:01 Sv4/4:{25,0,358,0,0};{0,0,0,0,0};{0,0,0,0,0};{0,0,0,0,0}
2025-05-24_16:26:02 Nmea:250524162600,(1,2),(5*******,1******,84),(23170,0),(13,10),(8,5,6)[0]
2025-05-24_16:26:02 Sv1/4:{1,28,135,33,1};{3,52,74,44,1};{4,68,154,35,1};{6,37,303,46,1}
2025-05-24_16:26:02 Sv2/4:{9,39,203,33,1};{11,5,307,40,1};{12,2,327,30,0};{17,33,227,40,1}
2025-05-24_16:26:02 Sv3/4:{19,41,261,41,1};{28,12,32,43,1};{31,23,57,41,1};{2,2,137,0,0}
2025-05-24_16:26:02 Sv4/4:{25,0,358,0,0};{0,0,0,0,0};{0,0,0,0,0};{0,0,0,0,0}
2025-05-24_16:26:03 Nmea:250524162601,(1,2),(5*******,1******,84),(23170,0),(13,10),(8,5,6)[0]
2025-05-24_16:26:03 Sv1/4:{1,28,135,32,1};{3,52,74,44,1};{4,68,154,35,1};{6,37,303,44,1}
2025-05-24_16:26:03 Sv2/4:{9,39,203,35,1};{11,5,307,42,1};{12,2,327,31,0};{17,33,227,42,1}
2025-05-24_16:26:03 Sv3/4:{19,41,261,42,1};{28,12,32,39,1};{31,23,57,43,1};{2,2,137,0,0}
2025-05-24_16:26:03 Sv4/4:{25,0,358,0,0};{0,0,0,0,0};{0,0,0,0,0};{0,0,0,0,0}

Vehicle journey highlighting UK activity

Mapping these coordinates highlights the vehicle's full journey across countries. While most movements follow expected routes, during its time in the UK we observed a cluster of GPS points at a single location, standing out from the usual travel patterns. This anomaly suggested a significant event in the vehicle’s lifecycle.

To investigate further, we performed a simple OSINT search using the location and date. This led us to a public Facebook post showing a car accident at the exact same location and date. The images and context perfectly matched the GNSS data, explaining why multiple GPS points were recorded at the same position.

Forensic data to real car accident

Conclusion

What started as a simple hardware check, a firmware dump, and a first security review quickly became a full forensic and cybersecurity investigation.

The telematics unit was more than a device, it was a data archive. Even after a vehicle is sold, damaged, or dismantled, logs and system events can remain accessible.

By combining forensic analysis and reverse engineering, raw technical data became real-world insights. GPS logs allowed us to reconstruct the vehicle’s journey and link it to a real accident. At the same time, reviewing configuration files and system logs highlighted security weaknesses.

Lessons Learned:

• Sensitive data can remain in ECUs after accidents or resale;
• Reverse engineering + OSINT can uncover real-world events;
• Embedded automotive systems often have overlooked security issues.

This work reflects what Quarkslab does in automotive and embedded security. We help companies investigate devices, extract forensic evidence, and assess system security:

• Need forensic analysis on automotive or embedded systems? Contact us.
• Want to improve the cybersecurity of your automotive products? We support you from investigation and analysis to full technical assessment.