P4wnP1 A.L.O.A. by MaMe82 is a framework which turns a Rapsberry Pi Zero W into a flexible, low-cost platform for pentesting, red teaming and physical engagements ... or into "A Little Offensive Appliance".
GNU General Public License v3.0
3.77k
stars
507
forks
source link
Triggers to issue events for automation (USB host connection, networkup, new DHCP client...) #6
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:
[x] connect/disconnect to/from USB host
[x] Network connection via USB ethernet established (could be solved via link layer polling of logical interfaces for RNDIS/CDC ECM)
[ ] Client connected to WiFi
[x] 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)
[x] 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
[x] fire events
[x] push events via gRPC to connected clients (only for notification, triggering of automation scripts happens on systemd service)
mame82
commented
6 years ago
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:
waitLEDcould 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
Additional triggers:
Triggers result in Actions, like