pyro2927

I was always under the impression you can install updates with persistence enabled. I am about to try anyways, I'll report back.

No, you don't. An 8 gig stick will work just fine: http://www.backtrack-linux.org/wiki/index.php/Persistent_USB

If we want to debug any code we write, we're going to have to solder on a JTAG and use the Atmel AVR JTAG In-Circuit debugger, aren't we?

It looks like renosite has been taken down, but there is some code here: https://usbcdemulation.svn.sourceforge.net/svnroot/usbcdemulation/teensy++/trunk/LUFA/Demos/Device/ClassDriver/MassStorage/ Maybe we can modify that to work. I'm going to have to solder on a JTAG header if I want to debug this though, aren't I?

Yes.

You could just try this: http://forums.hak5.org/index.php?showtopic=21111&st=0&p=185434entry185434

If you hold down the button while you plug the device in you can write to the chip with an AVR program.

I got the binary2ducky module working with SET. Here is the script: http://pastie.org/private/s6hb0sbq7plpoinl1xotna You can just drop it into set/modules/ and it will show up when you select Third Party Modules from the main SET menu.

I got some code running on my Ducky, but I'm getting an error when it tries to run the powershell command: http://cl.ly/3p3X0G3a1p1v2p352K3O

I believe that having multiple COM ports allows the Ducky to emulate 3 devices simultaneously. I could be wrong, but I think with a firmware update it will allow exactly what you are talking about, but having both virtual devices running at the same time

SET payload is almost done. It's all in python, and this will be my 2nd python script ever, so it's taking some time as I learn the syntax and stuff. Whitespace dependent is not something that is easy to work with, but I'm getting used to it. The script actually runs and works, creates an inject.bin, though it's dependent on duckencoder/jpduckencoder to actually create the bin file. I'm hoping to port the conversion code to python and have it all self contained, and clean up the script. If it gets fully done I'll post it this weekend!

Same here. Open source ISOstick? Awesome. Especially the fact that it would cost less than half of what an ISOstick is selling for, and you can swap in whatever microSD you want!

DEFAULT_DELAY doesn't work correctly in v1.2. The defaultDelay variable gets decremented until it hits 0, but is never reset back to it's original value for the next iteration of commands. I worked around this by creating a temp variable each time the default delay was added to the commands. Also, the if statement preceding the default delay loop seemed awfully complex, so I simplified it slightly: if (!delayOverride && defaultDelay > 0){ //copy the defaultDelay into a new integer so we can use it more than once int temp = new Integer(defaultDelay); while (temp > 0) { file.add(Byte.valueOf((byte)0)); if (temp > 255) { file.add(Byte.valueOf((byte)-1)); temp -= 255; } else { file.add(Byte.valueOf((byte)temp)); temp = 0; } } }

Some of you may have noticed that DEFAULT_DELAY doesn't work in duckencoder, and it doesn't even work correctly in jpduckencoder v0.1. Well, I fixed that so it works in jpduckencoderv0.2, which also has the CRLF fix flag. http://cl.ly/0y0q2X1E1v201K1j3p1c

Ha, were you listening to Darren and I at DerbyCon?? That's EXACTLY what we were discussing when I bought mine, and one of the main reasons I DID buy mine. We'll need access to the firmware source which I know the Hak5 guys are working on getting to us as fast as possible, but I plan on immediately working on an ISOstick style firmware for it.

It's not a dumb question. First off, emulating other devices would require a major rehauling of the script. Currently the firmware just checks for inject.bin on the SD card, then emulates the keystrokes it finds in that file. If you only update the firmware the duckencoder is still just going to load keystrokes into inject.bin, and nothing new will happen. The fun comes when you get the ducky emulating multiple devices at once. The computer recognizes it as both a mass storage device and keyboard. They keyboard can "inject" an xcopy script to dump important information to it's own SD card. You can have it emulate a physical DVD drive and load malicious ISOs on boot. It would give the RubbyDucky MUCH more potential and capable of different attack vectors, not just executing keyboard scripts. In short, the keyboard aspect would probably remain the same, you would just be able to attack via other ways as well.

A batch file won't work for detecting differences in Windows vs OS X vs Linux

I certainly will! It will actually be similar to his Teensy attack from SET. It'll create an inject.bin file that will type out binary in notepad, use some powershell, and run it. I'm running into a SET issue right now with it being finicky about importing 3rd party modules, but I'll definitely keep this thread posted with info

Interesting you bring that up! I just started working on getting something like that working about 3 hours ago with the help of SET. I'll report back when I make progress.

It doesn't seem so. It also seems the server that was hosting the USBRubberDucky wiki has crashed. :(

Bummer, that sucks. Hope you get better! You could say that your immune system got... HACKED! *cue sad trombone*

I generally hate to do this..... but "bump". I know many users are looking forward to the firmware source being released to make use of the additional com-ports. What better way to get a project traction that crowd sourcing the developmental work?

Hey everyone, As sort of a proof of concept I made an Android app that will allow you to create inject.bin files on the MicroSD card inside your Android device, whether it be a tablet or phone. I started this project before jpduckencoder, and haven't had time to merge the changes back into this project, so it may suffer from the DELAY issues, but I've tested it on some basic STRING commands and it works great! Here is the download: http://cl.ly/2V2Q1S2E3U1d2Y3t3v2f No all you need is your phone to create payloads and then pop the card into your RubberDucky and you're good to go! Note: It doesn't work on 100% of devices. For example, the Motorola Xoom lists /sdcard as being the SD Card location, but it's actually internal memory that that section of code is pointing to. Email thoughts/comments/bugs to joe+ade [at] pintozzi [dot] com

It looks like the CRLF issue still remains in 1.1, at least as far as I can tell.

I updated duckencoder to jpduckencoder so it has a fix to automatically strip out the CR if a flag is set. Seems to be affecting Windows users mostly as it's the line encoding default. http://forums.hak5.org/index.php?showtopic=21056