Create a `keylog` ring buffer for decoded inputs

[ge0rg]

When in passive_enum mode, it would be great to have a small in-RAM buffer (maybe something like 1k?) containing the human-readable sequence of sniffed and decrypted keys, that can be displayed over tty with a command like keylog, and produce something like this output:

> keylog
google.com[RETURN]usr[BACKSPACE]er[TAB]sEcReT[RETURN]

It should be possible to use the existing language layout to do the reverse mapping, right? :)

[mame82]

Reverse mapping to raw HID keycodes (human readable) is doable and already part of the log (and only of log) output.

LOGITacker currently doesn't utilize heap, and thus keeps no baglog on processed reports.

Considering the fact, that it requires too complex logic to do language agnostic logging of physical keyboard keys or even characters (undefined initial state on start of sniffing, keeping track of state for dead key presses, preserving timestamps etc) I opted for a more convenient solution:

• arriving reports could be forwarded to LOGITacker's raw HID interface (includes a decrypted version if key is known)
• additionally they could be forwarded to the HID keyboard interface (reproduce the actual key press on USB host)

The disadvantage of using a external solution to collect the USB HID reports, is compensated by the possibility to apply complex processing,storing etc to externally handled reports

[mame82]

Here's an example on USB keyboard pass through to a terminal running on Android.

https://twitter.com/mame82/status/1150762540080783360

Please note, the keys only arrive if the terminal has input focus (no camera picture), once pass-through has been enabled. This approach allows key logging/processing on the USB host.

Another option is to pass data to the raw HID interface. The raw interface isn't claimed exclusively by the USB host, produces no key presses and receives all other reports in addition (keep alives, encrypted version of key reports etc)