DIGITAL FORENSIC RESEARCH CONFERENCE

Investigating Evidence of Mobile Phone Usage

by Drivers in Road Traffic Accidents

By

Graeme Horsman and Lynne Conniss

From the proceedings of

The Digital Forensic Research Conference

DFRWS 2015 EU

Dublin, Ireland (Mar 23rd- 26th)

DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics

research. Ever since it organized the first open workshop devoted to digital forensics

in 2001, DFRWS continues to bring academics and practitioners together in an

informal environment.

As a non-profit, volunteer organization, DFRWS sponsors technical working groups,

annual conferences and challenges to help drive the direction of research and

development.

http:/dfrws.org

Investigating evidence of mobile phone usage by drivers inroad traffic accidents

Graeme Horsman*, Lynne R. ConnissNorthumbria University, Newcastle-upon-Tyne NE1 8ST, UK

Keywords:Digital forensicsRoad Traffic Act 1988InvestigationMobile phone forensicsDirect activityPassive activityInteractive communication

a b s t r a c t

The United Kingdom is witnessing some of the highest volumes of motor vehicle traffic onits roads. In addition, a large number of motor vehicle traffic accidents are reportedannually, of which it is estimated that a quarter involve the illegal use of a hand-heldmobile device by the driver. Establishing whether mobile phone usage was a causal fac-tor for an accident involves carrying out a forensic analysis of a mobile handset to ascertaina timeline of activity on the device, focussing on whether the handset was used imme-diately prior to, or during, an incident. Previously, this involved identifying whether SMSmessages have been sent or received on the handset alongside an examination of the calllogs. However, with advancements in smartphone and application design, there are now anumber of ways a driver can interact with their mobile device resulting in less obviousforms of evidence which can be termed as ‘passive activity’. This article provides ananalysis of iPhone's CurrentPowerlog.powerlogsystem file and Android device ‘bufferlogs’, along with their associated residual data, both of which can potentially be used toestablish mobile phone usage at the time of, or leading up to, a motor vehicle accident.© 2015 The Authors. Published by Elsevier Ltd. This is an open access article under the CC

BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Introduction

Within the United Kingdom (UK) in 2013, 183,670 roadtraffic casualties were reported, 8% of which were chil-dren, whilst approximately 2% of crashes resulted in fa-talities (Department of Transport, 2014). Further, trendshighlighted by the World Health Organisation (2011)suggest road traffic injuries will rise to constitute thefifth largest global cause of death by 2030. In light of thesestatistics, with around 35 million licensed vehicles inoperation on UK roads (Department of Transport, 2013),there seems to be an increasing need for investigation intocausal factors that put drivers at risk of road trafficaccidents.

It is vital to consider all possible factors when assessingevents leading up to and during motor vehicle incidents, inorder to establish the nature and order of events andimportantly, whether a particular party is at fault. Althoughstatistics identifying specific use of mobile phones duringroad traffic accidents in the UK is sparse, it is estimated thatin the United States, drivers were using mobile phones inalmost a quarter of all reported incidents (Pless and Pless,2014; National Safety Council, 2014; Northern IrelandStatistics and Research Agency, 2013). These figures proveconcerning, since the ability of a driver to operate theirvehicle proficiently is significantly decreased whilst using amobile device, thereby increasing the chances of an inci-dent or accident occurring on the road (Horberry et al.,2006). Further, the driver's attention is diverted from themain goal of ensuring their safety and that of othersthrough effective driving, towards a secondary activity,termed as ‘driver distraction’ (Hosking et al., 2009).

* Corresponding author.E-mail address: g.horsman@northumbria.ac.uk (G. Horsman).

Contents lists available at ScienceDirect

Digital Investigation

journal homepage: www.elsevier .com/locate/d i in

http://dx.doi.org/10.1016/j.diin.2015.01.0081742-2876/© 2015 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Digital Investigation 12 (2015) S30eS37

Issues facing a driver arising from mobile device usageinclude, but are not limited to, the following:

! Restriction of sight; limiting the driver's ability to surveythe road, potential obstacles or changes in traffic flow,since their line of vision is focused on the handset (Nasarand Troyer, 2013).

! Reduction of concentration levels and situationalawareness (Nasar and Troyer, 2013).

! Slower reactions times during adverse events (The RoyalSociety for the Prevention of Accidents, 2012), whichcould result in as much as a 50% reduction in responserates (Think!, 2014).

! Failure to maintain a high standard of driving etiquette,resulting in acts such as tailgating or improper roadposition (The Royal Society for the Prevention ofAccidents, 2012).

RAC (2014) surveys indicate that 75% of motorists haveobserved other drivers talking on their mobile phoneswhilst driving, however, only 8% admit to doing so them-selves. In turn, surveys undertaken outside of the UK (yetstill in jurisdictions where mobile phone usage whendriving is illegal) by White et al. (2010) indicate that over60% of participants professed to interacting with theirmobile phone whilst driving without the use of a hands-free kit. Similarly, there are a growing number of youngerdrivers with an increased dependency on mobile devicesresulting in them frequently being used whilst driving toaccess social media (Weller et al., 2013).

Due to the size of these devices it is likely that manycases remain unreported due to successful concealmentof usage of the device whilst driving. The challenge sur-rounding mobile phone-related vehicle accident in-vestigations lies with proving a device was used leadingup to or during an accident, thereby ultimately becominga causal factor and an element with which to potentiallyhelp establish blame. To achieve this requires theforensic analysis of the mobile handset and its residualdata.

This article provides an analysis of UK law governingmobile phone usage whilst driving, followed by the dis-cussion of the role of a mobile phone forensic analyst inroad traffic accident investigations. An examination ofiPhone's CurrentPowerlog.powerlog system file andAndroid device buffer logs will be presented and theirrelevance for detecting user activity on mobile handsetsoutlined.

UK law and mobile phone forensics

Since December 2003, the act of using a hand-heldmobile device whilst driving has been prohibited withinthe UK. Amendments to the Road Vehicles (Constructionand Use) Regulations 1986 (RVR86) via the Road Vehicles(Construction and Use) (Amendment) (No. 4) Regulations2003 have now introduced the following regulationunder 110(1) RVR86:

“No person shall drive a motor vehicle on a road if he isusing (a) a hand-held mobile telephone”

It is important to note that interaction with a mobiledevice via a hands-free device is legal provided its usagecould be proven. Further, government guidance states thathands-free phones, two-way radios and satellite navigationdevices can be legally used whilst driving, but if policebelieve the driver is being distracted and failing to suffi-ciently control their vehicle, prosecution may still occur(Gov.uk, 2014). Justice Lloyd Jones in R v Curtis (Regina vPhillipa Curtis [2009] EWCA Crim 1003) stated thatdriving requires 100% of the driver's concentration, and inthe recent case of R v Jaswinder Arora (Regina v JaswinderArora [2014] EWCA Crim 104), it was highlighted thateven drivers using hands-free kits are still up to four timesmore likely to be distracted and cause an accident. Inaddition, RVR86 regulation 110(6) (a) defines a device asbeing hand-held given the following:

“A mobile telephone or other device is to be treated ashand-held if it is, or must be, held at some point during thecourse of making or receiving a call or performing anyother interactive communication function”.

On initial inspection, the term ‘interactive communica-tion function’ appears ambiguous given the array of featuresand functionalities of the modern mobile device/smartphone and associated applications. Therefore, it is useful toexplore what this means in more depth.

What constitutes ‘interactive communication function’?

RVR86 regulation 110(6)(c) provides guidance foridentifying features and functionalities that may beinvolved:

““Interactive communication function” includes thefollowing:

(i) Sending or receiving oral or written messages;

(ii) Sending or receiving facsimile documents;

(iii) Sending or receiving still or moving images; and

(iv) Providing access to the internet.”

Upon interpretation of RVR86 regulation 110(6)(c), andparticularly the wide scope of regulation 110(6)(c)(iv), itwould appear that almost all interaction with the devicewhilst driving is prohibited. Given that most smart phonesnow maintain fairly constant communication with datanetworks in order to update applications automatically(unless disabled by the user), even the act of waking ahandset from a sleep state to view push notification alertson the handset's display (see Section ‘Interacting with thescreen lock’ below) could be deemed an interactivecommunication function. However, proving that thesesubtle interactions have taken place on the device whilstdriving may be difficult.

Categorisation of offences

The offence of using a mobile device whilst driving alsooverlaps with offences of greater severity laid out in theRoad Traffic Act 1988, notably the offence of causing deathby dangerous driving under Section 1 and causing death by

G. Horsman, L.R. Conniss / Digital Investigation 12 (2015) S30eS37 S31

careless or inconsiderate driving, under Section 2B. To beguilty of the offences, the behaviour of the driver is judgedagainst that of ‘the careful and competent’ driver, a hypo-thetical representation of what would be required toensure safe conduct. Research has frequently highlightedthe dangers caused by mobile phone distraction but unlikethose under RVR86 regulation 110(6)(c), where specific actsof interactive communication must be proven, for a pros-ecution under Sections 1 and 2B of the Road Traffic Act1988, any trace of mobile phone usage or handling by adriver in a serious road traffic accident may suffice.

Mobile phone forensics

Various solutions have been proposed as methods ofdeterrence and prevention (Artan et al., 2014; Yang et al.,2011); yet, standard UK motor vehicles contain no stan-dard or additional features for regulating the use of mobilephones whilst driving. As a result, law enforcement officialsin the UK will seize all mobile devices from the scene ofserious traffic accidents as standard protocol (Associationof Chief Police Officers, 2014). At this point, a mobilephone forensic practitioner is tasked with establishingusage patterns and providing information identifyingwhether a driver has potentially interacted with the deviceprior to or during the motor accident. To achieve this re-quires establishing the timeframe of the accident andevents immediately beforehand, to allow correlation withdevice timestamps and usage. The former can be donethrough the utilisation of multiple sources such as witnessstatements, police records, emergency service call logs andCCTV recordings (Redelmeier and Tibshirani, 1997).

The field of mobile forensics has developed significantlyover the last 10 years and now, various extraction methodssuch as logical, physical, J-Tagging or chip-off extractions,allow practitioners to gain access to a large quantity ofresidual data on the handset, both live and deleted,including protected operating system files. At the close ofan investigation, practitioners can frequently establish thefollowing types of evidence, which may indicate, pro-hibited usage of a mobile phone whilst driving:

! SMS messages, received, sent, drafts: both live anddeleted;

! Make/receive calls, including live and deleted callrecords;

! Access to social media applications for the purpose ofcommunication (e.g. Facebook, Snapchat, Twitter etc.);

! Sending and receiving emails, Internet browsing.

These typesof ‘direct activity’ involve interactionwith theoperating system of the device, executing events that leavebehind clear physical traces that the userhas interactedwiththeir handset. A typical and obvious example of direct ac-tivity would be when a user sends a message from theirdevice, leaving a record in their sent box, including anassociated timestamp. However, it is possible for a user tooperate their mobile phone and leave behind less obvioustraces of their actions throughwhat this article coins ‘passiveactivity’, which may still contravene UK driving legislation.

Passive activity on a mobile phone

It has been established that all forms of interaction witha mobile handset by a driver whilst driving, could lead toprosecution. Whilst the use of interactive communicationfunctions on mobile devices results in direct and traceableinteractions with system files and application data, otherforms of handset use may result in little residual data orchange to system files and as such, these types of activitymay be defined as being ‘passive’.

Passive activities, such as viewing the contents of theSMS inbox, without disturbing the status of any unreadmessages, are generally harder to detect yet may providesufficient distraction for a driver to cause a serious roadtraffic incident, but then go unpunished if evidence of theactivity can't be sufficiently established.

Whilst driving, any interaction on a mobile device withan application that provides access to the Internet is pro-hibited. Many social media and news applications wouldfall into this category. For example, Twitter may beconfigured to automatically update content via availablenetwork connections. The passive act of scrolling throughand viewing a Twitter feed whilst driving would breach theaforementioned legislation, yet determining when thisapplicationwas accessed, how frequently and how long thedriver potentially spent viewing it, in the run up to an ac-cident, may prove difficult. Oulasvirta et al. (2012) indicatethat some of the most frequently carried out tasks on adevice include checking social media updates and readingnews or articles. Such activities are often part of habitualand autonomous actions, triggered when the user is bored,killing time or subject to lapses in concentration(Oulasvirta et al., 2012). These are all actions, which mayremain undetected during analysis of the device as practi-tioners may look for more obvious traces of user interactioninvolving communication.

The consequences of failing to detect passive activity onthe handset may lead to a failure to prosecute drivers formobile phone-related offences. Therefore the followingsections below will now provide the findings of an inves-tigation into the discovery of evidence highlighting userinteraction for a given time frame on iPhone and Androiddevices, such as may be required for the purposes of roadtraffic accident investigation. The devices were chosenbased on the dominant shares of the mobile phone marketboth handset types maintain (Statista, 2014).

Analysis of an iPhone

This investigation will focus on the iPhone's Cur-

rentPowerlog.powerlog system file and the PLArch-ive directory, both located at /var/mobile/Library/

Logs/ and accessed via a physical extraction of thehandset. The test device was an iPhone 4 running iOSversion 7 which was analysed using Microsystemation'sXRY to acquire a physical extraction of the handset.

CurrentPowerlog.powerlog

The CurrentPowerlog.powerlog is a system fileconsisting of records denoting system events on the

G. Horsman, L.R. Conniss / Digital Investigation 12 (2015) S30eS37S32

handset. Each record entry is prefixed with an attribute tag,indicating the type of activity that has been carried out onthe handset, thus prompting a log entry. The relevance ofthis file in road traffic accident investigations is that almostall user interaction with the handset is recorded within itincluding passive activity; with entries ranging from whenthe user has pressed the power button and unlocked thehandset, to the execution and closure of applications on thehandset. Records within the CurrentPowerlog.po-

werlog allow a mobile forensic practitioner to profile aniPhone's usage by its owner. Each CurrentPo-

werlog.powerlog file records activity for a 24-h periodon the device (as specified in the [Log] entry at the start ofevery file; see Fig. 1). This enables a practitioner to profilethe device's usage throughout this period, and thus, byselecting the relevant CurrentPowerlog.powerlog file,the period leading up to a motor vehicle accident.

As the file continuously records device activitythroughout the defined [Log] period, the file can be inexcess of 5 MB, subject to the amount of activity on thehandset. Once the file has reached its defined [roll-overDate], the file is not deleted but moved to the/var/mobile/Library/Logs/PLArchive directory andplaced within a.gz archive, prefixed with the starting dateof the log (e.g. PL_2014-08-04-). This means that handsetactivity from previous days can also be access andexamined.

However, the PLArchive directory does not indefi-nitely maintain all CurrentPowerlog.powerlog filesfrom the first time the handsets was used, and although itcannot be confirmed in all models of iPhone handsets andiOS versions, logs on the test iPhonewere maintained for atleast 3 weeks. Therefore, investigating practitioners mustensure that the device is interrogated as soon after the roadtraffic incident as possible to prevent the handset over-writing these files. Of course, it may be possible that, if ahandset was jailbroken, users could download or writescripts or applications which could delete or tamper withsome or all CurrentPowerlog.powerlog files leavinglittle or no trace evidence.

Providing the CurrentPowerlog.powerlog files areretrieved from a suspect handset, the following sectionsprovide an indication of the relevance of data they maycontain.

Hands-free connectivity

As noted previously, hands-free mobile handset usage ispermitted whilst driving, however, the presence of ahands-free kit within a motor vehicle does not indicate thatit was in operation during or leading up to an accidentmeaning it must be proven that any such calls werereceived legally via the hands-free device at the time in

question. For the purposes of detecting hand-free usage, aseries of calls were made to the iPhone test device andanswered using the device handset. A further set of callswere made and instead answered using a ‘Plantronics M20’Bluetooth hands-free headset. After analysing [Tele-phony] log entries in the CurrentPowerlog.powerlog,calls answered through the Bluetooth headset maintain anadditional [Audio] entry (see Fig. 2.), denoting audio forthe call being routed via the Bluetooth headset as opposedto the handset speaker. Although only one hands-free de-vice was tested, given that these devices route audio to theBluetooth headset, it is presumed similar log entries wouldbe available for other manufacturers. This distinction be-tweenmethods of answering calls is not shown in standardmobile handset call logs where the handset speaker isemployed, therefore an analysis of the CurrentPo-werlog.powerlog could identify if an actual hand-freedevice was in use at the time of the accident.

Charging the device in-car

The use of in-car charging facilities has now increased tocope with demand and the widespread use of mobilephones. In turn, the act of plugging in the mobile handsetinto these devices whilst driving may provide sufficientdistraction from the road. The CurrentPowerlog.po-werlog provides the following entries for when the deviceis connected to a charger and when it's not, shown in Fig. 3.

Profiling the [Battery] log entries can indicate thetime a device was connected to an in-car charging facility.

Interacting with the screen lock

The lock-screen of an iPhone handset is displayed to theuser when the power button is pressed following sleepmode (see Fig. 4). Typical information displayed includestime, date and any notifications from applications on thehandset (received SMS, social media posts, emails etc.). TheiPhone offers the ability to preview messages in the noti-fication screen without directly accessing them. From theperspective of a forensic analysis of a handset, previewingthese messages on the lock-screen does not alter the

Fig. 1. Log timespan entry.

Fig. 2. Log entries for a call routed through a Bluetooth headset.

Fig. 3. Log entries for device charging.

G. Horsman, L.R. Conniss / Digital Investigation 12 (2015) S30eS37 S33

timestamp of data stored within the application (forexample, previewing a received SMS message still leavesthe message marked as unread on the handset). Theimplication of this is that it may not be obvious that theuser has illegally interacted with their handset at the timeof the accident and in turn, a user could argue the fact thatthemessage remains in an unread state indicating that theyhave not actually read it.

However, the CurrentPowerlog.powerlog recordsshown in Fig. 5 indicate when the user has pressed thepower button, initialising the lock-screen display.

In addition, the lock state of the phone is also recorded(see Fig. 6.), indicating whether the user has proceeded tounlock their device.

A combination of the [SpringBoard-states] and[Display] entries document whether the user has simply

looked at their phone (for the time, notifications etc.) orentered the device by unlocking it for further interactionwith handset features and applications. Profiling the entirelog for entries can lead to the identification of subsets oftime throughout a 24-h period in question where the de-vice is being actively used. In turn, the timestamp infor-mation could correlate to relevant times prior to, or duringan accident. Using the previous example of a receivedmessage, correlating lock-screen log entries with inboxmessage timestamps could indicate that the user hasactually used their handset prior to or during an accident tounlock their device and proceed to read a message.

Use of applications

Once the user has accessed the device, it is likely thatthey will proceed to initiate applications that are installedon the handset. The CurrentPowerlog.powerlog re-cords all access to applications installed on the device usingthe [Application] tag (see Fig. 7). The followingexample provides a record entry for the user initiating theFacebook application on their device.

Key data contained in the [Application] entry include‘executable¼’ which indicates the name of the applica-tion which has been executed. This corresponds to thename shown under the application's icon on the mainscreen of the handset. In addition, the ‘mode¼’ syntaxprovides an indication of the application's current runningstate. Modes include ‘Foreground Running’, ‘Back-ground Running’, ‘Terminated’ and ‘Suspended’. Giventhat entries in the CurrentPowerlog.powerlog aretimestamped, it is possible to profile application usage onthe handset to see when they are executed, and, in turn,closed by the user. The difference in time between entriesgives an indication of the duration that the application wasin use (see Fig. 8 for example of log content). These logentries can indicate when the user initiates, for example, asocial media or news application solely for browsing pur-poses, and, for how long; a passive act which could beoverlooked during a mobile forensic investigation yet isprohibited whilst driving.

Establishing a device has been inactive

The CurrentPowerlog.powerlog retains informa-tion about interactions with the device, and as may beexpected, the number of monitored events reduces whenthe device is in sleep mode or during periods of inactivity(although battery and network connectivity may be recor-ded whilst the device is in sleep mode). In addition, whenthe handset is powered off, all logging activity ceases.

Fig. 4. Example of notification screen content.

Fig. 6. Log entries for screen lock status. Fig. 7. Log entries for the ‘Phone’ application state.

Fig. 5. Log entries for power button presses.

G. Horsman, L.R. Conniss / Digital Investigation 12 (2015) S30eS37S34

Therefore, the practitioner can also identify periods wherethe device was inactive through an analysis of the entrytimestamps, which may prove crucial for refuting claimsthat a driver has interacted with their handset.

Analysis of the Android operating system

Handsets using Android operating systems present adifferent challenge to the practitioner. Unlike the iPhonedevice, there is no equivalent CurrentPowerlog.po-

werlog file stored within the file system monitoring dailyactivity. The challenge of identifying direct and passiveactivity requires an analysis of volatile system buffer logsstored under the file location/dev/log. However due totheir volatility, a live analysis of the device is required at thescene of the accident or shortly after, in order to accessbuffer log content within data retention restrictions;analogous to physical memory in computer devices, whenpower is removed from the mobile handset, buffer logcontent is purged. For this investigation, the extractionfrom the Android handsets was via the Android DebugBridge (ADB) which will be discussed below.

Buffer logs

For the purpose of application development anddebugging, the buffer logs maintain records of systemmessages on the handset, similar to that of the iPhone'sCurrentPowerlog.powerlog. As a result, log contentdenotes system messages generated by the user as theyinteract with their device and buffer logs are constantly inoperation whilst the handset is powered on. It should alsobe noted that there are multiple buffer logs in action on thehandset, which can all be extracted as shown in Table 1.

Each log contains a series of entries signifying specificevents on the handset, which can be distinguished via theirprocess ID (see Section ‘Analysis of buffer log content’below). As with the CurrentPowerlog.powerlog, logentries include when the user accessed their handsetincluding the opening and closure of applications,

complete with any intervening timestamp informationdenoting when an application event has occurred.

However, a restriction of the buffer logs is that theymaintain a finite size, and once filled, previous content isoverwritten. The volatility of the buffer logs poses thegreatest challenge to the mobile forensic practitioner, and,as a consequence, if more activity is carried out on thehandset there is a greater chance of activity in the log beingoverwritten. In addition, if the handset encounters heavyactivity in a short space of time, the log will contain recordsof the user's actions over a shorter time period due to sizerestrictions (see further discussion in Section ‘Buffer sizeconsiderations’).

Accessing/dev/log/

The volatility of buffer logs means that in order to cap-ture the maximum available information, the handsetsseized at the scene of a motor accident must be examinedimmediately. The device's current charge capacity mustalso be assessed and if necessary, connected to an auxiliarypower supply to prevent data loss. The Association of Chiefof Police (ACPO) guidelines for mobile phone seizurerecommend either turning the device off to preventchanges to resident data or placing the device within ashield environment (Association of Chief Police Officers,2007). In the case of the former, buffer log data will belost. In the latter, the mobile forensic practitioner must alsoconsider the difficulties posed by Faraday technology,which causes handsets to lose their charge at a faster rateand auxiliary power may be needed.

The/dev/log file location must be accessed throughthe Android Debug Bridge (ADB), a command line appli-cation for communicating with an Android device(Developers, 2014b). The necessary drivers for the specificmake and model of handset being investigated must beinstalled on the host computer being used for the access inorder to support communication with that particularAndroid device. As part of the ADB, the logcat commandcan be used to read the logmessages currently stored in thehandset buffer and export their contents to a text file (seeFig. 10).

Buffer size considerations

To determine buffer size, the ‘logcat-g’ commandshould be run (see Fig. 9). The larger the buffer, the moreinformation it is likely to retain. In addition, it is likely thatthis information covers a larger timescale, increasing thechance of retrieving information denoting handset usage atthe time of the motor vehicle accident. Testing showed thatbuffer log information from a Galaxy S3 running Jellybean

Table 1Types of buffer log (Developers, 2014a).

Type Main buffer log

System System messages for debuggingMain Main log buffer by defaultEvents System events-related messagesRadio Radio/telephony-related messages

Fig. 8. Example of CurrentPowerlog.powerlog content.

G. Horsman, L.R. Conniss / Digital Investigation 12 (2015) S30eS37 S35

4.3 held log information for events from 6 h prior to thepoint of extraction. In comparison, an HTC One handsetrunning Kit Kat 4.4 held log information for events from 2 hprior to the point of extraction, demonstrating the impactbuffer log size can have on an investigation. Althoughbuffer sizes can be increased, it is unlikely that the averageuser will have done so, therefore all buffer sizes referred toin this article have been left as the handset default.

Table 2 documents the results of an examination of asample set of Android operating systems to show the dif-ference in default buffer log sizes.

Analysis of buffer log content

Results provided in this section are the result of ananalysis of an HTC One handset running Kit Kat 4.4.

Log entries within the buffer logs contain a number ofmetadata fields which should be extracted for examination.For the purposes of maximum data acquisition, Fig. 10 de-notes the use of the ‘long’ command, accessing all avail-able fields for log messages in the events buffer, exportingdata to a text file for subsequent analysis.

As buffer logs record all actions on the handset, it islikely that a number of entries will be redundant for thepurpose of profiling a device's usage; filtering the logcontent via Process ID (PID) entry information can allowrelevant events to be identified. Table 3 provides an over-view of some of the basic PIDs associatedwith initiating thehandset and the actions of opening and closing andapplications.

To provide an example of buffer log content in context,the act of viewing SMS messages in the inbox of thehandset was carried out (all messages had previously beenread). Afterwards, handset buffer logs were extracted andanalysed, providing evidence of the SMS application beingexecuted, followed by the thread for the ‘Vodafone’ contactbeing opened to view the SMS messages.

The information shown in Fig. 11 is not available in aphysical or logical extraction of the handset. Despite theseactions clearly documenting device usage, which mayimpact upon prosecution of mobile device-related driveroffences, a failure to collect buffer log data would leavethese actions of a driver undetected.

A further example includes the use of social media ap-plications, for example, the user who synchronises theirTwitter feed whilst driving and proceeds to read tweets, anact breaching legislation. A practitioner viewing theextracted buffer needs first to find the PID for the Twitterapplication execution (prefixed am_proc_start). As thebuffer logs are chronological, the proceeding log entries,notably PID ‘sync:[com.twitter … ’ will indicate thatthe user has synchronised their feed. Immediately pre-ceding this entry, ‘ScribeService’ entries are generatedwhen the user scrolls through their Twitter feed (seeFig. 12).

Fig. 9. ADB command to establish the size of the events buffer log.

Table 2Default buffer log size variations by operating systems.

OS version Log size

4.4 (Kit Kat) All logs 256 kb4.3 (Jelly Bean) Main (2048 kb), system &

events (256 kb), radio (1024 kb)2.3 (Gingerbread) All logs 64 kb; except events log (256 kb)

Fig. 10. ADB command to extract log content with all metadata fields.

Table 3PID entries and description.

PID Description

screen_toggled(752):0 Handset sleeping.screen_toggled(752):1 Handset active but locked.screen_toggled(1065):2 Handset unlocked.am_proc_start Indicates application has been

executed.am_destroy_service Indicates application has been

closed.Am_on_resume_called Indicates application previously

running in the background hasbeen executed.

Fig. 11. PID information for opening the SMS application and looking at theVodafone contact SMS thread.

Fig. 12. Twitter newsfeed sync and scroll.

G. Horsman, L.R. Conniss / Digital Investigation 12 (2015) S30eS37S36

Hands-free device usage

Aswith the iPhone, it is necessary to establish whether ahandset was accessed through a hands-free headset. Thetests documented in Section ‘Hands-free connectivity’ forthe iPhone, were replicated on the test Android device.Extraction and analysis of the ‘events’ buffer showed nodistinction between a call answered on the handset andone answered via a hands-free headset. However, anextraction and analysis of the ‘main’ buffer log indicatedthe use of the Bluetooth headset to answer the call. How-ever, the relevance of this information is limited. Due to thevolume of events recorded in the ‘main’ buffer, events onlyhad a timespan of 4 min. Therefore, given the time it wouldtake to respond to a motor incident and extract data fromthe handset, log information would be overwritten.Therefore, unlike the iPhone, information denoting hands-free usage, tracing similar usage on an Android device is toovolatile and would likely not be available tomobile forensicpractitioners.

Conclusion

One of the key difficulties in a road traffic investigationinvolves establishing a timeline of events along with causalfactors for the road traffic accident. UK legislation effec-tively prohibits all drivers from using hand-held mobiledevices whilst operating a motor vehicle. After a motorvehicle incident, mobile phone forensic practitioners aretasked with establishing whether a driver has broken thelaw by looking for signs of mobile device activity leading upto or during an accident, typically consisting of an analysisof call and text message records as a minimum.

This article has presented an analysis of the iPhone'sCurrentPowerlog.powerlog and Android's buffer logs,highlighting the types of information relating to user-interaction on the handset, which are stored in theseareas and can be retrieved for the purposes of identifyingpotential causal factors. Activity recorded in these areascould highlight a driver's direct or passive activity on theirhandset, which, in turn may provide an explanation forevents leading up to amotor vehicle accident. Alternatively,analysis of these log files may indicate that a driver did notuse their mobile device prior to, or during a road trafficincident.

The analysis of mobile handsets in relation to roadtraffic accident investigations leads to a number of areaswhich require further investigation, particularly as tech-nology continues to evolve. Accident investigators willneed to factor in peripheral or integrated technology. Forexample, on-board car computers/management systemswith Bluetooth integration (e.g. Ford SYNC) will need to beanalysed in order to identify whether a driver's interactionwith the device was truly hands-free at the time of anincident. Similarly, voice-activated applications used toaccess and interact with handset functionality (e.g. sendSMS, make calls etc.) in a hands-free capacity will also needto be factored into road traffic accident investigations. As aresult, establishing a robust account of how such technol-ogies work will be a key area for future research anddevelopment.

References

Artan Y, Bulan O, Loce R, Paul P. Driver cell phone usage detection fromHOV/HOT NIR images. In: Proceedings of the IEEE conference oncomputer vision and pattern recognition workshops; 2014.p. 225e30.

Association of Chief Police Officers. Good practice guide for computer-based electronic evidence. 2007. p. 46 [Online] Available at: http://www.7safe.com/electronic_evidence/ACPO_guidelines_computer_evidence.pdf.

Association of Chief Police Officers. Reports of police seizingmobile phonesafter every road traffic collision are inaccurate [Online]. Available at:http://www.acpo.presscentre.com/Press-Releases/Reports-of-police-seizing-mobile-phones-after-every-road-traffic-collision-are-inaccurate-2e8.aspx; 2014.

Department of Transport. Vehicle licensing statistics: 2013 [Online].Available at: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/302409/vls-2013.pdf; 2013.

Department of Transport. Reported road casualties in Great Britain: mainresults 2013 [Online]. Available at: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/324580/rrcgb-main-results-2013.pdf; 2014.

Developers. Reading and writing logs [Online]. Available at: http://developer.android.com/tools/debugging/debugging-log.html; 2014.

Developers. Android debug bridge [Online]. Available at: http://developer.android.com/tools/help/adb.html; 2014.

Govuk. Using mobile phones when driving: the law [Online]. Available at:https://www.gov.uk/using-mobile-phones-when-driving-the-law;2014.

Horberry T, Anderson J, ReganMA, Triggs TJ, Brown J. Driverdistraction: theeffects of concurrent in-vehicle tasks, road environment complexityand age on driving performance. Accid Anal Prev 2006;38(1):185e91.

Hosking SG, Young KL, Regan MA. The effects of text messaging on youngdrivers. Hum Factors J Hum Factors Ergon Soc 2009;51(4):582e92.

Nasar JL, Troyer D. Pedestrian injuries due to mobile phone use in publicplaces. Accid Anal Prev 2013;57:91e5.

National Safety Council. NSC releases latest injury and fatality statisticsand trends [Online]. Available at: http://www.nsc.org/Pages/NSC-releases-latest-injury-and-fatality-statistics-and-trends-.aspx; 2014.

Northern Ireland Statistics and Research Agency. Northern Ireland roadsafety monitor [Online]. Available at: http://www.doeni.gov.uk/road-safety-monitor-2013-report.pdf; 2013.

Oulasvirta A, Rattenbury T, Ma L, Raita E. Habits make smartphone usemore pervasive. Pers Ubiquitous Comput 2012;16(1):105e14.

Pless C, Pless B. Mobile phones and driving. BMJ Br Med J 2014;348.RAC. RAC report on motoring 2014. 2014 [Online]. Available at: http://

www.rac.co.uk/RAC/files/eb/eb140396-0385-49db-a9e7-3a5b02dd28fd.pdf.

Redelmeier DA, Tibshirani RJ. Association between cellular-telephonecalls and motor vehicle collisions. N Engl J Med 1997;336(7):453e8.

Regina v Jaswinder Arora [2014] EWCA Crim 104.Regina v Phillipa Curtis [2009] EWCA Crim 1003.Statista. Global market share held by the leading smartphone operating

systems in sales to end users from 1st quarter 2009 to 4th quarter2013 [Online]. Available at: http://www.statista.com/statistics/266136/global-market-share-held-by-smartphone-operating-systems/; 2014.

The road vehicles (construction and use) regulations 1986. Available at:http://www.legislation.gov.uk/uksi/1986/1078/contents/made.

The road vehicles (construction and use) (amendment) (no. 4) regulations2003.Available at: http://www.legislation.gov.uk/uksi/2003/2695/made.

The Royal Society for the Prevention of Accidents. Road safety informa-tion [Online]. Available at: http://www.rospa.com/roadsafety/info/mobile_phones_2011.pdf; 2012.

Think!. Mobile phones [Online]. Available at: http://think.direct.gov.uk/mobile-phones.html; 2014.

Weller JA, Shackleford C, Dieckmann N, Slovic P. Possession attachmentpredicts cell phone use while driving. Health Psychol 2013;32(4):379.

White KM, Hyde MK, Walsh SP, Watson B. Mobile phone use whiledriving: an investigation of the beliefs influencing drivers' hands-freeand hand-held mobile phone use. Transp Res Part F Traffic PsycholBehav 2010;13(1):9e20.

World Health Organisation. Mobile phone use: a growing problem ofdriver distraction [Online]. Available at: http://www.who.int/violence_injury_prevention/publications/road_traffic/distracted_driving_en.pdf?ua¼1; 2011.

Yang J, Sidhom S, Chandrasekaran G, Vu T, Liu H, Cecan N, et al. Detectingdriver phone use leveraging car speakers. In: Proceedings of the 17thannual international conference on mobile computing andnetworking; 2011. p. 97e108.

G. Horsman, L.R. Conniss / Digital Investigation 12 (2015) S30eS37 S37