▄▄▄▄      ▄▄▄▄     ▄▄▄▄                                    
█▓    █▓  █▓    █▓  █▓    █▓                                 
█▓    █▓  █▓    █▓  █▓▀▀                                     
▀▀    ▀▀    ▀▀▀▀    ▀▀       ▀	█▀█  █▄  █▀█  ▄▄▄█  ▀█       
						█ N    I     █ N           J     A   


▀ Car Forensics - A Starting Point ▀

** Note: this is just a random rant/blog and opinions are my own ** The term computer forensics has slowly but quite aptly been eroded and replaced with Digital Forensics. A term that has grown to mean a plateaued of various niche areas such as Mobile Phones, Event Data Recovery Units (Airbags), Tablets, Smart TVs, Smart Watches, Internet of Things devices and of course cars in general. When we say car forensics what do we really mean? We are generally talking about infotainment units, some times airbag units and rarely but slightly more increasingly units like "OnStar Gen 10". systems with embedded SIM cards that phone the data home. Majority of policing units, intelligence, security and research labs are all doing the same thing. 1 : We need forensics for cars, there be evidence in them 2 : by commercial product not designed for the market in your country. 3 : notice unit is very limited look for other methods. 4 : talk to the community at which point you will be directed to someone who might be able to help. The commercial product in question is well known and for reasons of my own i will not name them, but everyone actively trying to do car forensics right now will have no problems guessing. Although it is a good tool as a starting point its limitation quickly out way it's usability. So how should you read such devices? Due to the nature of this work from this point forward the examples will be vague on parts on purpose, but all meaningful and useful information that can be provided will be. Thus moving on to our first example.

▬ Car Forensics Example 1 ▬

OnStar Gen 10. A simple unit with a well designed PCB. you open the blackbox and find out your new shinny tool doesn't support it. where do you go next? Well OnStar Gen 10 is only module your likely to find in the United Kingdom, It has a single FLASH chip on the front of the main PCB board. It is a 128MB Flash CFI compatible chip and if you google the chip name the first/second link takes to you to the correct datasheet, then just use your favorite CFI Flash reading method and happy hunting for those elusive but useful bits of information. IT is worth noting there are multiple versions of OnStar one using a Spansion Flash and one using a MXIC Flash both are CFI compatible, provided below is an image of a OnStar Gen10 PCB and the pin out for the flash chip, in the case of the image a Spansion but it shares the same pinout as a MXIC Flash chip. At this point you have a forensics image, soldered some wires, make some things and are ready to get all those bits of useful information/intelligence, in the case of the example above the how and whys aren't provided. How ever in the case study that will be presented in this article/paper/rant/thing it a lot more will be. So when we are doing car forensics what information are we looking for, more importantly what are the main questions and issues we need to be aware of? Every unit will be slightly different. Users never all pick the same features or settings and information available will differ. More units are unknown and unsupported than currently are. You are back in the good old days of early mobile forensics which is dominated by the rift box/jtagging and cellbrite. What skills and tools do you or your lab need to be able to effectively in a costly and time manner start doing Car Forensics? First thing you would have or are planning to do is buy the unnamed commercial tool, and or the same unnamed commercial tool for airbag recovery. These are designed for the American market. They support a lot but sadly the unsupported list is much greater. Even on systems they support information is missed or simply not provided. So what information should you expect to be able to get from a car? All depends on the features the first owner wanted installed. Bluetooth pairing is becoming more and more common, thus was this phone connected to this car is the question that has the highest success-rate of being answerable. Next question can i see if a text message was received/sent or phone call made, this is the second question that potentially can be answered, and the final one is what music were they listening to at a certain time? These are the 3 main questions that Car Forensics have the highest chance to answer, But in all likely hood your thinking or saying to yourself, wait a minuet i know they can store more information than that, and yes your correct they CAN, not all will. Best case scenario you find yourself in a situation where the following is possible.

▬ Car Forensics Example 2 ▬

The story of a BMW 320D infotainment unit. In 2016 a case appeared that had two main questions, Was the car in use at X time on Y date, and can you provide possible GPS/Location for the car that correspond. This resulted in learning all about BMW, QNX, QNX6FS and binary blobs. To make a long story short answers to both questions was Yes. for the purpose of this a image taken from a research car is used and not the evidence that this work had to process. How to obtain the infotainment unit and the initial image? Where the music CD gets inserted into the bash, behind is a small gray box that the CD would live within. In that on the top under the CD drive is a standard Desktop HDD which is password locked (Unlock with PC3K or visit forums such as MHAuto or Digital-Kaos to find out how to unlock). This hard drive contains multiple QNX6 partitions, of which the following information can exist and contains useful information. - Partition2:/conn/contactbook/contactbook_.db [sql lite db] Contacts from Bluetooth sync/sharing - Partition2:/conn/pim_bt/pim*.a & pim01.db [sql lite db] use pim01.db to identify which pim########.a belongs to which phone, after which browse each .a file associated. One point of interest is not all phones sync the same data, but potential information that can be obtained is as followed. - Emails : from, to, subject, content, date & time - SMS : from, to, subject, content, date & time, inbox or outbox, read on car, read on device. - Calender : generic calender information, what and at what time. Even if a phone has been desynced information that had been obtained will still be present. - Partition3:// Music with time and date stamps - Partition3:/backup/mme [sql lite db] The table mediastores contains potential useful information, such as last time a phone syncd its music with the system.

How To Mount QNX?

This is a basic guide just to help those not use to linux, figure out how to mount a QNX FS. - First find the phyiscal name of your drive Connect a clone drive physically to attach the image virtually via a local loopback you can use dmesg to identify location of your connected drive. as can be seen in the image below. as im using Qubes as my main OS all drives apppear as xvd* for me, but likely you'll have a sd* instead. - List avaliable partitions Using the command fdisk we can list all avaliable partitions. If you ran fdisk -f "imagefile.bin" instead of fdisk /dev/DISK, then it is important to make a new of the sector size and offset of each partition. the partition information is obtained by press p as can be shown in the image above. - Mounting the Partitions Before we mount we need point to mount each partition to, this is achieved easily by using mkdir to make a folder to mount our partitions to. after we have our mount points we can do the following to simply mount the partitions. If however you didn't connect a cloned drive via a write blocker and are using a file and want to do a local loop back to mount each of the partitions then you need to use the following command instead.

mount -o loop,offset=xxxx /path/to/disk.bin /mnt/part1

Offset is calculated as offset from fidsk * sector size, this will allow you to mount as a local-loop back. - Viewing files The easyest way to view each partition, without permssion issues and various problems is to run

"sudo nautils /mnt &"

At this point you have the image mounted and can begin to look at interesting files as mentioned above, but what files can be now access and process that commercial tools cant? and how do we go about anwsering the two questions of can we establish location and utility? In this case the GPS wasn't used and thus no artifacts were found for recorded journeys. What was found was the conEventLoggin.bin and multiple TPEG .dat files. Although conEventLoggin.bin sounds interesting, why should you care about TPEG (Traffic information?) Well TPEG format although can be purchased for a nice price is not publicly or freely available. Below is a graph of the full structure of the data contained within a TPEG file, This file was generated by reverse engineering the binary blob and using the limited information available online. The part of importance about this data is that TPEG data is unique based on location of the car. the more critical the incident the further afield they can be detected/displayed from. the less critical the small the area of disclosure. Thus the middle of a collection of Traffic events is a ruff estimate of the location of the car the files were obtained from.
A large amount of work went into making a tool to generate this map. but this is the first basic example of data that commercial tools at present cant access. The second piece of information to answer the question of utility is obtained from the conEventLoggin.bin file. Within this file is a very simple structure. Location: Partition 2, "/conn/conEventLoggin.bin"
The IDs that have been figured out and are of interest is Engine on, Engine Off, Someone used the Radio. - 512 = Engine On - 768 = Engine Off - 2584 = Radio Setting Changed - 2328 = Radio Setting Changed A research car was used and notes were made during a journey, from which this information could be derived. This helped to find these values. Allowing for this information to provide a answer to the question of utility. Was the Car in question used at X time on Y date. Of course processing all this requires effort and thus the script needed to generate it is available from the following link ( BMW conEventLog Parser ). This information was used and the following image was generated by the parser.
This image tells us when the car was and was not in use, it helps to see pattern of use. or to put it another way, the generated heat map is based on the engine on and off's from the eventlog this means although we cant say where the car was, when it's engine was on or off we can say for what periods of time it was on and off. and establish a use pattern of the vehicle. Additionally if we see two on IDs with no off ID inbwtween this is caused by the auto-start/stop function, which kicks in when the car stops for a period of time say at traffic lights, traffic or other reasons.

▬ So What does this mean? ▬

Car forensics is a unknown, even the best commercial tools have no idea what data really exists. It is a massive area of interest and research. Thus for this purpose based on my experience i provide the following information. of tools i use, software and I hope the above help shed some light on possibilities of car forensics, additionally it is further proof that when you sell your car there is no garantee your data is deleted or how much was stored and left upon the infotainment unit, potentially a issue for EU right to be forgotten?

▬ Car Forensics and You! ▬

If you've read this far likelihood your already doing this, looking to start doing this or simply want tips and advice. Commercial tools are a good starting point but that is all. So what tools, skills, knowleage do you need? The first place to start is tools, thus follows is a list of tools and disposable items I use. - JTAGULATOR - LynxJTAG Adatper (useful for arm only) - Bus Blaster (universal tool, JTAG + Flash) - UUPROG (motoroal CPUs and flash chips) - PC3K UDMA/Flash - Weller Soldering Iron + multiple fine tips - Bond Wire + Lots and lots of wire(s) - Weller Desoldering Station / Hot air gun - FluxCleaner - Liquid Active Flux - Silver solder - Quick chip solder paste - Microscope (possibly linked to a flat screen) Second is Software. - Ubuntu (hardware or VM to read QNX[6/4]fs) - FTK Imager - SQL Lite Viewer - WinVi32 / WinHex - Kaitai (used to make graphs provided) - OpenOCD - FlashROM Finally Skills and Knowledge. - How to Find / Connect to a JTAG Interface - How to read Flash via SPI/CFI - How to recognize chips of interest on a board - How to Solder / Desolder Car Forensics at present is a undefined area, there is no CORRECT way to do it, there is no BEST way to read/obtain data. majority of cases revolve around using JTAG, Chip Off or reading a standard HDD. The most commonly used format is a SQL Lite database file. Not all systems save user data on HDDs when present some will store it on a flash chip. What are the most commonly used operating systems and file systems? Android Auto, QNX and embedded windows. which means you could face EXT, Fat, QNX[4/6]FS, NTFS or other. How best to obtain units to research/practice/develop a best practice approach on? Scrap Yards setup a X amount per unit agreement regardless what unit is.

▬ Who Am I? ▬

I am by no definition an expert I currently working as a manager at a well known organisation. I was a former research associate at a university. I've worked upon car forensics both infotainment units and airbags for a number of people. My Degree was in computer forensics and volatile memory analysis, and currently awaitng my viva for my PhD. Sig: - md5sum: b254dd7da1f1463da566b48b09c43aab - sha1sum: 32c85466dcabe6aa87d09df6af12f50f6ab971b6 - date: 2017/06/30 - upated: 2021/07/14 Contact via: - IRC: Dr.Nia @ irc.darkscience.org/#darkscience - Twitter: @Dr.Nia - Discord: DigitalForensics @ Dr.Nia