Rewrite loop to be non-blocking and non-destructive

[pstray]

Hi! Here is a PR for a rewrite that makes loop to be non-blocking (it will return immediately if a delay is in effect instead of sleeping) and non-destructive (the script will still be intact, so a call to loop after it returns false will start the script again.

I made these changes so the main loop could call ducky.loop and not hang when it is in a wait state, so I can do other things like pulsing a led or wait for key presses or some such other thing.

[pstray]

I have no idea what that fail is, but if someone tells me, I'll fix :)

[jposada202020]

@pstray Hello :). the CI is falling because of formatting. We use black format to inspect python code. https://github.com/adafruit/Adafruit_CircuitPython_Ducky/actions/runs/4514214573/jobs/7950026861#step:2:766

In order to solve this issue, you could use pre-commit following the steps here https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/check-your-code, once the pre-commit pass locally in your machine it will pass the CI

[pstray]

Yes, I can see that it complains about reformatting... but not the specifics...

[pstray]

ah, ok... it actually reformatted the file...

[FoamyGuy]

I merged main to this to resolve conflicts (Hopefully I resolved them successfully my apologies if not)

I tested this version but found it was not properly handling COMMANDS in the duckyscript.

i.e. this script:

REM My first payload
DELAY 3000
f ENTER
t ENTER
String All Done!

Was outputting this result which included the literal string "ENTER" command instead of actually pressing enter

fENTER
tENTER
StringAllDone!

I changed the line:

line = line.strip(" \r")

to be:

line = line.strip("\n\r")

And it seemed to work more properly after that. I was no longer getting literal string "ENTER" and instead am getting proper enter button press to insert newlines.

I still need to carry out some more thorough testing, but wanted to get this feedback posted for the first thing that I ran into while attempting to test.

[pstray]

Not sure why you would get any merge conflicts with main, as this is a clean PR...

[pstray]

And of course... the commands are case sensitive (as it was before I patched it :)), so "String" won't work, but "STRING" will... but I see no problem in adding an upcase before testing if we want commands to be case insensitive.

[FoamyGuy]

The merge conflicts were a result of merging the other PR that was open. They are resolved now because I merged main to this branch after that PR was merged.

@pstray Sorry, I realize now that example code I provided is a little ambiguous and perhaps highlights more than one issue.

The specific issue I was intending to point out was the way that it includes the literal word "ENTER" in the output rather than interpreting it as a special character and entering a newline. i.e. the DuckyScript line t ENTER results in the literal output tENTER instead of t followed by newline like it should:

t

The last line "String All Done!" was included in my test script and indeed does have wrong case for the command. I'm in favor of keeping whatever case rules come with DuckyScript. Everything I've seen is all caps so I assume that is the intention. I'm not sure why I entered the wrong case for "String" It was not really my intention to test that functionality. I don't think we should bother adding support for that.

[pstray]

Yes, the literal ENTER (including the trailing \n) was because of that missing \n from the strip, and since "ENTER" is not the same as "ENTER\n" it was sent as a sting instead of the ENTER key... But the code would do that before my patch too, as i can't see any stripping of \n there either 😄

[FoamyGuy]

But the code would do that before my patch too

This is not the case. I tested the currently released version and it does not have this behavior. Given the duckyscript line t ENTER it will definitely output the correct string:

t

Not the string with the literal word "ENTER" like: tENTER

In the current code I believe the slicing with square bracket notation using a [:-1] slice is how the \n character is being account for:

Adafruit_CircuitPython_Ducky/adafruit_ducky.py

Line 135 in 716c07a

self.lines.append(line[:-1].rstrip("\r"))

However I think the square bracket slicing is a little harder to understand, a solution with a literal \n in the rstrip string of that line of code would aide in being more understandable / readable.

[FoamyGuy]

Is there a specific purpose for the leading space in this strip string " \n\r"?

I think that will cut out spaces at the end of the line, even if the user has intentionally put one there.

If possible I think it'd be best to not cut out any characters they have put in the code. If they decide they didn't want the space it should get removed from their code, not have the library modified to ignore it.

I think this line would do what we want if written like this without the leading space:

line = line.strip("\n\r")

I'll try to test this again later on tonight.

[pstray]

Possibly, but having significant whitespace at the end of lines seems not to be the best thing (anywhere, not just in ducky scripts 😄)... that's what SPACE is for 😄

Either way, not having a space there could result in empty commands, which then need to be handled correctly, especially if the space is at the beginning of a line.

[FoamyGuy]

Latest version looks good to me. Thanks again @pstray!

I tested successfully on a Feather S2 TFT using a version of the simpletest script modified to include some LED_Animations running during the DELAY in the duckyscript.

Really great new functionality to be able to do other stuff while the duckyscript isn't actively working!