mame82 / duckencoder.py Goto Github PK

I am piping live stream from keyboard into duckencoder.py; this is PITA because duckencoder.py is designed to work on closed stream, and not live pipe. Issue lays in both methods -r and -p, due to the use of

                        for line in sys.stdin:
                                source += line

This means the code is waiting for EOF before starting further work. Same issue happens further in the code:

        if rawpassthru:
                # parse raw ascii data
                result = ""
                keyboard = DuckEncoder.readResource(script_dir + "/resources/keyboard.properties")
                language = DuckEncoder.readResource(script_dir + "/resources/" + lang + ".properties")
                for line in source:
                        for c in line:
                                keydata = DuckEncoder.ASCIIChar2USBBytes(c, keyboard, language)
                                if len(keydata) > 0:
                                        result += keydata
        else:
                # parse source as DuckyScript
                result = DuckEncoder.generatePayload(source, lang)

        if ofile is None:
                # print to stdout
                # print(result)
                sys.stdout.write(result)
        else:
                # write to ofile
                with open(ofile, "w") as f:
                        f.write(result)

This whole section does things in two seperate steps: 1, it converts data, and when convertion is done, it tries to output it.

The way to fix for line in sys.stdin: is given in man python, in section for option -u. Fixing the rest needs a complete rewrite of the end of the source.

My workaround is to parse input data, and process it byte after byte, and call duckencoder.py once for each byte; this is overkilling, since it requires to reparse and recompile the python script for every single byte sent; the host can usually stand it because the initial input is a human typing on a keyboard, so it can hardly exceed 10 bytes per second for longer than 10mn ...

Well im very new to P4wnP1 and i don't really know how to add an language to the v0.1.0-alpha2. I want to add the German language because i think the language german isn't installed. I am also having trouble with the wifi_covert_channel.js i did everything the same as Seytonic (https://www.youtube.com/watch?v=-QrfCNUxKgE&t=) but when i enter the sessions command no sessions show up and i don't know why :/

There are situation when the REM command in a DuckyScript leads to type ou of a r.

Needs to be investigated, but // is working for comments.

[ and ] have to be exchanged for be

I have my .duck script and duckencoder.py in the same directory.

When I run this command:

python duckencoder.py -i rickroll.duck -o rickroll.bin

I get the following TypeError:

E:\Data\Dev\RubberDucky\Scripts>python duckencoder.py -i rickroll.duck -o rickroll.bin
Traceback (most recent call last):
  File "duckencoder.py", line 571, in <module>
    main(sys.argv[1:])
  File "duckencoder.py", line 555, in main
    result = DuckEncoder.generatePayload(source, lang)
  File "duckencoder.py", line 380, in generatePayload
    payload = DuckEncoder.parseScript(source, keyboard, language)
  File "duckencoder.py", line 346, in parseScript
    l = l.strip().replace("\r\n", "").replace("\n", "")
TypeError: a bytes-like object is required, not 'str'

The contents of the .duck script are:

GUI r
STRING chrome.exe
ENTER
DELAY 2000
STRING youtube.com
ENTER
TAB
TAB
TAB
STRING never gonna give you up
ENTER

https://github.com/mame82/duckencoder.py/blob/4af3dd262f43a9328894b4342cb97de675ee2d87/duckencoder.py

481-482
-p, --pastthru Read script from stdin and print result on stdout (ignore -i, -o)
-r, --rawpassthru Like passthru, but input is read as STRING instead of duckyscript

498-500 (and many other ones)
rawpassthru = False
try:
opts, args = getopt.getopt(argv, "hi:o:l:pr", ["help", "input=", "output=", "language=", "passthru", "rawpassthru"])

524-531:
elif opt in ("-p", "--passsthru"):
[...]
elif opt in ("-r", "--rawpasssthru"):

and I probably missed many other ones ...

# echo -e "\x1B" | python duckencoder/duckencoder.py -l us -r | hexdump -C
00000000  1b 20 69 6e 74 65 72 70  72 65 74 65 64 20 61 73  |. interpreted as|
00000010  20 41 53 43 49 49 5f 31  42 2c 20 62 75 74 20 6e  | ASCII_1B, but n|
00000020  6f 74 20 66 6f 75 6e 64  20 69 6e 20 63 68 6f 73  |ot found in chos|
00000030  65 6e 20 6c 61 6e 67 75  61 67 65 20 70 72 6f 70  |en language prop|
00000040  65 72 74 79 20 66 69 6c  65 2e 20 53 6b 69 70 70  |erty file. Skipp|
00000050  69 6e 67 20 63 68 61 72  61 63 74 65 72 21 0a 28  |ing character!.(|
00000060  00                                                |.|
00000061

This is wrong at several levels:

1B is a standart character, and used for many commands:
http://www-ug.eecg.toronto.edu/~gizmodoc/demos/code/Colour_Escape/keyCodes.txt

The error message is sent to stdout instead of stderror; what means:

• user can not see the error message (I lost 4h on tracking the root problem)
• invalid data are sent to the next command on the pipe, resulting in garbage sent to the host (USB HID Gadget client)

This implies the encoder can only work on pure alpha keys, and is unable to deal with ESC, arrows, function keys, or home ...

Hi, in keyboard.properties some of the values are in hex (preceded with 0x) but some of the values are in standard base 10. However, in the "gb.properties" file the KEY_BACKSLASH holds "64", is it supposed to be 0x64?

I tested it with "Keyboard" library of Arduino Pro Micro like this:

  KeyReport kr = {0x2, 0, // lack of 0x2 (0) results in backslash
    {
      0x64, 0, 0, 0, 0, 0
    }
  };
  HID().SendReport(2, &kr, sizeof(KeyReport));
  delay(50);

  kr = {0, 0, 
    {
      0, 0, 0, 0, 0, 0
    }
  };
  HID().SendReport(2, &kr, sizeof(KeyReport));

And it appears to correctly type the pipe character (which I was trying to type).

So my question is: are the "KEY_..." values within language-specific properties files actually hex values? E.g. Should KEY_ASH=100 be actually interpreted as 0x100?

Edit: It turns out that all the ascii characters are typed correctly using UK keyboard with English (UK) system settings and the KEY_ASH (or KEY_HASH?) value of 0x32 and KEY_BACKSLASH value of 0x64, however it was required to change the anomalies in the "ASCII_XX" order, e.g.
ASCII_7E in the place of ASCII_7C
ASCII_23 in the place of ASCII_5C
https://github.com/michalmonday/duckencoder.py/blob/master/resources/gb.properties

Language file /resources/us.properties doesn't exist or isn't readable
How to solve this problem?