The following information describes the tools used in this project and in the end you can find how to use all the tools combined to generate/convert/upload a payload to a DigiSpark Attiny85. I was inspired to make this based on the Duck2spark project.

https://github.com/mame82/duck2spark

This project provides a python script capable of converting payloads generated by DuckEncoder to an Arduino Sketch source targeting DigiSpark. The script solves two problems:

• Available solutions and tutorials emulating a RuberDucky on a DigiSpark suffer from poor keyboard layout support for non-US languages. This is solved by "outsourcing" the problem to DuckEncoder which supports multiple keyboard layouts.
• Solutions using DigiKeyboard.print() and DigiKeyboard.println() suffer from string size restrictions, due to DigiSparks RAM limitations (less than 512 Bytes available). This is solved by storing the payload in FLASH memory

• Support for DuckyScript "DELAY" and "REPEAT" command
• Option for initial delay, to cope with missing key presses, due to insufficient time for driver initialization on target.
• Option to repeat payload execution (counted loop, single run, endless run)
• Option to blink status LED when payload execution is finished (on by default, except endless loop)

• DuckEncoder: https://github.com/hak5darren/USB-Rubber-Ducky/blob/master/Encoder/encoder.jar

• duck2spark.py - Main script
• README.rst - this file
• example.sh - Example script building a payload by running DuckEncoder followed by duck2spark.py (encoder.jar has to be present)
• example.duck - RubberDucky script with test cases used by example.sh
• duckencoder.py-master.zip - Python port of infamous duckencoder for RubberDucky: https://github.com/mame82/duckencoder.py - unzip the file in the same directory and use it to compile the payload with abnt2 support.
• digisparkABNT2-master.zip - tornar utilizavel os digispark's em teclados abnt2 https://github.com/jcldf/digisparkABNT2 - the file scancode-ascii-table.h must go to /Users/XusernameX/Library/Arduino15/packages/digistump/hardware/avr/1.6.7/libraries/DigisparkKeyboard

• Arduino IDE_ to compile and upload the generated Sketch to DigiSpark

• Arduino IDE has to be configured to program a DigiSpark, following this guide_

• One, two or many DigiSparks ;-)

• DuckEncoder to generate a raw payload from DuckyScript, if you want to stay away from Java use my python port of DuckEncoder https://github.com/mame82/duckencoder.py_

• Python 2 installation

• Arduino IDE: https://www.arduino.cc/en/main/software

• Guide: https://digistump.com/wiki/digispark/tutorials/connecting

• DuckEncoder: https://github.com/hak5darren/USB-Rubber-Ducky/blob/master/Encoder/encoder.jar

If you did what I said above you just need to run this commands: *Copy you generate or get an example payload on https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payloads For example we will use web.duck as my payload and defining br as keyboard with the argument -l br :

cat web.duck | python ./duckencoder/duckencoder.py -r -l br > raw.bin

• Lets generate the sketch file to Arduino IDE

./duck2spark.py -i raw.bin -l 1 -f 2000 -o sketch.ino

• Lets verify the Sketch file in the Arduino IDE

After copying the file scancode-ascii-table.h as stated above to the folder /Users/XusernameX/Lirabry/Arduino15/packages/digistump/hardware/avr/1.6.7/libraries/DigisparkKeyboard/ open the Sketch file in the Arduino IDE

• Generate a DuckyScript test.duck you want to use as output::

  echo "STRING Hello World" > test.duck

• Compile the script using DuckEncoder with your keyboard layout (de in example) or use my python port <https://github.com/mame82/duckencoder.py>_::

  java -jar encoder.jar -i test.duck -o raw.bin -l ./resources/br-propertis

• Use duck2spark.py to convert into Arduino Sketch (options for single run, 2 seconds startup delay):

  duck2spark.py -i raw.bin -l 1 -f 2000 -o sketch.ino

• After setting up the Arduino IDE load the example "DigisparkKeyboard" and replace the Sketch source by the one saved to sketch.ino .

To get help on duck2spark.py run duck2spark.py -h

https://github.com/mame82/duckencoder.py

MaMe82's Python port of infamous hak5 DuckEncoder

Added in additional commandline parameters to pipe in STDIN.

-p (--passthru) could be used to pipe in DuckyScript from STDIN. Example

cat duckyscript.txt | python duckencoder.py -p -l de > inject.bin -r (--rawpassthru) could be used to pipe thru raw ASCII to a keyboard device. Example

cat text.txt | python duckencoder.py -r -l de > /dev/hidg0 Usage

Creds to: hak5Darren for original duckencoder https://github.com/hak5darren/USB-Rubber-Ducky

Converts payload created by DuckEncoder to sourcefile for DigiSpark Sketch

Usage: python duckencoder.py -i [file ..] Encode DuckyScript source given by -i file or: python duckencoder.py -i [file ..] -o [outfile ..] Encode DuckyScript source to outputfile given by -o

Arguments: -i [file ..] Input file in DuckyScript format -o [file ..] Output File for encoded payload, defaults to inject.bin -l [layout name] Keyboard Layout (us/fr/pt/de ...) -p, --pastthru Read script from stdin and print result on stdout (ignore -i, -o) -r, --rawpassthru Like passthru, but input is read as STRING instead of duckyscript -h Print this help screen

====

Here's an introduction to DuckyScript

• Introduction: http://usbrubberducky.com/?duckyscript#!duckyscript.md
• Payloads: https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payloads

• DuckEncoder has an issue encoding "GUI" or "WINDOWS" key without an additional key. The common scenario on Windows is a key combination like "GUI r", but using "GUI" alone would produce the incorrect character e as output. The issue is adressed here <https://github.com/hak5darren/USB-Rubber-Ducky/issues/51>. As there hopefully will be a patch duck2spark doesn't handle this issue. In fact it isn't possible to distinguish between "GUI" key and "e" key in an already encoded script. A patched version of Encoder.java could be found here <https://github.com/mame82/USB-Rubber-Ducky/tree/GUI-Key-fix/Encoder/src>.

• Using long delays in a DuckyScript results in big payloads, as delays longer than 250 milliseconds are split up into multiple delays, with a maximum of 250 milliseconds each. Each of these delays consumes 2 bytes in the final payload. As the memory of digispark is far more limited, it is suggested to use duck2spark's delay options instead. Duck2spark relies on DigiKeyboard.delay() and is more friendly in terms of memory consumption.

• Using the "PREPEAT N" instruction in DuckyScript results in repeating the whole key sequence of the former command and thus consumes N times as much memory in the final payload. Again, as Digispark is short on memory, it is suggested to use duck2spark's loop option whenever possible. Printing out a 10 character string 500 times by using "REPEAT 500" results in a payload 10000 bytes in size, which is to large for Digispark. Encoding a DuckyScript with a single 10 character string consumes only 20 bytes and could be combined with duck2spark.py -l 500 to achieve a 500 times repetition without further memory consumption.