Ducky Script Volume 12 — The Encode & Deploy Workflow — Ducky Script · Hacking

Getting a payload from a text file onto each device — Payload Studio (the official editor) with usage tips, the encoders, per-device deploy, and testing discipline

Section	Topic
1	About this volume
2	The workflow, in one picture
3	Payload Studio — the official Hak5 editor
4	Payload Studio — usage tips
5	The encoders — legacy and community
6	Deploy: USB Rubber Ducky
7	Deploy: Bash Bunny
8	Deploy: Key Croc
9	Deploy: O.MG family
10	Testing discipline — catch it before the engagement does
11	Resources

1. About this volume

Part I was the language; Vols 8-11 were the four devices. This volume is the connective tissue — how a payload actually gets from a text file in your editor onto a device and into a runnable state. It is the step every payload passes through, and it is the step where the official Hak5 editor, Payload Studio, lives.

The workflow has a shared shape across all four devices — author → (encode) → deploy → test — but the middle two steps differ per device, because the four devices are such different hardware (Vol 1 §5). This volume covers the shared authoring tool first (§§3-5), then the per-device deploy (§§6-9), then the testing discipline that applies to all of them (§10).

2. The workflow, in one picture

   The encode & deploy workflow — shared shape, per-device middle
   ════════════════════════════════════════════════════════════

   AUTHOR ──────► (ENCODE) ──────► DEPLOY ──────► TEST
   ──────         ────────         ──────         ────
   write the      turn the         get it onto    run it on an
   DuckyScript    .txt into the    the device     OWNED test
   (Payload       device's         (per-device,   machine, with
   Studio, or     runnable form    §§6-9)         the right layout
   any editor)    (per-device)                    (§10)
       │              │
       │   Payload Studio does AUTHOR + ENCODE for the
       │   Rubber Ducky in one place. For the other
       │   devices, you AUTHOR (anywhere, incl. Payload
       │   Studio) and DEPLOY without a separate encode
       │   step — they interpret the payload at run time.
       ▼
   payload.txt — the layout-neutral source (keep this in
                 scripts/ — it is the artifact you maintain)

The conceptual split that matters:

The USB Rubber Ducky has a real encode step — payload.txt becomes inject.bin, a compiled binary blob. Payload Studio does this.
The Bash Bunny, Key Croc, and O.MG do not pre-encode — they store the payload as text/script and interpret it at run time. For these, “deploy” is “copy the file / paste into the web UI,” and the layout is set as a payload property rather than baked into a binary.

So Payload Studio is most central to the Rubber Ducky workflow (it is the Ducky’s author+encode tool) but it is a useful authoring environment for all four.

3. Payload Studio — the official Hak5 editor

Payload Studio is Hak5’s official, browser-based editor and encoder for Ducky Script. It is the modern replacement for the old standalone duckencoder workflow, and it is the tool Hak5 points new and experienced users at. It runs in a web browser — there is nothing to install — and it is integral to the Mark II USB Rubber Ducky’s design (Vol 8 §4).

What Payload Studio is, functionally:

It is…	Meaning
An editor	a real code editor for Ducky Script — syntax awareness, structure, not just a text box
An encoder	it turns your `payload.txt` into the `inject.bin` the USB Rubber Ducky runs — the encode step (§2), done in the browser
Layout-aware	the encode respects a selected keyboard layout (Vol 7) — this is the place the Rubber Ducky’s layout decision is made
Cross-device-aware	it understands the Hak5 device family, not only the Rubber Ducky — a useful authoring home for Bash Bunny / Key Croc / O.MG payloads too
Always current	because it is web-based and Hak5-maintained, it tracks the current Ducky Script language — no stale local toolchain

   Where Payload Studio sits in the workflow
   ════════════════════════════════════════════════════════

   browser ──► PAYLOAD STUDIO ──► edit DuckyScript
                    │              pick keyboard layout
                    │              encode
                    ▼
              inject.bin ──► copy to the USB Rubber Ducky's
                             microSD card ──► done

   For the Rubber Ducky, Payload Studio collapses AUTHOR +
   ENCODE into one browser tab. That is its core job.

The reason Payload Studio matters beyond convenience: it is the canonical, current, Hak5-maintained path. The old duckencoder (a Java tool) and the many community encoders still work, but they drift — a community encoder may not know the newest 3.0 syntax, and a stale local toolchain is a classic source of “my valid payload won’t encode.” Payload Studio, being web-based and maintained by Hak5, does not have that drift problem. For an owner standardising a workflow, Payload Studio is the default; reach for an alternative encoder only for a specific reason (§5).

4. Payload Studio — usage tips

Practical tips for working in Payload Studio day to day:

Setup & habit

Bookmark it and use it as the default. It is the current, canonical tool — make it the first thing you open, not the fallback.
Keep payload.txt in version control anyway. Payload Studio is the editor; your scripts/ directory (the project’s scripts/README.md) is the source of truth. Author or paste in Studio, but keep the layout-neutral payload.txt in scripts/{payload-name}/ so it is diff-able and recoverable. Studio is a tool, not an archive.

The layout setting — the one that bites

Set the keyboard layout deliberately, every time, before you encode. This is the Vol 7 problem made concrete: the layout you pick in Payload Studio is baked into inject.bin. The default is not necessarily your target’s layout. A payload encoded for the wrong layout “works” and types garbage (Vol 7 §3) — and Payload Studio will not warn you, because nothing is wrong, it just encoded for a layout you didn’t mean.
Record the layout in the payload’s REM header (Vol 3 §3) so the source file itself states what it was encoded for.

Writing & structure

Use the editor’s structure awareness. Studio understands Ducky Script — let it help you see that an IF has its END_IF, a WHILE its END_WHILE, a FUNCTION its END_FUNCTION. Unclosed blocks are a common 3.0 error and the editor is your first line of defence.
REM-header every payload — what it does, target OS, target layout, authorization context (Vol 16). Do this in Studio so it travels with the payload.
DEFINE your tuning constants at the top (Vol 4 §7) — delays, URLs, magic numbers — so re-tuning for a slow target is a one-line edit in Studio, not a hunt.

Encode & verify

Encode, then sanity-check the result before you trust it. A successful encode means syntactically valid, not correct — it does not mean the payload does what you intended, on the layout you meant, with timing that works. The encode step catches syntax; §10’s testing catches everything else.
Re-encode after every edit. inject.bin is a build artifact — it does not update itself when you change payload.txt. Editing the source and forgetting to re-encode/redeploy is a classic “I fixed it but it’s still broken” trap.

Device family

Use Studio to author for the other three devices too, even though they do not need its encode step. A consistent editor across the family is worth more than a marginally device-specific tool — write the DuckyScript in Studio, then deploy it the device’s way (§§7-9).

5. The encoders — legacy and community

Payload Studio is the default; the alternatives, and when they still matter:

Encoder	What it is	When to use it
Payload Studio	Hak5’s official, current, web-based author + encoder	the default — almost always
`duckencoder` (Java)	the original command-line encoder	scripted/automated encoding pipelines; offline-only environments; legacy 1.0 work — but verify it knows the syntax you are using
Community encoders	various web/CLI/library encoders the community built over the 1.0 era	a specific niche need (a particular integration, a scripting language binding) — accept that they may lag the current language

The one durable rule across all of them: a stale encoder is a real failure mode. Ducky Script 3.0 added a large surface; an encoder that predates a feature cannot encode it correctly. If a payload that looks valid will not encode, or encodes to something that misbehaves, suspect the encoder’s currency before you suspect your payload — and re-try in Payload Studio, which by construction is current.

For the Bash Bunny, Key Croc, and O.MG there is no separate “encoder” in the Rubber Ducky sense — those devices interpret the payload at run time (§2). What those devices have instead is a deploy step (§§7-9), and the “encoding” concern there collapses into “is the payload syntactically valid for this device’s dialect,” which a good editor (Payload Studio) helps with at author time.

6. Deploy: USB Rubber Ducky

   1. AUTHOR    payload.txt in Payload Studio (or your editor)
   2. LAYOUT    select the target's keyboard layout in Studio
   3. ENCODE    Studio produces inject.bin
   4. DEPLOY    copy inject.bin to the root of the device's
                microSD card. (optionally: seed.bin for
                reproducible randomization — Vol 5/6.)
   5. INSERT    the card into the Rubber Ducky
   6. (later)   read loot.bin off the card for exfil results

The microSD card is the deploy mechanism (Vol 8 §6). There is no app, no pairing, no network. Swap payloads by swapping inject.bin on the card. The whole interface is a file on a card — which is the Rubber Ducky’s defining simplicity.

7. Deploy: Bash Bunny

   1. AUTHOR    the bunny-script payload.txt (DuckyScript +
                bash + ATTACKMODE — Vol 9)
   2. ARMING    set the 3-position switch to ARMING MODE; plug
                the Bunny into your own machine — it mounts as
                a normal drive
   3. DEPLOY    copy payload.txt into a payload slot folder;
                copy any tools/files the payload uses; set the
                payload's language/layout
   4. SLOT      set the switch to the slot you want to run
   5. INSERT    plug into the target — it boots (~7s) and runs
                the selected slot's payload

No encode step — the Bunny interprets payload.txt at run time. “Deploy” is “copy files in arming mode.” The switch position chosen at step 4 is the run-time payload selector (Vol 9 §7).

8. Deploy: Key Croc

   1. AUTHOR    the payload — a MATCH line + the action
                (DuckyScript + Linux — Vol 10)
   2. ARMING    put the Croc in arming / udisk mode; it mounts
                as a flash drive on your machine
   3. DEPLOY    copy the payload(s) into place; set the MATCH
                pattern(s); configure Wi-Fi / Cloud C2 / layout
   4. ARM       return the Croc to its armed state
   5. INSTALL   place it inline on the target's keyboard
                connection — then it logs, matches, and waits
   6. (remote)  monitor / re-task / retrieve over Wi-Fi

No encode step. “Deploy” is “edit files in arming mode” — including the all-important MATCH patterns (Vol 10 §5). The Croc’s deploy is the most configuration-heavy of the four because you are setting up an autonomous, conditional, install-and-leave device.

9. Deploy: O.MG family

   1. CONNECT   join the O.MG device's Wi-Fi
   2. WEB UI    open the O.MG web UI in a browser
   3. AUTHOR    write/paste the DuckyScript payload into a SLOT
                (you can author here, or paste from Payload
                 Studio / scripts/)
   4. CONFIGURE set the keyboard layout (Vol 7!), trigger
                conditions, geo-fence (Vol 11 §7)
   5. (no encode, no card, no switch — the web UI IS the deploy)
   6. TRIGGER   remotely, when you choose — or let a condition fire it

The O.MG has no card and no encode step — the web UI is the entire deploy mechanism (Vol 11 §5), and it is live and remote: you can deploy and re-deploy after the device is physically placed. The layout setting lives in the web UI’s payload configuration — the same Vol 7 trap, in a different place.

   Deploy mechanism, all four devices
   ════════════════════════════════════════════════════════

   USB Rubber Ducky  ──► inject.bin on a microSD card
   Bash Bunny        ──► files in a slot folder (arming mode)
   Key Croc          ──► files + MATCH config (arming/udisk mode)
   O.MG family       ──► slots in a web UI, over Wi-Fi (remote)

   Same language. Four genuinely different ways to get it
   onto the device. "Deploy" is not one skill — it is four.

10. Testing discipline — catch it before the engagement does

A payload that fails during an engagement is the worst possible time to discover it failed. The discipline that prevents it:

1. Always test on an owned machine first. Never let the target be the first machine a payload runs on. This is non-negotiable and it is also a posture rule (Vol 16) — testing on a non-owned machine is itself an unauthorized act.

2. Test on the target’s layout. Set your test machine to the keyboard layout you encoded/configured for (Vol 7). A payload tested on US-QWERTY and deployed against an AZERTY target is an untested payload.

3. Test on the target’s OS — ideally the version. GUI r vs GUI SPACE, the path conventions, the available shells — all OS-specific. If the payload branches on $_OS, test both branches.

4. Test on representative timing. A payload tuned on your fast laptop can fail on a slower target (Vol 5 §9). If you can, test on hardware comparable to the target, or build in margin (generous delays, jitter, host-confirmed waits).

5. Watch what it actually does. Run it and watch the screen. Did the right window get focus? Did the characters come out right? Did it finish, or hang? A payload that “ran without error” is not a payload that “did the right thing.”

6. Re-test after every change — and re-encode/redeploy. The inject.bin-is-a-build-artifact trap (§4): edit the source, forget to re-encode, test the old binary, conclude wrongly. After any edit: re-encode (Rubber Ducky) / redeploy (the others), then test.

7. Read community payloads before running them. A payload from a repo or forum is code you are about to run, fast, on a machine. Read every line. Know what it does. The cross-generation staleness problem (Vol 2 §7) means it may also target an OS version that has moved on.

   The testing gate
   ════════════════════════════════════════════════════════

   A payload is NOT ready for an engagement until it has:
     □ run on an OWNED machine
     □ run on the TARGET'S keyboard layout
     □ run on the TARGET'S OS (both branches, if it branches)
     □ been WATCHED doing the right thing, not just "running"
     □ been re-tested after the LAST edit (with a fresh encode)
     □ (if community-sourced) been READ, line by line

   Skip the gate and the engagement becomes the test. That
   is how a payload "worked in the lab" and failed on site.

11. Resources

Payload Studio — Hak5’s official editor (linked from the Hak5 docs and shop)
Ducky Script docs — encoding & “Hello, World!”: https://docs.hak5.org/hak5-usb-rubber-ducky/ducky-script-basics/hello-world/
Bash Bunny deploy / payload development: https://docs.hak5.org/bash-bunny/
Key Croc payload development: https://docs.hak5.org/key-croc/writing-payloads/payload-development/
O.MG — DuckyScript deployment web UI: https://docs.hak5.org/
Vol 7 — keyboard layouts: the setting this volume keeps warning you about
Vols 8-11 — the four devices whose deploy steps this volume details
the project scripts/README.md — where payload.txt source files live under version control

This is Volume 12 of an 18-volume series — and the end of Part II (the devices). Next, Part III (payloads, operations, synthesis) opens with Vol 13: payload patterns and the Hak5 Payload Hub — a catalogue of the structures real payloads are built from, with worked, per-device examples.

Ducky Script Volume 12 — The Encode & Deploy Workflow

Contents