Drone 101: From Target to Threat Model to Attack

BLUF

You cannot attack — or defend — what you do not understand. This class teaches a repeatable habit: first describe the system honestly, then reason about where it can fail, and only then test. The budget Wi-Fi FPV drone is a great teacher because it is cheap, legal to own, and built from ordinary parts with a well-understood class of weaknesses. Everything here is vendor-neutral: it describes the pattern these devices share, not one product. It also assumes you are testing a drone you own, in a space you control.

The three-act arc

flowchart LR
  A[Act 1: Understand the target] --> B[Act 2: Threat model]
  B --> C[Act 3: Authorized attack]
  C -->|findings feed back| B
  A -.->|recon: teardown, docs, radio| A

Security is a loop, not a line. Each attack you run teaches you something new about the target, which improves the model, which points at the next test.

Act 1 — Understand the target

The goal here is not to attack anything. It is to answer one question: what is this thing actually made of, and how does it talk? A security person calls this reconnaissance and attack-surface mapping. A non-cyber person can call it "reading the machine."

1.1 What this class of drone actually is

A budget Wi-Fi FPV toy drone is a ~$30 quadcopter with a Wi-Fi camera ("FPV" = first-person view). The same handful of ordinary parts shows up across brands. A public teardown of any one of them (see Sources) reveals the shared recipe:

1.2 Draw the system (data-flow diagram)

Before any security work, draw how data moves. This is a DFD (data-flow diagram) — the same picture threat modelers use.

flowchart LR
  subgraph You[Things you own]
    Remote[Handheld remote]
    Phone[Your phone + FPV app]
  end
  subgraph Drone[Toy FPV drone]
    RF[2.4GHz control radio]
    FC[Flight controller MCU]
    Cam[Wi-Fi camera + AP]
    Motors[Motors and sensors]
  end
  Remote -->|2.4GHz command packets| RF
  RF --> FC
  FC --> Motors
  Phone <-->|joins open Wi-Fi AP| Cam
  Cam -->|video stream| Phone
  Phone -->|some commands| Cam
  Cam -.->|GPIO / shared bus| FC

1.3 Recon you can do at home (no attacking yet)

Act 2 — Threat modeling

Now we reason about where it can go wrong — before touching a single tool. Threat modeling is just four questions, made famous as the Threat Modeling Manifesto:

1. What are we working on? → the DFD from Act 1.
2. What can go wrong? → this section.
3. What are we going to do about it? → mitigations (for the defender).
4. Did we do a good job? → validate with the attacks in Act 3.

2.1 Trust boundaries: where control changes hands

A trust boundary is any line where data crosses from something you trust into something you trust less (or vice-versa). Attacks cluster on these lines.

flowchart LR
  Attacker([Anyone within Wi-Fi range]):::bad
  subgraph Trusted[Owner's world]
    Phone[Your phone]
  end
  subgraph Semi[Drone camera network - OPEN]
    Cam[Camera AP + video + command port]
  end
  Attacker -.->|can also join the open AP| Cam
  Phone -->|joins| Cam
  classDef bad fill:#7a1f1f,color:#fff;

The killer observation: on this class of drone the camera's Wi-Fi is typically open and unauthenticated. The trust boundary you think exists ("only my phone talks to my drone") does not actually exist — anyone in radio range is on the same footing as the owner.

2.2 STRIDE on a toy FPV drone

STRIDE is a checklist of six threat types. Walk each one against the DFD. This is the heart of the class — do this slowly.

2.3 Rank the risks

Not all threats matter equally. Rank by likelihood × impact, keeping in mind this is a toy (impact is low — privacy and nuisance, not life-safety, as long as you fly responsibly).

Act 3 — The authorized attack

Now — and only now — we test. Every step targets your own drone on your own phone in a space you control. The point is to confirm the model, feel how easy each gap is, and understand it well enough to explain or defend against it.

3.1 Attack path overview

flowchart TD
  Start[Power on your drone] --> Scan[Step 1: Find and join the open camera AP]
  Scan --> Stream[Step 2: Pull the open video stream]
  Scan --> Enum[Step 3: Enumerate the command port]
  Enum --> Cmd[Step 4: Send an app command as an unauthorized client]
  Scan --> Deauth[Step 5: Deauth-to-drop test on your own phone]
  Stream --> Report[Step 6: Write it up - map results back to STRIDE]
  Cmd --> Report
  Deauth --> Report

3.2 The attacks, mapped to the model

3.3 From toy to real targets

Everything you practiced transfers upward. A professional does the exact same three acts on a $20,000 industrial drone, a smart lock, or a car:

flowchart LR
  Toy[Toy: open Wi-Fi cam] --> Pattern[Same method]
  Pattern --> IoT[Any IoT camera]
  Pattern --> Enterprise[Enterprise drone links]
  Pattern --> Car[Connected vehicle]
  classDef good fill:#1f4d2e,color:#fff;
  class Pattern good;

The parts get fancier and (hopefully) encrypted, but the questions never change: What is it made of? Where are the trust boundaries? What does STRIDE say? Can I prove it?

Recap: the whole class in one table

Where to go next

• Drone landscape — put this class of drone in context with bigger systems.
• Radio and frequency guide — the receive-first RF safety rules referenced throughout.
• Safe learning path — a simulation- and bench-first progression before real flight.
• Sources and validation — how to keep claims honest.

Sources

• Representative teardown of a drone in this class (E88, one of many equivalent brands): https://circuitdigest.com/review/everything-you-need-to-know-about-the-e88-drone-teardown
• Threat Modeling Manifesto: https://www.threatmodelingmanifesto.org/
• STRIDE (Microsoft threat model): widely documented; use for the six-threat checklist.