Keyboard light as feedback.

[jtagcat]

There's many feature requests in one issue, this is for more discussion and thus is not separated in to many issues.

You can't get any feedback with a ducky? Wrong. Malduino detects when it's ready to start by waiting feedback on (I think it was) scroll lock. Let's use it for Malduino Smart Transmisions™.

DELAY command / rdy indicator

So instead of adding many delays (delays vary depending on say if the computer is running on a hdd or ssd), change scroll lock in to rdy.

Say we have a script what could execute from 0.5s to 5s.

For example, on PS we could add $o=new-object -com wscript.shell;$o.SendKeys({scrolllock}) (the first part only needs to be exed once for many keypresses) at the end of the script.

On Malduino, instead of DELAY 5000, we add WAIT or WAIT 5000 (timeout wait must be the last wait in a given script, as the original rdy might fire when the second rdy is indicated) (5s timeout) to the script.

If statements

Reference

Renaming the keys:

• scroll lock = rdy
• num lock = trans(mission, data transit in progress/lock)
• caps lock = data

Each key is one bit. 2 numbers represent num lock and caps lock.

Async with the WAIT command.

We can't use rdy for data transmission or as the trans key (what would give us one more bit) as the rdy could fire at any moment.

Caps Lock and Num Lock may mess up Malduino transmissions

So let's say caps lock is being used for data transmission to the Malduino while Malduino is injecting something. This happens: $vArIABLE=1;if ($VARIabLe=1){echo why is there an if statement here}. The same could happen with the num lock key, but in more rare situations.

Introducing command TRANSTIMEOUT. Normally unset, but if a data transmission is cut short or too long, this could be used to ensure carrying out the script is at least tried.

Turning on trans pauses Malduino from injecting code.

Getting harder and forking the spec.

We still can't use rdy, as it's completely taken for async. One is used for indicating data transmissions.

There're 2 options:

We trust the computer can time light blinking.

Normally, we just pause Malduino from injecting code. Here we still do that, but we also store any rdy changes (so we can continue afterwards, as they are independently async).

Data Transmission Protocol:

Speed of one bit can be set with TRANSTIME 100.

1. toggle trans (on)
   (Malduino waits half of TRANSTIME, it will always be reading on the 'offbeat', giving the maximum margin of error)
2. if bit=1, toggle data
   (Malduino reads if the state has changed)
   (Malduino waits 100ms)
   (multi-bit transfer loop start)
3. wait TRANSTIME
   (Malduino has waited 50ms)
4. if bit=1, toggle data
   (Malduino is waiting 50 more ms)
   (Malduino reads)
   (eof multi-bit)
5. toggle trans (off)
   (Malduino: if uneven amount of 1-s, toggle data, then continue normally)

Rdy indications wait until transmission is over.

This has the advantage of being reliably fast (no need to time stuff, the computer can transmit as fast as it can (can the Malduino keep up?)) at the cost of adding overhead to each relevant WAIT setup.

All relevant:

REM DO STUFF
WAIT <- not relevant as there isn't a data transmission to interrupt it
REM DO STUFF
WAIT <- neither is this 
REM DO STUFF with data transmission
REM
REM DO other STUFF
WAIT <- relevant as it might interrupt a data transmission

.. rdy indicators must while trans=on,sleep 1;done before the normal toggle rdy.

Data transmission protocol:

1. toggle trans (on)
2. if bit=1, toggle data
   (multi-bit transfer loop start)
3. toggle rdy
4. if bit=1, toggle data
   (eof multi-bit)
5. toggle trans (off)
   (Malduino: if uneven amount of 1-s, toggle data, then continue normally)

Async data transmission (you can set up multiple data transmissions, and can receive them out of order):

• while trans=on,sleep 1;done before starting with the normal transmission protocol (this could collide with relevant rdy indicators in the second method!)
• first x bits transmitted are the ID of the data transmission, as defined with IDBITS x.

Getting to the actual IF statement.

• Variable is the last data transmission.
• If there has been no data transmitted (or since the last if statement), event listener: trans is off
• The bits are in order of transmission. In this example, there has been a 2-bit transmission.
• Syntax: IF <bits> <command>
• MF is for Multiline (and 2nd side of IF, could be MIF, MI). It executes, when the latest if statement (there could be another MF or a 'global command' in the way) is true.

IF 11 STRING foo
IF 10 STRING bar
IF 01 STRING baz
IF 00 STRING ALT f4
MF GUI r
MF STRING powershell
ENTER
MF STRING echo hello world
MF ENTER

Async

• If has a new syntax: IF <ID> <bits> <command>.

Leave no trace

If the script includes wait or if statements, save the indicator states, on script end, restore the scroll/num/caps state.

---

(Finally, the end. Feels like writing a networking spec. It kind of is.)