Rubber Ducky upgrade?

[th23289]

Hello hackers, coders and imagineers,

I don't know if the Rubber Ducky is looking for an upgrade anytime soon, but if so I have a few ideas based on a recent project of mine, which uses the Teensy 3.1.

Firstly, the one way nature of the device makes it difficult to acquire information from the host system. I see you have solved this by suggesting that a USB drive is used in parallel with the Rubber Ducky. Whilst this is a solution, it would be nice if the device could imitate a hub and provide the functionality of both the Rubber Ducky and a USB drive. Though, this will increase the hardware requirements and cost, so may not be ideal. In my project I simply used the onboard EEPROM to store data, which removes the need for two USB sticks, but severely limits the amount of non-volatile memory available. So, the addition of some non-volatile memory that can be written to and then read from at a later time would be nice to see on the Rubber Ducky.

Secondly, although there is non-volatile memory available on the Teensy, this doesn't solve the problem of feedback: How do you get the data mined from the host system back on to the device?

This is difficult since the device is pretending to be a keyboard and keyboards generally don't require feedback. In my project I utilised the fact that whilst the Teensy emulated a keyboard it could simultaneously run a serial connection. In this way I could get the Teensy to find the relevant information and then send it to itself via an open serial link. This opens up the use of the available non-volatile memory as mentioned above, but also many other things that weren't possible without feedback. For example, in my project I mess with the "networksetup" command in terminal, which, in most cases requires the user to specify the hardware port in question. As such, the first thing I do is to get a list of all the ports on the host system. This is then fed back in to the Teensy, which searches for the hardware port related to the WiFi. Then this information can be used to send commands to turn the WiFi card off, change the AP to which the host system is associated or just gather more information. This could be a huge advantage if implemented on the Rubber Ducky.

Lastly, with most keystroke injection attacks commands have to be sent and then there's a delay whilst the host system executes the command. However, these delays can vary wildly making them very difficult to predict. In my project I added a debug mode option, which allows the user to step through chunks of code so that the variable delays can be controlled by the user. Additionally, these types of attacks are unreliable, since a program may not start as expected or a pop up gets in the way. For this reason I also added a reset button, so that if the attack fails it can quickly be reset and start again without having to unplug and replug in the device. These can be very useful in practise, however they both require the addition of a button, which could make the Rubber Ducky look less like a legitimate USB drive.

As a side note, another thing I found useful was an LED indicating when the program was complete. It's especially convenient when you are unable to see the screen of the host system.

If anyone is interested this is the link to my project called the WiFi Pixie: http://www.instructables.com/id/WiFi-Pixie/

There's code there as well, which is the most interesting part of this project. The Teensy platform is good if anyone wants to get very hands on with this type of pen testing tool. It uses the Arduino IDE and will require some knowledge of C. But if you're more familiar with scripting languages and you want an easy device to plug-and-play with, then the Rubber Ducky is probably a better option.

I would also be interested to hear of any other ideas people have for this kind of device...

Hack on!