Darren Kitchen

Not currently. Half the Jtag pins can be used for IO using the firmware. An open source version will be released in about a week or so. Stay tuned :)

I think shift is the best key to press periodically to keep a machine awake. Unless someone is actively typing it'll go unnoticed.

Brilliant! I could see adding to the firmware a function that captures capslock and numlock states. That way you could, albeit slowly, send data back to the duck without using conventional means. For example, if capslock represented 1 and numlock 0, with the right payload you could extract hash data from a target machine and send their binary equivelents back to the ducky. /mind blown

A quick to deploy and effective payload creates a txt file with FTP commands, then schedules an "FTP -S" task to run said commands at a specific time (like after hours when the user is away from their desk) using the AT command. The SET binary - hex converter will work on the Ducky as does IllWill's encode.vbs and decode,vbs http://dabermania.blogspot.com/2011/03/converting-any-file-to-ascii-for.html

As MS1605 pointed out we're proud to have these made in the USA but as such it adds significantly to the cost. In all honesty though I suspect the rubber ducks were actually made overseas. Not sure. Got 'em from a US distributor but can't be 100% sure. Anyone know an American rubber ducky manufacturer? Now, as for the cases I encourage everyone to experiment with cases and if MS1605 wants to sell some of his creations here he's more than welcome to. We have a few designs in the works that we'll be making with our new laser cutter. If you were at Derbycon you may have seen the wooden prototype case I was sporting. Still need to find a source for the leather strap. Going for a oldschool Western feel there. I hope soon we'll have several enclosure options available. I think there are compatible generic USB enclosures from digikey and the like similar to the ubertooth. And we just made an order here recently for empty USB drive enclosures so we'll have 'em on the hakshop as soon as they come in. Maybe 2 or 3 weeks.

I noticed this on a friends tablet the other day. It had both /sdcard and a /removable media/sdcard directory. The former being the internal memory.,

Yep, once you have Java installed the process is the same for any OS. "java -jar duckencode.jar -i payload.txt -o inject.bin" Actually I think you can omit the "-o inject.bin" part. It'll create inject.bin in the current working directory without it. I think the only major difference is the path to your SD card. On Linux for me it's in /media/volumename while on Windows it'll be a drive letter.

I haven't seen that behavior, but I'd say a DELAY between MENU and STRING a are in order for sure. That might be the issue in fact.

I threw the wiki up on my dreamhost account which hasn't seen real traffic in quite some time. I think it'll need to move to one of our domain.com servers here soon. As for the firmware, Jason called me last night to let me know he was working on the firmware for release. Will update this thread soon.

Sorry for the delay. I have every intention of uploading it today -- just have to clean up a few things here and there. Ended up coming down with something bad post-Derbycon. In debug mode now downing OJ and Chicken Noodle Soup. That tuned!

Nope, it's new hardware from ALFA. Just finished the prototype during this otherwise boring 5 hour flight from Atlanta to San Francisco. Internet Connection Sharing is a breeze with this new guy, and the radio performance is stellar. I'm getting blackberries in first class while I'm sitting back behind the wing. Thanks gogoinflight -- hope you don't mind I just shared the net with everyone on this plane for free ;)

It shouldn't be too much longer now. And I think everyone is going to love the changes we're making for the MK3. I'm actually flying back form Derbycon right now working on some code for it and so far it's fantastic. Got half the plane connected to me. ^_^

When I run your escape.txt against my duckencode.jar I get the same hex output: 08 01 cat'ing escape.txt reveals two lines: ESCAPE CONTROL ESCAPE When I create my own escape2.txt with the above two lines and compile it with the same duckencode.jar I get this hex output: 29 00 29 01 The "29 00" is line 1 -- ESCAPE while "29 01" is line 2 -- CONTROL ESCAPE. To break it down further, "29" is ESCAPE, "00" is null and "01" is CONTROL. I've tested and come up with the same results while working in nano, vi and gedit. So then I checked the hex results of both your escape.txt and my escape2.txt and here's what I've found Yours: 00000000 45 53 43 41 50 45 0D 0A 43 4F 4E 54 52 4F 4C 20 45 53 43 41 ESCAPE..CONTROL ESCA 00000014 50 45 0D 0A PE.. Mine: 00000000 45 53 43 41 50 45 0A 43 4F 4E 54 52 4F 4C 20 45 53 43 41 50 ESCAPE.CONTROL ESCAP 00000014 45 0A 0A E.. The carriage return "0A" is in common on both, but your editor seems to be adding "0D" before the return. May I ask, what text editor are you using and what format options do you have when saving? Will add this to the list of features to implement in the next version of the duckencoder -- ignoring the "0D" value.

I don't know the exact hex codes as I'm still on my cell coming home from Derbycon but let's use this as a test case for troubleshooting. What I'd like from you are the following: What text editor are you using? Can you attach both the txt and bin? Alternatively, Could you create a text file containing only "ESCAPE" (without quotes), duckencode it and provide the hexedit output of the resulting bin. For example: echo ESC >> esc.txt java -jar duckencode.jar -i esc.txt -o esc.bin hexedit esc.bin Thanks!

Thanks. Had posted it from my phone and couldn't verify.

Yep! Sorry for the delay guys. As soon as I get back from Derbycon and can tidy up the code it'll be on the wiki. Thanks for your patience!

Not sure but I'll loop Jason in here.

http://www.youtube.com/#/watch?v=NeDYD9nb7PM This 30 minute video should have you singing the rubber ducky song in no time. I'll continue to update with new videos as the software and payloads release.

Great ideas. Would love to see what you can come up with. I've been chatting with the guys at Derbycon getting inspiration for some new payloads. Already have a wicked new one done that takes win7 laptop pwnage to the next level. Should help in extracting hashes. Will publish when I get back.

I' at Derbycon on my phone so I'll be brief. 256MB, plenty for inject.bin. Doesn't come installed in the rubber ducky - duck is included as optional casing / novelty trinket. Hardware is our own custom, not repurposed from another product. No sd card adapter. Will try to source usb micro sd adapters when I return next week.

http://www.usbrubberducky.com/wiki/ I've put together a wiki specifically for the USB Rubber Ducky project. So far the scripting language syntax with examples, hardware, duckencoder and a few payloads are up. As the first batch of duckies go out this is your best resource for getting started. I'll be writing up a more fleshed out 'quack start guide' soon.

No, the hex generated by the duckencoder are designed to be executed off the sd card by the usb rubber ducky. The teensy needs to be programmed in C with teensyduino and flashed. That said the teensy can execute the usb keyboard aspect of the rubber ducky attack -- just requires programming.

Not all of the things, but some if you're a talented programmer. This is why we've developed the ducky the way we did. The Teensy is able to act as a USB HID keyboard and perform the keystrokes as with the payloads demonstrated on the show, however this requires programming with C in Teensyduino, compiling with GCC and flashing with the teensyloader. The USB Rubber Ducky is scripted with our simple language in any text editor, compiled with the cross-platform duckencoder and loaded onto the SD card -- just drag and drop the inject.bin So yes, in theory the Teensy 2.0 is capable of performing one aspect of the attack but not without a higher investment of time and skill. Also bear in mind that the teensy and rubber ducky hardware are significantly different -- 8bit/16mhz w/ 1 uart vs 32bit/60mhz w/ 3 uart -- which will become apparent shortly.

I've given it a lot of thought and the best I can figure is that modern operating systems need to fundamentally change the way they deal with USB devices, HIDs in particular. An OS should never trust a keyboard, mouse, hell even a joystick (what if someone ducky'd your flight sim and made you do a barrel roll into a mountain?!?!?!) The way I see it the best an OS can do to combat this vector of attack is to implement a CAPTCHA. Insert an untrusted keyboard? No problem. Let's just sandbox that sucker until we get some validation. Popup a window with 4 characters and a soft keyboard and ask the user to use the mouse to validate. Of course this isn't without it's own set of problems (how do you validate the mouse, and which came first - the chicken or the egg?) Vendor and device ID is easily spoofed so securely pairing a host and input device is hopeless. Even if MAC level identification was implemented we've seen how trivial that has been to overcome in the WiFi world. I don't think there is a perfect solution and truthfully I believe the I/O attack vector will be with us for quite some time...until ultimately the concept of a PC is redefined.