Jump to content

timmattison

Active Members
 View Profile  See their activity

  • Posts

    19

  • Joined

  • Last visited

 Content Type 

Posts posted by timmattison

    New Ducky encoder implementation

    in Classic USB Rubber Ducky

    Posted

    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.

    New Ducky encoder implementation

    in Classic USB Rubber Ducky

    Posted

    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!

    New Ducky encoder implementation

    in Classic USB Rubber Ducky

    Posted

    I am running into an issue where it seems like ENTER is being treated like ESC. I have been experiencing this for a while but am having real trouble getting solid data or a cause on this. I can recreated with a specific payload I am using. This is in an android environment 4.4.4. KK. REPEAT is not used in this scenario. And if I encode with the vanilla encoder it does not happen. If you want some more specific's just ask away and I can try to obtain this for you. I did recreate this on different phones as well. Same build and model just two of the same phone.

    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.

    New Ducky encoder implementation

    in Classic USB Rubber Ducky

    Posted

    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!

    New Ducky encoder implementation

    in Classic USB Rubber Ducky

    Posted

    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.

    New Ducky encoder implementation

    in Classic USB Rubber Ducky

    Posted

    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!

    I really liked the concept of that repeat feature and could use it for some my payloads I am working on. My current request though is for some basic instructions. I have cloned via git into a dir and get the general concept but have no idea how to use your encoder. Right now with the current encoder which is just a .jar it is very easy to run. If you could make it that easy or give some instructions for us n00b's that would be great.

    New Ducky encoder implementation

    in Classic USB Rubber Ducky

    Posted

    Hi,

    Sorry it took me so long to reply. I love what you have done with this, and you have obviously given it a lot of thought. I have just written a simple script and I find that it has worked quite well. I will have to look into the things you've added, like the REPEAT function.

    Great Job!

    MB60893.

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

    New Ducky encoder implementation

    in Classic USB Rubber Ducky

    Posted

    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?

×
×
  • Create New...