timmattison

BTW, here's the Perl script that generates the Ducky input. Here's the Ducky input itself to type the numbers 1 - 10000.

I conducted a test this morning to try to rule out the possibility of a limitation on the Ducky. I assumed that maybe there was a max instruction limit so I wrote a script that typed out the numbers from 1 to 10000 with an ENTER in between them. I opened TextEdit and let it run. When it was done I could see that it did get all the way to 9999. So now I'm a bit stumped. It doesn't seem like an instruction limit. It doesn't seem like a difference in encoders. My current wild guess is that you may be running into a keyboard buffering issue on the device. It is possible that the Ducky is sending characters too quickly, the buffer fills up, and then ignores the last bunch of commands. However, if that happened I think you'd see a few random instructions towards the end. I'm happy to help, we just need to keep chipping away at the details.

I just ran this script through my encoder and the original encoder as a unit test and I got identical output. Both encoders gave me 10,934 bytes of output. Are you seeing a similar size? Can you send me the header info that my encoder outputs so I can make sure we're working on the same version?

Hmm, I got a notification about an instruction limit question you had but I don't see it here. I did a test with 1000, 10000, and 1000000 instructions and they all work as I would expect them so an instruction limit shouldn't be the issue. I'll take the script you provided and test it locally here and let you know what happens. Thanks!

This script has REPEAT instructions in it. I can remove them and try it without them but I just want to make sure that this script definitely shows the issue and works on the original encoder. Once I know that for sure I can quickly see what's going on.

Hey, that'd be a great bug to fix. Can you post the script that does it? I'll compare the output from the original encoder and my encoder and make sure they're the same.

The code is still working for you right? The new stuff is in the issues list on Github - https://github.com/timmattison/USB-Rubber-Ducky/issues - but none of it is done yet. BACKSPACE support should be easy but I haven't had time to tackle it.

Great! Sorry it took so long to get synchronized on this but I think the improvements were well worth it. Keep me posted!

Nope, your command is right. From the output I can see that you were on the master branch and not the multi-statement-repeat branch. I've merged multi-statement-repeat into master. Try pulling again and try it again. Everything else looks right.

OK, so here's what has happened so far today... I checked and the "BACKSPACE" command is not implemented. It appears to not be implemented in the original encoder either. Does it work for you in any of the old versions or any of the forks? If there is a fork where it works let me know and I'll see if I can implement that quickly too. I've created a ticket for it so I won't forget https://github.com/timmattison/USB-Rubber-Ducky/issues/20 It seems strange that you're getting a NoParserFoundForStringException. This could be because you're on the wrong branch or using an old JAR. I've updated the master branch and my multi-statement-repeat branch to have two specific features to make this easier to debug. First, the application now prints out the githash that it was built from. So you'll see something like this: Rubber Ducky Encoder Application - githash: 9f79d891760ad92bdb389159869f75d11790ff8f Each time you run the application. If you run into a string that doesn't parse you should see something like this: Rubber Ducky Encoder Application - githash: 9f79d891760ad92bdb389159869f75d11790ff8f This line could not be parsed: BACKSPACE com.timmattison.hacking.usbrubberducky.exceptions.NoParserFoundForStringException at com.timmattison.hacking.usbrubberducky.StandardRubberDuckyEncoder.encode(StandardRubberDuckyEncoder.java:56) at com.timmattison.hacking.usbrubberducky.RubberDuckyEncoderApplication.main(RubberDuckyEncoderApplication.java:51) Whenever you are reporting an issue be sure to include this information. I then took your input from above and manually converted it to this: REM Test repeat DELAY 500 ESC DELAY 500 CONTROL ESCAPE DELAY 500 ESC DELAY 500 DELAY 1000 STRING ~ DELAY 1000 DOWN DOWN LEFT ENTER DELAY 1000 STRING vz test DELAY 500 DOWN ENTER STRING Starting SMS/MMS Test. ENTER STRING Char Count 141 ENTER DELAY 1000 STRING GixUp0N6mBZj7Q7uWN1G0Vec6XpJl@L2Y0AxQ7150ks9U3Uo3vz5lMdIL7M3R5gEuY7lT79@x5m7OR33Yy8xi4Vr2C190om6icZSSOsH5s2lfV9cAKFH35C0g3i8t21ag6t4AdFuxH61 ENTER DELAY 1000 STRING GixUp0N6mBZj7Q7uWN1G0Vec6XpJl@L2Y0AxQ7150ks9U3Uo3vz5lMdIL7M3R5gEuY7lT79@x5m7OR33Yy8xi4Vr2C190om6icZSSOsH5s2lfV9cAKFH35C0g3i8t21ag6t4AdFuxH61 ENTER DELAY 1000 STRING GixUp0N6mBZj7Q7uWN1G0Vec6XpJl@L2Y0AxQ7150ks9U3Uo3vz5lMdIL7M3R5gEuY7lT79@x5m7OR33Yy8xi4Vr2C190om6icZSSOsH5s2lfV9cAKFH35C0g3i8t21ag6t4AdFuxH61 ENTER DELAY 1000 STRING GixUp0N6mBZj7Q7uWN1G0Vec6XpJl@L2Y0AxQ7150ks9U3Uo3vz5lMdIL7M3R5gEuY7lT79@x5m7OR33Yy8xi4Vr2C190om6icZSSOsH5s2lfV9cAKFH35C0g3i8t21ag6t4AdFuxH61 ENTER DELAY 1000 ESC ESC ESC ESC And then I compared the output against what the encoder produces for your input vs mine and they came out as identical bit strings on the multi-statement-repeat repeat branch. I would suggest pulling the latest multi-statement-repeat branch, rebuilding, and trying to run it again. If it doesn't work then post the new results with the additional information generated in the thread. Again, thanks for testing!

Taking a look now. I'll get back to you hopefully today.

Nah, I probably messed something up. Let me take a look at it and get back to you. Thanks for testing though!

I tried this script: STRING Hi STRING 1,2,3 STRING OMG REPEAT 3 3 With mine and it did generate a binary file. Did you do a "mvn clean package" after you pulled the latest code?

If you're interested there is a branch called "multi-statement-repeat" on the repo. It implements multiple statement repeat but I'm having some trouble getting one of the tests to pass. Would you try it out? The syntax to repeat multiple statements should be: REPEAT 2 4 Where "2" means repeat twice and "4" means repeat the last four statements. So you would expect something like this: STRING Hello, world DELAY 500 STRING Time to repeat DELAY 500 REPEAT 2 4 To print out: Hello, world Time to repeat Hello, world Time to repeat Hello, world Time to repeat The first copy of "Hello, world, Time to Repeat" is from the original commands. The next two are the repeat. My Ducky is at home and I can't test it right now.

Thanks for the feedback. I've updated the README to indicate what you need to do to get started but here's the gist. First, run "mvn clean package" to create the JAR file. Then, run "java -jar target/Encoder-1.0-SNAPSHOT-jar-with-dependencies.jar" and it will tell you what the command-line options are. After that you can just append those options to this command. Let me know if that works for you and if you find any bugs!

Thank you so much! If you have feature requests or bug reports please let me know on Github!

Any thoughts?

Sorry about that. I copied and pasted it into my text editor and when I pasted it back the link got turned into just blue underline text. https://github.com/timmattison/USB-Rubber-Ducky Thanks for pointing that out!

Hey everyone, I recently implemented a Ducky encoder from scratch and wanted to share the results here. My motivation was originally just to have a project to play around with but after many, many commits I think that it is something that other people can probably use as well. Honestly, I didn't look to see if someone had already done something similar before I started since I wanted to do a completely clean implementation. After perusing the forums a bit I see someone else is maintaining and updating the original code in a new repo with some very interesting features that I haven't implemented yet. What did I do? First, I made a version of my code that was completely compatible with the original encoder. I did this by extracting the scripts from the Wiki and adding tests to the Java code that would run the original encoder, capture the output, run my encoder, and then make sure they matched byte-for-byte. Then I saw there were a few bugs in the original implementation so I fixed those: - Incorporated Peter Janes' "GUI SPACE" fix - Fixed issue where DEFAULT_DELAY values larger than 127 get thrown away - Fixed a crash when lines are less than two characters long - Added a REPEAT implementation - CTRL and ALT characters don't seem to work properly on Macs (still working on this) Then to add a bit more flexibility for the new encoder I touched up the scripts in the wiki that caused problems. Most of this was changing things like "CONTROL Z" to "CONTROL z". My code would generate a control code with an upper-case Z with the first string but the original code always treated control characters as lowercase. These changes wouldn't affect older encoder versions so that shouldn't be a problem. With the new version you can do "CONTROL Z" and "CONTROL z" and it'll generate CTRL-SHIFT-Z and CTRL-Z respectively. I cleaned up some minor Wiki code formatting junk too but that's not that exciting. The real benefit to the new code is that it is more modular than the original code so adding new functionality and commands should be easy. For example I have included the following new features: - REPEAT instruction (although this is in the original version now as well) - The ability to create strings like "CTRL ALT SHIFT x" to generate more complex keypresses. You can even do "LEFTALT RIGHTCTRL GUI F11" if you want. The code makes sure you don't do two keypresses that collide too. I need to test this more but so far it appears to work well. - Improved REPEAT instruction that lets you do something like "REPEAT 5 4" which will make 5 copies of the last 4 instructions - Added support for pre-processors that can convert legacy or new syntax into other commands. For example, one translates DEFAULTDELAY to DEFAULT_DELAY. Another one translates “CTRL-SHIFT” to “CONTROL SHIFT". This helps keep the processing code focused on just implementing the key press instructions and moves some stuff that can end up cluttering the code out to where it isn’t distracting. - Maven support for building and testing If anyone is interested the code is on github. I'd really like feedback and feature requests. Feel free to use this thread and the issue tracker there to contribute. Thoughts?