Ducky Script · Volume 17
Ducky Script Volume 17 — Device Comparison & Which-to-Use-When
The four owned device families side by side, and a setup-per-job guide for the recon job, the smash-and-grab, the persistent implant, and the keylog-and-trigger
Contents
1. About this volume
tjscientist owns all four device families. This volume answers the question that follows from that: given a job, which device — and how is it set up? It is the synthesis of Vols 8-16 into a decision tool.
The framing established in Vol 1 §7 holds: the four devices are not a good/better/best ladder. They are optimised for different engagement shapes, and “which one” is almost always answered by what shape is this job — not by which is more powerful. §§5-9 are five common job shapes, each with the device choice and the concrete setup.
2. The four devices, side by side
The four owned devices, at a glance
════════════════════════════════════════════════════════
RUBBER DUCKY BASH BUNNY KEY CROC O.MG
What it is microcontroller Linux box Linux box ESP implant
Form factor "flash drive" chunky stick inline adptr cable/plug/adapter
Fires on plug-in plug-in(+7s) a MATCH remote/geo trigger
Vectors HID (+storage) HID/stor/ HID/stor/ HID
serial/ETH serial/ETH
Network none via ETH Wi-Fi Wi-Fi
emulation
Covertness looks-like conspicuous visible IS the object
(visual only) if looked (genuinely covert)
Boots? no (instant) yes (~7s) yes no (ESP)
Remote ops no no yes (Wi-Fi) yes (Wi-Fi/web UI)
Exfil Keystroke SSD / network keylog + over its Wi-Fi
Reflection capture Wi-Fi
Best at fast, clean multi-vector, observe- covert, remote,
injection Linux tooling then-act install-and-leave
Volume 8 9 10 11The one-line each:
- USB Rubber Ducky — the fast, simple, deterministic one. Plug in, it types, you leave. The reference.
- Bash Bunny — the powerful one. A Linux box that injects keystrokes and can be a network adapter, storage, a serial port — multi-vector, scriptable, tooled.
- Key Croc — the patient one. Installs inline, logs everything, fires payloads when the target types a trigger. Observe-then-act.
- O.MG — the invisible one. Is, genuinely, a cable/plug/adapter. Triggered remotely over Wi-Fi. Install-and-leave, covert.
3. The four axes that decide it
Almost every “which device” question resolves on four axes. Score the job on each, and the device falls out:
Axis 1 — TIMING: when does the payload need to fire?
────────────────────────────────────────────────────
on plug-in, immediately ........... Rubber Ducky / Bash Bunny
when the TARGET does something .... Key Croc (the MATCH)
when I decide, remotely ........... O.MG
when a CONDITION/location is met .. O.MG (geo-fence)
Axis 2 — ACCESS: what physical access do I have?
────────────────────────────────────────────────────
brief, hands-on, then I leave ..... Rubber Ducky / Bash Bunny
I can install inline and return ... Key Croc
I can place/swap a covert object .. O.MG
I get NO second physical access ... O.MG / Key Croc (remote ops)
Axis 3 — CAPABILITY: is "typing" enough?
────────────────────────────────────────────────────
yes, just type a thing ............ Rubber Ducky
no — need network/storage/serial .. Bash Bunny / Key Croc
no — need to capture what's typed . Key Croc
yes, but it must be COVERT ........ O.MG
Axis 4 — DETECTION: what's the stealth requirement?
────────────────────────────────────────────────────
brief loud moment is acceptable ... Rubber Ducky
doesn't matter much ............... Bash Bunny
must be physically inconspicuous .. Key Croc / O.MG
must be INDISTINGUISHABLE from a
normal object ................... O.MGThe axes interact — a job is rarely decided on one — but Axis 1 (timing) is usually the dominant one. “When does it fire” splits the family cleanly: plug-in (Ducky/Bunny), target-behaviour (Croc), operator/condition (O.MG). Get the timing axis right and the field is usually down to one or two.
4. The decision tree
START: I have a keystroke-injection job.
│
├─ When must it fire?
│ ├─ on plug-in ──────────────────────────────┐
│ ├─ when the TARGET types something ──► KEY CROC
│ └─ when I decide / a condition ─────► O.MG
│ │
│ (plug-in branch continues:) ◄───────────────┘
│ └─ Is "just typing" enough?
│ ├─ yes ───────────────────────► USB RUBBER DUCKY
│ └─ no — need network / storage /
│ serial / Linux tooling ─► BASH BUNNY
│
├─ Must the device be COVERT — indistinguishable
│ from an ordinary object, still function as one?
│ └─ yes ──────────────────────► O.MG (overrides above)
│
├─ Must I capture what the target TYPES?
│ └─ yes ──────────────────────► KEY CROC (overrides above)
│
└─ Still unsure / it's a combination?
└─ it's probably a COMBINED workflow — Vol 14.
Decompose the job, assign each piece to the
device that does it best.Two override rules sit on top of the timing-first tree: covertness forces the O.MG (nothing else is genuinely covert), and needing the keylog forces the Key Croc (nothing else logs). If neither override applies, the timing axis plus the capability question gets you there.
5. Setup-per-job: the smash-and-grab
The job: brief, un-observed physical access to a target machine. Run a payload, get out. Recon, a foothold, an exfil of a specific value — fast.
The device: USB Rubber Ducky. This is its home turf (Vol 8 §8). Fastest plug-to-inject, deterministic, nothing to boot, simplest possible workflow. The Bash Bunny is the alternative only if the job needs a vector typing cannot provide.
The setup:
□ Author the payload in Payload Studio (Vol 12 §3-4)
□ Set the keyboard layout to the TARGET's (Vol 7, Vol 12 §4)
□ Pattern: launcher (Vol 13 §3) or staged loader (Vol 13 §4)
— staged loader if the real payload is long/symbol-heavy
□ Timing: operator-gated if you can (WAIT_FOR_BUTTON_PRESS,
Vol 13 §7) — climb the reliability hierarchy (Vol 5 §9)
□ Keep it SHORT — every line is a desync chance (Vol 3 §9)
□ LED for operator feedback: red=running, green=done (Vol 8 §5)
□ CLOSE section leaves the host clean (Vol 13 §2)
□ Encode → microSD → TEST on owned hardware (Vol 12 §10)
□ Authorization artifact in hand (Vol 16 §4)Why not the others: the Bunny’s 7-second boot is dead time you do not have; the Croc and O.MG are install-and-leave devices and this is a get-in-get-out job.
6. Setup-per-job: the recon job
The job: gather information from a target machine (or several) — OS, config, network, installed software, users — to inform a later stage. Possibly multi-machine.
The device: USB Rubber Ducky for a single quick pass; Bash Bunny if recon needs the network vector or on-device processing. If the recon is “type some enumeration commands and capture the output,” the Ducky does it. If it is “be a network adapter and watch what the host does,” or “run a real recon tool from the device,” it is the Bunny (Vol 9 §8).
The setup (Bash Bunny variant):
□ Author the bunny-script payload (Vol 9 §4, Vol 12 §7)
□ ATTACKMODE: HID for the typed enumeration; add STORAGE to
capture output to the Bunny's SSD, or ETHERNET if recon
is network-side (Vol 9 §5)
□ OS-adaptive pattern (Vol 13 §5) if targets vary — bash
`case` on the detected OS, QUACK the matching enumeration
□ Capture to the Bunny's SSD — recon output is bulk data,
not a secret; the Bunny has room (Vol 9 §8)
□ LED states to track phase; arming switch to carry a
second recon payload variant (Vol 9 §7)
□ TEST on owned hardware, target OS + layout (Vol 12 §10)
□ Authorization covers recon specifically (Vol 16 §4-5)Why the Bunny over the Ducky here: recon often produces volume (command output, captured traffic) and the Ducky’s only native exfil is the slow, secrets-sized Keystroke Reflection channel (Vol 6). The Bunny’s SSD and network vector make it the better recon platform when the recon is more than “type three commands.”
7. Setup-per-job: the persistent implant
The job: establish a presence on the target environment that persists — that can be reached, re-tasked, and triggered after the operator has left.
The device: O.MG (covert + remote) or Key Croc (inline + remote) — depending on covertness. If the implant must be invisible, it is the O.MG. If it can be a (small, inconspicuous-but-not-invisible) inline adapter and the value is in also keylogging, it is the Key Croc.
The setup (O.MG variant):
□ Choose the form factor for the placement (Vol 11 §3) —
Cable to go home with the target, Plug for a workspace,
Adapter for an inline run
□ Author payload(s) in the web UI slots (Vol 11 §5, Vol 12 §9)
□ Set keyboard layout in the web UI (Vol 7 — same trap)
□ Configure GEO-FENCING as a SCOPE control (Vol 11 §7,
Vol 16 §6) — bound it to the authorized site so it
CANNOT fire off-scope
□ Confirm passthrough — it must still work as the object
it is (Vol 11 §8)
□ Verify Basic vs Elite tier — it bounds payload size/slots
(Vol 11 §6)
□ A RETRIEVAL PLAN exists (Vol 16 §6) — when/how it comes back
□ Authorization EXPLICITLY permits leaving the device
(Vol 16 §4, §6)Why this is the highest-discipline job: an install-and-leave device is a continuing presence (Vol 16 §6). The geo-fence-as-scope-control, the retrieval plan, and the explicit leave-authorization are not optional polish — they are what makes a persistent implant a professional act rather than an indefensible one.
8. Setup-per-job: the keylog-and-trigger
The job: capture what the target types, and/or fire a payload conditioned on the target’s own behaviour — act at the moment the target creates the right conditions, not at a moment you guessed.
The device: Key Croc. This is the only device that does it (Vol 10). Nothing else logs; nothing else has the match-and-trigger engine.
The setup:
□ Author: MATCH pattern(s) + action(s) (Vol 10 §5-6, Vol 13 §8)
— keyword or regex; remember it is typo-tolerant
□ The action's injection part is DuckyScript via QUACK
(Vol 10 §6) — Vols 3-7 apply
□ Configure Wi-Fi for remote monitoring + re-tasking
(Vol 10 §7) — on an authorized network
□ Decide on Cloud C2 enrollment (Vol 14 §6) — weigh the
attack-surface cost
□ KEYLOGGING IS AUTHORIZED EXPLICITLY, with interception/
consent addressed (Vol 16 §7) — this is the hard gate
□ Install inline; confirm pass-through is transparent
(Vol 10 §4) and the keylog is writing
□ Retrieval plan (it is install-and-leave — Vol 16 §6)The hard gate: Vol 16 §7. Keylogging engages wiretap/interception law on top of computer-access law, and it can require consent the system owner alone cannot give. The Key Croc does not get deployed until that is explicitly resolved in the authorization artifact. Of all five jobs, this is the one with the most legal weight per Vol 16.
9. Setup-per-job: the covert remote-trigger
The job: a payload must run on a target machine, covertly, at a time the operator chooses remotely — with no on-screen-activity-on-plug-in giveaway, and no device a casual look would spot.
The device: O.MG. Covert form factor, remote/web-UI trigger, dormant-until-fired (Vol 11). The Key Croc is remote-capable too but is visible as an inline adapter and fires on a match, not on operator command — different job.
The setup:
□ Form factor chosen for the placement (Vol 11 §3)
□ Payload authored in the web UI slot (Vol 11 §5, Vol 12 §9)
□ Keyboard layout set in the web UI (Vol 7)
□ Trigger: remote/operator-initiated (NOT geo/condition —
this job is "I decide the moment")
□ Tier check (Vol 11 §6) — Elite if the payload is non-trivial
□ Passthrough confirmed — cover holds (Vol 11 §8)
□ Wi-Fi reachability planned — how does the operator reach
the web UI at trigger time?
□ The Wi-Fi is a detectable signal — accept it (Vol 15 §7)
□ Authorization covers covert placement + remote trigger
(Vol 16 §4, §6)Why the O.MG specifically: the value here is the combination — covert AND remote AND dormant-until-fired. The Ducky is not covert or remote; the Bunny is neither covert nor remote; the Croc is remote but visible and target-triggered. Only the O.MG is all three.
10. Which to learn first, and how to grow the skill
For tjscientist, owning all four, the learning order:
The learning path
════════════════════════════════════════════════════════
1. USB RUBBER DUCKY ── learn the LANGUAGE here.
It is the canonical 3.0 implementation; everything
transfers. Get fluent in Vols 3-7 on this device.
The Ducky's simplicity means nothing gets in the way
of learning the language.
2. BASH BUNNY ── learn MULTI-VECTOR here.
Once the language is fluent, the Bunny teaches you
ATTACKMODE properly, the network vector, and "Ducky
Script inside a bigger payload" (QUACK).
3. KEY CROC ── learn OBSERVE-THEN-ACT here.
The MATCH engine is a different way of thinking about
WHEN a payload runs. And the keylogging forces you to
internalize Vol 16 §7 — which makes you a better,
more careful operator on every device.
4. O.MG ── learn COVERT + REMOTE here.
The web-UI workflow, geo-fencing as scope control,
the install-and-leave discipline. The most "tradecraft"
of the four.
Then: COMBINED workflows (Vol 14). Once each device is
individually fluent, the real skill is decomposing an
engagement across them — and across the WiFi Pineapple.The skill is not “knowing four devices.” It is knowing the language cold (Part I), knowing each device’s shape (Part II), and being able to look at a job and see which shape it is (this volume) — then, beyond that, decomposing the jobs that need more than one (Vol 14). The four devices are a toolkit; this volume is how you pick the tool; Vol 14 is how you use several at once.
11. Resources
- Vols 8-11 — the four device families, each in depth (the “what” behind this volume’s “which”)
- Vol 12 — the deploy workflow each setup-per-job references
- Vol 13 — the payload patterns the setups are built from
- Vol 14 — combined workflows, when one device is not enough
- Vol 16 — the posture every setup-per-job is gated by
../_shared/comparison.md— the hub-wide cross-tool matrix (this volume is the Ducky-family-internal version of it)- Vol 18 — the cheatsheet: this volume’s decision logic, compressed
This is Volume 17 of an 18-volume series. Next: Vol 18, the cheatsheet — the whole manual compressed to laminate-ready reference: the language, the four devices, the deploy steps, the patterns, the decision tree, and the posture checklist, all on a few pages.