From the radio link to the motor bus, one drone ecosystem in one model
QVR-REF-001 models Project Quiver, an open-source 25 kg multirotor, with its ground station, a Crazyflie 2.1 stack, a maintenance bench and the twin platform: nine systems, built only from public sources. Watch an attacker reach the motors in under two minutes, then see what closes the path.
Built from open-source hardware, with every value marked
Project Quiver publishes its bill of materials, its PCB production files and its harness guide. The model is built from those, from the Bitcraze and ArduPilot documentation and from vendor manuals, and from engineering judgement where the sources are silent.
- system records in the ecosystem
- 9system records in the ecosystem
- BOM items from the open-source repository
- 143BOM items from the open-source repository
- PCB components at KiCad positions
- 297PCB components at KiCad positions
- harness wires with pin, signal and gauge
- 135harness wires with pin, signal and gauge
- interfaces · sub-interfaces
- 34 · 58interfaces · sub-interfaces
- failure modes, 10 of them attacker-triggerable
- 45failure modes, 10 of them attacker-triggerable
- github.com/Arrow-air/project-quiver
Arrow-air Project Quiver
The airframe: bill of materials, KiCad PCB files, harness guide and ArduPilot configuration.
- Crazyflie 2.1 datasheet (PDF)
Bitcraze Crazyflie 2.1
The nano-drone stack: processors, radio, sensors and the expansion-deck bus.
- Hobbywing DroneCAN ESC
ArduPilot documentation
How the flight controller drives the Hobbywing ESCs over DroneCAN.
- EUR-Lex
Regulation (EU) 2024/2847
The Cyber Resilience Act, the regime the evidence pack is built for.
Every value in the model is marked reported, from a cited source, or assumed. Firmware versions are unpinned, geometry is procedural and no hardware was tested.
Watch an attack reach the motors, and what stops it
The walkthrough runs twelve chapters in 1 minute 55 seconds and then loops: the nine systems, the airframe taken apart part by part, the flat onboard network, a path from the radio bridge to the flight controller, two hardware faults and the controls that close the path. Pause it, pick a chapter, switch the three injected faults on or off, change the view to X-ray or wire, or select any part, wire or conduit to inspect it.
It is a stripped-down visualization of the model, not the platform interface. Its behavior is simulated and runs the same way every time.
On a phone, open it full screen.
- systems
- 9systems
- parts in the scene
- 1,181parts in the scene
- interfaces
- 34interfaces
- failure modes
- 45failure modes
- chapters
- 12chapters
- scenario switches
- 3scenario switches
Twelve chapters, three injected faults
Times are where each chapter starts in the walkthrough, and the titles are its own. A dashed chip names the scenario switch that takes the chapter's fault out of the run.
The system
- 010:00
Nine systems, one model
The representational ecosystem: Project Quiver with its HM30 link, the MK32 ground station, QGroundControl, a Crazyflie 2.1 stack, a maintenance bench and the twin platform. Every part, wire and interface is a record.
Monitor - 020:08
Project Quiver at full scale
Aluminum plate frame, carbon arms, four X6 Plus motor-ESC units and a 14S 30 Ah smart battery, built from the open-source BOM. Zones are drawn as volumes around the parts they hold.
Monitor - 030:15
Every part, exploded
143 BOM items, 297 PCB components at KiCad positions, 28 harnesses and about 600 fasteners, each with its own record, zone and links. Geometry is procedural; identifiers and quantities come from the repository.
Inspect - 040:24
The onboard LAN
One flat 192.168.144.0/24 network joins the HM30 bridge, two unmanaged GigaBlox switches, the CubeNode PPP adapter and the Raspberry Pi 5. No VLANs or 802.1X are documented.
Inspect
The attack path
- 050:32
Companion computer: known exploited vulnerabilities
The SBOM lists Raspberry Pi OS (64-bit) with versions unpinned. If the image is unpatched, five entries in the CISA KEV catalog apply to its kernel and userland; without pinned versions the match is flagged as possible, not confirmed.
VulnerabilitySwitch: KEV - 060:42
Initial access through the radio bridge
The HM30 carries Ethernet transparently, so a node on the ground station's network reaches the aircraft LAN. The scenario assumes SSH on the companion with a weak credential; this step needs no CVE.
AttackSwitch: KEV - 070:52
Privilege escalation to root
With a shell, the attacker uses CVE-2024-1086, a use-after-free in the kernel's nf_tables, listed in KEV since May 2024. Root on the companion gives control of its network stack, MAVLink router and camera client.
AttackCVE-2024-1086Switch: KEV - 081:00
Pivot to the flight controller
From the companion, MAVLink packets cross the switch and the CubeNode PPP link to the Pix32 v6. Signing is not configured, so ArduPilot accepts mode changes, mission uploads and arm commands from any source.
AttackFM-32FM-27Switch: KEV - 091:10
Effects on the aircraft
Top events reached in the fault trees: flyaway and uncommanded motor start. The pilot still holds RC through SBUS, but the GCS failsafe is off by default, so loss of telemetry triggers nothing.
ImpactFM-32FM-27Switch: KEV
Faults and the fix
- 101:21
Hardware fault: CAN1 short
A short between CAN_H and CAN_L in any ESC, GNSS, radar or Remote ID harness silences the whole bus. The ESCs fall back to PWM, both GNSS receivers drop together, and the EKF failsafe lands the aircraft.
FaultSwitch: CAN1 short - 111:34
Single motor loss
A quad has no motor redundancy. Losing the front-right motor removes attitude authority within about 150 ms, and crash check disarms after 2 s of attitude error.
FaultFM-14Switch: motor loss - 121:44
What closes the path
Pin and patch the companion image so the KEV match can be checked, disable password SSH, put the companion on its own VLAN with an allow-list to the CubeNode, and enable MAVLink 2 signing. Separate the ESC bus from GNSS and payload nodes.
Mitigated
Nine systems, eight zones
Project Quiver is a 25 kg maximum take-off weight multirotor with 5 to 8 kg of payload, four Hobbywing X6 Plus motor-and-ESC units, a 14S 30 Ah smart battery and four custom PCBs. The model holds it, and the systems around it, as independent system records, each with its own bill-of-materials fragments, documentation, configuration and the buses and links to its neighbors.
- SYS-QVR-AIR
Air vehicle
Pix32 v6 flight controller with ArduPilot, Raspberry Pi 5, 2× GigaBlox Nano switches, CubeNode ETH, Here4 + M9N GNSS, NRA15, MR82, RPLidar S2L, db201 Remote ID, SIYI A8 mini, Main / BC / FC / Attachment PCBs
- SYS-HM30-AIR
Airborne link
SIYI HM30 air unit and two antennas: RC, MAVLink telemetry and video over one radio
- SYS-MK32-GCS
Ground controller
SIYI MK32 handheld ground station
- SYS-QGC-WS
Operator workstation
QGroundControl workstation
- SYS-CF21-AIR
Air vehicle
Crazyflie 2.1: STM32F405 + nRF51822, BMI088 / BMP388, expansion-deck bus
- SYS-CRADIO
Radio gateway
Crazyradio 2.0 (nRF52840) USB dongle
- SYS-CF-HOST
Operator workstation
cfclient / cflib host
- SYS-DT-PLAT
Twin platform
DMZ broker and gateway, asset graph, model store, telemetry store
- SYS-MAINT
Maintenance
Debug probe, provisioning laptop, charger, calibration turntable
Zones inside the product
| Zone | Contains | Why it is separate |
|---|---|---|
| Z-AIR-FLIGHT | Pix32 v6, FC PCB, GNSS, LiDAR, radars | Integrity and availability of flight control dominate |
| Z-AIR-ACT | Battery, BC PCB, busbars, X6 Plus motors and ESCs, propellers | Prevent unsafe actuation and preserve a safe state |
| Z-AIR-COMMS | HM30 air unit, antennas, CubeNode ETH, switches, Remote ID | Terminates every externally exposed conduit |
| Z-PAYLOAD | Raspberry Pi 5, A8 mini camera, attachment interfaces | Potentially lower-trust applications |
| Z-GROUND-CTRL | MK32, QGroundControl, cfclient host, Crazyradio | Holds operator authority and credentials |
| Z-DMZ · Z-ENTERPRISE | Twin integration DMZ; twin services | Separate operational data from enterprise services |
| Z-MAINT | Debug probe, provisioning laptop | Privileged cross-zone capability |
Z-DMZ and Z-ENTERPRISE share a row, as in the case study, so seven rows hold the eight zones.
Who can command the motors
The model holds the airframe part by part and link by link: plates, arms, PCBs with their components at KiCad positions, every harness wire with its pins, and the buses that join them. That is what lets a single failure, or a single unauthenticated bus, be traced to everything that depends on it.
Avionics architecture, ground to power
- GroundMK32 ground controllerQGroundControl workstationTwin platform: DMZ broker, asset graph
- RF · SIYI HM30 · 2.4 GHz · RC + MAVLink + video on one link
- Ethernet · flat 192.168.144.0/24 via 2× GigaBlox Nano · PPP over TELEM2 via CubeNode ETH (addressing assumed)
- Payload and companionRaspberry Pi 5: companion computer, MAVLink router (assumed)SIYI A8 mini: RTSP :8554 · SDK UDP :37260 (assumed)
- CAN2 · NRA15 radar altimeter, CubeNode, payload attachment interfaces
- Flight controlPix32 v6 + FC PCB: ArduPilot, on the Main PCBHere4 + M9N: dual GNSS on CAN1
- CAN1 · DroneCAN · X6 Plus ESCs ×4, GNSS, MR82, Remote ID · PWM backup on the same harness
- Power and actuationTattu 14S 30 Ah: smart battery, BMS on CANBC PCB: SSR, precharge, fusingCu busbars: HV bus to 4× XT60X6 Plus ×4: 24×8 propellers
Drawn from the model (case study, Figure 1). The HM30 is the single radio conduit leaving the aircraft. Addressing and rates marked assumed are typical defaults.
Any node on CAN1 can command the motors
DroneCAN frames carry no authentication, so for this configuration the answer to "who can command the motors?" is any node on CAN1: the four ESCs, both GNSS receivers, the MR82 radar and Remote ID share the bus, and the PWM backup runs in the same harness. That is a specific, testable finding rather than a general statement about the protocol.
Exploded X-ray view (case study, Figure 2). Each labeled item is a part with its own record, zone and links. Geometry is procedural, not CAD.
Every link, typed
| Link | Protocol · rate | Control | Evidence |
|---|---|---|---|
| Flight controller → X6 Plus ESCs | DroneCAN on CAN1, 1 Mbit/s; RawCommand at 400 Hz (assumed) | CRC only; no node authentication | Reported |
| HM30 ↔ flight controller | MAVLink 2 over UART, 115 200 baud (assumed) | Signing available, not configured | Assumed |
| HM30 → flight controller | SBUS, 100 000 baud 8E2, 16 channels | Physical access only | Reported |
| Flight controller ↔ CubeNode ETH | PPP over TELEM2 with RTS/CTS | Flat LAN; no VLAN or 802.1X | Assumed |
| A8 mini → HM30 | RTSP / H.264 over Ethernet | None documented | Assumed |
| MK32 ↔ HM30 | Vendor 2.4 GHz digital link | Pairing; encryption not evidenced | Unknown |
| Crazyradio ↔ Crazyflie | CRTP over Enhanced ShockBurst, default address 0xE7E7E7E7E7 | No authentication or encryption | Reported |
| STM32F405 ↔ nRF51822 | Syslink UART, 1 Mbaud | Checksum only | Reported |
One record for hardware, software, wiring and crypto
The model holds CycloneDX 1.6 bills of materials beside a DEXPI-style structural export, all keyed to the same component identifiers. Here the hardware side is rich, because the repository publishes it; the software side is thin, because firmware versions are not published.
HBOM
143 BOM items with quantities, materials, suppliers, part numbers and STEP references; 297 PCB components with footprint, value and position.
Missing in open-source dataBatch, lot and certificate-of-origin data
SBOM
19 firmware, OS and application components across both stacks, with package URLs where they exist.
Missing in open-source dataEvery version is unpinned, so no CVE match can be claimed
Harness
28 harnesses and 135 wires with pins at both ends, signal, color and gauge.
Missing in open-source dataRoute lengths come from the guide; 3D routing is procedural
CBOM
Placeholders for link encryption and signing per sub-interface.
Missing in open-source dataNo cryptographic material is documented in the sources
Suppliers in the open-source BOM
The Project Quiver bill of materials names the supplier of each part. The model records them, so provenance and export questions can be asked of it.
China
5- HobbywingX6 Plus motor + ESC, MFP 24×8 propellers
- HolybroPix32 v6 flight controller
- SIYIHM30 link, MK32 controller, A8 mini camera
- Tattu14S 30 Ah smart battery
- Nanoradar · Slamtec · MateksysNRA15, MR82, RPLidar S2L, M9N
Australia
1- CubePilotHere4 GNSS, CubeNode ETH
United Kingdom
2- Raspberry PiRaspberry Pi 5
- BotBloxGigaBlox Nano Ethernet switches
Sweden
1- BitcrazeCrazyflie 2.1, Crazyradio 2.0
Locations as publicly stated by each company, for illustration only. They are headquarters, not batch-level provenance.
Two paths, and what closes them
The model carries a dependency model of 80 functional nodes. Any part, wire or bus can be failed, and the cascade, the redundancy that holds and the failsafes that respond are replayed on a timeline. Ten of the 45 failure modes can be triggered by an attacker through a security gap. Two of them:
Uncommanded motor start via CAN1
- A rogue node is attached to CAN1, for example through a payload or service connector.
- It publishes DroneCAN ESC RawCommand frames; the ESCs cannot tell them from the flight controller's.
- Motors spin up or change thrust without operator command.
Mitigations to evidence
- Physical access control on CAN connectors
- Segment the ESC bus from GNSS, radar and payload nodes
Malicious firmware through the service port
- A provisioning laptop is compromised.
- An unsigned image is flashed to the flight controller over USB or SWD.
- The aircraft behaves as the attacker chooses: flyaway or uncommanded motor start.
Mitigations to evidence
- Signed bootloader enabled and recorded
- Controlled provisioning with firmware hash checks
The network path the walkthrough plays
A third path runs over the radio rather than a connector. Chapters 6 to 9 of the walkthrough follow it step by step.
- Radio bridge (HM30)Chapter 06
- Companion computer on the flat LANChapter 06
- Privilege escalation to rootChapter 07
- Unsigned MAVLink to the flight controllerChapter 08
- Effects on the aircraftChapter 09
Five possible known exploited vulnerabilities
Chapter 5 of the walkthrough lists five entries from the CISA Known Exploited Vulnerabilities catalog that could apply to Raspberry Pi OS on the companion computer.
- CVE-2024-1086Linux kernel · nf_tablesCWE-416 · in KEV since 30 May 2024
- CVE-2023-4911glibc ld.soCWE-122 · in KEV since 21 November 2023
- CVE-2021-4034polkit pkexecCWE-787 · in KEV since 27 June 2022
- CVE-2024-53104Linux kernel · UVC video driverCWE-787 · in KEV since 5 February 2025
- CVE-2023-0386Linux kernel · OverlayFSCWE-282 · in KEV since 17 June 2025
Possible, not confirmed: the SBOM's versions are unpinned, so no CVE can be matched to this build. The case study claims no match.
What closes the path
The last chapter of the walkthrough maps the controls that break the path to the requirements they answer.
CRA Annex I
(a) pin and patch, VEX per CVE · (d) MAVLink 2 signing, key-only SSH · (h) split CAN1, separate PWM harness · (j) companion VLAN, allow-list
IEC 62443 foundational requirements
IAC · SI · RDF
Scores and capability estimates are engineering judgement for a representational model, not a certified analysis. Both scenarios end in a top event of the fault trees: loss of control, flyaway or uncommanded motor start.
Each phase produces part of the technical file
The example was built with the same six-phase readiness method used for client engagements. Phases 1 to 4 follow IEC 62443, with the emphasis on the product lifecycle and component requirements (62443-4-1 and 4-2) and the CRA obligations on top. Phases 5 and 6 are Eigenia additions: an ALARP review, so residual risk is argued rather than assumed, and a defined handover to the test bench.
| Phase | Applied to the example | Feeds the CRA evidence |
|---|---|---|
| 1Scope and classify | Nine system records inventoried; scope and class left open for a representational product | Classification record with reasoning; product description for the technical file |
| 2Risk assessment | Eight zones from flight control to maintenance, with SL-T per foundational requirement; 45 failure modes and five fault trees | The cybersecurity risk assessment the technical documentation must contain |
| 3Requirements and design | 34 interfaces and 58 sub-interfaces typed at signal, protocol, network and security level | RTM rows; non-applicable requirements justified |
| 4Secure development and vulnerability handling | CycloneDX 1.6 SBOM with 19 firmware and software components (versions unpinned); HBOM from 143 BOM items | Vulnerability handling evidence and the security update plan |
| 5ALARP review | Estimated SL-C against SL-T per sub-interface; cascades simulated for every failure mode | Residual risk argument recorded in the technical file |
| 6Handover to the test bench | Export package generated; gate decision recorded as no-go with listed gaps | RTM, test results, declaration readiness |
The 24-hour clock
Under Article 14 of the CRA, which applies from 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability or a severe incident must report it through the single reporting platform to ENISA and the national CSIRT.
- T + 24 hEarly warning
- T + 72 hNotification
- FinalFinal report
The regulation applies in full from 11 December 2027, when CE marking requires demonstrated conformity.
Annex I requirements, mapped to evidence
- No known exploitable vulnerabilities19 SBOM components placed on their links; versions unpinnedGap
- Secure by defaultArduPilot defaults leave GCS and battery failsafes disabled; Crazyradio uses a default addressGap
- Protection against unauthorized accessDroneCAN, CRTP and unsigned MAVLink accept unauthenticated commands; SL-C 0 against SL-T 2Gap
- ConfidentialityUnencrypted links listed per sub-interfaceGap
- IntegrityCRC on buses; firmware signing not evidencedGap
- Minimal attack surface34 interfaces enumerated, including USB-C and SWD service portsPartial
- Resilience to denial of serviceA single CAN1 fault drops ESC CAN, both GNSS, radar and Remote ID; cascade simulatedPartial
- Secure updatesUpdate paths modeled for flight controller, ESCs and peripherals; signing not evidencedGap
The digital files
Every file is machine-readable and generated from the same model, so they agree with each other by construction.
- models/drone-twin-sos.glbglTF 2.0 · full scene with per-part metadata
- sbom/cyclonedx-1.6.jsonCycloneDX 1.6 · hardware, firmware, applications, interfaces as services
- dexpi/drone-twin.dexpi.xmlDEXPI-style XML · equipment, signal lines, cables and conductors
- data/icd.csv · icd.jsonCSV / JSON · interfaces and sub-interfaces with parameters and pinouts
- data/harness_wires.csvCSV · 135 wires with pins, signal, color and gauge
- fmeca/failure_modes.jsonJSON · 45 failure modes with cascade, failsafes and top events
- fmeca/dependency_graph.graphmlGraphML · 80 functional nodes and their dependencies
- db/neo4j/drone_twin.cypherNeo4j Cypher · assets, zones, interfaces and failure modes as a graph
Test bench readiness
The model defines what a bench must test and tracks whether each test is ready. For this representational example none has been run.
- Port and service scan of every interfaceDefined
- Signed and unsigned firmware on the flight controllerBlocked
- Injected DroneCAN ESC commands on CAN1Defined
- Unsigned and replayed MAVLink framesDefined
- CAN1 short with PWM backup checkDefined
- SBOM against firmware manifestBlocked
- Early-warning drill inside 24 hoursDefined
Requirements Traceability Matrix, an excerpt
| Requirement | Components | Test | Evidence |
|---|---|---|---|
| R-01No known exploitable vulnerabilities | ArduPilot, AP_Periph, HM30, A8 mini firmware | SBOM against manifest, CVE scan | SBOM + VEX record |
| R-03Unauthorized access | Pix32 v6, X6 Plus ESCs, HM30 | Injected and replayed frames | Bench log |
| R-05Integrity | Bootloader, CAN1, UART links | Tampered firmware, command injection | Bench log |
| R-07Denial-of-service resilience | CAN1, ESC signal harnesses, HM30 | Bus short, link jamming | Cascade + bench log |
| R-08Secure updates | Flight controller, ESCs, peripherals | Signed and unsigned bundles | Update test report |
| R-09Vulnerability reporting | Whole ecosystem | 24-hour drill | Drill record |
Not ready for the bench, and the gaps are listed
Versions are unpinned, firmware signing is not evidenced and the onboard links accept unauthenticated commands, so the readiness review records no-go. In a representational example many rows are gaps, and showing them is the point: on a client engagement each gap gets an owner and the work needed to close it.
The same model, other regimes
The same record answers the RED delegated act, the UK PSTI rules and IEC 62443-4-1 and 4-2. How we take a product through them is on the CRA conformance page.
CRA conformanceThe presentation
The 20-slide presentation
The same example as a slide deck: who it is for, the eight layers with a drone example for each, the worked example on the platform, why now and which rules apply, and what you receive.
Representational: public sources and engineering judgment; firmware not pinned, no hardware tested. Client engagements use controlled engineering data that stays under the client's control.
Product security and compliance, built on a Cyber Digital Twin
What this model is, and what it is not
QVR-REF-001 is representational: built only from open-source information and engineering judgement, to show how the Cyber Digital Twin prepares a product for the CRA. It is not a model of any manufacturer's product and is not to be read as high fidelity.
Limited information, by design
Firmware versions are unpinned, geometry is procedural and no hardware was tested. The model shows how the platform works; it makes no claim about the security or compliance of Project Quiver, the Crazyflie or any product built from them.
Every figure on this page comes from the case study. The walkthrough adds its own count of parts in the scene and the five possible KEV entries, both labeled where they appear.
What turns it into your twin
- 01CAD and DEXPI drawings of your design
- 02Build manifests, so every SBOM version is pinned
- 03Firmware hashes and the signing and key records
- 04Supplier certificates and batch-level provenance
- 05Test results from your own bench or lab
Eigenia is not affiliated with Arrow Air, Bitcraze or any of the hardware vendors named on this page, and none of them has reviewed or endorsed this model.
Product and project names describe publicly documented equipment; they are the trademarks of their owners. Regulatory summaries are not legal advice, and CRA classification must be confirmed for each product.
See the twin on a facility like yours.
Book a walkthrough
A 45 minute walkthrough of the model, using a facility close to yours. No preparation needed.
We reply within one business day.
Ask a question
A few lines are enough. Tell us what you are working on or what you want to know.
We reply within one business day.
This Site Uses No Cookies
Eigenia does not set cookies. The only thing stored in your browser is one preference, saved in local storage, noting that you have seen this notice.