A Digital Forensics Case Study of the DJI

Mini 3 Pro and DJI RC

Aaron Taylor

Abstract— The consumer drone market is rapidly incidents and illegal use of drones has inevitably increased the
expanding with new drone models featuring unique number of Digital Forensic (DF) investigations involving
variations of hardware and software. The rapid drones [3], [9].
development of drone technology and variability in drone Drones present several challenges to the DF field. They often
systems can make it difficult for digital forensic feature a complex array of technologies, including wireless
investigators and tools to keep pace and effectively extract communication, GPS, and cameras, which can make it
and analyse digital evidence from drones. Furthermore, the challenging for investigators conducting a DF investigation [8],
growing popularity of drones and their increased use in [10]. There is also a lack of modern DF tools specifically
illegal and harmful activities, such as smuggling, espionage, developed for drones [4], [10], and this, combined with the fast-
and even terrorism, has led to an increase in the number of paced development of drone technologies, can rapidly render
drone forensic cases for authorities to manage. To assist
available tools obsolete and unfit for purpose [4], [5].
forensic investigators, a static digital forensic case study was
Additionally, Drone Forensics (DRF) is a relatively new
conducted on two drone devices recently released by Da-
discipline within the DF field. Only recently, Interpol published
Jiang Innovations (DJI): the Mini 3 Pro drone, and its
remote controller, the DJI RC. The study discovered the guidelines for DRF investigators [8], and researchers [4], [10]
presence of several digital artefacts on both devices, have proposed novel methodologies for the DRF field. Despite
including recorded media, flight logs, and other information these efforts, there still remains a lack of universally agreed
that could help investigators trace the drone’s usage and methodologies and approaches [9], [11], presenting further
identify its operator. Additionally, this paper explored challenges for DF investigators to navigate.
several methods for extracting and visualising the drone’s To ensure DF investigators are effective at conducting DRF
flight history, and highlights some of the potential methods investigations, they require specialist knowledge and skills [3],
used to limit, obscure, or remove key types of digital and should be aware of the limitations of the DF tools they use
evidence. [5]. DRF guidelines such as [8], published by government
agencies, and DRF case-studies such as [10] and [12] by
Index Terms— digital forensics, drone forensics, flight logs, academics, could assist DF investigators to address these
investigation, flight visualisation, telemetry, digital evidence. challenges [13].
Forensic case studies of older drone models, particularly DJI,
I. INTRODUCTION 1 appear widely in the literature; however, there appears to be a

D rones are unmanned aircraft vehicles (UAVs) that typically

operate autonomously by an onboard computer or
controlled remotely by a human pilot [1]. Drones were typically
gap relating to the newer DJI Mini 3 Pro and its remote
controller (RC) the “DJI RC”. This is not surprising given that
both devices were only recently released to the market. This
limited to police, search and rescue, and military operations [2], study aims to address this gap by performing a static forensic
[3]; however, in recent years they have become increasingly case study on these devices, with a particular focus on
popular in commercial and recreational settings due to various identifying the presence of key digital artefacts that could be
factors, such as declining cost, changing public perception, and useful to investigators. Additionally, the paper explored
expanding range of applications ranging from recreational methods for visualising the drones flight history and assessed
flying, agricultural spraying, parcel delivery, through to aerial some of the potential anti-forensic (AF) methods that could be
photography and surveying [2], [4]. utilised on these devices. It is hoped that the findings of this case
While legitimate use of drones has increased, so too has their study will assist investigators and researchers in future DRF
involvement in illegal activity and accidents [5]. The Federal analysis of these specific devices.
Aviation Administration (FAA) has reported an increase in This paper is structured as follows: Section 2 discusses
drone accidents and incidents in the last two years [6]. related work in drone forensics. Section 3 explores the
Additionally, there are reports of drones being used for illegal methodology applied in the case study. Section 4 presents the
activities, such as drug smuggling, gathering intelligence for results and analysis. Section 5 discusses findings of the
criminal purposes, disrupting critical infrastructure, and even research, and lastly, Section 6 of the paper concludes with future
terrorism [3], [4], [7], and [8]. The increasing number of drone research directions.

.
 II. BACKGROUND AND RELATED WORK is considered less significant when compared to static forms of
digital evidence.

A. Key Data Types

C. Acquisition and Analysis Approaches
There are several types of digital artefacts potentially
valuable to forensic investigators. According to Interpol [8], As seen in [3], [7], and [15], drone forensic acquisition and
these include recorded media (digital imagery and video analysis approaches can be grouped into two broad categories.
One of these is the “static” approach, which involves extracting
footage), flight logs, payload created content (e.g., drop zone
and analysing data at rest which is not subject to change [16].
locations), Personally Identifiable Information (PII), and usage
An example of a static approach, one of which is demonstrated
logs (e.g., system and sensor logs). These key data types were
by [10], is extraction and analysis of metadata stored within
the focus for drone forensic case studies completed by [3] - [5], images extracted from a Secure Digital (SD) card used in a
[10], [14], and [15], further supporting the recommendations drone. The static approach typically involves imaging a disk of
provided by [8]. the target system while it is powered off [17]. The other type of
While flight logs are key evidentiary items in DRF [8], approach is a “live” approach, which involves extracting and/or
extracting and processing them can be time-consuming, as they analysing data that is dynamic and subject to change [16]. In the
can be encrypted, granulated, and unstructured in their raw form context of DRF, this would include wireless data transmitted by
[14]. Their structure can also vary significantly between drone the drone’s systems and interacting with the devices while they
makes and models, which can present further challenges for are powered on [3]. Live approaches were taken by Schiller et
investigators [13], [14]. Case studies on the DJI Phantom 4, al. [7] and Salamh et al. [3]. Of the two approaches, the static
Yuneec Typhoon, and the Parrot Bebop by [14] found that the approach was most widely used among studies by [4], [5], [10],
flight logs for the Parrot Bebop and Yuneec Typhoon were and [12] - [15]. This may be due to the additional complexities
unencrypted and able to be parsed more easily than that the DJI often involved in live forensic approaches.
Phantom 4, which in comparison had encrypted logs containing There are four data extraction methods that can be applied to
substantially more parameters. DRF: manual extraction, logical extraction, physical extraction,
Although payload data could indicate transportation of illegal and wireless extraction. Manual extraction involves direct
goods by a drone, only [10] included it as a focus of their drone interaction with the remote controller and/or taking photos of
forensic case study. It appears that research focusing on this data what is shown on the screen, while logical extraction obtains
data from a readily available part of the file system (usually
type is lacking in current literature.
presented as directories and files and does not normally include
In terms of PII, [4], [10], and [13] mention attribution of
access to unallocated space nor previously deleted files) [18].
drone ownership as a key goal for investigators. Some of the
Physical extraction utilises a bit-by-bit copy of the storage
types of PII include the user account of the drone operator [8], medium, and, unlike logical extraction, includes unallocated
their location data [7], and serial numbers of the drone, RC, and space [9], [18].
batteries [13]. Researchers [4] concede that PII data is more Physical extraction methods may include reading the data
likely to be found on the RC rather than the drone itself. from a chip located on its host device [15], and are usually
performed on a wired-interface such as a Universal
B. Data Sources Asynchronous Receiver Transmitter (UART) [7], or Joint Task
Action Group [8], also located on the host device. Case studies
There are several possible sources for acquiring data from by [3], [4], [12], and [13] successfully retrieved digital artefacts
drones. The sources typically include non-volatile memory using some or a combination of these methods.
sources (internal memory and external memory cards), volatile Other physical extraction methods include ‘chip-off’. ‘micro-
memory sources (e.g., Random Access Memory), sensor data read’ and capturing wireless Radiofrequency (Rf) signals [19].
(e.g., propellers and camera), and wired and wireless network The ‘chip-off’ method involves removing the target chip from
systems (e.g., Universal Serial Bus [USB], Wi-Fi, and its host device and placing it in a reader or another similar host
Bluetooth) [9]. Studies by [3], [13-15], examined data acquired device to extract the data directly from the chip [18]. Unless the
from non-volatile memory sources of the drone/RC, specifically chip has full disk encryption, this method could potentially
the internal memory of the drone and smartphone-based RCs, bypass any authentication and encryption mechanisms applied
and removable SD cards used in those devices. Conversely, the by the chips’ usual host device [18]. The ‘micro-read’ method
study by [7] focused on wireless data produced by the DJI’s involves removing the top layers of silicon from the storage chip
DroneID system (a proprietary wireless drone identity and to expose the logic gates so they can be examined with electron
location beaconing system) on several DJI drones, while [3] microscope which can read the data [9]. Wireless data extraction
applied vulnerability testing exercises against two drone models methods typically involve the use of a wireless Rf receiver, such
in an attempt to examine wirelessly transmitted data over the as the Software Defined Radio (SDR) receiver used by [7] to
drone’s Wi-Fi systems. Drone forensic guidelines by [8] capture wireless Rf signals from several DJI drone models.
mention the following possible sources of data: removeable Both the ‘chip-off’ and ‘micro-read’ methods typically offer
memory cards, internal memory, cloud-based storage, wireless investigators the most amount of data from the drones, however
systems (e.g. Wi-Fi and Bluetooth) and Internet services used they are more complicated to undertake, require specialist
by the drone. hardware and tools, and are often destructive to their host target
While [5] and [11] suggest there is value in data gathered from devices [4]. Researchers in [13] had success in partially
wireless-based signals, [11] stressed that this type of evidence
recovering a previously deleted image using a chip-off method also highlighted it as a possible AF technique that could be
on a DJI Phantom 4 and [15] also recovered data from a DJI exploited.
Mavic Air 2 using this method. This data was not discovered by To help address the difficulties associated with tracking the
the less invasive methods. However, utilising extraction identity and location of drones operating in United States (US)
methods that are likely to alter or damage the original source of airspace, the FAA will be mandating a wireless identity and
data or host device is not best practice in DF and is only location broadcasting system, which they are calling RemoteID,
recommended when data deletion is suspected and/or data by the end of September 2023 [22]. Their mandate stipulates
retrieval by other methods has been unsuccessful [9], [13]. that all drones operating in US airspace will need to be
Drone forensic guidelines by [8] recommend that wirelessly broadcasting their identity and location to authorities,
investigators apply a variety of acquisition and analysis
and that all drone pilots will need to be registered with the FAA
methods to drone investigations. This recommendation is
[22]. To help DJI drone owners meet the FAA’s RemoteID
supported by [10].
requirements, DJI have implemented their internally developed
Another approach to gaining access to normally inaccessible
areas of a storage device is to obtain root privileges [15]. This RemoteID system (DroneID) on several of its drone models [7].
is usually achieved by exploiting a vulnerability in the software Despite this, a study of DJI’s DroneID system by [7] found that
running on the device [15]. Studies by [3] and Schiller et al. [7] it was susceptible to spoofing, which could lead to
involved the use of vulnerability testing techniques in order to misattribution of a drone operator and/or complete avoidance of
gain elevated privileges and access data from the drone/RC that attribution.
were normally off-limits to the user. Although [7] identified There are a variety of tools available for a DRF investigation,
methods for gaining root access to an RC used in their study, and often several tools are required [10]. For example, a case
they did not publicly disclose the details of the vulnerabilities. study of the DJI Mini 2 by [10] encountered issues when they
Although methods to gain elevated privileges could yield attempted to decrypt .DAT type flight logs using DatCon, but
promising results, it could unintentionally alter the data on the were able to successfully decrypt them in an online flight log
target device, which would be a violation of one of the parsing and visualisation site called “Airdata UAV”
Association of Chief Police Officers (ACPO) principles of DF (https://app.airdata.com/).
[20, p 6,],“Principle 1: No action taken by law enforcement Another key challenge in DRF relates to limitations of
agencies, persons employed within those agencies or their forensic tools. The tools available to a forensic investigator
agents should change data which may subsequently be relied could turn out to be unreliable for a variety of reasons. For
upon in court”. example, DatCon, an open-source flight log decryption tool was
To generally avoid altering data on a target device, it is successfully used by [3], [13] to decrypt flight logs acquired
recommended to use a write blocking device where possible from a DJI Phantom and a DJI Matrice, however this tool was
during the data extraction phase [8], [17]. Existing DRF case reportedly not able to decrypt flight logs from a DJI Mini 2
studies by [5], [10], [15] mentioned using either hardware- or when attempted by [10]. The inability of the tool to be able to
software-based write blockers when imaging data from SD decrypt the logs from the Mini 2 is likely due to changes made
cards. in the encryption and/or specification of the flight log standard,
Some DF studies have focused on drone wireless systems. For which the manufacturer can change at any time in a firmware
example, [7] examined DJI’s DroneID system using a SDR update. In another example, [3] assessed the capabilities of two
receiver. Their study concluded that the data transmitted by the popular forensic analysis tools: Autopsy and Cellebrite, and
version of DroneID operating on several DJI drone models found a slight discrepancy between the timestamps presented
examined in their study was not encrypted, despite the for a flight log acquired from a DJI Phantom. The researchers
manufacturers claims otherwise [7]. Schiller et al. [7] were also in [3] also discovered that Autopsy and Cellebrite generalised
able to manipulate the DroneID system to send a spoofed serial the flight log waypoints, while DatCon produced the most
number and GPS location of the RC. accurate results. However, the same researchers also found
DJI have also developed Ocusync, a proprietary wireless slight differences in the values outputted by log files parsed by
system for control and video downlink of compatible DJI model DatCon when Java compiler was used. Slight discrepancies can
drones [7]. The DJI Mini 3 Pro and DJI RC both reportedly use have significant forensic implications [3]. To this end,
Ocusync version 3 [21]. Like DroneID, the specifics of this researchers [4], [5], and [10] recommend that investigators have
technology have not been publicly documented by DJI [7]. a thorough understanding of the capabilities and limits of the
Schiller et al. [7] study also examined Ocusync 2.0, which they available tools.
believed was the host transmission protocol for DroneID. A lack of DF methodologies and guidelines pose another key
challenge. According to current literature, there is no consensus
among researchers on methodologies, guidelines, and standards
D. Key Challenges for DRF investigation. For example, researchers [10] referenced
Although attribution is a key goal of DRF, it can be difficult application of the National Standards and Technology (NIST)
to achieve for various reasons. [14] cited technical reasons as a DF guidelines for mobile devices [19] for their case study of the
significant challenge. As an example of this, [10] DJI Mini 2, while [9] and [13] cited Interpol DRF guidelines as
unintentionally found that the DJI Mini 2 drone examined in suitable.
their study was unable to get a GPS signal lock and fetch Researchers [9] and [11] reviewed several existing DRF
location coordinates when it was flown inside a sports hall. models and identified gaps in the models. [9] claimed that
While this finding was the result of a technical limitation, [10] existing DRF methodologies focus on traditional computer
systems or mobile devices, which were not specific enough to A. Experiment Design
address the cyber-physical nature of drones, while [11] posited To minimise the amount of unrelated data and cross-
that many of the existing models were not versatile enough to contamination of data in the case study, the experiment
provide coverage for all drone models and technologies. Both environment was controlled as much as possible given the
[9] and [11] agreed that the DRF field was in need of resources and time available during the study.
standardised international guidelines. In an effort to further To keep the study within key data of interest, data acquisition
develop an international standard, researchers [11] proposed and analysis methods were aligned with guidelines by [8]
their own model which they believed made up for the “Framework for Responding to a Drone Incident: For First
shortcomings of the models they reviewed. Their proposed Responders and Digital Forensics Practitioners”.
model considered both legal and technical aspects of the DRF In addition, four scenarios were devised to simulate possible
domain and included a preparation phase, something they real-life situations initially faced by a digital forensics'
claimed was lacking in existing models. Despite claims by [9] investigator performing a drone forensic investigation. These
and [11], Interpol, an international organisation, had already scenarios were:
made efforts to develop an international standard by publishing
their own DRF guidelines [8]. 1) Scenario A: In this scenario, only the drone is recovered
The ability to identify and track drones and their pilots is by authorities at the scene. The device is fully functional and
another challenge of DRF. RemoteID, which the FAA is contains an external Micro SD card. The RC did not contain an
mandating in September 2023, is envisioned to assist forensic SD card prior to, or during, the flight. The flight involved a safe
investigators by providing authorities with drone tracking and take-off and landing and was unremarkable.
identification of pilots in US airspace [22].
2) Scenario B: In this scenario, only the RC controller is
E. Gaps in the Literature recovered by authorities at the scene. The device is fully
The majority of forensic case studies in the literature focus functional and contains an external Micro SD card which was
on DJI models. The reason for this is likely due to the fact that used during the flight. Additionally, the SD card in the RC was
DJI are the most popular drone manufacturer, claiming a 76% selected as the primary storage device and the drone did not
global market share [23]. To best of authors knowledge, there contain an SD card. The flight involved a safe take-off and
are no published DRF case studies on the Mini 3 Pro or the DJI landing and was unremarkable.
RC.
In addition, [10] claimed there was a lack of literature 3) Scenario C: In this scenario, both the drone and RC are
pertaining to DRF of drones weighing less than 250 grams. recovered, they are fully functional, and both contained an SD
Their study of a DJI Mini 2 attempted to partially address that card during flight. The flight involved a safe take-off and
gap. landing and was unremarkable.
The majority of DRF studies reviewed that involve flight log
analysis, used online based tools, which require uploading the 4) Scenario D: In this scenario, both the drone and RC are
data to a third-party provider. This may raise privacy concerns recovered, however neither device contained an external SD
for sensitive cases. None of the literature reviewed appears to card during the flight. Additionally, the drone was flipped
have utilised the Flight Reader software, a Windows-based upside down by hand toward the end of the flight to simulate a
application that was designed to locally decrypt and present DJI collision. The simulated collision resulted in both devices being
flight logs in text and visual forms. partially damaged prior to the investigation, and as a result, the
A review of the literature indicates a lack of research into AF Universal Serial Bus (USB) ports were inoperable during the
methods for drones. This conclusion is echoed by [4], who calls investigation. Despite this, both Wi-Fi and Bluetooth systems
for more research into AF techniques of drones. were functional. Furthermore, to simulate a potential anti-
“CIAJeepDoors” is an open-source Python program that its forensic tactic, the user account was logged out of the DJI Fly
author claims is capable of disabling DroneID on some DJI app on the RC immediately prior to the flight.
drones [24]. This application was not mentioned in any of the
reviewed literature. These scenarios were conducted in the order presented. In all
scenarios, the identity of the drone’s operator and usage are
III. METHODOLOGY treated as unknown, and the goal of the forensic investigator is
to try to determine this information from digital artefacts
acquired from the devices.
The selected research methodology in this paper aimed to This DRF case study also identified possible digital anti-
address the research questions presented in Section 1 by a) forensic methods available for these devices. However, due to
comprehensively assessing the digital evidence characteristics time constraints, these methods were not thoroughly tested
of the DJI Mini 3 Pro and DJI RC, b) extracting and analysing during the study.
key digital artefacts from the selected devices, c) exploring The primary focus for this DRF case study was on the digital
methods for visualising the drone’s flight history, and d) data stored on the internal storage memory of the selected
highlighting potential anti-forensic tactics for these devices. An devices and removable storage devices used during the
individual case study design was selected to address the experiment. DJI’s cloud storage service and proprietary
research questions. The parameters of this case study are wireless systems, Ocusync and DroneID, were not in scope of
described in further detail below. the study.
B. Process workflow to generating data for Scenario A; however, it was discovered
The high-level workflow for the practical elements of the during subsequent analysis of this scenario that previously
case-study is shown in Figure 1. Each scenario starts with a deleted files were still present on the card, leading to cross-
preparation phase, followed by data generation, then extraction contamination of data between the scenarios. For successive
and analysis, and lastly, recording of the results. scenarios, the native Linux Data Duplicator utility was used to
zero out the SD cards. Additionally, after each sanitisation
activity, the cards were carefully examined using Autopsy to
verify that they did not contain any remnants of data. When it
was confirmed that a card did not contain data, the SD card for
the drone was formatted using the native format tool in the
Windows OS and the card used in the DJI remote controller was
Fig. 1. The generic steps followed for practical elements of the case study.
formatted using the native Android Files utility on the RC.
Further detail on the preparation, data generation, extraction,
4) Mini 3 Pro Drone: The DJI Mini 3 Pro (Model: MT3M3VD)
and analysis phases are provided in the following sections. The
is a sub-250g multi-rotor consumer class drone developed by
‘record results’ phase entails making comprehensive notes of DJI. Its key features are a 3-way collision avoidance system,
the results and documenting them in this article. GPS connectivity, a stabilized 3-axis gimbal, and a 1/1.3-inch
sensor camera that is capable of recording 4K resolution video
C. Preparation and Equipment and capturing 48-megapixel images [21]. A topside view of the
DJI Mini 3 Pro drone that was examined in the study is shown
1) Forensic Workstation Setup: A laptop was set up
in Figure 2.
purposely for the experiment. It comprised of an i9 Intel Core
processor, 64 GB of ram, and a 1 TB hard drive. The host OS of
the machine was Windows 11. Virtual machine (VM)
environments were setup specifically for the experiment. The
VM’s were Windows 10 OS (see Microsoft.com) and SANS
SIFT Linux Workstation (see sans.org).

2) Tools: Several tools were utilised in the case study.

Table 1 outlines these tools. The primary digital forensic tools
used in the study (FTK Imager and Autopsy) are popular in the
digital forensics field. Two DJI developed applications, DJI Fly
and DJI Assistant 2, were used in the study. DJI Fly was utilised
for a range of activities, including controlling the drone,
displaying the drone’s live video feed on the RC, capturing, and
viewing recorded media, and transferring recorded media
between the RC and a compatible device. The DJI Assistant 2
tool is a Windows/Linux-based tool that provides the ability to
extract logs from non-user accessible storage areas of the Mini
3 Pro and DJI RC. These tools assisted in examining and
extracting digital artefacts devices from the devices.
Several tools were used for parsing and visualising flight logs Fig. 2. A top-down image of the DJI Mini 3 Pro drone.
over satellite imagery. DatCon and Flight Reader
(https://www.flightreader.com/) were used for initial decoding The drone and RC utilise DJI’s Ocusync protocol (version
and parsing of the logs, while the ‘Airdata UAV’ website,
3.0) for control plane and video feed communication [21].
Google Earth Pro, and Flight Reader were utilised for flight path
Currently there is no option for a user to factory reset the drone
visualisation.
or format or wipe its internal memory. The only known non-
Many of the tools selected for the study were either freeware,
open-source, or already owned and licenced by the researcher invasive option available to users is to delete existing files and
prior to the study. Open source and freeware tools were directories from the drone’s internal drive while it is mounted
preferred over proprietary tools for this case study due to cost by a suitable device. This is not an effective method for
constraints. The tools used in the study were installed on their sanitising data on the drone’s internal storage. As the drone was
respective VM’s as outlined in Table 1. extensively used prior to the experiment, it contained data from

3) External Storage Cards: Two SanDisk Ultra Class 1 Micro-

SD cards (a 16 GB and 32 GB) were used in scenarios A, B and
C. To lessen the possibility of cross-contamination of data
between the scenarios, both Micro SD cards underwent data
sanitisation prior to and in between the data generation phases
for scenarios A, B and C. The SD Association’s card formatting
tool “SD Card Formatter” was used to prepare both cards prior
 TABLE 1
HARDWARE AND TOOLS USED

Hardware/Tool Version Description Usage Availability Vendor Link

Flight system
Model: MT3M3VD.
DJI Mini 3 Pro Firmware 01.00.0400 Drone. Generate data and examination target N/A www.dji.com
Model: RM330. Firmware Drone navigation/run DJI Fly application/capture live
DJI RC 01.02.0100 Drone remote controller. video feed and examination target N/A www.dji.com
1.8.0 (RC)
DJI Fly 1.9.1 (iPhone 13) Support tool Drone control/Data transfer Freeware https://www.dji.com/downloads/djiapp/dji-fly
SanDisk Ultra Micro
SD card 32 GB SDXC Class 1 Data Storage. External data storage for drone N/A sandisk.com
SanDisk Ultra Micro
SD card 16 GB SDXC Class 1 Data Storage. External data storage for RC N/A sandisk.com

Forensic extraction and analysis tools

Forensic workstation Metabox Prime-SR Windows-OS-based laptop Primary forensic workstation Proprietary metabox.com.au
SIFT Ubuntu 20.04 Linux-OS VM environment Open source https://www.sans.org/tools/sift-workstation/
https://www.microsoft.com/en-au/software-
Windows 10 10 Windows-OS VM environment Proprietary download/windows10
VMware
Workstation Pro 16.2 VM application For running VM environment on host OS Proprietary vmware.com
Smartphone based DJI Fly app
Apple iPhone 13 installed To acquire media and flight logs via Wi-Fi/Bluetooth N/A apple.com
DJI Assistant 2 https://www.dji.com/downloads/softwares/dji-
(consumer series) 2.1.15 Support tool. Firmware update/Data download Freeware assistant-2-consumer-drones-series
Linux Data
Duplication Utility N/A For wiping data on MicroSD cards Preparation for data generation Open source linux.org
Micro SD card
adapter N/A With hardware write blocker switch hardware based write blocker N/A www.sandisk.com
SD card reader N/A Unitek USB card reader Data extraction N/A www.unitek-products.com
Autopsy 4.19.3 - Windows 64-bit Forensic imaging and analysis tool Imaging/hashing/analysis Open source https://www.autopsy.com/download/
AccessData FTK 4.3.0.18 – Windows 64-
Imager bit Forensic imaging and analysis tool Imaging/hashing/analysis Freeware https://www.exterro.com/
Exif Tool 5.16.0.0 - Windows 64-bit Image metadata viewer Extract metadata from images Freeware http://u88.n24.queensu.ca/exiftool/forum
VLC Media Player 3.0.18 - Windows 64-bit Video viewer View recorded videos and flight telemetry Freeware https://www.videolan.org/vlc/
Offline DJI Flight log decrypting
DatCon 4.2.6 - Windows 64-bit tool Alternative tool for decrypting DJI logs Open source https://datfile.net/DatCon/intro.html
Notepad++ 7.9.5 - Windows 64-bit Text editor For viewing .DAT and .TXT files Freeware https://notepad-plus-plus.org/
For viewing Joint Photographic Experts Group
Infranview 4.62 - Windows 64-bit Image viewer (.JPG/.JPEG) images Freeware infranview.com
Infranview Plugins 4.62 - Windows 64-bit To view additional image filetypes For viewing Digital Negative (.DNG) images Freeware infranview.com
HxD Hex Editor 2.4.0.0 – Windows 64-bit Hex editor/viewer For viewing files at bit level Freeware www.mh-nexus.de
Flight Reader 1.4.6 - Windows 64-bit Offline DJI Flight log analyser Decrypt flight logs/visual analysis of flight data Proprietary https://www.flightreader.com/
Google Earth Pro
(Desktop version) 7.3 - Windows 64-Bit Satellite map viewer To visualise the decrypted log files. Freeware google.com/earth
previous usage. This limitation was factored into the experiment o “Approximate Location info” was enabled.
during the extraction and analysis phases, and as such, data • The Wi-Fi option on the Android OS was set to off.
identified as having been generated prior to, or outside of the • Video subtitles were enabled.
experiment, was unless specifically mentioned in the findings, • The RC was not jailbroken/rooted.
deemed out of scope. Preparation for the drone included
ensuring that it was fully charged prior to and during the data 6) Apple iPhone: A smartphone version of DJI Fly
generation, extraction, and analysis phases, calibrating the application is also available for compatible Apple iOS devices
drone with the RC-based version of the DJI Fly application, from the App Store [25]. When the application is paired with a
performing visual checks on the drone body for signs of compatible smartphone-based DJI remote controller (such as
damage, and placing the rotor arms into flight position prior to the model RC-N1) it can act as a flight controller and provide
flight. similar features to the DJI RC. However, the smartphone
application can also connect directly to the DJI RC or the Mini
5) DJI RC: The DJI RC (Model RM330) is an all-in-one 3 Pro drone via the Bluetooth and Wi-Fi protocols to transfer
remote controller that is compatible with the DJI Mini 3 Pro multimedia to the smartphone. To provide a wireless data
drone [21]. It features an integrated touchscreen for viewing live extraction method for Scenario D, the DJI Fly application was
video feed from the drone and recorded videos and images. It installed on a used Apple iPhone 13 and paired with the Mini 3
also features controls to operate the drone, USB ports for Pro Drone and DJI RC prior to the experiment. Additionally, the
connecting the RC to external devices, an 8 GB internal memory researchers’ DJI user account was logged into the iOS DJI Fly
storage device, and a Micro-SD card slot for extending storage app prior to, and during, the experiment.
capacity [21]. Preliminary examination of the device indicated
that the device’s host OS was Android version 10. A topside
D. Data generation
view of the DJI RC that was examined in the study is shown in
Figure 3. To generate sufficient data for the practical elements of the
case study, at least one flight of the drone was undertaken for
each of the scenarios outlined in Section III-A. Additionally,
each flight was controlled using the DJI RC and at least one
video and image were taken during each flight.

E. Acquisition
Data acquisition guidelines outlined in [8] were adapted for
this case study. The primary preparation and acquisition
processes for the scenarios of this case study are outlined in
Figure 5.
This study was limited to manual, physical, and logical
extraction methods and where possible, in this order to conduct
the examination in a forensically sound manner as
recommended in [8].
Data integrity has also been considered. To meet the
minimum data integrity requirements, image files created by
FTK Imager were hashed, and a hash report generated for the
image.
Fig. 3. A top-down image of the DJI RC.
Specific extraction methods are detailed as follows:
The DJI RC was shipped with the DJI Fly application pre-
installed. The controller was prepared and configured for the 1) Mini 3 Pro drone: The Mini 3 Pro drone features a 1.2
experiment as follows: GB capacity internal storage device, a Micro SD card slot for
external storage, and a USB-C port for connecting to external
• It was paired with the Mini 3 Pro drone used in the devices. Figure 6 show the port placement in respect to the
study. drone.
• A DJI user account was logged in to the DJI Fly app As per the process workflow depicted in Figure 5, if the
during Scenarios A, B and C. scenario involved use of a Micro-SD card in the drone, then this
• The DJI user account in the DJI Fly app was bound to was imaged prior to attempting data extraction from the drone’s
the drone during the study. internal memory. Methods used for extracting data from the
• DJI Fly app privacy settings: drone’s internal memory included:
o “Local Data Mode” was disabled. • Connecting the drone to the forensic environment via
o “Mobile Device GPS Info” was disabled. a wired USB connection and exploring the user
o “DJI Device Hardware Info” was disabled for accessible volume presented to the forensic VM (i.e.,
some of the scenarios. a logical acquisition).
 • Using the DJI Assistant 2 tool (via a wired USB
connection) to access areas of the drone’s storage not
presented to the forensic VM.
• Using the DJI Fly app, on both the DJI RC and the
Apple iPhone, to wirelessly connect to the drone and
extract multimedia files from it.

Fig. 6. A view of the USB port and Micro-SD card slot on the Mini 3 Pro.

2) DJI RC: The DJI RC features an 8 GB capacity internal

storage, a Micro SD card slot for external storage, and two USB-
C ports for connecting to external devices. Figure 7 shows the
port placement on the RC.

Fig. 7. USB ports and Micro-SD card slot location on RC.

Similar data extraction methods carried out on the drone were

adopted for the RC, however, as the RC is an integrated device,
manual extraction methods were an additional option that were
Fig. 5. The preparation and acquisition processes adopted in this case study. explored. The Micro-SD cards used in Scenarios A, B and C
were imaged before other possible extraction methods (i.e.,
manual, and logical) were explored on the RC’s internal
memory. The DJI Assistant 2 tool was used to attempt to extract
flight and system logs from the RC while Windows Explorer
and Linux Files utility on the RC’s host-OS and the Linux
forensic VM were used to explore the RC’s internal memory.

3) External Storage: A 16 GB SanDisk Ultra High-

Capacity Micro SD card was present in the RC during the data
generation phase of Scenarios B and C while a 32 GB SanDisk
Ultra High-Capacity Micro SD card was present in the drone
during the data generation phase of Scenarios A and C.
A SanDisk Micro-SD to SD card adapter was used as a
hardware write blocking device while imaging the Micro-SD
cards. Prior to imaging a Micro-SD card, the adapters’ write
block switch was placed into the enabled position (as shown by
the red arrow in Figure 8). Placing the switch into this position
blocks write operations on the Micro-SD card [26]. The write
block switch was placed into the disabled position for data
sanitisation activities.

Fig 8. Micro-SD card adapter with write block switch enabled. Fig. 9. General data analysis processes

F. Analysis
Data was analysed using the tools outlined in Table 1. The
general processes that were followed for the analysis are
depicted in Figure 9. The primary analysis tools were Autopsy,
HxD, the EXIF Tool, Notepad++, DatCon, and Flight Reader.
Specific analysis steps were undertaken for suspected flight
logs. This included submitting the files to both DatCon and
Flight Reader for initial decoding and parsing. DatCon did not
have an integrated visualisation feature; therefore, logs parsed
by DatCon were uploaded to the Airdata UAV and Google Earth
for visualisation analysis. These steps are depicted in Figure 10.

Fig. 10. Flight log parsing and visualisation processes

 IV. FINDINGS creation timestamps of the previously deleted
images were not the original creation date of the
Digital artefacts were discovered and retrieved from the Mini 3 images, rather the timestamp was the point in time
when the images were extracted by Autopsy.
Pro and DJI RC. These were grouped into three primary
categories: media, flight logs, and other. The findings of the • A subtitle file (DJI_0161.SRT) was present in
“DCIM\100\MEDIA” folder. The file was viewed
scenarios are detailed in Subsections A to D. Additionally, anti-
in notepad++ for further analysis. It appears this file
forensic methods were identified; the results of which are
contains metadata of the flight of the related video
outlined in Subsection E. A summary of the overall findings is (DJI_0161.MP4). As shown in Figure 13, it was
provided in Subsection F. discovered that when subtitles are enabled and used
in conjunction with the related video in VLC player,
A. Scenario A flight telemetry data is displayed on screen during
playback.
For this scenario, analysis was first performed on the FTK-
acquired image of the 32 GB Micro-SD card that was used in
the drone. This was followed by analysis of the drone’s internal
memory. Autopsy was used in both cases.

1) SD Card:

a) File System/Structure
• Filesystem type was FAT32.
• Three parent folders were present in the root Fig. 11. The magic number of DJI_0161.SCR.
volume:
o DCIM
o LOST.DIR
o MISC

b) Media
Images and videos were discovered in several locations
on the SD card image, including unallocated areas.
• High-resolution images were successfully retrieved Fig. 12. The magic number of DJI_0161.THM.
from folder “DCIM\100MEDIA”. These included
raw (.DNG) and compressed JPEG (.JPG) versions c) Flight Logs
of each image captured by the drone. No fight logs were discovered on the Micro SD card
• A high-resolution video taken for Scenario A was image.
retrieved (in full) from “DCIM\100MEDIA”. The
filename was DJI_0161.MP4. The video was able d) Other
to be replayed in full using VLC Player.
• Autopsy discovered a total of 236 deleted files on
• A pair of thumbnail images of the first frame of the
the unallocated volume of the SD card. These
recorded video was discovered in the
included images (in DNG and .JPG format), movies
“MISC\THM\100\” folder. The filetypes of these
(in .MOV format), an Adobe flash file (.SWF) and
images were .SCR and .THM. However, a hex
flight logs (in .TXT format). Of these files, the
analysis of these files revealed that they were both
movie and flash files were 0 bytes and could not be
JPEG files (see Figures 11 and 12). The image files
recovered.
ending in .THM were 160 x 90 pixels wide while
.SCR files were 960 x 540 pixels wide. The • Of the total recovered from the unallocated portion
filename of these images corresponded with the of the SD card, 131 of them were .txt type files.
filename of the related video (“DJI_0161.MP4”). These files had filenames in the format:
“fxxxxxx.txt” (“x” representing a number value).
• Previously deleted images were discovered by
Closer inspection of these files with Notepad++
Autopsy in an unallocated portion of the SD card.
revealed they contained the following flight history
These images were a mixture of JPG and DNG type
metadata:
files. The recovered JPEG images were thumbnails
of older images captured by the drone prior to the • Date/time of flight
case study. The pixel size of these recovered images • GPS coordinates (latitude, longitude, and altitude)
matched the respective pixel sizes of the .THM and • Camera parameters (such as shutter speed, iso,
.SCR files. The DNG images recovered by Autopsy zoom ratio, and sensor temperature).
were 48-mega pixel high-resolution images
captured by the drone prior to the case study. The The type of data and format of data in these files was
similar to that observed in DJI-generated subtitle telemetry
 files. It is believed these text files were previously deleted
subtitle files. A snippet of this data is highlighted in Figure
14. Note that the latitude and longitude coordinate values
have been partially redacted.

Fig. 13. Screenshot of video overlay telemetry file showing camera data. Note that the GPS coordinates have been partially redacted.

Fig. 14. Snippet of the contents of a text file recovered by Autopsy from an unallocated space of the Micro-SD card. Note that the highlighted
GPS coordinates have been partially redacted.

• The images recovered from the SD card were analysed image was taken. Spot checks of the EXIF metadata
for the presence of Exchangeable image file format confirmed it was accurate.
(EXIF) metadata. It was discovered that both the
compressed JPEG (.JPG) and raw images (.DNG) 2) Internal Memory Analysis:
located in “DCIM\100MEDIA”, and the raw (.DNG)
images discovered in and recovered from the a) File System/Structure
unallocated volume contained comprehensive EXIF • Filesystem type was ExFAT.
metadata. The information stored included timestamps • 1.5 GB user-accessible volume
of when the images were created, the make and model • Mounted in Windows as a Mass Storage Device.
of the drone, camera sensor information (including its
serial number), and GPS coordinates of where the
 b) Media • A cached video of a video recording taken during
Nil found. the flight for Scenario B was successfully recovered
using Autopsy. The file was called
c) Flight Logs “2023.01.28.19.09_49_Cache.mp4” and was
Nil found. located at:
“/Android/data/dji.go.v5/files/MediaCaches/”. The
d) Other video was extracted to the forensics workstation for
further analysis. The specifications of this video
• A .DAT file was retrieved using DJI Assistant 2. were:
The file was saved to the forensic VM as o MPEG-4 file type
“DJI_Mini_3_Pro_2023-01-25_21-38-00.DAT”. It o 864x480 pixels
appears that the timestamp in the filename o Length: 00:01:38 h/m/s
coincides when the file was extracted, not when it
o Creation date: 28.1.2023
was originally created in the drone. Analysis of this
o Creation time: 1911 hours
file with Notepad++ indicated that it was a binary o Size: 49.5 MB
file. DAT files contain serials. Decoding was
• While not technically part of this scenario, the
attempted with DatCon; however, the output files
related full-sized video was discovered on the
were either 0 or 1 KB in size and did not contain
drone’s internal memory. The specifications of this
any useful information.
video were:
• DJI Assistant 2 provides an option to extract o MPEG-4 file type
software system logs (called “Assistant logs”). o 1920 x 1080 pixels
Each extraction with this option generates two text o DJI_0005.MP4
files. The filename format for one of these files is o Creation Date: 28.1.2023
“YYYY_MM_DD@HH_MM_SS.log” while the o Creation Time: 1911 hours
other is titled “ui_ass2.log. The log file with time
o Size 437 MB
and date in the filename appears to be in a mix of The cached version discovered on the RC was
Korean and Chinese simplified encoded text. around 11% the size of the larger video discovered
Online translation sites Google Translate on the drone.
(translate.google.com) and DeepL (deepl.com)
were not able to decode it into anything meaningful. c) Flight Logs
The other log “ui_ass2.log” contains multiple lines
with timestamps in English, accompanied by Nil found.
encoded text. Text appears to be a Base64 or
d) Other
Base85 type encoding scheme. Attempted to further
decode with various Cyberchef modules Several interesting patterns emerged when Autopsy’s
(cyberchef.org), but the attempts were timeline feature was used on the SD card image.
unsuccessful. It is believed that both of these files • To begin with, it was discovered that several files and
were using a proprietary encoding scheme. top-level directories were generated on the SD card
around the same time (See Figure 15). The file creation
timestamps reported by Autopsy correlated with the
B. Scenario B date and time the SD card was last formatted by the
In this scenario, only the RC was retrieved. The RC contained RC.
an SD card which was imaged and analysed using Autopsy. • The timestamp for a “file accessed” event entry for
Manual and logical extraction methods using Windows “music_sound_wave” coincided with the time the RC
Explorer and DJI Assistant 2 were explored for analysis of the was booted up (see Figure 16). The associated sound
RC’s internal memory. file is played when the RC is powered on.

1) SD Card Analysis: 2) Internal Memory Analysis:

a) File System/Structure a) File System/Structure

• Filesystem type was ExFAT. • Filesystem was presented to Linux and Windows
• Several directories discovered in the root volume. OS as “Generic Hierarchical” type.
• 3.84 GB user accessible volume.
b) Media • The device mounted as a Media Transfer Protocol
• No images were found on the SD card. device, and as a result, imaging the drive was not
• The original video files of the recordings made possible with the available tools.
during the flight were not found on the Micro SD
card image.
b) Media x_xxxxxx_YYYYMDDxxxxxx_photo_previe
• Nil found via the volume presented to the forensic w.jpg”.
OS.  Size = 960 x 540 pixels
• Several thumbnail-sized images were discovered on
the RC’s internal memory using manual extraction The lowercase “x” denotes a sequence of numbers
methods. The images were located at “DJI while a capital “X” correlates with the number
RC\Android\data\dji.go.v5\cache\ImageCaches”. assigned to the related full-sized photo/video file.
(See Figure 17). The length of the assignment number depends on
• It appeared that a pair of different sized thumbnails where the sequence is at.
was generated for each recorded photo/video:
o Filename c) Flight Logs
“Photo_x_DJI_X_jpg_xxxxxxx_0_YYYYMD • Flight records discovered in the root directory of
Dxxxxx_photo_thunmbnail.jpg”. (The word the internal memory when the viewable partition
“thumbnails” were misspelt in these file types). was investigated using Windows Explorer. File
 Size = 160 x 120 pixels details were:
o Filename o Filename “DJIFlightRecord_YYYY-MM-
“Photo_xxxxxxxxxx_DJI_XXX_jpg_xxxxxxx DD_[HH-MM-SS].txt”
_0_YYYYMDDxxxxx_photo_preview.jpg”. o The created timestamp was accurate.
 Size = 960 x 720 pixels o Similar files were found on the RC in “DJI
o Filename RC\Android\data\dji.go.v5\files\FlightReco
“Video_xxxxxxx_DJI_XXX_mp4_xxxxxxxxx rd”.
x_xxxxxx_YYYYMDDxxxxxx_photo_thunm o The log file was successfully parsed in Flight
bnail.jpg”. Reader. Figure 18 shows a screen snippet of
 Size = 160 x 90 pixels the application output:
o Filename
“Video_xxxxxxx_DJI_XXX_mp4_xxxxxxxxx

Fig. 15. Screenshot taken of Autopsy timeline showing several files and directories
created on the SD card at the same time.

Fig. 16. Screenshot take of Autopsy timeline showing the date and time the RC’s
power-on sound file was last accessed.
 Fig. 17. Thumbnail images discovered on the RC’s internal memory via the RC files utility.

Fig 18. Screenshot taken of Flight Reader parsing the recovered flight log.

o This log displayed the error messages that drone model as a “Phantom 4”; however, the flight
were shown on the RC screen during the flight. path and time were accurate.
o The flight logs contained hundreds of • The RC-based DJI Fly app listed the email address
parameters, including flight start and finish of the logged in DJI account in “Profile” settings.
time, drone make and model, drone and battery • The email associated with the DJI user account was
serial numbers, error messages, warnings, discovered in several text files stored in the volume
GPS coordinates, and altitude. parent folder “SyncResult”. Figure 19 shows a
o The flight path was also visualised in Google snippet of this text. The timestamps in the filename
Earth Pro by selecting the KML file download and within the file indicate when the RC was last
option in Flight Reader. The flight path synced with DJI’s online servers.
presented by both applications appeared to be
accurate, however, as of the time of writing,
neither application appeared to offer start-to-
finish visual playbacks of flight paths.

d) Other
• The flight for Scenario B could be viewed directly Fig. 19. An email address belonging to the DJI user account signed into
on the RC (via the DJI Fly App) by selecting the RC was discovered in a log file on the RC’s internal memory. Note
“Profile”, then “more” and then tapping on the that the email address has been partially redacted.
flight. The application incorrectly reported the
 • A partial .DAT file was extracted from the RC 3) SD Card – RC:
using DJI Assistant 2 over a USB connection.
Further analysis of this file in Notepad++ indicated a) Media
it was a proprietary encoded binary file. The RC’s Like scenario B, a cached video of the video recorded
model number and what appeared to be a serial for scenario C was found on the SD card. The related
number were identified in the beginning of the file. video of which was discovered on the SD card used in
See Figure 20. The longer string (a mix of letters the drone.
and numbers) did not match any serial number
identified during the study. b) Flight Logs
Nil found.

c) Other
A subtitle file (.SRT) of the associated video was
Fig. 20. Model number and unknown string discovered in the .DAT file in retrieved in full.
plain text. Note that the identified string has been partially redacted.
4) Internal Memory Analysis – RC:
C. Scenario C
a) Media
In this scenario, both the drone and RC were recovered. Both
devices contained an SD card, and the flight was normal. Thumbnail images of recorded video and image from
Scenario C was discovered on the RC in
1) SD Card – Drone: “DJI RC\Android\data\dji.go./v5\cache\ImageCaches”

b) Flight Logs
a) Media
Like Scenario B, flight logs were discovered in txt
• A full-sized MP4 video was retrieved from folder
filetype.
“DCIM\100MEDIA\”
• Two thumbnail images (a .THM and a .SCR file) of c) Other
the first frame of the above video were retrieved.
• Similar to Scenario B, the flight could be viewed
b) Flight Logs directly on the RC (in the DJI Fly App) by selecting
“Profile”, then “more” and then tapping on the
Nil found.
flight. The application incorrectly reported the
drone model as a “Phantom 4”; however, the flight
c) Other
path and time were accurate.
A subtitle file (.SRT) of the associated video was • Using manual extraction methods, a DJI user
retrieved in full. account and email address were discovered signed
into the DJI Fly app on the RC.
2) Internal Memory Analysis – Drone:

a) Media D. Scenario D
Nil found. For this scenario, both the drone and RC were recovered,
however neither contained an SD card. To simulate a collision,
b) Flight Logs the drone was carefully turned over by hand just prior to being
Nil found. powered down. USB connections were not available for this
scenario, only Wi-Fi and Bluetooth. Additionally, the DJI user
c) Other account was logged out of the RC during the flight for this
scenario.
A .DAT binary file containing the drone’s model
number and a possible serial number was discovered
1) Internal Memory Analysis – Drone:
using DJI Assistant 2 over USB. See Figure 21. The
longer string did not match any serial number identified
a) Media
during the study.
• A full-sized image and video taken for this scenario
was successfully retrieved from the drone using
“Quick Transfer Mode” on the iOS version of the
DJI Fly application. The file names of these files
were:
Fig. 21. Model number and possible serial number in binary file extracted • “dji_fly_YYYYMMDD_xxxxxx_XXX__x
from the drone’s internal memory. Note that the unidentified string has been xxxxxxxxxxxx_photo.jpg”
partially redacted.
 • “dji_fly_YYYYMMDD_xxxxxx_XXX__x details, including the same warning message that
xxxxxxxxxxxx_video.mp4”. Flight Reader parsed.

b) Flight Log c) Other

Nil found. • The .DAT flight log file contains the “Flight
Controller” serial in plain text. This was visually
c) Other confirmed with serial listed in the “About” page of
Nil found. the RC version of the DJI Fly application.
• The flight history for this scenario was not available
2) Internal Memory Analysis – RC: for viewing on the iOS version of the DJI Fly app.
Note that the auto syncing flight logs option was not
a) Media enabled on the RC.
• The “Flyshare” option on the iOS version of the DJI • The flight for Scenario D appeared on the RC under
Fly was connected to the DJI Fly app on the RC. No “profile” and “more” options when the DJI user
media was presented to the mobile DJI Fly app account was logged back in.
using this option. • The email address of the previously logged in user
• Using the native Android filesystem utility on the account was shown in full as an auto-complete
RC, thumbnail images associated with a recorded prompt on the RC-based DJI Fly app when the first
video and image taken for Scenario D were few letters of the email was entered into the
discovered within the folder “DJI username field.
RC\Android\data\dji.go./v5\cache\ImageCaches”.
E. Anti-forensic Methods
b) Flight Logs
Potential anti-forensic methods to avoid or limit the
• Using the native Android filesystem utility, a .DAT generation, storage, and transmission of digital artefacts of
based flight log for this scenario was discovered in interest were identified with the Mini 3 Pro and DJI RC. These
“DJI included:
RC\Android\data\dji.go.b5\files\FlightRecord”.
This file could not be transferred via Bluetooth in 1) Purging cached flights from the RC via the DJI Fly
its native form. The filesystem utility displayed an application: It was found that cached flights could be deleted
error on the RC screen “no apps can perform this by several methods:
action”. Despite this, the the file could be renamed • Remove individual flights from the device by selecting
to a .TXT filetype using the filesystem utility and “Profile”, then “More”, followed by swiping left on the
then transferred to the forensic workstation via flight to remove, and pressing the red icon depicted
Bluetooth. The file was reverted to the original with a trash can that appears.
.DAT filetype and converted using DatCon. A • To bulk clear the flight log cache, select “Profile”, then
.CSV and .txt file were generated by DatCon. “More”, then “Storage”. In the box titled “RC Internal
Attempts were made to load these files into the Storage”, expand the “Clear Cache” menu, and select
Flight Reader application, however neither were “Clear Aircraft Flight Record Cache”. If applicable,
successfully parsed. The application did not provide this method can also be used for the SD Card.
a reason why it could not parse the files. The .DAT
file was uploaded to the Airdata UAV website, 2) Preventing the RC and iPhone from syncing flight records
which it parsed; however, the output did not contain with DJI’s online servers: Two methods were discovered for
an entry relating to the simulated collision. Figure this:
22 is a screenshot of some of the information parsed • Opening the DJI Fly app on the RC, selecting
by the Airdata UAV site. “Profile”, then “Settings”, then “Sync Flight Data”,
• A .TXT flight log for the flight associated with and disabling the setting “Auto-sync Flight Records”.
Scenario D was also discovered in folder “DJI • Similar steps to the RC, but performed on the iOS
RC\Android\data\dji.go.b5\files\FlightRecord” version of the DJI Fly app.
using the native Android filesystem utility on the
RC. This was able to able to be transferred to the 3) Preventing or limiting PII being sent to DJI: it appeared
forensic workstation via Bluetooth and parsed by this could be achieved with the RC’s software in several
the Flight Reader application. The error associated different ways:
with the simulated collision during Scenario D was • In the DJI Fly app, select “Profile”, then “More” then
captured by Flight Reader (see Figure 23). “Notification and Privacy”. From there is an option to
• The same .TXT log was able to be parsed by the enable/disable network data transmission labelled
Airdata UAV site. Despite being significantly “Local Data Mode”. Enabling this generated an on-
smaller than the .DAT file, it displayed more screen prompt that informs the user that all network
 data transmission would be disabled. These claims could still be flown without a user being logged into
were not examined or verified during the experiment. the DJI Fly application.
• In the same menu area as above was a section titled
“Privacy”, with four different slide switches labelled 4) Formatting the SD card used in the RC/Drone: Options to
“mobile Device GPS info”, DJI Device GPS Info”, format an SD card mounted on the RC, and the RC internal
“DJI Device Hardware Info”, and “Approximate memory, were discovered on the DJI Fly app and the Android
Location Info”. It appeared that a user could only OS filesystem utility. Due to time constraints, the effectiveness
disable three of these four ‘privacy’ options. The of these formatting options was not assessed. It was found
exception was the option labelled “Approximate however during the study that formatting an SD card previously
Location Info”. Attempts to disable this feature used in the drone or RC using the SD Association’s tool “SD
resulted in an immediate on-screen warning prompt Card Formatter” did not effectively wipe the data from the SD
with the message “Authorization required for the app card. This indicates that formatting an SD card is not a reliable
to run normally and cannot be disabled”. The DJI method for data sanitization.
Security Whitepaper (v2) confirms that this option
cannot be disabled [27]. Additionally, it was found that 5) Unbinding the device with a DJI account: It was discovered
disabling the option “DJI Device Hardware Info” that a DJI account binded to the drone could be unlinked via the
resulted in regular on-screen prompt messages when RC- and iOS-based versions of the DJI Fly application by
the drone was powered on and which required the user selecting “Profile”, then “More”, then “Device Management”,
to acknowledge to remove them. It was found that then selecting “Remove Device from Account” in the “Account
these warning prompts stopped while the drone was in and Device” menu. This option was outlined in the official DJI
flight but returned as soon as the drone landed. Mini 3 Pro user manual [19]. The DJI Fly application informed
• Syncing locally stored data with internet-connected the researcher that unbinding the DJI account with the drone
services via the RC OS. It appeared that the would limit the ability to check the device usage. This option
controllers’ Wi-Fi system could be disabled at the OS was not attempted or verified during the research.
level by turning off the Wi-Fi option presented by the
OS. This option was located by simply swiping down F. Summary
from the top of the RC screen. This option was not
examined thoroughly, nor verified during the Several key digital artefacts were retrieved from both the
experiment. Mini 3 Pro and the RC. Table 2 provides a summary of the
• Not logging into the DJI Fly app on the RC. It was digital artefact findings. Additionally, several potential anti-
found that the user account that was previously logged forensic methods were identified; however, due to time
in could be logged out of the application. The drone constraints, the efficacy of these methods was not thoroughly
assessed during the study.

Fig. 22. Screenshot of flight log information decrypted by the Airdata UAV website.
 Fig. 23. Screenshot of flight log information decrypted by Flight Reader.

TABLE 2
A SUMMARY OF THE DIGITAL ARTEFACT TYPES DISCOVERED

Artefact type: Media Flight log Other

Scenario: Device: SD Internal SD Internal SD Internal

A Drone Y N N N G, D D, E

B RC Y Y N Y N G, P, D

Drone Y N N N G, D D, E
C
RC Y Y N Y N G, P, D

Drone -- Y -- N -- G, D
D
RC -- Y -- Y -- D, E
Y = Artefact discovered, N = No artefacts discovered, G = Artefacts containing geolocation found, P = Artefacts containing PII found,
D = Artefacts with device identifiable information found, E = Encrypted/encoded artefacts found that could not be decrypted/decoded.

V. DISCUSSION third parties could raise privacy and legal concerns for
investigators. In contrast, this study also evaluated the
Several digital artefacts of potential interest to forensic capabilities of Flight Reader for local flight log analysis. It was
investigators and researchers were discovered on the Mini 3 Pro found that this application was capable of parsing and
and DJI RC. These artefacts included media, flight logs, and presenting DJI flight logs, however, an Internet connection was
other PII, including an email address of the associated drone required to obtain maps and other data. The application
operator. These results are similar to that of case studies of older developer confirmed that Flight Reader requires an Internet
DJI drone models by [4], [5], [10], [15] connection to obtain map data, decryption keys, and verify the
Acquisition of key digital artefacts from these devices was application licence [28]. Due to this fact, the exchange of such
straightforward, with the majority able to be acquired from data could also raise privacy concerns for investigators.
simple manual extraction methods, while other artefacts, such Previously deleted subtitle telemetry and image files were
as flight logs and previously deleted files, required more effort. recovered from unallocated portions of the SD cards. It is
The was partially attributed to the absence of password believed this was due to a limitation of the card formatting
protection on these devices and is likely to assist investigators utilities used in the study to properly sanitise data on the SD
conducting DRF examination on said devices in the future. cards. This finding was identified early, during analysis of
Flight logs located and retrieved from the internal storage of Scenario A, and steps were taken to ensure that the SD cards
the RC were successfully decrypted by DatCon and Flight were sufficiently sanitised for subsequent scenarios.
Reader. Flight logs decrypted by DatCon were submitted to the A cached video file discovered on the RC during analysis of
Airdata UAV website to present the logs in a visual form, while Scenario B was only 11% of the full-sized associated video
Flight Reader was capable of decrypting and presenting logs saved to the drone, however the resolution of the video was
directly to visual form. Both methods were able to present the sufficient enough to make out details. This finding could be
relevant flight history information in an intuitive way; however, useful to investigators in situations where videos have been
it was discovered that an error log entry relating to the simulated recorded, but the associated full-sized video from the drone is
collision in Scenario D was missing from the information unable to be recovered.
presented by Airdata UAV. This is a significant finding as the It was surprising to see DJI’s Wi-Fi-based “Quick Transfer”
absence of such information could be crucial in determining the feature functioned between the drone and RC even though Wi-
circumstances behind a drone related event. This finding Fi appeared to be turned off on the RC’s Android settings. The
highlights a potential limitation in the capabilities of Airdata reason for this is currently unknown, though it is suspected that
UAV’s flight log parsing service which investigators should be the DJI Fly app enables Wi-Fi, Ocusync, and/or Bluetooth to
aware of. facilitate this media transfer system.
The reviewed literature assessed the capabilities of online Although it appeared there was an option to disable
services such as Airdata and Google Earth for parsing flight logs “Approximate Location” in the RC DJI Fly application settings,
and presenting them in a visual form. Uploading flight logs to it did not appear that it could be disabled. This finding was an
unusual juxtaposition considering that the application physical data extraction and analysis. Despite these limitations,
developers could remove the faux option altogether. the findings in this study could still potentially assist
The nature of the strings found in the .DAT files extracted via investigators and researchers with future DRF examinations of
the DJI Assistant 2 application was unknown to the author. It is these and similar devices. In addition, this study partially
proposed that these strings may be hidden serial numbers unique addresses the previously discussed gap in literature pertaining
to the respective devices. A comparison with other DJI Mini 3 to DF of drones weighing less than 250g.
Pro’s and RC’s might support or disprove this theory.
Of the two devices, it was discovered that the RC contained
all of the PII related digital artefacts. This finding supports the APPENDIX
view by [4] that attribution is more likely to be achieved with Table 3 contains a list of abbreviations used in the paper.
data acquired from an RC rather than a drone.
As the marketed weight of the DJI Mini 3 Pro is 249 grams TABLE 3
[21], this study partially addresses claims by [10] of a gap in the ABBREVIATIONS USED IN THE ARTICLE
literature pertaining to DRF case studies of drone models ACPO Association of Chief Police Officers
weighing less than 250 grams. AF Anti-forensics
The system logs were not able to be decoded, which mirrored DF Digital Forensics
the experience of [10]. It would be useful to be able for DRF Drone Forensics
investigators to be able to decode these. DJI Da-Jiang Innovations
DNG Digital Negative
VI. FUTURE WORK FAA Federal Aviation Administration
EXIF Exchangeable Image File Format
JPEG Joint Photographic Experts Group
Several promising areas for future research were identified
NIST National Standards and Technology
out of this case study. The first is further investigation into DJI’s
OS Operating System
DroneID technology. The presence and specifics of the
technology on the devices examined in this study are unknown, RC Remote Controller
and as such, DRF case studies that focus on this technology Rf Radiofrequency
could advance the literature. Inability to decode DJI system logs SD Secure Digital
was a limitation identified during the study. Such logs could SDR Software Defined Radio
provide investigators with valuable insight into the drone’s UART Universal Asynchronous Receiver Transmitter
usage and assist with attribution. Therefore, research into UAV Unmanned Aerial Vehicles
methods for decoding these logs could be valuable to digital USB Universal Serial Bus
forensic investigators. VM Virtual machine
Other potential areas to research include submitting the DJI
Mini 3 Pro and DJI RC to vulnerability testing to get root access,
performing a chip-on assessment on the devices, assessing the REFERENCES
weight carrying capabilities of the drone and investigating the
potential presence of digital artefacts relating to a history of
[1] Civil Aviation Safety Authority. (2022). The RPAS and AAM
payload transport. Strategic Regulatory Roadmap. [Online] Available:
https://www.casa.gov.au/sites/default/files/2022-06/the-rpas-and-
aam-roadmap.pdf
VII. CONCLUSION [2] S. Frost, "Study analysing the current activities in the field of UAV.
Technical Report, ENTR/2007/065. 2007," European Commission,
2007. [Online]. Available: https://ec.europa.eu/home-
In this case study, the DJI Mini 3 Pro and DJI RC were affairs/sites/homeaffairs/files/e-
library/documents/policies/security/pdf/uav_study_element_2_en.p
examined for presence of digital artefacts that could be of key df
interest to investigators. Additionally, potential digital anti- [3] F. E. Salamh, U. Karabiyik, M. K. Rogers, and E. T. Matson, "A
forensic methods for both devices were explored. The case comparative UAV forensic analysis: Static and live digital evidence
study was divided into four potential DRF scenarios that a traceability challenges," Drones, vol. 5, no. 2, 2021, doi:
10.3390/drones5020042.
digital forensic investigator may be faced with. The study found [4] G. Thornton and P. Bagheri Zadeh, "An investigation into
digital artefacts, such as media, flight logs, and PII, on both Unmanned Aerial System (UAS) forensics: Data extraction &
devices that could potentially reveal the drone’s usage history analysis," Forensic Science International: Digital Investigation, vol.
and identify the operator/registered owner. Of these, flight logs 41, 2022, doi: 10.1016/j.fsidi.2022.301379.
[5] M. Yousef, F. Iqbal, and M. Hussain, "Drone Forensics: A detailed
and PII were discovered on the RC, while full-sized media was analysis of emerging DJI models," in 2020 11th International
discovered on the drone. Of the two devices, it is apparent that Conference on Information and Communication Systems (ICICS),
the RC is the primary device for acquiring drone usage and PII 2020.
related data. Key limitations encountered during the study [6] Federal Aviation Authority. "UAS Sightings Report."
https://www.faa.gov/uas/resources/public_records/uas_sightings_re
included not being able to be decode system logs and not having port (accessed Jan. 23, 2023).
full access to the internal memory of both devices for complete
[7] N. Schiller et al., "Drone security and the mysterious case of DJI’s
DroneID," 2023.
[8] Interpol, "Framework for responding to a drone incident - For First
Responders and Digital Forensics Practitioners," 2020. [Online].
Available:
https://www.interpol.int/content/download/16243/file/Guidelines%
20to%20Digital%20Forensics%20First%20Responders_V7.pdf
[9] E. Mantas and C. Patsakis, "Who watches the new watchmen? The
challenges for drone digital forensics investigations," Array, vol. 14,
2022, doi: 10.1016/j.array.2022.100135.
[10] M. Stanković, M. M. Mirza, and U. Karabiyik, "UAV forensics: DJI
Mini 2 case study," Drones, vol. 5, no. 2, 2021, doi:
10.3390/drones5020049.
[11] A. Al-Dhaqm, R. A. Ikuesan, V. R. Kebande, S. Razak, and F. M.
Ghabban, "Research challenges and opportunities in Drone
Forensics models," Electronics, vol. 10, no. 13, 2021, doi:
10.3390/electronics10131519.
[12] H. Studiawan, T. Ahmad, A. M. Shiddiqi, B. J. Santoso, and B. A.
Pratomo, "Forensic event reconstruction for drones," in 2021 4th
International Seminar on Research of Information Technology and
Intelligent Systems (ISRITI), 2021, pp. 41-45, doi:
10.1109/isriti54043.2021.9702864.
[13] F. E. Salamh, M. M. Mirza, and U. Karabiyik, "UAV forensic
analysis and software tools assessment: DJI Phantom 4 and Matrice
210 as case studies," Electronics, vol. 10, no. 6, 2021, doi:
10.3390/electronics10060733.
[14] R. Kumar and A. K. Agrawal, "Drone GPS data analysis for flight
path reconstruction: A study on DJI, Parrot & Yuneec make drones,"
Forensic Science International: Digital Investigation, vol. 38, 2021,
doi: 10.1016/j.fsidi.2021.301182.
[15] J. K. Lan and F. K. Lee, "Drone Forensics: A case study on DJI
Mavic Air 2," in International Conference on Advanced
Communications Technology (ICACT). 2022.
[16] G. Johansen, Digital Forensics and Incident Response : Incident
Response Tools and Techniques for Effective Cyber Threat
Response, 3rd ed. Birmingham: Packt Publishing, Limited, 2022.
[17] K. Kent, S. Chevalier, T. Grance, and H. Dang, "Guide to integrating
forensic techniques into incident response," National Institute of
Standards and Technology, Gaithersburg, MD, NIST SP 800-86,
2006.
[18] R. Tamma, O. Skulkin, H. Mahalik, S. Bommisetty, and I.
Mikhaylov, Practical Mobile Forensics - Third Edition : A Hands-
On Guide to Mastering Mobile Forensics for the IOS, Android, and
the Windows Phone Platforms. Birmingham, United Kingdom:
Packt Publishing, Limited, 2020.
[19] Guidelines on Mobile Device Forensics, NIST SP 800–101 Revision
1, 2014. [Online]. Available: http://nist.gov
[20] Association of Chief Police Officers. (2012). ACPO Good Practice
Guide.
[21] DJI. "DJI Mini 3 Pro User Manual." DJI.
https://dl.djicdn.com/downloads/DJI_Mini_3_Pro/UM/20221104/D
JI_Mini_3_Pro_User_Manual_v1.4_en.pdf (accessed Feb. 5, 2023.
[22] Federal Aviation Authority. "UAS remote identification."
https://www.faa.gov/uas/getting_started/remote_id (accessed Feb.
2, 2023).
[23] D. Slotta. "Global market share of drone manufacturers."
https://www.statista.com/statistics/1254982/global-market-share-
of-drone-manufacturers/ (accessed Jan. 20, 2023).
[24] CIA Jeep Doors [dot] py. (2022). [Online]. Available:
https://github.com/MAVProxyUser/CIAJeepDoors/blob/main/REA
DME.md
[25] "DJI Fly." https://apps.apple.com/us/app/dji-fly/id1479649251
(accessed Feb. 5, 2023).
[26] L. Stanton. "How to remove write protection from an SD card."
https://www.alphr.com/remove-write-protection-from-sd-card/
(accessed Feb. 5, 2023).
[27] DJI, "System Security: A DJI Technology White Paper V2.0," 2022.
[28] M. Singer, private communication, Jan. 2023.