Admin’s Note: It’s been a while since I posted a new article and logged into the public account. Unfortunately, many issues beyond my control, combined with my principle of not being a mere transporter, mean that creation always takes time. Today, I am back with an interesting topic for everyone.

Drone Security and Fault Injection Attacks

Gabriel Gonzalez

Hardware Security Director

Compiled by Fan Shan

Table of Contents

Abstract… 2

Introduction… 2

Attack Surface… 3

OcuSync. 4

Mobile Applications… 4

Assets… 5

Firmware… 5

No-Fly Zones… 5

Sensitive Information… 5

Drone Architecture… 6

Technical Background… 6

XYZ Table… 7

EM Probes… 8

Oscilloscope… 9

SPIDER and EM-FI Detectors… 10

Target Drone… 11

Drone PCB Preparation… 11

Method One… 12

Method Two… 16

Future Work… 21

Mitigation Measures… 22

Appendix A: Additional Information… 23

About IOActive. 23

About the Author… 23

Appendix B: JAVA Code… 23

Appendix C: FIPY Controller Code… 27

Abstract

IOActive is exploring the possibility of executing code on commercial drones with publicly disclosed vulnerabilities using non-invasive techniques such as electromagnetic (EM) side-channel attacks and electromagnetic fault injection (EMFI). If successful, we can apply the lessons learned to a completely black-box approach and attempt to compromise devices without known vulnerabilities.

Our target is DJI, an experienced manufacturer that emphasizes the security of its products, [1] such as signed and encrypted firmware, Trusted Execution Environment (TEE), and secure boot. We utilize a controlled environment to study the impact of side-channel attacks and EMFI techniques.

We demonstrate that it is feasible to compromise the target device by injecting specific EM faults at the right time during firmware updates. This would allow an attacker to execute code on the main processor, thereby gaining access to the Android operating system that implements the core functionalities of the drone.

Introduction

Unmanned aerial vehicles, also known as drones, are increasingly being deployed in industries such as aviation, agriculture, and law enforcement. As the range of these devices expands, so do the cybersecurity concerns. These versatile machines offer many benefits but also face unique challenges in maintaining security.

One of the key challenges is that drones are typically remotely operated. This means that external actors can potentially access the drone’s control system by intercepting the wireless signals used to control the drone, compromising the ground computer systems used for operating the drone, or accessing the device itself; if the drone is stolen, the thief may collect sensitive information or implant malware onto the system.

This white paper covers IOActive‘s research on the current security landscape of the drone industry. In this work, we chose one of the most common drone models, the DJI Mavic Pro. [2]

The objectives of this research are:

• To understand the architecture of drones

• To investigate vulnerabilities in drones

• To determine which methods are meaningful in real-world attacks

• To gain experience in launching EMFI attacks against high-end multi-core systems running mature multitasking operating systems, compared to microcontrollers running bare-metal software

This white paper covers the following areas:

• Attack Surface: Provides an overview of drone components and identifies valuable assets

• Technical Background: Introduces the concepts of the target drone and test setup

• Method One: Describes how IOActive attempts to obtain firmware decryption keys using side-channel attacks

• Method Two: Describes how IOActive attempts to achieve code execution using EMFI

• Future Work: Discusses the next steps for IOActive‘s research

• Mitigation Measures: Recommendations to address highlighted issues

Attack Surface

Drones are used in various applications, including military, commercial, and recreational. Like any other technology, drones are susceptible to various types of attacks that can compromise their functionality and security.

Figure1: High-level overview of elements involved in the normal operation of a drone

As shown in Figure1, the attack surface exposed by drones depends on their specific capabilities. Some common attack surfaces include:

• Backend: Like almost any other modern system, drones are susceptible to various attacks targeting their backend systems. Attackers can exploit a range of issues, such as SQL injection or server-side request forgery, to access sensitive data, manipulate systems, or disrupt operations. Additionally, attackers may be able to leverage the backend systems as a pivot point to launch further attacks on other components of the ecosystem.

• Mobile Applications: Attackers can exploit vulnerabilities in mobile applications to access sensitive data or remotely control the drone. Common methods of breaching these vulnerabilities include flaws in the application or operating system, or even targeted attacks.

• Radio Frequency Communication: Drones use radio frequency communication systems to receive and transmit commands, data, and video. RF attacks can use various techniques, such as jamming, spoofing, and interference, to disrupt or manipulate the RF signals used by the drone. DJI implements a custom RF protocol OcuSync for sending video and commands to the remote controller used to control the drone.

• Physical Devices: Hardware or software vulnerabilities may allow attackers to access critical aspects of the drone, such as firmware and sensitive information, and potentially modify its behavior.

OcuSync

OcuSync is a wireless communication protocol developed by DJI. It is used in many of DJI’s drones, including the popular Mavic series, to provide reliable and low-latency connections between the drone and its associated remote controller.

One key feature of the OcuSync protocol is its ability to support multiple communication channels. This allows the drone to automatically switch between channels to maintain a strong and stable connection, even in challenging environments where radio interference may be present.

The OcuSync protocol also includes security features to protect over-the-air (OTA) communications. This includes the use of encryption to secure the wireless link between the drone and the remote controller, as well as authentication mechanisms to prevent unauthorized users from accessing the drone’s control system.

Mobile Applications

Mobile applications are available for both iOS and Android devices, allowing users to easily control and monitor the drone via smartphones or tablets.

Some key features of the DJI mobile application include the ability to remotely control the drone’s movements, access camera settings and controls, and view real-time video from the drone’s camera.

In addition to these basic control features, DJI’s mobile application also offers a range of advanced functionalities, such as automated flight planning, custom flight path creation, and the ability to access and manage the drone’s flight logs and other data.

Assets

IOActive’s initial goal was to access the drone’s firmware and search for vulnerabilities across the exposed attack surface. Below are the assets that attackers may target, depending on the desired outcome.

Firmware

The software running on the system-on-chip (SoC) in the target device is the holy grail of vulnerability research. By reverse engineering the latest version of the software managing communications, a better understanding of the system can be obtained, and potential security flaws and vulnerabilities can be identified.

For the Mavic Pro, DJI only provides signed and encrypted firmware packages. A public vulnerability in the Mavic Pro[3] allows IOActive to enable debugging access to the device. This information allows us to better understand the internal structure of the device and advance our research.

No-Fly Zones

Most drones have several “no-fly zones” set up to prevent accidents and unauthorized use. These no-fly zones are areas where drones are not allowed to take off or fly, designed to protect sensitive locations such as airports, military bases, and other areas where drone operations may pose safety risks.

Sensitive Information

In some cases, exploiting the information stored by drones, such as flight plans, images, and other potentially sensitive data, is worth considering.

Drone Architecture

DJI integrates a variety of sensors and peripherals into its drones to enable advanced features and enhance performance.

• Gyroscopes and accelerometers are used to measure the drone’s orientation and motion, providing the necessary information to maintain stability and control.

• Barometers measure atmospheric pressure, allowing the drone to determine its altitude and maintain a consistent flying height.

• Global Positioning System (GPS) sensors are used to determine the drone’s location and enable features such as automated takeoff and landing, as well as geofencing.

• Compass sensors are used to determine the drone’s heading and enable features such as automated waypoint navigation.

• Ultrasonic sensors measure the distance to the ground or other objects, enabling features such as automated hovering and obstacle avoidance.

• Cameras are used to capture photos or video footage from an aerial perspective. Drones are equipped with cameras that allow users to see in real-time what the drone sees and capture images and videos from unique angles that traditional cameras cannot achieve.

The two main processors in the DJI Mavic Pro are:

• Video and Image Processing CPU: This SoC is produced by Ambarella International LP (Ambarella), a technology company specializing in the design and development of low-power, high-definition video processing semiconductors. [4] Founded in 2004, headquartered in Santa Clara, California, the company is known for its ability to capture and transmit high-quality video while consuming very little power.

• Android-based Control CPU: This is an ARM Cortex-A7-based SoC produced by Leadcore Technology Co., Ltd., a Chinese telecommunications company headquartered in Beijing. The company is known for developing telecommunications technologies, including mobile chipsets and other related products. Leadcore has been operating since 2009, and its products include a range of mobile chipsets for various smartphones and other devices.

Technical Background

Side-channel attacks rely on indirectly obtaining information about the target system by performing different types of measurements during specific operations. Some common attacks using side-channel analysis include:

• Timing Attacks: Analyze and exploit the time taken to complete target operations, such as guessing a personal identification number (PIN) or compromising encryption implementations.

• Power Analysis: Simple Power Analysis (SPA) and Differential Power Analysis (DPA) exploit the power consumed by the target operation. Measurements are typically taken through the voltage paths of the tapped chip. The captured data is mathematically processed to recover secrets, usually encryption keys.

• EM Analysis: Instead of directly measuring power from the hardware’s voltage rails, an EM probe is placed close enough to the chip to capture EM emissions. This method has the advantage of being less invasive and more localized compared to power analysis.

Electromagnetic Fault Injection (EMFI) aims to create hardware disruptions during certain operations. A metal coil (EM probe) is placed near the surface of the target processor. The current flowing through this coil will cause current changes within the processor. This is expected to induce changes in the behavior of the CPU, gaining an advantage; for example, by changing values in memory cells or registers before or after processing.

As mentioned above, the advantages of EMFI include its non-invasiveness, and the disturbance is more localized, unlike power noise interference, where the PCB typically requires physical modification, and the noise interference affects all internal peripherals and processing units connected to the target power rail.

In this work, IOActive used Riscure’s widely recognized FI/ Side-Channel Analysis (SCA) suite. [5] Specifically, we utilized the components described in the remainder of this section, which also came with a powerful and comprehensive software suite designed to support security researchers.

XYZ Table

When using power analysis techniques, data is retrieved by tapping the voltage paths powering all internal processing units of the target processor. One of the challenges when converting voltage readings to EM readings is finding the right location on the chip’s surface. To achieve this, we used an XYZ table, as shown in Figure2, to scan the chip area and locate the best position for leaking more information.

Figure2:XYZ table fixed to the bottom surface of a PCB

To correctly use this device, properly setting the Z axis is crucial. This is a key factor because if the EM tip is too close to the target, the tip itself may get damaged while moving around the chip package. Conversely, if the EM tip is too high, the measured signal will be too weak to be effective.

IOActive adopted two techniques to address this issue. The first is using a USB micro camera to observe the gap between the EM tip and the surface. The second is a technique commonly used in 3D printing: placing a thin piece of paper between the EM tip and the chip, positioning the EM tip, and then attempting to pull the paper out. If the gap is too small, the paper will not move; conversely, if it is too large, it will move freely. A slight friction when moving the paper indicates that the tip height is optimal.

Once the Z axis is set to a fixed position, the next step is to specify a rectangle on the XY axis, which is the area of the chip to be scanned.

EM Probes

The high-precision EM probes used in this study are designed by IOActive to detect EM emissions from semiconductor circuits and are equipped with tips of three different diameters (0.2mm, 0.5mm, and 1.2mm) with directional coils and PTFE protective shells. This tool is capable of picking up electromagnetic fields up to 6GHz and converting them into AC signals.

The EM probe connects to an amplifier, as shown in Figure3, with the output routed through a BNC cable to an oscilloscope. The software suite then interprets the EM measurements to create heat maps, accurately locating the areas of maximum emission.

Figure3: Block diagram of EM probe and amplifier, along with the XYZ table connecting the EM probe to the amplifier

Oscilloscope

IOActive used the oscilloscope shown in Figure4 as a critical element of the project’s SCA and FI sections.

Figure4: Oscilloscope used to identify optimal points and verify EM faults

During SCA, the oscilloscope is used to capture signal leaks from computations executed in the target CPU. During EMFI, it is used to verify whether small faults are generated in the desired shape and timing.

SPIDER and EM-FI Detectors

For EMFI, IOActive utilized Riscure’s Spider tool and EM-FI transient probe, as shown in Figure5.

Figure5:Riscure’s Spider (left) and EM-FI transient probe (right)

Spider simplifies the complexity of SCA and EMFI by creating a single control point with all I/O and reset lines for custom or embedded interfaces. As part of this project, IOActive used the Spider tool to generate arbitrary fault waves. This tool allows for adjustments to the output voltage, timing, repetition rate/ frequency, and duration of the pulses.

Riscure’s EM-FI transient probe senses fast, high-power EM pulses at user-defined locations on the chip. Fast and short pulses can be configured via software, providing rapid and predictable trigger responses.

Target Drone

IOActive’s approach is to use a controlled testing environment to investigate whether it is feasible to attack hardened drones using side-channel or EMFI techniques. To ensure a controlled environment, IOActive targeted a drone model and firmware version with publicly disclosed vulnerabilities. This would allow us to better understand and control each different stage by reverse engineering the software components involved in the firmware upgrade process. Additionally, it would provide an opportunity to gain insights into potential device failures or other behaviors that could delay testing. If successful, we could apply the lessons learned from this stage to attempt these types of attacks on devices without known vulnerabilities using a completely black-box approach. Furthermore, if any future targets use the same SoC as the initial target, we could even reuse the search areas identified in this project. This would save valuable time by eliminating the need to scan the entire SoC surface and adjust parameters such as duration, delay, and intensity.

Considering these factors, IOActive chose the DJI Mavic Pro. In addition to key leakage, it is also common in the second-hand market, which may be beneficial during our research process if an incident leads to unit damage.

Drone PCB Preparation

The first step is to identify the main PCB of the drone and create an isolated environment where it can be powered without the original battery and placed under the analysis probe.

After removing the plastic casing, peripherals, and sensors, the result is shown in Figure6. The components of interest are highlighted in red: Leadcore SoC. This SoC runs a custom version of Android and manages USB communications and the firmware upgrade process.

Figure6: Main PCB with all different components

Figure7 shows the PCB being analyzed. It is important to note that IOActive had to include an external fan to dissipate the heat generated by the PCB components. Without it, the temperature would rise rapidly after powering on, leading to a reboot.

Figure7: PCB on the XYZ workstation, powered by an external source

Method One

As mentioned in the assets section, one of the main priorities for any threat actor approaching the system is to access unencrypted firmware. Therefore, our first goal is to investigate the feasibility of recovering the keys used to encrypt/decrypt firmware packages using side-channel power leakage.

The power leakage of cryptographic algorithms is related to the mathematical operations involving payloads controlled by the attacker and unknown keys. The instructions computing data from two elements will consume more or less power, depending on the number of bits in the use case outcome. This is commonly referred to as a leakage model, and is sometimes modeled as Hamming distance.

IOActive’s goal is to build a setup that allows us to:

• Send random data to the target for later use in encryption calculations

• Perform repeated tests to collect thousands of power traces

• Analyze the retrieved data and recover the encryption key

As stated in step1, a key part of leveraging side-channel leakage is performing targeted operations to handle sufficiently entropic data for statistical analysis. In this case, we were able to submit random data that would conform to the target operations in the encryption algorithm. To achieve this, we analyzed the packet format and generated valid packets that could be input into the decryption process. Figure8 shows one of the packets modified to provide verification applications and some values.

Figure8: Binary view of the upgrade package showing the type and length of the packet

The generated package contains random data that will be used during statistical analysis in relation to the captured EM traces. Therefore, we need to generate a large number of “fake” update packets.

Step2 involves understanding the update process so that we can automate the submission of modified packets and record EM emissions for later analysis.

Figure9 describes the steps involved in the DJI drone firmware update process. We were fortunate to have a model running an ADB shell, allowing us to identify the process handling software package signatures and decryption.

Figure9: Steps involved in the firmware update process[7]

Signature verification and decryption are performed by the dji_verify application. This executable is designed to run as a command-line tool and accepts various parameters, including the path to the file containing the firmware package.

Further analysis of the binary file allowed us to determine the points at which signature verification is executed. Since one task is to find the locations on the chip surface with stronger EM signals, we decided to patch the dji_verify binary to bypass the signature check and directly execute firmware package decryption.

From a top-level view, the entire process includes the following steps:

• Generate modified firmware packages (although during the first scanning phase we used fixed firmware packages).

• Copy the file to the drone via ADB.

• Execute the patched dji_verify.

• Obtain EM data and return to step1.

Step3 will bring together the hardware and software necessary for performing power analysis. Figure10 shows the partial setup used to record power leakage in the form of EM emissions. The EM probe is connected to the XYZ table and positioned on top of the Leadcore SoC, where encryption operations are performed.

Figure10: Setup for detecting power leakage in the form of EM emissions

A key feature of the tools provided by Riscure is the Inspector, a powerful software suite that implements all statistical, mathematical analysis, and data transformation required for performing SCA.

The only missing part is those that need to interact with each different range of devices. For this project, IOActive developed Java code (included in Appendix B) that accepts input parameters (such as repetition) and coordinates the launch of the target binary. The inspector will be responsible for locating the XYZ table, reading the EM signals, and plotting the results.

At this stage, the first goal is to find a region with strong EM signals so that we can place the probe and record thousands of traces to obtain enough information to extract the key.

Once the location with the strongest signal is identified, we switch from the patched dji_verify binary back to the original setup, which includes firmware signature verification. We then begin exploring the feasibility of using EMFI to bypass the signature check.

At this point, we switched from Inspector to FIPython (FIPy), a web-based framework provided by Riscure to assist the FI process. This is described in more detail in the “Method Two” section of this document. Figure11 is a graph produced by FI Spotlight, showing the results of this round of testing.

Figure11: Successfully bypassed (red), undetermined (orange), rebooted (yellow), and normal operation (green)

After several days of experimentation and data analysis, we found that the probability of successfully bypassing the signature was less than 0.5%. This made key recovery infeasible, as the hardware-based encryption engine used by Leadcore SoC requires collecting hundreds of thousands of traces to execute a SCA attack.

At this point, we paused further efforts on Method One, reanalyzed the target, and proposed a second attack scenario.

Method Two

There are several potential avenues for bypassing security mechanisms using physical attacks, but most of them require modifications to the PCB. We would typically use EMFI with the hope of enabling debugging capabilities via JTAG; however, we chose a path proposed in a research paper by Riscure.

Riscure’s researchers described the different results they obtained when applying FI to the target SoC. An interesting finding in IOActive‘s research was that faults caused the processor to modify the contents of target registers during memory operations.

If the above results can be reproduced, we could potentially execute our payload during the update process. This means two requirements:

• We have the capability to provide custom payloads for the target system. From our work using Method One, we already know this to be true.

• The process will copy memory from one location to another. Additionally, from our work on dji_verify, we know that the provided payload is first copied to memory to compute the encryption signature and see if it matches the signed signature.

In this new attack path, we aim to demonstrate that using EMFI on the target device to gain code execution is feasible. The high-level overview of the process is as follows:

• The update process will copy an attacker-controlled payload from one memory location to another.

• During the copying, a small fault is generated with the aim of altering the behavior of the instruction being processed.

• Analyze the results to determine what type of instruction modification occurred.

To proceed with this approach, we need to complete the following tasks:

• Generate the firmware package that the dji_verify program will process.

• Obtain stack traces and register information to simplify the process of understanding whether the attack was successful. We used GDB for this step; this is one of the benefits of having a controlled environment.

• Set up Riscure’s fault injection device and adjust FIPy to match our target.

To accomplish task1, we modified the packet header and added a file containing 10MB 0x41 bytes as the payload, as described in Method One. This helps assess the actual exploitability of the injected payload when analyzing the GDB output.

A limitation of the EMFI setup is finding an accurate hardware trigger. The density of components and multi-layer PCB make it challenging to find the right signal without risking damage to the sample (which is one of the limiting factors of this project). To overcome this issue, we relied on timing, based on the moment we received information through the sub-threshold output; however, this approach reduces the repeatability of the injection, making it harder to find successful hits.

Figure12 shows the setup we used to complete task3 for EMFI. The EM probe is connected to the XYZ workstation, and the Spider tool is connected to a computer providing the trigger timing. The oscilloscope is used to verify that we injected the correct pulse shape at the right time, with the output shown in Figure13.

Figure12: Setup used for FI during the second approach

Figure13: FIPy application displaying oscilloscope records

Using Inspector and FIPy has one distinction: the former provides a Java interface, while the latter executes Python scripts. This time, we wrote a Python script (included in Appendix C) to manage interactions with the target device, instructing the Spider tool to trigger faults and store results.

Once the entire setup works perfectly, we need to run tests multiple times around the XY axis with different noise interference strengths and timings until we find a successful or potential error that can help us narrow down the attack surface.

After identifying a sufficiently small area, we modified the shape and timing of the fault until we observed a successful fault. After multiple attempts, we achieved what we wanted: the dji_verify program crashed, as shown in the following output.

Our payload appeared in several registers. After checking the code at the target address, we determined that we had achieved the perfect combination of timing, position, and fault shape.

Figure14 clearly shows the load instructions that copy IOActive‘s data into registers R0 and R1. The GDB output above shows that registers R3 and R4 also ended with controlled data.

Figure14: Illustration of segmentation fault occurrence

The following two instructions copy R0 and R1 to controlled addresses instead of copying data to the destination buffer.

The most likely scenario here is that we were able to modify the load instruction instead of just reading two registers; it ultimately read four. The original instruction encoded as:

While the instruction encoding that led to the observed results is:

This means that the fault was able to modify a byte by flipping two consecutive bits and converting one instruction into another.

With this result achieved, the next step would be to write an appropriate payload that converts this memory corruption into a code execution vulnerability. This could potentially allow an attacker to gain complete control of a device, leak all its sensitive content, enable ADB access, and possibly leak encryption keys.

Future Work

In this document, we described the materials and methods used to successfully implement drone attacks using EMFI technology.

The goal of this project was to investigate the feasibility of such attacks on complex modern devices. Having successfully demonstrated that runtime control can be obtained on the device during firmware updates, the next step is to apply the knowledge gained from DJI to another model that previously had no known vulnerabilities.

To accomplish this task within time and budget constraints and create reliable exploitability, several elements must be improved:

• Hardware Trigger: This may be the element that can significantly reduce project time and complexity. As mentioned in this document, we only used a timing-based trigger software, which made it difficult to reliably know how to trigger a successful fault.

To achieve the desired hardware trigger, two different avenues can be explored: (i) finding an LED or available PCB trace from which we can detect level changes while the firmware update is being processed, or (ii) using Riscure‘s ICWaves to identify power signatures consistent with the firmware upgrade package being processed.

• Integration: Integrate all elements discussed in this report, as well as the hardware trigger and the firmware package sent to the drone, as it will be used for actual firmware updates.

• Payload: Create a payload that can be easily checked to determine whether the fault was successful. There are different options, but one of the most obvious choices is to enable ADB, allowing us to check from the host initiating the attack whether the USB connection is active.

Mitigation Measures

Increasingly published research indicates that applying EMFI to mitigate the outcomes of target systems is promising. This opens up new avenues for potential vulnerability attacks on current and future products.

IOActive recommends that product developers implement EMFI countermeasures in their products by employing hardware and software countermeasures to mitigate these attacks. Hardware countermeasures are highly effective in preventing EMFI attacks but can be costly and must be planned during the early design stages. On the other hand, software countermeasures can be added in the later stages of development but may be less effective in mitigating certain attacks. Information on implementing EMFI countermeasures can be publicly accessed in academic papers, conference presentations, and blog posts.

We also recommend using third-party labs such as IOActive to assess the effectiveness of EMFI countermeasures.

AppendixA: Additional Information

This appendix aims to provide more information about the introduction and a glossary of the charts and equations used in this document.

About IOActive

IOActive is a trusted partner of over 1000 enterprises across all industries, providing research-driven security services. Our cutting-edge security team offers highly specialized technical and procedural services, including full-stack penetration testing, program performance assessments, and hardware hacking. IOActive brings a unique attacker perspective to every engagement to maximize security investments and improve our clients’ security posture and operational resilience. IOActive was founded in 1998 and is headquartered in Seattle, with global operations.

IOActive Labs research blog: http://blog.ioactive.com

About the Author

As the Hardware Security Director and vulnerability researcher at IOActive, Gabriel Gonzalez has completed hundreds of projects in reverse engineering, code review, and integrated hardware and software penetration testing. His primary focus is on hardware and embedded systems technology, with expertise in low-level attack vectors, fault injection, and side-channel analysis. Gabriel has researched in areas such as automotive, avionics, smart grid/utilities, satellite communications, banking equipment, and the Internet of Things.

Gabriel is actively involved in the security research community and has presented many original cybersecurity research projects at major conferences such as Black Hat Europe.

AppendixB: JAVA Code

The following Java code accepts input parameters such as repetition and coordinates and launches the target binary

AppendixC: FIPY Controller Code

The following Python script manages interactions with the target device, instructing the Spider tool to trigger faults and store results.

[1] https://security.dji.com/data/resources/

[2] https://www.dji.com/mavic

[3] https://github.com/CunningLogic/DUMLRacer

[4] https://www.ambarella.com/

[5] https://www.riscure.com/security-tools/

[6]Source: https://github.com/o-gs/dji-firmware-tools/wiki/WM220-Core-Board-A

[7]Source: DJI Security White Paper: https://security.dji.com/data/resources/

[8] https://www.riscure.com/publication/controlling-pc-arm-using-fault-injection/