Mr. Self Destruct

A USB keystroke injector with software-triggered 5v payloads

This is a project breakdown with basic circuit info. Construction info for anything dangerous has been intentionally withheld. The demo videos are not reproducible without additional work and knowledge/components. If you like this, I post more at https://twitter.com/MG

UPDATE: In part 1 of my segments with Hak5, I gave a rundown of this device: https://www.youtube.com/watch?v=fV6ajbDOLbQ

https://vimeo.com/239761255 https://vimeo.com/239761429

When presented as an exploding or smoke-emitting USB drive, there isn’t much in the way of practical use besides a tv/movie prop for a dramatic hacker scene. They sure do make for a good PoC video though! However, there are a lot of opportunities to adjust the physical payload. Example: If you used a battery powered “sound grenade” as the physical payload, you could retain the Pavlovian Awareness Training angle here that many Red Teams are immediately seeing. When plugged in, the keystroke injection does whatever you wish, then a loud siren would trigger that cannot be turned off until the battery dies. This is possible because the software controls a switch capable of handling as much power as your USB port can provide. So there are many small circuits that could be used here. If you can utilize a bigger package size, such as a 2.5" removable, then the options are even greater. This would work well for large battery powered devices. Example: a wifi attack device (cracking, jamming, etc) that only starts using its battery once it has been brought comfortably inside the physical target area.


This started as a small project initiated by a ridiculous picture I saw on twitter of what appeared to be a firecracker inside a USB thumb drive. Everyone who saw it had the same reaction: hilarious but evil. I wondered if there was a way to combine this with something like a USB Rubber Ducky, allowing for both a data payload and a physical payload. For me, this resulted in a lot of failed experimentation while chasing minor improvements and alterations. The majority of these tweaks required skills I didn’t have. But stumbling through every step of the way is where the fun was for me. I hadn’t done surface mount prototyping, IC programming, worked with android or AVR chips, etc. There isn’t much that is new here, I simply connected together a lot of work that other people had done. And I did so in a barely functional way. I found a lot of help and inspiration from people like @evanbooth, @notdan, @Viss, @gsuberland, & @deviantollam.

I was originally going to use a $50 Hak5 Rubber Ducky for this. The only output interface on the Ducky was the 3.3v LED. I found a very small MOSFET that could handle 3+ amps using a minimum trigger voltage of ~1v. This was perfect. I could tap into the LED’s power and switch anything else on that the USB port could handle. I just needed to find a way to control the LED as the ducky script didn’t allow it. Unfortunately, I was only able to get very basic control of the LED using custom firmware. I then discovered the “$5/$3/$1 USB Rubber Ducky” projects that others had done using the ATtiny85 chip. This was a much better path. As a bonus, there are also two unused GPIO ports in most of the circuits!

In searching for the least expensive source that didn’t take months to arrive from China, I realized that the $5 DigiSpark was a nearly prebuilt board and I could get them on Amazon. There are also several DigiSpark clones on Amazon for ~$3 and down to $1.50 on eBay. Not only did the $3 DigiSpark clone have the ATtiny85 I wanted, but it had most of the other components I needed.

So let’s look at the parts list:

Essential parts:

  • 1x COMMON SENSE —Don’t expose yourself or others to anything dangerous.
  • 1x ATtiny85 (from DigiSpark clone)
  • 2x 68ohm resistor (from DigiSpark clone)
  • 1x 1.5kohm resistor (from DigiSpark clone)
  • 2x 3.6v zenner diode (from DigiSpark clone)
  • 1x IRLML2502 MOSFET (There are many alternatives here. I found the ZXMN2F34FHTA to work just fine as well)
  • 1x ~680 ohm(?) resistor (see build notes for important safety info!)
    Discretionary misc parts & tools:
  • an old clamshell USB thumb drive. we need the shell and the USB connector.
  • SMTPads 50x50 prototyping board. (this is just what I made work, others will have better ways of putting this all into a circuit)
  • copper tape. (I used this to bridge connections on the SMTPads board)
  • solder, solder paste, & rosin
  • soldering iron & solder rework station
    Payload parts:
  • This depends entirely on what you are adding. Your payload will receiver 5v for whatever duration of time you configure (as long as the drive stays plugged in anyway, so add a battery as needed).
  • For something like a “sound grenade”, you would just tie directly to the 5v payload connectors.
  • For something dramatic like the colored smoke cakes, I am intentionally leaving that info out just so someone doesn’t do something stupid. In fact, there are several intentional hurdles here to prevent someone from doing something dumb.

Putting it all together

If you want to use a large device, such as a 2.5" external, then you can just use the DigiSpark and add the MOSFET for physical payload control. However, if you want to cram everything into the little USB thumb drive, you’ll need to shrink things down. I did this by cannibalizing the DigiSpark. This ended up being more cost effective (and faster to acquire) than sourcing all the components individually. The following information assumes you are choosing cannibalization.

Nothing new here. This design was already made by all the ATtiny85 Ducky clone projects, this just has a MOSFET added to pin 5. The smallest and cleanest example is probably the uDuck. The circuit is extremely basic and the bare minimum for sane USB functionality. The zener diodes drop the data lines down to 3.6v. The resistors help with obeying some of the USB specs (speed identification, power, etc) for compatibility between machines. I have seen some, or even all, of the resistors & zeners removed, but compatibility and reliability is substantially decreased.

A few things to note:

  • The resistor between the Source and Drain of the MOSFET still needs exploration. If the resistance is too high, or there is no resistor at all, the payload will momentarily trigger on boot. This is because the pins of the ATtiny are powered up on boot. Thanks to Graham Sutherland (@gsuberland on twitter) for the help here.
  • You can have a dual trigger by duplicating the MOSFET setup on pin 6.

PCB layout:

Considering the nonstandard PCB setup, I wasn’t quite sure how to mock this up. The red indicates lines of copper tape. Note where it wraps around the edges. The green are the solder points to for wires going to the USB cable. The blue are the solder points for wires running to the physical payload. Why copper tape? Because I don’t know what I am doing and it seemed to actually work after I failed about a dozen times when trying to connect the pads in other ways.

Here is one of the PCB’s taped up before soldering. The vias (holes) are not used. They were just part of the SMTPads protoboard that I cut into pieces. You will notice that I removed the pad where the ~600 ohm MOSFET resistor sits. This is to prevent accidental bridging.

This is what it looks like all soldered up. You can see the remains of the green PCB of the thumb drive that I cut off.

And here it is installed in the clamshell. You will want to secure the USB end in place. If you look closely, this prototype is missing the pulldown resistor on the MOSFET.

Programming the ATtiny85

When using the ATtiny from a DigiSpark, programming is very easy as there is already a bootloader. You open up your Arduino IDE, create a sketch, tell the sketch to upload, then plug in the board to your USB port.

Someone already created a converter, called digiduck, for existing ducky scripts. As a bonus, you can use “LIGHT ON” and “LIGHT OFF” inside your input script to trigger the payload MOSFET. The LIGHT ON function turns on voltage the pin 5 & 6, which is what we have the MOSFET tied into. If you are running this on an uncannibalized DigiSpark, there is a blue LED that also turns on when pin 5 sends power. This is very helpful for testing.

Below is the sketch used in the original video with the confetti. The OS X Terminal is opened, then the volume is turned up and a fullscreen browser pointed at a vimeo video is launched. (Animation is by RedNoseStudio) It's a pretty basic process by HID attack standards. After a 22 second delay, I use digitalWrite to send voltage to the MOSFET. After 3 seconds, voltage is removed for this specific payload.

#include “DigiKeyboard.h”
#define KEY_TAB 43
#define KEY_DOWN 81
#define KEY_DELETE 42
#define KEY_INSERT 73
#define KEY_PAUSE 72
#define KEY_HOME 74
#define KEY_PAGEUP 75
#define KEY_END 77
#define KEY_PAGEDOWN 78
#define KEY_RIGHT 79
#define KEY_DOWNARROW 81
#define KEY_LEFTARROW 80
#define KEY_UP 82
#define KEY_UPARROW 82
#define KEY_NUMLOCK 83
#define KEY_CAPSLOCK 57
#define KEY_MENU 118
void setup() {
 pinMode(1, OUTPUT);
 pinMode(0, OUTPUT);
 digitalWrite(0, LOW);
 digitalWrite(1, LOW);
 DigiKeyboard.sendKeyStroke(KEY_SPACE, MOD_GUI_LEFT);
 DigiKeyboard.println(“osascript -e ‘set volume 4’ && open https://player.vimeo.com/video/184549201?autoplay=1");
 digitalWrite(0, HIGH); 
 digitalWrite(1, HIGH);
 digitalWrite(0, LOW);
 digitalWrite(1, LOW);
void loop() {

You will notice that digiduck translates LIGHT ON/OFF to digitalWrite for both (0, HIGH) and (1,HIGH). This corresponds to pin 5 (0) and pin 6 (1) on the ATtiny. So yes, that means multiple LEDs, or in this case multiple triggers.

Removing the 5 second startup delay

The one annoying aspect of the DigiSpark is the 5 second boot delay. The delay is what allows you to easily push down new sketches by just plugging it in. If you remove the delay, you will have to short 2 pins of the ATtiny together when you want to program it. To remove the delay, you need a new bootloader. This can be done with an ISP programmer, but a much more interesting method is using a NOPslide to push a bootloader from the memory space that normally takes your sketches. But to program a new bootloader, you have to remove some of the fuse bits that are set in the chip. This, unfortunately, does require a programmer, specifically a high voltage (12v) programmer. I hear some of the DigiSpark clones do not set the fuse bits, but mine had them.

High Voltage Programmer

The high voltage programmer path has many options such as the $60 commercial options. However, a $4 v3 nano (Arduino) and some breadboard work does just fine. Someone made an Arduino sketch that automatically clears the fuses as well, which is very handy. Steps 1–3 from this guide worked for me: http://www.instructables.com/id/How-to-unlock-Digispark-ATtiny85-and-convert-it-to/ Instead of plugging the ATtiny directly to the breadboard, I ran the leads to a SOIC-8 clip so I could program the chip directly. I also replaced the 12v battery with a $5 5v booster (set to 12v). I was using so often that I moved it from a breadboard to a more permanent protoboard.


Programming a new bootloader

Now that the fuse has been removed, you can upload a new bootloader. As I mentioned, you can push a new bootloader using an ISP. With some minor changes, the high voltage programmer above would work. But it’s not as fun as doing it the way you aren’t supposed to.

There is a project called micronucleus that has developed new bootloaders. Hidden inside the project is a tool called “upgrade” that leverages a NOP slide to write a new bootloader over the USB interface. You run “micronucleus BootloaderName.hex” and its done. I used the precompiled micronucleus-1.11-entry-jumper-pb0-upgrade.hex for my needs. Keep in mind that, after changing the bootloader to remove the 5sec delay, you will need to short either pin 1 or pin 5 (depends on the bootloader you use) to ground every time you want to push a new sketch to the ATtiny.

To do/wish list

  • legit PCB for ease of soldering
  • ability to pull user input and expand the possible functionality

B-Sides & Fails

I didn’t document every step of the way, but there were some notable failures.
A DigiSpark with MOSFET:



the initial 5v trigger test:

Trying to shave down the size of a DigiSpark in hopes of it fitting in a clamshell case:

Trying to make the SOT-23 package of the MOSFT have leads that could be used on a breadboard. The legs snapped off the moment I picked it up…

A much better path to breadboarding the tiny MOSFET. This is where I first discovered the potential of copper tape for SMT soldering.