16 Advanced Device Analysis: IoT, Wearables, and Drones
As discussed in Chapter 3, the era of IoT and other connected devices is upon every investigator and investigation. Like mobile devices, both iOS and Android, these devices and their associated apps can hold valuable information for the examiner. Digital traces left by the billions of devices within the Internet of Things, wearables, and drones could be the smoking guns in today’s investigations. The “Wild West” once reserved for the examination of data from a mobile phone or a smart device is now the world of these emerging devices. In Chapters 13 and 15, information hidden beneath the “tip of the iceberg data” was discussed as a way to help uncover additional information from both iOS and Android devices. In this chapter, we will discuss both “tip of the iceberg data” and additional information that will assist in the investigation of these devices.
The limitations imposed by many of these emerging technologies results particularly from the support offered by commercial tool vendors—or lack thereof. These limitations are not the result of a lack of knowledge or research, but result from the sheer pace of deployment of these devices and our inability to keep up. In addition, the lion’s share of data for many devices is stored within the Cloud. Although for many commercial tools, cloud storage represents another hurdle, it is often the reluctance of examiners to attempt to access this valuable data that keeps it hidden—and there is little case law or legal precedence regarding accessing and extracting data from the Cloud.
Even with lawful access to the device or cloud stores, the information that is often examined or located represents only a fraction of the data that is available to the examiner. This is not for a lack of trying, but results from the examiner’s lack of support and ultimately lack of understanding of where to look. Now that IoT, wearables, and drones are so mainstream and are found in many homes, on many wrists, in the skies, and in vehicles, it is imperative that examiners understand not only what data is available, but where to look for it.
This chapter is not an exhaustive listing of the data, but more of a starting point to locations within the Cloud and mobile device backups, application sources, and fringe devices such as drones. “Fringe” might be an inaccurate descriptor, however, because the data contained inside these types of devices can be monumental to a case, and is more often used in investigations. Nevertheless, they are “fringe” devices simply because of a lack of documentation and commercial support for them—they are truly the Wild West in forensic examinations.
“Tip of the Iceberg Data”
The success of an investigation often comes down to the examiner’s ability to access the data on these types of devices, but the examiner must also understand the format of the data and realize that not all automated forensic tools are created equally. For example, many IoT devices, vehicle systems, wearables, and drones can be accessed only using atypical connectors, or they may require invasive connections. Often, only “tip of the iceberg data,” or the lowest-hanging fruit, will be available.
Unlike the data in iOS and Android devices (discussed in Chapters 13 and 15), however, which are generally parsed and obtainable using most commercial tools, IoT, wearable, and drone devices are not easily investigated. Although many of these devices’ file systems may resemble those of Android devices, or they may be based on Android systems, commercial forensic tools often lack the “knowledge” of where this data is located on the devices. Knowledge, or logic, in the development sense, rests completely on the shoulders of investigators to code the correct path and then parse and extract the needed data. This data is then revealed to the investigator within the interface of the application. Because many, if not all, of these devices are not documented by manufacturers or on the Web, commercial forensic tool developers face plenty of research and development tasks. Often, reliance on the digital forensic community is essential to assist in their continued development to support more information about gathering evidence from these devices.
The following sections cover the information extracted from cloud stores and backups of various devices to include Google Home, Alexa, Apple Watch, Fitbit, and unmanned aircraft systems (UASs), or drones. Note that the information presented here is based on the devices mentioned, and it is not a global description for every smart watch, smart home device, or drone. However, this information offers the investigator a starting point in the investigation of these devices.
Smart Home Devices
Smart home devices have become popular around the globe, as more and more of these devices are made available each day to consumers. The types of smart home devices available today include doorbells, thermostats, and lighting—anything in the home capable of receiving an electrical current. The more the investigator knows about the type of data that is available from these devices, even at the “tip of the iceberg,” the better qualified he or she will be to form a collective forensic picture for the investigation. Crimes have been solved and people have been exonerated with data gathered from smart home devices. Two devices and systems, Google Home using Assistant and Amazon Echo using Alexa, are discussed in the following sections.
Google Home
Access to “tip of the iceberg data” on a Google Home device is gained within the apps that access the device via the Google Assistant (such as Chromecast and others), as well as within the Google Cloud account for the device. The data available within these apps is extremely limited, however, because the apps are active web-based applications, meaning the data is not accessible if the device is offline. In other words, the app data will be available on the device only with a connection to the Google server. Without this connection, the data available on the device is limited to usernames and other general account information. As you know, to determine whether an app relies only on server data, forensic investigators would need to open the app with the device isolated. And if the app is not populated with data, there is a good chance app data will need to be retrieved from the app’s server. Furthermore, the Google Assistant and Google Home app data is generally available only with a physical extraction of an iOS device and via root on an Android. A Standard iTunes backup or ADB backup will not recover most of the valuable data.
The user needs a Google account to set up the Google Home device. Applications on the smart home device will also need to use the associated Google account to communicate with the device. The smart home device is visible via Bluetooth and Wi-Fi to any device that has paired with it and can play media over the device. For example, data from the Chromecast app (which was replaced by the Google Home app, but the Chromecast name was kept for the app bundle) in an Android device can be found within com.google.android.apps.chromecast.app/sp/com.google.android.apps.chromecast.app_preferences.xml with the following flags:
Imagine if, during the investigation, information was found within an app on a mobile device, but the Google Home device was not located in the area. This definitely could mean more investigation would be needed, especially if Assistant was not installed on the mobile device.
Commercial tools, as well as public APIs, can be used to extract data from Google Home cloud activity, but few parse the data from the apps on the mobile devices. Apps such as Home are almost entirely active, so the data is not accessible if the device is offline. Within the Android file system, the investigator can find the Google Home app data at com.google.android.apps.chomecast.app and Assistant app data at com.google.android.apps.googleassistant.app. Assistant data is also accessible via the My Activity cloud account, as is Google Home data. Table 16-1 lists some information that can be recovered from files within the Google Home application on the mobile device.
TABLE 16-1 Google Home App Contains Limited Data, But Can Assist with an Investigation
Information that can be obtained from both direct API communications with the Google Home device and Google My Activity are immense, however. The API for Google Home is primarily exposed to handle the creation of “actions” that can be used by the Google Home device. For cloud tools, the support for My Activity (which tracks the user’s activity) is initiated with the Google Account, username/token, backup passwords, Authenticator, or app-specific passwords. Both are discussed in the following sections.
Direct to Device
Using the Google API, the investigator can interrogate the device(s) as long as the IP address of the device is known. The device’s IP address can be collected using one of several network scanning apps run from a mobile device, the Google Home app, or the router. Note that access to the Wi-Fi network that is connected to the devices is required for both identifying the Home device if using an app and during the interrogation of the device. This type of access requires that the investigator weigh the pros and cons of access in this situation. The information that can be extracted over TCP within the internal network is quite impressive, however, to include but not be limited to the following:
• Device name
• Time zone
• Language
• MAC address
• Public encryption key
• All Bluetooth devices in the area
• Connected Wi-Fi
Once connected to the device, the investigator can retrieve the data using GET statements. (The opposite command, POST, is one the investigator should not employ, for obvious reasons.) Using GET will allow for the extraction of the data without adding data to the specific records requested. The data is returned in JavaScript Object Notation (JSON) (see Chapters 12 and 13). To communicate and obtain the information from the device, the investigator will need to use an interface that will allow for communication over TCP using GET commands. Several REST web-based tools are available for this. In the following exercise, the Advanced REST client (https://github.com/advanced-rest-client) is used. The commands covered here are all undocumented calls by Google but are outlined by rithvikvibhu on Github (https://rithvikvibhu.github.io/GHLocalApi).
The HTTP port that is currently used by Google Home is 8008. To access the device using the REST utility, the investigator would use the following template:
GET http://<discoveredIP>:8008/setup/<file>
Table 16-2 lists some of the files and also the expected results from the data retrieval.
TABLE 16-2 Important Files Within the Google Home Device Retrieved Using HTTP
Google Home Cloud (My Activity)
The majority of Google Home device data will be stored in the user’s My Activity account. The information stored in the user’s account will comprise the actions that the device performed based upon the user’s suggestions. Both the Assistant subcategory and the Voice & Audio within My Activity can provide a gold mine of Google Home user data. The Google Home device will capture any phrase the user spoke, as well as the return data by the Home device. The actual voice is recorded and analyzed on the Google servers and the voice is stored. So not only can an investigator see what the Google Home device transcribed, but he or she can hear the actual recording used to make the transcription! This could be monumental to a case when a subject denies being at a location, or when a subject utters the words to search for “closest store to buy duct tape,” and his or her actual voice has been recorded.
The subsection in My Activity, Voice & Audio, is displayed in Figure 16-3 from an Oxygen Forensic Cloud extraction, and the platform Google Home is identified. Also, the Assistant is a subsection that lists usage of the Assistant app on both iOS and Android devices, as well as using Assistant with the Home device. Figure 16-4 shows data collected from My Activity’s subsection Assistant.
FIGURE 16-1 Running a GET command on an active Google Home device to retrieve the contents of the file eureka_info
FIGURE 16-2 Running a GET command on an active Google Home device to retrieve the contents of the get_bonded file
FIGURE 16-3 Voice & Audio data extracted from Google My Activity that clearly displays the action and the response
An investigation into the Google Home device, as well as the artifacts found both within the app and in the Cloud service, can often uncover additional data for any investigation. From information regarding searches a user has conducted using the Home device, to other connected devices that have been attached to the Home device, to locations that are captured upon each request, this important data should not be overlooked.
Alexa
Devices that access Alexa (such as Echo, Echo Dot, and so on) store data primarily in the Cloud. These devices communicate with and to mobile phones via the Amazon Alexa app and control requests to play music, integrate other IoT devices, and provide weather or other news updates. Again, much like other devices, these devices use an API to communicate to and from the Alexa device over the user’s internal network and then outbound to the Alexa Cloud. Communication from the Alexa Cloud to other IoT devices can be used to control smart TVs, lights, thermostats, and more.
“Tip of the iceberg data” will be discussed in this section, as well as some additional artifacts. The API for Alexa is not public, but this information is hosted at several documented sources, which will be covered in detail. A mobile device app is generally used to set up the device and control many of the “skills” that define the usage of the Alexa-powered device. Users of the Amazon brand of smart devices will need an Amazon account to set up the device, and to access the data within the account or Cloud, investigators will need the user’s credentials.
Investigators can use commercial tools as well as unpublished APIs to extract data from the Alexa Cloud, but few tools parse the data from the apps on mobile devices. Currently, Magnet Forensics, Cellebrite, Paraben, and Oxygen provide limited support for the apps on a mobile device. As mentioned, apps such as Alexa are almost entirely active, and the data is not accessible if the device is offline. Some account data can be useful for interrogation of the cloud service, but much of the user data is generally encrypted. Alexa, the app bundle, and folders can be found at com.amazon.dee.app for Android and com.amazon.echo for iOS devices. The folder is obtainable only in a physical collection of the Android device. The folder structure contains multiple folders and files (Figure 16-5). Table 16-3 lists some information that can be recovered from the Alexa application on the mobile device.
FIGURE 16-4 The Assistant section in Google My Activity holds data that is captured by Google Home.
TABLE 16-3 Alexa App Data from Within Both iOS and Android Devices
FIGURE 16-5 Folder structure of Alexa app within a Samsung SM-G900T running 5.11 Android
The data is primarily stored as JSON strings either in individual files or within the SQLite database. Some of the information can be pertinent to a case, such as the account, cards, and endpoint strings. Brian Moran of BriMor Labs has presented research on the recovery of contacts and messages as well as call history by combining the endpoint URL in the configurations table of the arn:aws file and the Amazon ID string found in map_data_storage_v2.db. If the investigator is authenticated in the Amazon account and runs a script, call logs and messages can be retrieved. This is covered in the next section.
Direct to Amazon Cloud
As with the Google Home device, the data from the Cloud will be paramount to the overall investigation. This information can be obtained using HTTP calls as well as by using many cloud extraction tools. Using information that is obtained from the mobile app, to include the endpoint URL from the configurations table and Amazon ID string, an investigator can query the account and recover additional information.
Using Burp Suite Professional and a trusted SSL certificate, Karl Fosaaen (https://blog.netspi.com/speaking-to-a-city-of-amazon-echoes/) reported he was able to capture traffic from an Alexa device. In doing so, he obtained the commsID; this can be used by all investigators, along with the data from the mobile app, to create an HTTP call and recover additional data unavailable even from within the web portal for Alexa (https://alexa.amazon.com), messages, and call log data. The only prerequisite for the investigator is that he or she must know the Amazon login information and be signed into the account. The user’s contacts, even if the contact does not use an Alexa-enabled device, are populated in the Alexa Cloud. Calls and messaging, if they occurred via the Alexa app to other Amazon device users, are recoverable using this method as well. The investigator need only run the following commands on an authenticated account.
To recover contact data, run the following:
The results, in Figure 16-9, are in Notepad++ with a JSON viewer and clearly show all contacts information after running the contact script.
FIGURE 16-6 The eventsFile is a JSON file containing identifying information about the device.
FIGURE 16-7 The map_data_storage_v2.db SQLite file contains the account name as well as the Amazon ID string.
FIGURE 16-8 File showing endpoint URL that, when combined with data from map_data_storage_v2.db, investigators can use to obtain user calls, messages, and media
FIGURE 16-9 All contacts are shown in Notepad++ after running the contacts script.
For messaging and calls data, run the following:
You can think of conversations as “threads” between contacts. If an investigator wants to extract a single conversation, the conversationId (shown in Figure 16-10) must be appended and used in the HTTP request, as shown here:
FIGURE 16-10 Results shown in Notepad++ with JSON viewer of messages from the Alexa Cloud
This information was documented by Brian Moran and Karl Fosaaen and can be used by an investigator to conduct live analysis of the Alexa Cloud, along with the following information on accessing additional data using undocumented and documented APIs.
A list of HTTP requests is provided in Table 16-4 (obtained from http://analyticphysics.com/Diversions/Accessing Amazon Echo Data with JavaScript.htm and www.dfrws.org/sites/default/files/session-files/paper_digital_forensic_approaches_for_amazon_alexa_ecosystem.pdf as a reference. As with the previous HTTP commands, the investigator must have access to the device and be authenticated for the Amazon account. The response returned will be in JSON format (see Figure 16-11). As with other responses, using a tool such as Notepad++ with a JSON viewer will help to decode and format the data for easy investigation.
FIGURE 16-11 A query of the device information provides the name of the device, ID, customer ID, and serial number.
TABLE 16-4 Listing of HTTP Request URLs and Data Returned
Cards are the voice instructions given to Alexa devices; the investigator can access these individually if they are not included in the response. In addition, the audio files that are referred to within the JSON format are stored and are retrievable from the Amazon servers. This audio data is stored indefinitely, unless the user removes it. Amazon clearly states the following in the user’s account under Your Devices | Device Actions | Manage Voice Recordings:
When you use your device, we keep the voice recordings associated with your account to learn your voice and how you speak to improve the accuracy of the results provided to you and to improve our services.
This type of information can be critical to understand if your investigation involves the retrieval of voice information from the Alexa device.
Currently, only two commercial cloud tools can access data from a user’s Alexa account: Oxygen Forensic Cloud Extractor and Cellebrite Cloud Analyzer. The extraction techniques are built upon the data that has been provided in this section as researched, with generally the same extracted data. Commercial tools also need to have access to the username and password combination and/or token. The advantage of using a commercial cloud tool will be the data formatting as well as the automated logic. However, the examiner’s understanding of the information obtained from the Cloud by using the commands provided throughout the section should prove valuable if testimony is required.
Wearable Devices
Wearables are everywhere—people wear mobile computing devices around their wrists, on their heads, and on their bodies. With the Fitbit and Apple Watch almost mainstream, most users wear these devices on their wrists. As with any other form of digital storage device, an investigator must consider what type of data can be recovered. The technology of these devices continues to grow and will continue to advance. An investigator must be prepared to look for these types of devices at the digital forensic scene and be prepared to look for ways to extract the information from the associated mobile app, if applicable, directly from the device via advanced methods, and from the device’s cloud service.
No longer are investigators simply dealing with a mobile device; our connected world demands the investigator start thinking of these additional devices and their content. Failing to become educated on the new possibilities of the wearable device, and its data, could result in an investigator missing data that could likely close a case. In Chapter 3, we discussed some high-level data within the backups of the Apple Watch as well as some data that could be lingering within the Fitbit. Like the data from smart home devices, much of the information on these devices is stored within the Cloud.
This section covers the Apple Watch and the Fitbit. The “tip of the iceberg data” will be discussed as well as information from the Cloud. With the number of wearables, particularly watches, on the rise, the investigator should be prepared to delve into the file systems of these devices.
Apple Watch
Data for the Apple Watch is backed up within a standard iTunes backup as well as an iCloud backup. There is, however, a caveat to this: if health and fitness information is to be backed up, then the backup must be done via iCloud or the iTunes backup must be encrypted. Within an iTunes backup, the investigator should look to the path privatevarmobileLibraryDeviceRegistry for data that is backed up to the mobile device and subsequently found in the iPhone backup (Figure 16-12). Also, the investigator can find current settings for the device at privatevarmobileLibraryDeviceRegistry.state.
FIGURE 16-12 File system location for the backup of the Apple Watch in a standard iTunes backup
Information that is shown on the watch is often simply a reference to the information within the stock app databases. Examples of this are the AddressBook folder, located at privatevarmobileLibraryDeviceRegistry<Device ID>AddressBook; and within the ABSyncState table of ABSABShadow.db SQLite guid field is a GUID that can be matched within the ABPerson table of privatevarmobileLibraryAddressBookAddressBook.sqlitedb. The examiner can use a simple SQL command to show the names accessible with the Apple Watch. The investigator can also find data at additional locations within the Apple Watch backup file system, as discussed next.
Settings File
The main watch settings file is located at privatevarmobileLibraryDeviceRegistry.statehistory.plist. The history.plist contains a history node with several keys that are made up of arrays. Each array first lists a ClassName NRDeviceCollectionHistoryEntry with an associated date. The date is represented as an OS X UNIX time and identifies the date and time of the backup snapshot. Each array under the history node will have the ClassName NRDeviceCollectionHistoryEntry and its associated date of collection. Within each array, if changes have been made, additional investigative values can include the following:
• Hardware model (hwModelStr)
• Pairing device ID (pairingID)
• Type of device (systemVersion)
• System build (systemBuildVersion)
• Location of the backup (localPairingDataStorePath
• Wi-Fi MAC address (WIFIMACAddress)
• Serial number (serialNumber>UUID)
• Preferred languages (preferredLanguages)
• Name of the operating system (systemName)
• If the device is paired (bluetoothPaired)
• Last active date (lastActiveDate) OS X Epoch UNIX
• Date device paired (pairedDate) OS X Epoch UNIX
• Version or product type (productType)
• IMEI, MEID, CSN (UUID is key)
• Name of device (deviceNameString)
Generally, the first collection history array will contain the majority of strings.
User Information
Within the iOS device’s backup that was paired with the Apple Watch the investigator can find valuable information to assist with the case. This data can range from applications that have been installed on the device to voicemails that have been delivered to the wearable. The information listed next includes some paths within the device backup that can hold this critical data.
• privatevarmobileLibraryDeviceRegistry<DEVICE GUID>NanoMail egistry.sqlite This file contains many tables with GUIDS and paths of e-mail sent and received to the watch. Tables include COMPOSED_MESSAGE, DELETED_MESSAGE, MAILBOX, and SYNCED_ACCOUNT. Within the SYNCED_ACCOUNT table, the user ID as well as e-mail addresses can be located for the account. Within the MAILBOX table, the investigator can match the user ID from the SYNCED_ACCOUNT table to the correct e-mail path URL. Also within the MAILBOX table, the SYNC_ENABLED field will indicate whether the mailbox was currently being synched (0 = no and 1 = yes).
• privatevarmobileLibraryDeviceRegistry<DEVICE GUID>NanoPreferencesSyncNanoDomainscom.apple.Carousel This file is a property list that clearly defines the applications that are installed on the Apple Watch. The FavoriteApplications node lists the built-in Apple Watch applications, and the IconPositions node contains an embedded property list with all installed apps in a series of arrays.
• privatevarmobileLibraryDeviceRegistry<DEVICE GUID>com.apple.tccdWatchKitApplications This property list contains the version numbers of all the third-party applications that are installed on the Apple Watch.
• privatevarmobileLibraryDeviceRegistry<DEVICE GUID>NanoPreferencesSyncNanoDomainscom.apple.mobilephone This property list contains the path for voicemails with the key kVoicemailForReplicationKey. This key contains an embedded property list with multiple arrays with a data key (NS.data). The data includes the phone numbers and also the path to the voicemail within the iOS device file system. See Figure 16-13.
FIGURE 16-13 Data in the kVoicemailForReplicationKey showing the phone number and path to the voicemail
• privatevarmobileLibraryDeviceRegistry<DEVICE GUID>NanoPreferencesSyncNanoDomainscom.apple.nanoprefsyncd This plist file lists all the settings for the device that may help an investigator understand the following watch settings:
• Voice dialing enabled (allowVoiceDialing)
• Camera enabled (allowCamera)
• Whether backup can occur via iTunes (allowiTunes) or iCloud (allowCloudBackup) or both
• If chat is enabled (allowChat)
• If Find My Device is on (allowFindMyDevice)
• If a PIN is enabled (forcePIN)
Remember as discussed in Chapter 3 that the Apple Watch uses the shared area of many of the applications that are added as applications and the default Apple apps. The shared area is denoted by group.<Reverse DNS app bundle name>, as shown in Figure 16-14. Also, it is not necessary to have an Apple Watch paired to the device to recover user information from health information.
FIGURE 16-14 Location for the sharing of application data between apps given permissions as well as Apple Watch
Two database files should also be investigated:
• privatevarmobileHealthhealthdb.sqlite This database contains several tables that can help an investigator determine whether an Apple Watch was paired and authorized. Two tables, authorization and source_devices, will list the devices, operating system versions, and dates and times of devices using the health functions.
• privatevarmobileHealthhealthdb_secure.sqlite This database file contains several tables with additional settings and user information. The table key_value_secure contains the user’s birthdate (birthdate), name (NameKey), sex (sex), and body composition (height, body_mass).
The data that is created during the use of the Apple Watch can be valuable to an investigation. Whether this information assists the investigator in understanding what additional information is in an iTunes or iCloud backup, where it is located, or what was installed on the Apple Watch, it can provide additional clues or artifacts that may help in a forensic case.
Fitbit
Like the Apple Watch, the Fitbit device can be used to receive and send messages, receive alerts from applications, and keep track of the user’s health. However, unlike the Apple Watch, the Fitbit’s primary function is for health purposes; only recently has the device required an accompanying GPS-enabled device to properly document location and activity. The Fitbit has an app for both iOS and Android and also stores data in the Cloud; both can be sources of information. The app includes meaningful data such as account, health, and location information, to name a few.
Accessing the data on the mobile device is difficult, as the Android or iOS device requires root or physical access. In both iOS and Android operating systems, the data is not available with just a basic file system backup, as is obtained using the Apple Mobile Sync or ADB backup protocols. The app was developed not to back up that valuable investigative data, for obvious privacy concerns. What has been found, however, is that data that is available is stored in SQLite databases and files compressed using gzip.
The file system (Figure 16-15) of the Fitbit app package is similar to that of many other Android apps and can be viewed by using a reverse DNS name of com.fitbit.FitbitMobile with a cache folder, download folder, files, no_backup, and shared_prefs. First, the application will be analyzed to see what type of “tip of the iceberg data” can be uncovered, and then the investigation can move to the cloud resource, where additional historical data may be hiding.
FIGURE 16-15 Text files in the httpcache folder contain valuable information to identify the data within the associated data file.
com.fitbit.FitbitMobile
As mentioned, the folder structure for the app is similar to that of other Android apps that have been referenced throughout the book. In this section, the data that is available will be exposed in an effort to help the investigator gather intelligence when the Fitbit app is part of the investigation or when it may corroborate other data recovered.
The first folder, app_companions, contains JavaScript companion files that have been shown to hold no investigative data but that are important for the function of the running processes. Another folder, app_MixpanelAPI.Images.DecideChecker, will generally be next in the folder structure; it contains an image of the device that Fitbit has been set up to use.
The cache folder holds a tremendous amount of information, particularly the httpcache folder. This folder is where synced data is stored, from the Fitbit to the Cloud and from Fitbit to the mobile device. The mobile device then submits this data to the user’s account or receives it in the form of GET or PUT statements using the Fitbit API. This data includes not only app settings but also health settings. The files in this folder contain both text files and data files. Each data file has a unique filename with a 1 extension, and most have an associated text file, with the same name, with a 0 extension. The text file identifies the content, path to the data, and format of the associated data file.
Figure 16-16 shows the information that can be gleaned from the text file, indicating the path on the server via the API. The content of the associated file is in JSON format and in a compressed gzip file. The file was exported, and 7-Zip was used to uncompress it, while Notepad++ was used to format the JSON content. As you can see from Figure 16-17, the user needs more sleep!
FIGURE 16-16 The data file is uncompressed and the JSON file viewed to locate valuable content.
FIGURE 16-17 Parsed JSON file for sleep records recovered
The database folder contains all of the SQLite databases that one would expect in a mobile app. These databases are outlined with an overview of the data that can be obtained from each. This is not an exhaustive list of all the databases in the Fitbit app, but more of a guideline of places to look for pertinent data.
• datadatacom.fitbit.FitbitMobiledatabasesactivity_db This SQLite database will hold tables ACTIVITY_ITEM, ACTIVITY_LOG_ENTRY, MOST_RECENT_ACTIVITY, and others. The three mentioned tables are the most important because MOST_RECENT_ACTIVITY and ACTIVITY_LOG_ENTRY contain date and time information.
• datadatacom.fitbit.FitbitMobiledatabasescom.fitbit.FitbitMobile.devmetrics This file reports on the setup, particularly the setup of the device the app is running on, the Wi-Fi SSID, and TimeZone offset from GMT within the STORED_FSC_EVENT table.
• datadatacom.fitbit.FitbitMobiledatabasescoreux.db This SQLite file represents the built-in notifications for the Fitbit.
• datadatacom.fitbit.FitbitMobiledatabasesexercise_db This file records the exercises of the wearer. The data that is contained in EXERCISE_SESSION and EXERCISE_EVENT can be used when looking for event times, since date and times are logged in these tables.
• datadatacom.fitbit.FitbitMobiledatabasesfitbit-db This is the main SQLite database that contains the user information in the table PROFILE. This table contains the FULL_NAME, TIME_CREATED, TIME_UPDATED, DATE_OF_BIRTH (Epoch UNIX (ms), HEIGHT, GENDER, TIME_ZONE, and many others. Also in this database are several other tables, including ALARMS and DEVICE, which outlines date and time information of the last sync and the type of the device.
• datadatacom.fitbit.FitbitMobiledatabasesheart_rate_db This file reports on the daily average in the HEART_RATE_DAILY_SUMMARY table and can be JOINed with table HEART_RATE_ZONE to show the high and low values for the dates and times in the first table. This information can be important, especially when working cases to determine time of death when a user is wearing the Fitbit.
• datadatacom.fitbit.FitbitMobiledatabasessleep The Fitbit tracks the user’s sleep patterns. Within this database, the information on sleep patterns include dates and times, durations, and types of sleep.
• datadatacom.fitbit.FitbitMobilefilesUser<USERID>companion_dataplatform.db The Fitbit has several built-in apps, but the user can also add apps to the device, referred to as companions. Using this database, an investigator can uncover what apps are installed on the device. Within the companion table of the database is a listing of the apps along with the installation path, date modified, and the app name.
As discussed, an investigator can find data within the Fitbit app to help during an investigation, but the device must be collected at a physical level to expose the verbose information described earlier. However, the data that is sitting on the mobile device is often duplicated within the user’s Fitbit cloud account. The following section will describe collecting this type of information.
Fitbit Cloud
Like all the other IoT devices mentioned in this chapter, data for the Fitbit device is often just a username and password away. This mobile device communicates with the cloud sever using the Fitbit API. This is how commercial tools are able to collect and extract the information. However, the account will need to be authenticated by the investigator to extract the information successfully. Some tools, such as Cellebrite Cloud Analyzer, do not necessarily support Fitbit, but they do allow for the capture of the information from the front-facing user dashboard. Currently no commercial tools support the Fitbit Cloud. The method to obtaining the information from the Fitbit Cloud is very similar to obtaining Alexa Cloud data with the use of GET calls in a secure HTTPS instance. What is quite interesting is that Fitbit appears to have secured the extraction of this process with the utilization of a token process that differs from the authentication process of the Alexa Cloud. The information that can be received includes, but is not limited to, the following:
• Profile
• Friends
• Location and GPS
• Weight
• Device information and settings
• Sleep
• Food and water logs
• Activity and exercise
• Heart rate
The API information can be located at https://dev.fitbit.com, which an investigator can build on if a collection from the Fitbit cloud source is necessary. As mentioned, manually collecting this information is tedious and should be considered an advanced technique. However, the steps will be clearly documented here.
First, the investigator must visit the web page https://dev.fitbit.com/build/reference/web-api/oauth2/#obtaining-consent and create an account. This page documents the steps in obtaining an access token (OAuth2.0) that will allow the use of a secondary page to run API calls and retrieve data from the user’s account.
The user ID from the Fitbit app will be needed for this process. The user ID can easily be located in the file tree at datadatacom.fitbit.FitbitMobilefilesUser<USERID>. When creating the app, the investigator should elect READ-ONLY. This will allow only GET commands and not POST commands, helping to keep the integrity of the data within the user’s cloud store.
Once the testing app is created using this ID, the investigator selects all options for data on the Fitbit permissions screen. An OAuth 2.0 token will be granted to the investigator, who can move to the next stage using the online Fitbit testing tool at https://dev.fitbit.com/build/reference/web-api/explore/#/.
This online tool will allow for the query of data from the Fitbit server with the USERID that can be used to create the testing app and OAuth2.0. The investigator must be logged into https://dev.fitbit.com to utilize the functions and receive a JSON return. Several API calls are provided on the page, including profile, friends, location and GPS, weight, device information and settings, sleep, food and water logs, activity and exercise, and heart rate. For example, all API calls are prefixed with https://api.fitbit.com/1/user/<USERID> and then the data requested to extract.
Recall that the httpcache folder contains numerous text files that identify a data file obtaining data from the server. In the text file, the URL will contain a hyphen (-) instead of the USERID. This hyphen indicates that the data will come from the currently logged in user. These URLs can be used to query data from the server to obtain the data viewed on the mobile device. When using the Fitbit development page, the investigator will also use a hyphen (-) since he or she is logged in and using the target USERID.
Table 16-5 lists some of the commands and the expected results.
TABLE 16-5 GET Commands Using the Fitbit API to Retrieve User Information
FIGURE 16-18 User activity for the Fitbit user
Currently, the API GET commands listed enable commercial tools to extract data from the user cloud service. As mentioned, the Fitbit service does contain authentication hurdles that an investigator must overcome if the data is going to be extracted. However, like the Apple Watch data, the Fitbit data that can be obtained can bolster any digital forensic investigation.
Unmanned Aircraft Systems
In Chapter 3, drones were discussed along with their impact on several types of investigations. Drones are used to deliver prison contraband and drugs, to stalk victims, and to support terrorist efforts. These devices are easily available to anyone who wants to become a UAS pilot.
When the word drone is brought up in conversation, some people immediately picture the military drone, soaring above the earth on a secret mission. This chapter does not discuss the data within those types of drones, but focuses on data that can be collected from recreational drones that can be purchased from any electronics reseller. These devices have become a real problem for law enforcement, and tools have been developed to thwart the flying of these devices in restricted areas. However, continued illegal operations and activities will not cease even with certain countermeasures in place. An investigator must be prepared to tackle these devices if a drone is encountered in the lab.
This section will cover “tip of the iceberg data” to help an investigator establish a starting point when dealing with drones, particularly drones created by Dà-Jiāng Innovations (DJI). Because DJI is one of the largest and most prolific drone manufacturers, an investigator is more likely to encounter these recreational drones in an investigation than others. Data from these devices can be obtained from several locations, including the controller, the mobile app, the actual drone, the associated media card, and the associated cloud storage. An investigator will have to tackle several different angles, because the data from each is often unique. It is important that the investigator have a general understanding of the types of data that can be stored in the various locations. In the following sections, each area will be discussed and an outline of the data from each will be listed.
Mobile App: DJI GO
DJI uses its own mobile app, in two versions: DJI GO 4 and DJI GO. DJI GO 4 serves the Phantom 4 and newer devices, while DJI GO is used for devices that preceded the Phantom 4 series. Other apps specific to the DJI drone can also be accessed in an investigation. The non-DJI brands that may be located on a mobile device can include the following:
• Litchi Mavic Pro, Phantom 3 and 4, Inspire 1 and 2, Spark
• Airmap Mavic Pro, Phantom 3 and 4, Inspire 1 and 2, Spark
• UgCS for DJI Mavic Pro, Phantom 3 and 4, Inspire 1 and 2, Matrice
This section covers the DJI GO 4.0 in an effort to inform the investigator on the type of data that can be recovered from within the application. DJI GO contains a similar structure, and the examples discussed here can also be utilized. Both iOS and Android devices can be used as controllers using the DJI GO application. In an investigation, information such as flight logs, images, videos, account information, and flight information may provide critical data. Figure 16-19 shows the file system view of the com.dji.go app (com.dji.pilot for DJI GO app) that can be recovered from a standard iTunes backup extraction. An Android device will contain comparative data, and root access to the device is generally needed to recover the amount of records available in the iOS app. The Android app package is dji.go.v4, and some of the path information to data is covered next.
FIGURE 16-19 DJI GO 4 app file structure from an iOS device
The recoverable data that can help with an investigation is found throughout the folder structure. Some notable locations are shown in the following list. This information is by no means an exhaustive list, but these locations hold user data relative to the drone and its flight.
• privatevarmobileApplicationscom.dji.goDocuments.LocalCacheagpsagps_infoagps This file contains a binary plist file that contains a key, time_since_1970, that is a UNIX date for the time the app was launched and obtained a signal. This file also contains location keys, lat and lng. If location services are not provided to the app, the lat and lng will be set to 0.
• privatevarmobileApplicationscom.dji.goDocuments.mediaLibrarydjifile This folder contains file names by GUID. These are plist files that contain the metadata for the image files found in the .mediaLibrary.Cache Screennail and Thumbnail folders. Metadata includes the device used to produce the image as well as the created time.
• privatevarmobileApplicationscom.dji.goDocuments.mediaLibrary.Cache This path contains two folders, Screennail and Thumbnail. These folders contain the full images and thumbnails cached to the app either because the SD card was not used for storage, was default to the app, or was not inserted. All filenames are GUIDs, and the associated metadata can be found under the matching GUID in the djifile folder.
• privatevarmobileApplicationscom.dji.goDocumentsvideoCache This folder contains MP4 files of flights as well as the associated thumbnails stored to the app from the device. The filenames are the date and time of the recording (YYYY-MM-DD-HH-MM-SS).
• privatevarmobileApplicationscom.dji.goDocuments.3F88AF223C2B1FBA25A35BF02935F356 The JSON file will be named with the registered user’s e-mail.
• privatevarmobileApplicationscom.dji.goLibraryPreferencescom.dji.go.plist This property list file contains keys and values that identify milestones for the device. Values such as the total flight time, maximum height, user e-mail address, date user ID created, flight records with date/time, along with the country in which the flight took place.
• privatevarmobileApplicationscom.dji.goDocumentsFlightLogs This folder contains flight log .dat files that are prefixed with a date YYYY-MM-DD. This .dat file is a formatted text file that contains take-off dates, home point recorded date with altitude, and obstacles avoided with date and time.
• privatevarmobileApplicationscom.dji.goDocumentsFlightRecords This folder contains a file prefixed with DJIFlightRecord_<Date> with a .txt extension. This encrypted file contains the data records for the flight(s). The data contained within the text file includes the device and serial numbers along with GPS location, time, speed (meters per second), number of satellites used, altitude (barometric pressure and displays in meters above sea level), direction, power, and movement (meters per second) along the X, Y, and Z axes. The X axis is front to back, Y is side to side, and Z is up and down. This information can help the examiner determine flight path at a granular level. Note that the air pressure is set initially on preflight and helps with hovering and auto-landing. Some commercial tools such as Oxygen Forensic Detective parse and display this data for investigations (Figure 16-20). Also, the encrypted text files can be uploaded to online services such as www.phantomhelp.com/LogViewer/Upload/, which will also parse the information.
FIGURE 16-20 Flight information displayed in Oxygen Forensic Detective
Some versions of the app also have a folder called MCDatFlightRecords that contains a .DAT file that can be found on the SD card in the drone if inserted. This file contains fewer reading points than are in the associated encrypted text file, and it is not compressed or encrypted. The smaller file does not change the validity of the GPS data; it shows data generally every second of the drone flight.
From the DJI SDK documentation (https://developer.dji.com/mobile-sdk/documentation/introduction/flightController_concepts.html) the X, Y, Z concepts are described as “aircraft translation in positive X, Y, and Z is therefore defined in the Body Coordinate System as forward, right and downward translation respectively. Aircraft rotation is also described with these same axes using the coordinate right hand rule to define the direction of positive rotation. When describing rotational movement, the X, Y, and Z axes are renamed Roll, Pitch, and Yaw.”
For Android device apps and the dji.go.v4 app in a physical collection, the information and path to some important data are found within the media path datamedia DJIdji.go.v4. This location contains several folders that hold the cached imagery files as well as the log files for flights.
• datamedia DJIdji.go.v4CACHE_IMAGE This folder contains thumbnail images. Since most Android devices can have SD cards, the main images will be stored on the external media.
• datamedia DJIdji.go.v4DJI_RECORD This folder contains MP4 files of flights as well as a matching .info file that lists the metadata for the video to include GPS information, device type, and date and time.
• datamedia DJIdji.go.v4FlightRecord This folder contains the encrypted .txt flight logs.
• datamedia DJIdji.go.v4LOGMAP This folder contains log files with a date and time. Many of the log files will contain a value addHomeMarker, which provides the GPS coordinates and can be valuable to the investigation.
• datadatadji.go.v4databasesdji.db This SQLite database contains all of the devices and their serial numbers and the user’s registered e-mail.
By using multiple files from the app that controls the drone, an investigator can gain good information on the flights for the drone along with imagery captured and account information. Because multiple apps can be used to control and capture the data from the drone, not just the manufacturer app, the investigator must be aware of the currently available apps. The flight logs that can be extracted from the associated app can also be parsed online as well as using commercial tools supporting the data format.
Physical Acquisition
Drones capture information and store the data to non-volatile flash media. Like mobile devices, the drone’s data can be captured physically by invasive and non-invasive methods. Invasive methods include the removal of the chip from the device and reading in the associated reader/programmer; non-invasive physical collection includes obtaining root access via USB or another method and copying the user/system data. The chip-off procedure can yield a pristine copy of the data that had been recorded during flight(s). Because the device does not have to be powered on to receive GPS coordinates, several different flights and multiple registered home locations can be recovered. To perform the non-invasive physical collection, the device needs to be powered on, and this can cause the device to obtain a GPS lock. DJI protocol will then zero-out .txt and .dat files from the device. Note that the .txt files that had been logged to the mobile com.dji.pilot application can still remain, however. While the chip-off procedure does have advantages, the investigator should understand the circumstances of the case. Removal of the chip is destructive, and the drone will be inoperable; a non-invasive physical collection will not destroy the drone.
The data observable in a chip-off extraction—at the time of writing this manuscript, the entire blackbox folder—contains only incremented flight data as compared to the robust flight data, .dat files, and associated vision folder in the USB physical collection described in the following section (see Figure 16-21). This could result from a change in firmware between the time of chip-off extraction to the current USB extraction, which was approximately four months. An investigator can use the following non-invasive landmark sections for the investigation of a chip-off since the paths have been shown to be almost identical.
FIGURE 16-21 Primary folders in chip-off extraction are not observed, versus a USB physical collection.
Non-invasive physical collection offers many benefits, being a non-destructive means of extraction using a USB cable and Android root exploit. DJI, and many drone manufacturers, continue to upgrade the firmware on the devices in an effort to update the no-fly zones and to conform to changing legal requirements on recreational flying. However, the Android operating system that is still being utilized, often 4x, allows for the extraction of the user data with admin privileges. Note that DJI controllers run almost a duplicated OS version along with the firmware. This also allows for the physical extraction of the data from the device, using the same methods currently employed only (at the time of writing) within Oxygen Forensic Detective.
The user data folder structure is almost identical to that of the invasive chip-off technique, with the only limitation being that some files are zeroed out by the startup and acquisition of a location fix. Some working in the community of drone examiners advise that data is not available using extraction via USB and only via chip-off, but it seems that DJI devices simply increment the flight data file upon a new flight and remove the old data because of limited space on the 4GB onboard flash. Often the drone investigation comes to the lab without a mobile device or controller, and the drone will be the only evidence collected, so it is imperative that the examiner understand where some of the information can be located in an extraction with a USB.
• amtamtwifi.config This file contains the SSID of the drone as well as the passcode in clear text.
• amtamtBTBT_Address.txt This file displays the Bluetooth address of the device.
• amtamt fz fx.db This SQLite file contains all of the current latitude and longitude information for the no-fly zone that is often replicated in the mobile app. The table airmap_geofence_polygons outlines the country number as well as the radius for the geofence. As an investigator, this information can assist when dealing with no-fly zones to determine whether the device had the proper information about the restricted area.
• amtamt pi_testsn_dut This text file contains the serial number of the drone.
• lackboxlackbox Much like the blackbox on an airplane, drones have a controller box that records information from all aspects of the device to .bb files. Information from the camera, the network, the controller, the flight system (vision), and all other running processes are stored in these folders. Generally, files are zeroed out by the DJI system with all containing a latest file that shows the last file that was being used to record flight data and calibrations.
• lackboxlackboxflyctrl This folder contains all of the .DAT files of the logged flights and the contents described in the previous mobile app section. The files are prefixed with the date with FLY<n>.DAT and the number is incremented. These flight files are encrypted, but they can be decrypted in most commercial tools.
• userdatadatamiscwifihostapd.conf This file contains the Wi-Fi SSID as well as the country this Wi-Fi was obtained in, and the password is in clear text.
• userdatadatamiscwifiwpa_supplicant.conf This file contains the Wi-Fi SSID, and the password is in clear text.
The information that can be obtained from a physical extraction can help to supplement data recovered from the mobile device that had been used to control the drone. Also, if the mobile device is not available, important data, including flight logs, Wi-Fi, country where the flight took place, and user data, is recoverable. Remember that avoiding the acquisition of signals (Wi-Fi, Bluetooth, GPS) is important if the recovery takes place via the USB port. Likewise, recall of the DJI drones will zero-out files included in the blackbox as well as flight records. However, I have been able to recover multiple flights both from the mobile device (more probable) and drone device.
Media Card
Media cards, generally miniSD cards, are used by the drone to store flight logs as well as imagery. An SD card does not have to be inserted into the drone to function. If an SD card is not inserted, the data is stored directly to the mobile device that has been paired with the drone. If the drone is using a radio control (RC) controller independently, the data will be stored to the drone’s internal flash. This section discusses the data structure an investigator should expect to see on an SD card.
The file system on the SD card is formatted as FAT and can be read in tools such as FTK Imager, Oxygen Forensic Detective, Cellebrite UFED4PC, and Magnet AXIOM. As with acquiring data from removable media, the investigator should take all precautions when creating a forensic image of the card (photograph, write block, image, and work on copy). Once the image is created, the folder structure is similar to what would be expected from a digital camera. However, in the root of the file system are the drone’s .DAT files. The .DAT files utilize encryption that differs from that of the internal .TXT files or mobile device .DAT files, but the data is consistent between files. These files can be brought into many commercial tools such as Oxygen Forensic Detective, Cellebrite UFED4PC, and MSAB XRY. The data is then overlaid on a map to produce a flight path and route.
Two additional folders are created on the SD card: the DCIM folder and MISC folder. The DCIM folder contains the images and videos captured by the drone’s camera. The drone captures and stores EXIF metadata for both videos and images, which can then be used to identify location—a fantastic piece of evidence for the investigation. The following illustration shows the skyline in Singapore taken with a DJI Spark. A great piece of evidence, the SD card and UAS were seized in another country. Within the MISC folder is a secondary folder, THM, which will contain the thumbnails of the files found in the DCIM folder. The prefix of the THM file will correspond to the media file within the media folder.
Data on the SD card should not be overlooked, because it will contain information that may not be found within the mobile device app or even within the drone itself.
Cloud Services
Drone storage, like storage on many other devices, has moved to the Cloud. The information transitions from the mobile device, as a controller, and into the appropriate cloud service. This storage location can provide a treasure trove of flights, account information, and imagery. The user must subscribe to this service and is not obligated to sign up to use the Cloud for the drone to be operational. However, as an investigator, the knowledge of another source of data is paramount, especially if the drone, controller, or both are not available.
Users of DJI devices have the opportunity to sign up to use the DJI Cloud via the DJI GO app, where they can store their profile, device info, media, and flight logs. Users can also upload the information to SkyPixel to share their videos with the community. The uploading of the data is not automatic for the user. The user must set up the account and elect to sync the logs to the Cloud. Currently, Oxygen Forensic Cloud Extractor is the only commercial tool that can extract profile, devices, media, flight logs, username, password, and token. Look for the following in the extraction; these files are relative only to the extracted data with the Oxygen Forensic Cloud Extractor.
• cloud.dji.data<UserEmail>DroneFlights.json This JSON file contains the general flight data for a single event for each device by serial number. The serial number of the drone is listed, along with longitude and latitude, total distance, flight time, and a date and time.
• cloud.dji.data<UserEmail>Main.db This SQLite database is a gold mine of user data and drone data. Within the database are three tables: account_info, dbver, and drones_info. In account_info, the investigator will find the e-mail address, password, token, username, date signed up, and physical address (if entered). Within the table dbver is an integer indicating the database version. Table drones_info contains anything and everything pertaining to each drone using the account. This information includes but is not limited to serial number, the countries the devices has flown in, the drone type and name, and totals on flight time, distance, speeds (m/s), and altitudes (m). All are the maximum numbers from all flights, but also shown are the dates the maximum was recorded.
• cloud.dji.data<UserEmail>Avatarsaccount.jpg This is the image file the user uploaded to the DJI Cloud account.
• cloud.dji.data<UserEmail>RawLogsDJIFlightRecord<Date>.txt These text files contain flight data much like the records found on the mobile device controller and the onboard flash for the drone. These text files use a form of encryption that differs from that of the mobile device and onboard flash, and they are supported by tools such as Oxygen Forensic Detective. What is extremely important to understand is the fact that logs in the cloud can include every flight the user has taken, along with images. This data is not zeroed out like the onboard flash or mobile app, making this repository extremely important and valuable to the investigation. Figure 16-22 shows flight paths from DJI cloud extraction.
FIGURE 16-22 Flight paths produced with data from DJI cloud extraction overlaid in Oxygen Forensic Maps
The information that can be obtained from the drone’s user storage cloud service cannot only complement the data that has been extracted from the device but also can open the door to additional data that could not be recovered or is not accessible from the controller, mobile app, and even the drone. The information within cloud services should never be discounted.
Chapter Summary
From IoT devices in the home, to wearable devices, to recreational drones available in any electronics store, today’s investigator must be prepared to handle this emerging trend and the extraction of data from these state-of-the-art devices. Some may want to use the word “threats” instead of “trends,” but that is not an accurate statement. These devices can simplify the lives of users, help to notify people of health problems, and protect the public safety. However, as with any device, some users will push the limits, or rather use the limits, to satisfy a nefarious purpose to their gain. IoT forensics is not much different from the infancy stages of mobile device forensics. At that time, classes were being taught on how to take pictures of the data on the device in an effort to document the information, or in utilizing tools that sync software, since there were no “forensic” tools back then. This is where digital investigations of IoT devices must rise above the days of Wild West forensics. Nevertheless, the industry—and both commercial software and forensics examiners—is not there yet.
The collection of data from these device types is all but simple point-and-click. Acquiring data from these devices can be extremely time consuming, if not frustrating. As indicated throughout the chapter, extracting the information can involve several methods as well as several locations in which the data may reside (such as mobile device, Cloud, controller). Autonomous extraction and parsing of IoT devices to include wearables, vehicles, and drones is in the infancy stages of development by commercial tools. It will be up to the investigators and examiners to work through the weeds to develop strategies to attack these new data repositories.
IoT devices such as the Amazon Echo series using Alexa and Google Home will only grow in popularity. There have already been documented cases of this data being used, or rather attempted to be used, in civil and criminal cases. With most, if not the majority, of the available home smart speakers, TVs, and other connected devices, the data is available within a cloud service dedicated to a user. If this was not the case, the user would not be able to log in using a mobile device to check the status of the contents of the refrigerator or to access the front door. It is simply a matter of investigation and observation.
With wearable devices, data is also available within the Cloud, and within the produced backup in the case of the Apple Watch. Because this is such a new frontier, however, the extraction of devices such as the Fitbit is tedious work, since currently a lot of manual work is involved using the published API. With wearables, from clothes to eyewear, the data is available—it just comes down to the location of the repository, the method used to access data, and ultimately making sense of the output. Sounds easy. Unfortunately, as outlined in this chapter, it will continue to be a lot of work for the foreseeable future.
The number of drones available to anyone in the world continues to grow daily. Coupled with easy availability and a plethora of features, the use of these once recreational devices has shifted to assist in devious behaviors. Stalking, terrorism, drug delivery, prison contraband delivery, border crossing, and national security breaches have been attributed to alternative use of drones. The astonishing fact through investigation indicates that the interrogation of these devices by digital investigators is almost non-existent outside of military investigations. With the number of recreational drones in use anticipated to reach more 450,000 devices by 2022 and 300,000 commercial drones by 2022, as reported by the Federal Aviation Administration, it is a certainty that these devices will be in every investigator’s lab.
The data presented in this chapter has been grown from research, communication with industry experts, and a lot of work. Simply said, there is not a lot of documentation on this type of data collection anywhere in the world, and within this chapter, some information has never been documented and discovered until now. To those experts mentioned in the chapter: thank you for your diligence and hard work. To all investigators: follow-up with your documentation to gain a better understanding, rather than relying solely on what was presented in this chapter.
To sum up the information discussed in this chapter, there is an unbelievable wave of data and data sources that are coming and that are currently here. Whether you are a seasoned digital forensic guru or a green investigator, the data collected from these devices will be invaluable in painting a total picture of our digital world. Be prepared.