The latest in our new Case Work series highlights why forensic tools can only take you so far. Android phones store a wealth of information - often overlooked by the tools - but of great use to those analysts who know where to look and how to extract it.
CCL received a submission from a Police Force following their own internal examination. They had used the standard forensic tools XRY and Cellebrite UFED Physical Analyzer to seek evidence in relation to a suspect using a mobile phone whilst driving. The suspect had caused a fatal Road Traffic Collision (RTC) and the driver of the car was suspected of driving whilst using a mobile device at the time.
It was initially essential to confirm the exact time and date of the RTC and the timeframe of interest to the Officer in Charge of the case (OIC). It was equally essential for CCL analysts to interpret the time/date of the RTC in relation to Coordinated Universal Time (UTC). UTC is the format by which digital devices record time/date of information. It refers to the time on the zero or Greenwich meridian and is an internationally coordinated time scale which takes into consideration the different time zones in operation across the World and any Daylight Savings Time (DST) offsets applicable to individual areas.
For example, a RTC which occurred in the United Kingdom at 13:30 01/06/2020 would need to have the timezone (zero adjustment) and DST (+01:00 during British Summer Time) offsets considered. With the UK being one hour ahead of the Greenwich meridian during Summer, this would need to be accounted for in determining when the RTC occurred in UTC. 13:30 01/06/2022 is 12:30 01/06/2022 in UTC. Where timings of events are so critical, it is important to consider such variables in date-range searches, filters and reporting of evidence in the case.
CCL performed the extraction of the mobile phone using Cellebrite UFED software to recover and parse as much user data as possible for investigation. Initially, a search for the ‘low hanging fruit’ was conducted:
- Communications (calls, SMS, MMS, chat messages, emails)
- Media files (images, videos)
- Internet browsing (internet history, bookmark creation)
This approach would identify any evidence created around the time of the RTC which the forensic tool has recovered. No evidence was found of activity around the time of the RTC.
A timeline search was conducted in order to assess whether any other evidence recovered by the forensic tool showed phone usage around the time of the RTC. No evidence of activity was found.
The CCL analyst turned their attention to evidence that the forensic tool had not identified or had overlooked. Android phones store a wealth of information not considered relevant by forensic tools, which if understood and applied accurately in context to the user activity, might be useful to digital investigations. With knowledge of the storage artefacts of smartphones, the internal file system was exported for a deeper dive into the files which might have been modified around the time of the RTC. This directed the analyst to several application files and Power Saving/Screen Activation logs.
Application files:
A system configuration file suggested the phone microphone was enabled at the time of the RTC. Although interesting information, this wasn’t entirely indicative of user activity on the phone.
Databases containing Gmail, Facebook and Android News Feed data were investigated as having been modified around the time of the RTC. Upon investigation, no confirmed user activity was found.
The WhatsApp database was investigated. It showed messages having been delivered around the time of the RTC. A flag within the database showed that messages remained as unseen. This suggested the user had not actively opened the incoming WhatsApp messages around the time of the RTC.
Power Saving / Screen Activation log files:
Investigation of several battery statistics and power saving cache cleaner applications turned up no discernible evidence.
A database file containing evidence of active screen sessions contained evidence of four active screen sessions around the time of the RTC, one starting three minutes before the RTC and ending two minutes after.
Upon discovering this evidence, it was important to highlight and accept that the creation of these records was not fully understood, and there was a risk in attributing user activity to this information without understanding what user activity was required to trigger these records being created.
A test device was purchased and set up to mirror the Android version on the exhibit. The application was installed and a series of tests performed in order to record screen activation events and compare these known events to the data recorded in the database file. The phone was extracted and the test data reviewed to confirm what user action had caused this data to be populated in the way it had been recovered from the exhibit.
It was concluded that accessing the device screen by pressing the power button was the only action required to trigger this database to be populated and register a screen session event in the database. Although new notifications and incoming communications caused an active screen session of a few seconds, there were no circumstances when the phone screen was off that caused a screen session of the length of time seen on the exhibit.
It was reported to the OIC that it was likely that the phone screen was active for the entire period of three minutes prior and two minutes post the RTC.
Our experts are on hand to learn about your organisation and suggest the best approach to meet your needs. Contact an expert today.
Get in touch