DEFAULT_DELAY not working

[BoRealBobadilla]

Hi all,

I just received my Hak5 kit and have been toying around already with several projects.

I have been using the Rubber Ducky which seems to function as expected, with the exception of the DEFAULT_DELAY/DEFAULTDELAY command. No matter where I put this command in the script, it does not delay as expected. It does not matter how small or large I create the delay, it does not function. I am using the following syntax as documented:

DEFAULT_DELAY 300
-OR-
DEFAULTDELAY 300

Any ideas? It creates a lot of extra work to manually put in DELAY lines after each command.

Thanks!

[Irukandji]

It's covered here.

https://docs.hak5.org/usb-rubber-ducky-1/getting-started/writing-your-first-payload

[BoRealBobadilla]

8 minutes ago, Jtyle6 said:

It's covered here.

https://docs.hak5.org/usb-rubber-ducky-1/getting-started/writing-your-first-payload

Thanks for your reply, Jtyle6. Any chance you could be more specific? I have followed the documentation to a tee and have been able to write and encode successful scripts, but DEFAULT_DELAY has never worked and I cannot find anything specifically regarding this command in the documentation that you have linked.

 

Thanks!

[dark_pyrro]

The command is documented on this page

https://docs.hak5.org/usb-rubber-ducky-1/the-ducky-script-language/ducky-script-quick-reference

But.... there are two things here. Let me guess, you are using some variant of the official jsencoder when encoding the payload, not the older java based encoder, right? If so, there are some things to try.

First of all, it seems as if there's some kind of bug in the jsencoder. When I encode a simple payload using either DEFAULT_DELAY or DEFAULTDELAY and encode it with the jsencoder, the Ducky doesn't care at all about any delays what so ever. Not the two already mentioned or any "standard" DELAY used anywhere in the script. It just races through the payload (at close to light speed) making the whole payload useless.

However, if encoding it with the traditional/old java encoder, it works as expected. Hence the suspicion that there is a bug in the jsencoder (there are at least one other known in the jsencoder since before).

Secondly, if using the old java encoder, the logic behind how you specify the default delay in milliseconds according to the documentation does not apply. If I, for example, set the default delay to 5000, then it waits 10 seconds between each command. So, "milliseconds * 10" (as the documentation states) isn't valid when using the java encoder. I've looked in old documentation (like the "Hak5 Field Kit Pocket Guide") to see if I've failed to remember some old ways of doing things, but it's the same information there. (As a side note, there's some confusion when reading the docs about the DELAY command as well. It says that "time is specified in milliseconds from 1 to 10000", but the example just below that text in the docs says that DELAY 50 "will wait 500ms before continuing to the next command").

[Irukandji]

10 hours ago, BoRealBobadilla said:

Thanks for your reply, Jtyle6. Any chance you could be more specific? I have followed the documentation to a tee and have been able to write and encode successful scripts, but DEFAULT_DELAY has never worked and I cannot find anything specifically regarding this command in the documentation that you have linked.

 

Thanks!

Oops I didn't fully looked through the that doc.

[BoRealBobadilla]

13 hours ago, dark_pyrro said:

The command is documented on this page

https://docs.hak5.org/usb-rubber-ducky-1/the-ducky-script-language/ducky-script-quick-reference

But.... there are two things here. Let me guess, you are using some variant of the official jsencoder when encoding the payload, not the older java based encoder, right? If so, there are some things to try.

First of all, it seems as if there's some kind of bug in the jsencoder. When I encode a simple payload using either DEFAULT_DELAY or DEFAULTDELAY and encode it with the jsencoder, the Ducky doesn't care at all about any delays what so ever. Not the two already mentioned or any "standard" DELAY used anywhere in the script. It just races through the payload (at close to light speed) making the whole payload useless.

However, if encoding it with the traditional/old java encoder, it works as expected. Hence the suspicion that there is a bug in the jsencoder (there are at least one other known in the jsencoder since before).

Secondly, if using the old java encoder, the logic behind how you specify the default delay in milliseconds according to the documentation does not apply. If I, for example, set the default delay to 5000, then it waits 10 seconds between each command. So, "milliseconds * 10" (as the documentation states) isn't valid when using the java encoder. I've looked in old documentation (like the "Hak5 Field Kit Pocket Guide") to see if I've failed to remember some old ways of doing things, but it's the same information there. (As a side note, there's some confusion when reading the docs about the DELAY command as well. It says that "time is specified in milliseconds from 1 to 10000", but the example just below that text in the docs says that DELAY 50 "will wait 500ms before continuing to the next command").

dark_pyrro,

Thanks for your reply.

Yes - I am using the official jsencoder that is recommended in the documentation. Strangely enough and contrary to your experienced behavior, the DELAY command does properly function for me, it's only the DEFAULT_DELAY/DEFAULTDELAY command which does not. It makes sense that there is a bug in the encoder.

I will search around for the java encoder - it looks like it might still be available on Darren's github. I agree with your assessment of the documentation on the DELAY command being unclear, I had the same thought you did about the DELAY 50 / 500ms example. From your experience of 5000 = 10sec, I will try a multiplier of 2 when I find the java encoder and test that out. I do hope I am able to get it working. Only bummer is that it looks like the java encoder documentation doesn't have support for a couple of the commands which the jsencoder does.

Thanks again for the reply!

[dark_pyrro]

I have to clarify my answer before regarding DELAY. It works for me as well when using it isolated. But when throwing in DEFAULT_DELAY in the mix, that's when it starts to misbehave. If having a payload only using DELAY = no problems.

As you mention, the Java encoder is still available on Darren's GitHub. There's one called "duckencoder.jar" here
https://github.com/hak5darren/USB-Rubber-Ducky

But I guess it's better to use "encoder.jar" here
https://github.com/hak5darren/USB-Rubber-Ducky/tree/master/Encoder

The later one is version 2.6.4 (the first 2.6.3).

The help info when running the jar without command line parameters has changed between 2.6.3 and 2.6.4 regarding how delays should be used (when it comes to the time factor), but it still doesn't really match reality. 2.6.4 help texts are more accurate than the official documentation though, even if it still doesn't really does what it says when it comes to the DEFAULT_DELAY (the x2 "issue").

Regarding commands/features, it looks as if they should support the same things. At least when comparing the help output of the jsencoder and the output of the encoder.jar (2.6.4) Java encoder. Is there any specific command you are referring to?

[BoRealBobadilla]

Looking at 2.6.4 it appears that the only command which isn't listed is the MENU command that emulates a right-click.

[SchrodoBaggins]

There is an issue with the jsencoder.html - I had the same problem!

Comparing the git-hub java src against the jsencoder.html I found the issue...delayOverride is not getting cleared to false within the main loop for parsing/encoding each line.  Open jsencoder.html and look for the following block of code and ADD the bold line.  This fixed the issue for me.

        try {
            let sanitized = sanitizeDS(duckyscript);
            // reject new lines here before parser tries splitting nonsense
            // convert lines that contain only a space to a space here
            let lines = splitDS(sanitized).filter(l => l !== null && l !== '').map((l) => { if (l === " ") { return "SPACE"; } else {return l;}});
            instructionMap = buildInstructionMap(lines);
            // Main parse loop - Encode instructions line by line
            for (let lineNumber in instructionMap) {
                currentInstructionIndex = lineNumber;
                // init/clear
                let command = null;
                let args = null;
                let delayToAdd = null;
                delayOverride = false;
                // set
                command = instructionMap[lineNumber][0];
                args = instructionMap[lineNumber][1];
                if (instructionsToIgnore.includes(command)) {
                    continue
                }
                // parse line add to file
                delegateDSCommand(command, args);
                delayToAdd = doDelayCheck();
                if (delayToAdd !== null) {
                    appendHexStringArray(delayToAdd)
                }
                lastUsefulInstructionIndex = lineNumber
            }
 

delayOverride will get set to true upon a DEFAULT_DELAY, DEFAULTDELAY, or DELAY command and process correctly now during doDelayCheck() and get reset for the next encoded line...