no42

Not annoying! I really want to work on language support this year! The more questions the better, the better the understanding - i hope! I'll help you with ru.properties, my time is limited at moment, but will do my best to help. Does the cyrillic in ru.properties work correctly? Is it latin character support you are after? Just for clarification, thanks.

You really want to convince your employer to use the power of the cloud and elcomsoft software, a few processors and gpu's should yield a quicker result.

You need to edit ru.properties Use encoder v2.2 Java -jar encoder.jar -l resources/ru.properties -i input.txt -o output.txt

Your network device is set to usbmon1, shouldn't it be eth0 or wlan0 depending on network/wifi network? Do a "show options". You probably need "set interface eth0" or something similar.

For apple vid & pid. See http://code.google.com/p/ducky-decode/wiki/Keyboard_VID_PIDS You can change vid & pid easily with version 2 firmware. Howto is on forum somewhere and ducky decode website, maybe Darren could demo this on next episode?

Speed is limited to the open source spi protocol, the connection interface to the sdcard. Sd has its own proprietary interface/protocol which is faster but costs $$$. This would affect licensing and cost of ducky. Trying to keep software as freeware & open source as much as possible. I'm afraid you'll have to live with slow speed. Corruption - never had problem, 1st sdcard was faulty , replacement still working fine. Sdcard loading times, your right smaller the quicker. I get by with cheap 256/512mb.

Most are here: https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payloads

%myd% is the variable storing the drive letter, just like %systemroot% is a variable for c:\windows\system32 so to call executable / jar files on the sdcard you need %myd%/execute_me.exe or java -jar %myd%/my_jar_file_on_sdcard_root.jar

Twin Duck firmware: Mass Storage support HID injection

The ducky could call the jar file, this could be downloaded from internet, or loaded from mass storage drive. Your just dependant on having: Java needs to be installed on the system Java needs to be fully configured; e.g. class path, executable path

Do you mean one that changes from USB Storage to HID Keyboard on a key press? Otherwise, check out http://code.google.com/p/ducky-decode/downloads/detail?name=c_duck_v2_S001.hex&can=2&q= triggers are the *_LOCK keys. CAPS,NUM,SCROLL LOCK all trigger the same payload; inject.bin.

you could use the twin duck firmware to load the image from the mass storage partition...

Q1: No see above. Q2: The chip is a micro-controller, not an actual full-blown OS, its pre-programmed with a set of instructions triggered/executed by a series of interrupts.

Thanks for the info... I'll amend the flashing how-to guide, to include this package. Thanks Snake

I've been getting questions, on how I was successful at creating the community edition firmwares. Background After using usblyzer or busdog to record various dumps of USB traffic from devices like the Ducky, HID keyboards, and Mass Storage devices. I spent hours checking the USB protocol for how it interacts with computers. Learning that different OS's have speed tolerances, descriptor packets are formed in a specific way, learning about EP (Endpoints). I had proved that the Ducky could cope with other languages or keyboards,by programming the Ducky for the UK keyboard-map (where I was currently working at the time), I then moved to Germany briefly, so started to write a DE-encoder with some help from the community. Hoping for more community support, I changed my focus to firmware rather than the encoder. I wanted Mass Storage Support, so left the encoder development for the research below in writing firmware. Later, Dnucna came along with his Encoder improvements (He's a better Java programmer than me). Firmware Development Basically, it involved research, and a fair amount of time pouring over Atmel's data sheets, and project examples. Atmel's framework, contained a few bugs, so I was constantly getting stressed over strange errors. These were slowly getting fixed as I queried these errors with Atmel Tech Support, and progressively downloaded updated frameworks. I started on ASF-2.11 for initial HID, the latest composite only worked on ASF-3.1+ the code never really changed just the Atmel framework, and the lower base calls. At first I was scared about bricking the Ducky, as I didn't want to overwrite the Ducky's bootloader! (How you can repeatedly flash the Ducky, I downloaded a lot of documentation and programmed a simple bootloader just incase I erased it. When I took the risk and plunged in and ref lashed, I though shit..... its bricked! But then it came to life :) looks like Jason had set some fuses protecting the bootloader, thus i did not have to worry about bricking the Duck. Now I could focus on programming and flashing firmware, debugging USB traffic concentrating on developments. I could guess (from using google) that the hardware that the chip was based on the EVK1104 demo board. I could have bought one, but decided to go right ahead and attempt flashing the Ducky, using the EVK1104 sample projects I got a feel for the code and what calls were necessary. HID - Multi OS support First I concentrated on speeding up the Ducky - secret to multi OS support. I played around with various settings from Atmel's examples and had mixed results - too fast I would loose keys, too slow and the Ducky was unimpressive. also all HID codes needed a signal button-down and button-up. When Jason and Darren released their Source, it confirmed my initial guesswork. And Jason's state-machine for managing key presses was impressive and fast (with low error rate), so decided to keep this part of the code - as DuckyScript and the Encoder were dependant on this relationship - any change could add complexity, and potentially break their good relationship. MSC Support I was working in an organisation, with data-leaks were a problem, the company employed device control software to limit USB access, and enforce the use of encrypted USBs. I though *BANG!* I could probably program the Ducky to bypass this software, and use the Ducky to move data. After 2 months of more reading/trial and error I had a working prototype :) Or so I thought, the device was registering as a USB drive in device-manager, but windows mounted no drive. Chatting with Tech Support I had messed up the boards clock settings (imported from their example). Not knowing these actual values, a began bruteforcing the values/settings; this was a painful and long process. Then one day I returned to the Hak5 forum to see Darren released the HID source-code, reading the code it involved learning how Darren/Jason was using the clock, and I quickly realised my mistake. Making the necessary changes - I had the first Ducky that supported Mass Storage. After some more months, I then created the community website and dumped the firmware online. As the support for the Ducky appeared to have dwindled, and people were complaining about the use of a Duck (initial costs were $80), so I could least give people the option of using their Ducky's as flash-drives. Around this time Darren enquired about composite devices. So I moved onto combining both the HID and the MSC firmwares. Multi Payload Support It was a long process and without any success at composite I took a step back. Rumors of data-exfiltration via keyboard LED lights was an interesting research project, but i decided to look at controlling payloads dependant on the keyboard LEDs. Many chats with Tech Support on endpoints and the ability for keyboards to sense key presses yeilded no results. In the end I stuck my head down and realised only the status of LED lights are read by the AVR library. So I tied different files (inject.bin, inject2.bin, etc) to the status of these lights; again no success. The trick was getting the Ducky to acknowledge the change in file, and execute the different commands. Upon accidentally hitting the GPIO (reset button) I realised that it did actually work. Hence the naked-duck was born, as you needed access to the GPIO. Later developments, enabled me to perform the reset in software, removing the need for the GPIO button as a reset. Composite Just before Xmas I updated the ASF framework to 3.1+. Suddenly the composite code sprung into life. The idea was to release the code at Xmas, I gave demos out to a few private test subjects and thus had some time to test this feature in the real world, and had a chance to resolve bugs. One clever person noticed the code change in the SVN (hinting at composite support); so I decided to come clean and release the test-code early. My plan then changed to reveal the improvements in the New Year.... this is when I released the Firmware 2 Enhancements. Future Improvements To this day I am still playing around, hopefully I can work out some nice features and introduce these into future projects/releases. Summary of Steps Goto Atmel website http://www.atmel.comDownload Atmel Studio (windows only & version 6.0) (Atmel Studio 6.1 is beta and breaks the code!!!) http://www.atmel.com.../atmel_studio6/Look for documentation on chip, and example projects (EVK1104 or UC3B1) AT32UC3B Complete Datasheet doc8360.pdf doc8445.pdf doc8446.pdf Example code: http://asf.atmel.com...tml/index.html http://asf.atmel.com...ard__group.html http://asf.atmel.com...msc__group.html http://asf.atmel.com...msc__group.html Prepare to have lots of chats with Atmels Technical Support when things go wrong???? Also worth joining Avrfreaks.net (they do some limited 32bit stuff, but mainly 8bit support for lower spec avrs). So if you want to repeat what I've done, have a crack at writing your own code, or potentially improve the firmware / features of the Duck. You now know at least how I did it! ~~Snake

Hmm, I've used that OS with the Ducky no problems ???

What's the version of your os?

Yes, until these guys get wise! Symantec, Sophos, and lumension (old versions)can be bypassed! Lumension just released new version, that dictates what users are allowed USB. If you user isn't allowed USB, ducky will be blocked. Windows 7+ GPO settings can also block the duck. Other versions and products, block by vid&pid hence version2 firmware makes it easier for you to change these values without re flashing. Go forth, and quack the system, my ducklings!

Oops. That still looks like the demo code from before Xmas. Still works though ;) (hid instructions are in the file marked ui.c) just need to combine it with the HID_duck source :P . Put your dev hat on B) , and frankenstein the code together. I'm currently away from my machine with all the Ducky code, Ill post the updated source as soon as possible..... How does 2/1/2013 (1st Feb) sound for a countdown... 9 days to go!

Probably worth contacting nek6994 to see how far he has got. Otherwise, follow the instructions in that blog post to create an es.properties. First one gets the Kudos! (But I do want to promote working as a Team!)

I give beginners: http://learnpythonthehardway.org/book/ http://www.learnpython.org You may be looking for something more advanced? but the basics are always a good place to start! You'll probably fly through these sites really quickly, and start looking for bigger challenges.

Just remember to label the sdcard to "DUCKY" for this to work..... their not labelled by default (if they are its usually some pseudo-random code eg "23AF-3DDE")

Your help is welcomed! General Instructions are below: Make sure your using the latest encoder (currently v2.2). You best option is download the ducky-decode svn inside the svn is the Folder Encoder/v2/resources This is the location of all the language maps. keyboard.properties is the main file, it maps ascii characters to their HID values. Do not edit this file. You probably now want to read a non-english language french (fr.properties)/italian(it.properties)/german (de.properties) to see how special characters are mapped. An example from de.properties: ISO_8859_1_A7 = KEY3, MODIFIER_SHIFT This website http://www.charset.org/charactersets.php is good for finding your character map and ISO codes. Basically, you need to create a new file es.properties, and build lines similar to: ISO_8859_1_code = key_located_on_US_QWERTY_keyboard ISO_8859_1_code = key_x, modifierkey_y It may be a long process, but do this for all the characters you need. You can probably cheat and start using it.properties - and make necessary changes! Edit: If a character is missing a warning is prompted when you run the encoder. Example: Char not found:ASCII_72 Char not found:ASCII_70 Char not found:ASCII_6F This will help identify gaps in keyboard mappings Also, when your sure you've got a working es.properties add it on the ducky-decode website under Issues, and label as Patch - it will then be added into the main repository. This is a brief post, if you need clarification, ask questions, and I'll edit this post to make things clearer.

USB transfer rates are known to be slow, because we're limited to using the open-source SPI protocol. The SD-transfer protocol is faster but this is proprietary, so we would have to spend a lot of money for the SD code spend time integrating the code into the ducky's firmware (ducky has a small amount of memory? no guarantees) charge all you ducky followers a lot more for the firmware updates For now the slow speeds are acceptable, considering the firmware is opensource & freeware. As to wiring up the button - this was in the demo firmware, quite easily to bring back. UPDATE: See c_duck_v2_S0002.hex on ducky-decode The driver delay only happens the first time you insert in Windows - its the way windows handles drivers - cant be helped! Version 2 firmware supports easy manipulation of the VID & PID, if you find one that doesn't require a driver-install, please feedback. Different payloads by key-press combo's - not sure how the ducky would detect this??? currently the ducky only detects keyboard LED status: this is how we detect all the *_LOCK keys.

Little bits kit from adafruit. http://adafruit.com/products/745 Good starting point for kids... less of the programming, if she finds this too easy jump to Hummingbird is a bit pricy, but aimed at kids http://www.hummingbirdkit.com/ Another alternative is the raspberry pi http://www.adafruit.com/category/105 Adafruit has a good section on using the GPIO pins for different projects, theres scratch for introductory programming, and she'll be learning linux. Best of all this is relatively quite cheap Special adafruit electonics distro for Pi: http://learn.adafruit.com/adafruit-raspberry-pi-educational-linux-distro Tutorials: http://learn.adafruit.com/category/raspberry-pi