• store device path in systemd service state during USB gadget deployment (aa31a1f)
• add gRPC methods to communicate device pathes
• add functionality to the CLI client to allow retrieving the device path of a given device, like P4wnP1_cli DEVPATH keyboard or P4wnP1_cli DEVPATH mouse

Client side input validation

• IP addresses
• mac addresses
• valid USB PID/VID (overall form validation)

Currently only changes to the LED state of the HID keyboard are tracked, there's no way to determine the actual state itself. The problem behind this has more complexity as it seems on the first look.
LED tracking has two goals:

1. Determine "keyboard input readiness" of a possible target (on Windows/Linux the keyboard driver sends the LED state once, when the driver is ready to receive keyboard input).
2. Control the flow of HIDScripts by changing LED state by key pressing on the keyboard of target hosts (f.e. pressing NUMLOCK on the target keyboard changes the LED state, which on Windows/Linux is shared among all keyboards and thus could be read back by P4wnP1 and ultimately change control flow of a HID script)

One of the core features of the new HIDScript engine is to run multiple concurrent scripts which share the same resource (a single virtual keyboard and a single virtual mouse). The HIDScript methods utilizing the LED state changes are waitLED and waitLEDRepeat. To account for the first goal, determine keyboard input readiness, it has to be assured that no LED state change gets missed after connecting to a new USB host (connecting/disconnecting without rebooting P4wnP1 is another new feature). The waitLED method is intended to retrieve a single LED change and would trigger, in case the method is running when the initial LED state arrives from the target host. As it couldn't be assured that the user already runs the waitLED method, when the initial LED state arrives (which effectively is a state change, as no other state is known), all LED state events have to be preserved, until at least one script registers a listener for LED state changes (by calling waitLEDor waitLEDRepeat).

Currently this is accomplished like this:

• HID keyboard LED output reports arrive in a dev file, which gets constantly read in a blocking loop (blocks reading when no new state is present).
• one of the tasks of the reader loop is to "fan out" LED state changes to all registered listeners (waitLED or waitLEDRepeatinternally are registering such listeners).
• this means: if no listener is registered, the loop blocks and no state change is read
• not reading state changes, effectively means the kernel enqueues arriving states in FIFO fashion, till they are read from the dev file
• the actual LED state is represented by the last HID output report of this queue, which couldn't be retrieved if no listener (waitLED/waitLEDRepeat) is registered

To have the latest LED state accessible, without missing any LED state change when needed (determine input readiness of USB host), the state queue of the kernel has to be moved into the P4wnP1 service. The optimal solution would be to use a channel as internal FIFO queue and to keep LED state changes till consumed. Before a new LED state is written to this channel, the current LED state could be updated. The shortcoming of this approach is, that such a channel has a defined, and thus limited, size. If LED state changes should be read constantly (in order to have latest state available), state changes have to be dropped, when the queue is full.

ToDos

• introduce an additional (channel based) LED state queue to allow consuming all state changes as soon as they happen, without loosing history
• before writing the latest state to this FIFO queue channel update global LED state

An additional problem is that the LED state is undefined, until the first LED output report arrives. From this point up the state is defined. Successively received LED states are interpreted as changes, if they differ from the last state. This only holds true, if P4wnP1 isn't disconnected from and reattached to the USB host. When this happens, the state has to be transferred back to undefined. To accomplish this, a trigger on USB attach/detach is needed to reset the state (see issue #6 )

• once the needed trigger exists, reset LED state on USB disconnect/reconnect

The "old" P4wnP1 ad a static configuration "per boot". Changing running USB gadgets, network configuration etc. at run-time wasn't intended.
The purpose of this new P4wnP1 version is to allow run-time configuration changes and CONNECTING/DISCONNECTING TO USB HOSTS WITHOUT REBOOT OF P4wnP1 (battery buffered).

This means new methods are needed and have to be implemented, to trigger scripts which are used to automate tasks. Currently, a script (which could be customized by a user) is triggered ONLY ON SERVICE START.
Additional trigger have to be found for the following situations:

• connect/disconnect to/from USB host
• Network connection via USB ethernet established (could be solved via link layer polling of logical interfaces for RNDIS/CDC ECM)
• Client connected to WiFi
• lease / release for DHCP Clients (Dnsmasq is used as DHCP server and allows adding a binary which is called on lease/release. Alternatively the lease files could be monitored with inotify, as they contain more informations, but parsing has to be done in "incremental" fashion)
• HID Keyboard is ready to receive inputs (the HIDScript command waitLED could be used to wait for the very first LED state, which should work on Windows and Linux, but not OSX. It has to be tested, if sending keys to USB hosts, without a ready loaded keyboard driver still ends up in kernel Oooops on P4wnP1. If the latter isn't the case anymore, sending CAPS while monitoring LEDs could be used to test for targets input readyness)

Additionally events have to be fired for all these triggers

• fire events
• push events via gRPC to connected clients (only for notification, triggering of automation scripts happens on systemd service)

Additional triggers:

• IO Pin high/low

Triggers result in Actions, like

• run script
• run HID Script

Allow providing a wpa_supplicant.conf file in WiFi client (station) mode, to attempt to connect to multiple known access points.

It has to be tested if this could still be combined with failover mode. Otherwise usage will be restricted to client mode

Current RPC interface design for USB settings

P4wnP1_service stores a temporary state of USB settings (not yet deployed settings).

The clients are meant to issue gRPC calls to manipulate this temporary settings and ,once all changes are applied, to deploy these settings.

The idea behind dividing the change of USB settings into multiple steps, was to allow incremental changes of settings before deployment (relative settings change).

Example:
Even if the current gadget settings are unknown, a gRPC call could be issued, which enables HID keyboard. It doesn't matter which settings have been applied so far, as they are preserved and the keyboard is switched to on, additionally. But these settings aren't ultimately deployed , as this would involve rebuilding the whole USB stack and kill all depending services (Network gadgets, applied DHCP server, clients, already running HID scripts etc..). So deploying new settings is some kind of critical task.

In pseudo code, configuration with the CLI client could have looked like this:

// current USB state unknown, maybe USB mass storage/serial/mouse etc. is on, maybe not
P4wnP1_cli USB set --cdc-ecm 1 //enable CDC ECM
P4wnP1_cli USB set --hid-keyboard 1 //enable HID keyboard
P4wnP1_cli USB set deploy //deploy the new settings to kernel

// --> we know for sure HID keyboard and CDC ECM are on, other USB settings still unknown

To avoid the overhead of running a deploy command, the CLI behavior was changed to "autodeploy" new settings if not suppressed with an additional --no-deploy flag (short -n)

Same script after no-deploy flag addition

// current USB state unknown, maybe USB mass storage/serial/mouse etc. is on, maybe not
P4wnP1_cli USB set --cdc-ecm 1 -n //enable CDC ECM, but don't deploy
P4wnP1_cli USB set --hid-keyboard 1 //enable HID keyboard and deploy
// P4wnP1_cli USB set deploy //<-- not neded anymore

// --> we know for sure HID keyboard and CDC ECM are on, other USB settings still unknown

The script from above with short flags:

P4wnP1_cli USB set -e 1 -n     //enable CDC ECM
P4wnP1_cli USB set -k 1         //enable HID keyboard and deploy

Wrapping both settings changes in a one-liner

P4wnP1_cli USB set -e 1 -k 1 //enable CDC ECM, enable HID keyboard and deploy (don't suppress deployment)

Simplification for redesign

As the last version of the script shows, the whole USB settings can be fit into a one-line using the CLI client. Toggling single settings, using multiple commands without deploying isn't a very natural approach in scripting, it would be more interesting to use this in interactive sessions.
By introducing a webclient, an additional layer of temporary USB settings state was introduced (the webpage keeps an own USB settings state, till they are send to the gRPC service - which doesn't happen on every single change).

To keep a long story short:
The approach of changing setting incremental (only providing settings which have to be changed, not all settings). The step of storing temporary settings before deployment could be removed, as isn't to useful but requires managing and synchronizing various unneeded states.

The implementation is not hardened against attacks.
SSL with a self signed cert should be introduced to for the web service.

• provide self signed cert when necessary
• allow wrapping WebSockets for gRPC-web into SSL
• wrap static HTTP content into SSL

Switching between STA and AP mode for WiFi leaves "defunct" wpa_supplicant processes. Termination has to be rechecked

During editing the UI layout TriggerAction of a trigger action is complex and allowing editing multiple actions at once makes it hard to keep state between multiple clients and server in sync.

Only one TriggerAction should be editable at a time (by adding it one entering edit mode). The overview of all trigger actions needs a simplified representation.

• HIDScript docu (basically ES5 with some additional commands)
• CLI docu (let's rely on the built-in help screens, for now. They need to be reworked themselves)
• folder structure of resources/configuration files
• language map format (maybe for first release, to help community to bring up own keymaps)

Lesson learned: Documenting, by providing example payloads didn't worked out for the P4wnP1 (nearly no external payload contributions)

• run async scripts
• proper job management and cancelation

is possible p4np1 support for latam keymap?
i have in rubberducky format https://gist.github.com/vay3t/ec99702ee9f0554a35c9763050892400

Currently the internal LED state reader only consumes a new state, if a listener is present (at least one HIDScript with a running waitLED or waitLEDRepeat command pending).

This design decision was taken, to assure that no LED state change is missed if no listener is running. This is because Windows sends a LED state change ONE TIME in case a keyboard driver is ready. This event mustn't be missed, if the intention is to use it as trigger (for "ready to type"). It couldn't be guaranteed that a HIDScript with such a trigger, is already running when this initial state change occurs, thus ALL LED state changes are preserved until at least one consumer is present (relies on the FIFO queue of the kernel, by not reading from the HID device file till needed).

This behavior by far isn't optimal, as not consuming new LED states means: The current LED state is undefined, till all state changes are consumed.

The situation changes, when reliable trigger for the following USB gadget states (dual role mode) are available:

• USB gadget mode, not connected to host
• USB gadget mode, connected to host
• OTG mode, no device connected (OTG adapter attached, but no device on OTG adapter)
• OTG mode, device connected (OTG adapter attached and device attached to OTG adapter)

If a state change to USB gadget mode, connected to host is used to trigger a HIDScript (and assuming the delay between firing the trigger and starting the script is negligible), there is no need to preserve past LED state changes which haven't been consumed. Instead, a waitLED command on the start of such a HIDScript would reliably catch the first LED state change, which is issued from the keyboard driver once ready).

• remove dependencies of CLI client on service package, to keep resulting JS small
• debug out of HIDScript puts way to much CPU load on journaling daemon (floods logs)
• allow gRPC server to abort Running HID scripts on context.Done()
• jobs aren't deleted from global job list, unless result is fetched with waitResult. This affects interrupted
• jobs (f.e. timeout) and jobs run as background job --> cancelled jobs need a way to communicate back to the controller, that they could be deleted (Solution: goroutine listening for context.Done() per job in controller)
• proper error message extraction from gRPC calls (the error contains other, unneeded, info like status code etc.): Not possible (the status library isn't working as intended)

• Update Makefile to account for all new dependencies
• test build on bare raspbian lite
• test build on kali without nexmon
• add alpha release images

on oneplusone is not working as it should, not sure what is causing it. Any idea how to solve it?
Thanks for this beautiful gift, btw.

As soon as I try to initialise the HID attack and I press run it gives out an error "CONTROLLER ABORTED". Called abort on Hid Controller...some help would be greatly appreciated. Mouse attacks still work but keyboard attacks are a no show.

Action: SendValue(groupName, value)

Trigger:
OnValue(groupName, value)
OnValueSequence(groupName, []values)

• remote pwd, cd, download, upload ...
• up and download already implemented for HID script transfer, but not accessible via gRPC otherwise

A proper serialization mechanism for the state instance objects is needed, along with a proper storing mechanism for the serialized data

• should be used to store templates
• persistent storage (on SD card)
• has to sync FS as soon as data is written, because the situation of power loss is common (f.e. when powered by host USB and detached)
• as protobuf is already used to transfer data (gRPC), a method for storing serialized protobuf messages would be prefered

Candidates for serialization:

• protobuf
• JSON
• gob ??

Candidates for storage

• file based (not prefered, because of the need to manage multiple files with additional metadata)
• sqlite --> has to be checked for the "immediate FS sync" requirement

A database driven solution is preferred for the storage problem

• configuration capabilities for BNEP/NAP on server, keep in mind BLE use cases (idea of stand-alone proxy)
• gRPC implementation
• CLI client support
• web client support

• consistent logging (no mix between STDOUT/STDERR)
• reduce logging of gadget setting changes (only if settings are deployed)
• remove debug out
• proper unregister of event listeners of web app

Add an option to automatically change WiFi ethernet interface to DHCP client when in STA mode and to DHCP server when in Access Point mode

Hello, Im on the need of running some adb commands on a lot of android devices, in order to get adb to work, a keyboard could be used to enable it.

Its possible to have both?

regards!

All files created by P4wnP1 service have execute permissions set, which has to be disabled (proper umask)

Ive tried both press("PRINTSCREEN") and press("PRNTSCRN") and neither seem to do anything. Is there a way to view all available keys that are valid inputs to the press function?

Kali

• fix bluetooth (weird)
• /dev/random not enough entropy for hostapd --> install havegd & modify build-script with systemctl enable haveged
• enable monitor interface of nexmon on boot (doing it with P4wnP1 service script is a bad idea for service restart)

The HID controller uses multiple Otto VMs to allow running concurrent HIDScript jobs (currently 8 VMs).

If the controller has to be reinitialized (because USB setup changes), these VMs have to be reinitialized.
It isn't possible to destroy the VM objects without leaking memory. To account for this, the existing VMs are kept and reused once the HIDController is reinitialized. It has to be assured, that all VMs are usable after re-initilization of the HIDController.
The trade-off is that the maximum Number of VMs is present (occupies resources), even if not all of them are needed. Thus the max VM number is limited to 8, which hould be enough for most, if not all, use cases which need concurrent HIDScript execution.

(re-use of memory leaking VMs + limited VM pool size, to keep impact reasonable)

• Quick fix: set initial state of wifi interface to on, because hostapd doesn't start if the interface is disabled
• proper watching of hostapd process, to indicate a failed start (error cases: interface goes from UNDEFINED->DISABLED or DISABLED->DISABLED)

I want to translate into Chinese and I also want permission from the author.

Rework logging of service

• reduce debug out
• clean up mix of STDOUT, STDERR
• custom logger, tee-like splitting of messages to gRPC events and STDOUT
• apply the custom logger to Otto VMs, to send JS output from service to gRPC clients

Wrapping bluez-tools binary could be avoided by interfacing with DBus + "Bluetooth Management Socket" API.

See: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc

Currently the state of the systemd service is only partialy stored in an hierarchical object, parts of the state are stored in global variables. The structure doesn't account for the need to split everything state in runtime settings and runtime state (f.e. the DHCP server configuration of an interface is a setting which could be changed at runtime, but DHCP leases handed out to clients belong to a kind of runtime state).

Additionally there're complex dependencies in state changes, which are arising mostly from USB gadget as a root element. These dependencies have to be recorded in a state tree and used to build a new state object.

Example:
Assuming that an USB gadget with keyboard, mouse, rndis and serial functions is active and the user wants to disable the serial function, the following dependencies arise:

1. Changing the active USB functions involves destruction and recreation of the whole composite gadget.
2. Once the gadget is destroyed, the logical RNDIS interface on P4wnP1 disappears.
   1. Service attached to the RNDIS interface have to be suspended or terminated, f.e. a running DHCP client or server.
   2. If a DHCP server is running (external process dnsmasq managed by P4wnP1) all client leases are lost and clients have to re-request them.
   3. The interface goes up again, former running DHCP related processes (server/client) have to be restarted, with the last known configuration.
3. When the gadget is destroyed, additionally the HID devices like keyboard and mouse go down.
   1. The HIDController has to be stopped, as it tries reading the LED state of the USB host in an endless loop with blocking IO. Before the HIDController is restarted, the new device file to read Keyboard LED reports from, has to be redetermined (could change during USB reconfiguration)
   2. Stopping the HIDController, means all the currently running HIDScripts (managed by the controller) have to be interrupted (in fact they are terminated).
   3. Processes not managed by P4wnP1, but relying on HID functionality have to be terminated, too, as it couldn't be assured that USB HID functionality will be reestablished with the same device files. (f.e. the python based server for HID covert channel, which relies on presence of raw HID device). In fact every service depending on HID has to be managed by P4wnP1 to solve this and thus has to be part of the run-time state.

ToDos:

• design a dependency tree (visualization), holding all run-time settings and state
• create a data structure for the systemd service, reflecting this tree (could be done in proto file, to allow easy gRPC usage)
• deploy getters and setters for state changes, to have an entry point for event generation available
• check if dependent actions could be triggered using events, instead of propagating along the tree (decoupling)

• extend installer to move HIDScripts to a fixed absolute path
• set date from webclient
• Load&Store runtime configuration from/to templates (accessible via web client)
• add reboot/shutdown option accessible from webclient

Currently only US and DE are supported. A way should be found to auto-generate the needed layouts (at least key combos fall all ASCII chars for every major language)

• Common (A common layout was created, reflecting US keyboard mapping. New layouts only have to describe keys which differ from US layout. F.e. ASCII-character-wise the German layout has Z and Y swapped in comparison to US layout. Thus only these two characters has to defined for upper and lower case)
• DE
• US
• additional languages

Will this project support Swedish layout as p4wnp1? would really be needed ;)