[Info] How I Wrote the Community Edition Firmware

[no42]

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.com

Download 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

Edited March 12, 2013 by midnitesnake

[C3PBRO]

Kudos snake! A firmware that I would love to eventually see is one that has the ability to act like a normal mass storage device when plugged in, but when a certain key is pressed it triggers the inject.bin script. (Instead of auto triggering the script when the duck is plugged in)

[no42]

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.

Edited January 28, 2013 by midnitesnake

[C3PBRO]

Ya that's exactly what I mean!

Edited February 6, 2013 by midnitesnake

[no42]

Try this link:

c_duck_v2_S001.hex

24+ downloads

[Dnucna]

That's an interesting summary of the hard time you passed!
It was so easy to dump the ducky with its limitations but you have done so good!

Thank you Snake.

[no42]

Thank you (Dnucna) for giving me the time by taking on the Encoder challenge.

Hopefully, this year we can increase language support.