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.