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

From hardware analysis to OSINT: how we retrieved information about a BYD car crash by analyzing the TCU embedded memory.

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...