From hardware analysis to OSINT: how we retrieved information about a BYD car crash by analyzing the TCU embedded memory.
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:
[Data block] |Padding| [Data block] |ECC] [Data block] |Padding| [Data block] |ECC] ... [Padding 0xFF]
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.
If you would like to learn more about our security audits and explore how we can help you, get in touch with us!