swedishhat
commented
6 years ago My opinion on the priorities of the project are (1) make it work, (2) make it easy for others to use, (3) make it cheap.
With that in mind, I believe the best way to make it work is to go the route of an off-device interpreter that generates C files at build time. Plus, it would be a tool that may make it easier to port Ducky Script to other architectures.
So one of the first things that we need for this project to be viable is the ability to interpret existing USB Rubber Ducky payloads. Payloads are plaint text files loaded onto the Rubber Ducky via an SD card. This raises an architectural question: how do we get scripts onto the device if it's too small to support an SD card?
One idea is a portable C library that can parse strings, interpret the Ducky Script, and then provide hooks to whatever is doing the execution. We then have a way to put the DARKWING into a mass storage device mode and load the text files onto it.
Another option is to have a script in the Makefile that will look at a payloads directory, parse the Ducky Script, and then generate a C file that is included in the build during compile time. This has the downside of requiring a full toolchain to modify the payload but it means we don't need any file system middle-ware, mass storage USB code, on-device interpreters, etc.
Prior art using Arduinos and SD cards: https://github.com/ernesto-xload/ducky_interpreter/ https://github.com/Creased/arducky