This post contains my findings from an analysis of a Ford Sync first generation module I undertook as part of my master’s project at University of South Wales into vehicle forensics. This was completed under the supervision of Gareth Davies and Amilia Perera who are part of the Information Security Research Group (ISRG) and the Computer Forensics department at the University.
Most modern Ford vehicles from 2007 onwards come with what is known as a Ford Sync module. The Sync is an in-vehicle communication and entertainment system. With features including the ability to connect devices via Bluetooth, make phone calls, send and receive text messages, and play music, there is a lot of potential for data of evidential value to be recovered from these modules.
The Ford Sync Gen 1 module itself is a small, rectangular black box. Removing the lid via the removal of four screws reveals the PCB.
Through some research, a teardown was found of a Sync Gen 1 by Electronics360 (see here: http://electronics360.globalspec.com/article/3498/ford-sync-1st-generation-teardown). They identified the module as having a 2GB NAND flash memory chip. This is where all the user data is stored.
To extract the data from the memory chip I performed a JTAG extraction using the vehicle forensic tool iVe by Berla. iVe supplies all the required jigs, cables and JTAG boxes and has step-by-step instructions of where the JTAG ports are located and how to set everything up for extraction. Once all the jigs were attached, a power supply running at 12V was hooked up to provide power and the extraction started. iVe gives the option of a logical or physical extraction; physical was selected in this case. Being a JTAG extraction, it took a long time (12 hours to be exact) so it may be worth performing ISP or Chip-Off acquisitions in future to speed up this acquisition process. I’m not certain why but iVe failed to generate hashes for the extracted data upon completion so before I started my analysis I generated both MD5 and SHA1 hashes using HashMyFiles to maintain good practice.
With the JTAG extraction complete and hashes generated, the analysis could begin. The Ford Sync uses the Windows CE operating system; a version of Windows designed for embedded devices. One partition was found, formatted in TFAT16 (Transaction-Safe FAT File System). Within the root directory of this partition is one directory – _TFAT_HIDDEN_ROOT_DIR – which contains nine directories. These nine directories are ‘Application Data’, ‘Applications’, ‘Documents and Settings’, ‘GrammarFSM’, ‘MediaCache’, ‘PresetStore’, ‘Temp’ and ‘Windows’.
The first two directories, ‘Application Data’ and ‘Applications’ contained little data. Only one file was found across these two directories – ‘speng.rgs’. In this file, there are multiple references to ‘Nuance’. Through some research, this appears to be a company that provides speech applications. These two directories will most likely contain more data in the Ford Sync Gen 2 models, otherwise known as AppLink. This introduced the ability to use apps on a user’s phone through the module. So data about app usage is likely to be found here.
The ‘Documents and Settings’ directory contained the Windows CE equivalent of registry hives – .hv files. The tool HVEdit was required to view the contents of these files as they are not standard registry files. Nothing of interest was found in these hives, though again, later versions of the Sync modules may contain more relevant data as more features were added.
The next directory, ‘GrammarFSM’ contained multiple files with the extension .fsm1. Viewing these files, they appear to contain information related to devices that were previously connected to the module. What seems to be contact names appear throughout the files as well as references to artists and songs. There is no indication in these files what device this information is from.
The ‘MediaCache’ directory contains information about what devices have been connected and music that was on that device. This information is found in the multiple ‘Source’ files with the extension .dat.
Each source file represents a different device. On this Sync module, four devices were identified – a Kingston hard disk, LG Nexus 5 phone, an iPod and another hard disk which had no make or model. The LG Nexus 5 and the iPod both have serial numbers associated with them in these files. There are also some files in this directory with the name ‘NowPlaying’, these are also .dat files. There was no data in these files but the name suggests any media that is played through the Sync would be found in these files.
The next directory will be one of the most interesting to a forensic investigator, ‘TextMsgApp’. The name alone indicates what can be found here, that is, text messages. There is one file in here, ‘TextMessages_bcf5ac848ec4’. The 12 length alphanumerical string in the filename is the unique Bluetooth address associated with the device the text messages came from; in this case, the LG Nexus 5 phone identified previously. There is no indication of the status of the text messages (read or unread), and there are no date and time stamps associated with them either. I did come across an issue with viewing the text messages in iVe as can be seen in the picture below. iVe is able to identify the number of text messages on a system but failed to display the actual contents of the text and who sent it most of the time. This information can be retrieved by manually parsing through the text message file, however, there is a lot of null bytes throughout the file so this can be a rather time-consuming process; especially if there are a lot of text messages.
The final directory, ‘Windows’ contains seven directories. They are as follows – ‘DumpFiles’, ‘ExtraDumpFiles’, ‘Installer’, ‘LogFiles’, ‘phonebook’, ‘Profiles’ and ‘UserLexicons’.
Most of these directories contain little of interest; some of them containing no information at all (ExtraDumpFiles and Installer) and some containing what appears to be standard system information (DumpFiles and UserLexicons).
Looking at ‘DumpFiles’ directory first. Two files are found – ‘Ce021203-01.kdmp’ and ‘Ce021203-01.RTL’. The .kdmp file is a default Windows CE file containing data about system crashes. The .RTL file appears to be some form of log file containing information related to an iPod that was connected to the system, indicated by the protocol name IPDSVC appearing throughout. In this file an instance of some music being played was found, however, there were no date and time stamps associated with this.
The ‘LogFiles’ directory contains two files – ‘MsgLog1.txt’ and ‘MsgLog2.txt’. These are both log files and contain some interesting information. According to iVe, these files contain information relating to when the Sync module was powered on and off along with a run time of the power event.
These log files also store information about the devices that were connected to the system including the previously identified LG Nexus 5 phone and iPod. There are further entries relating to the Nexus 5 elsewhere in the log files. These are the Bluetooth connections made by the phone and contains the unique Bluetooth number that is used in the filenames associated with the Nexus 5.
The ‘Profiles’ directory contained Internet Explorer files and directories such as index.dat, History.IE5, Cookies and Temporary Internet Files. There was no information of significance found in these files and directories; and they appear to be default files in Windows CE, however, as this is a 1st Gen Sync, internet capabilities were not present and so more recent versions or even modules which have seen more use may contain information of evidential value.
The final directory under ‘Windows’ is ‘phonebook’ which contains three files – ‘CHbcf5ac848ec4.xml’, ‘GlobalPhonebook.txt’ and ‘PBbcf5ac848ec4.SYN’. As you will notice, the previously identified 12-digit alphanumerical number – bcf5ac848ec4 – the Bluetooth number for the LG Nexus 5, is part of the filename for two of the three files. The CH in the first file indicates this as being Call History with the PB indicating Phone Book.
Starting with the Call History file (CHbcf5ac848ec4.xml), the file contains the device id and three call history types; 0x10000, 0x20000 and 0x40000. These are Incoming, Outgoing and Missed Calls respectively. The contact name and phone number are stored as part of call history, however, like the text messages, there are no date and time stamps to be found.
Moving onto ‘GlobalPhonebook.txt’, this appears to just store all the contacts from the associated device. There are no phone numbers associated with the contacts. Each of the contacts is assigned a number starting from 0, incremented by 1 for each contact.
The final file under the phonebook directory – PBbcf5ac848ec4.SYN – is another phone book file but this contains the phone numbers associated with each contact. The number of entries in this file is greater than in GlobalPhonebook.txt as some of the contacts have multiple phone numbers associated with them.
So as can be seen, the Ford Sync module has significant information that can be pertained to the driver or passenger of a vehicle. This is a Gen 1 model and so further investigation of the AppLink (Gen 2) and the recently released Gen 3 Sync modules will help paint a more complete picture of the Ford Infotainment ecosystem. It is important to note that this system was bought second hand and it is unknown how much use the system had seen. If known data is able to be placed on the system a more complete and comprehensive picture of what data is available on these systems for forensic investigators could be established.
NOTE: This is a section of an upcoming academic journal paper which will cover the total findings of research that was carried out into the area of vehicle forensics.
James G Digital Forensics 