P4wnP1
P4wnP1 copied to clipboard
RoganDawes
USE_HID_TEST with OSX / Macbook
The USE_HID_TEST Feature seems to be not working on OSX, as it seems like, there is only a backchannel message for Capslock.
Is there an option to change the key/event? Or is there an option to trigger the exploit after a certain amount of time? (without a custom sheduler/cronjob/...)
EDIT: also there seems to be no backchannel for Capslock, OSX is using caps lock as "per" device. (connecting two apple keyboards and Turing caps lock on, doesn't turn it on on the second one.)
This is already filed as bug in #168.
To use LED based "keyboard up detection" was the initial idea (P4wnP1 sends NUMLOCK or CAPSLOCK till it could read back a LED state change, to assure keyboard functionality is up / driver is ready).
Unfortunately this approach didn't worked out, as it ended in kernel ooops when keystrokes are sent before the target has loaded a keyboard driver (no timely IRQ response).
The way it works is to simply listen for ANY KIND of LED state change, before allowing keystroke injection. This works out nicely on windows (all keyboard LEDS are reset when a keyboard driver is installed), but unfortunately it doesn't on OSX. I have to investigate this, which needs to things I missing right now:
- A Mac (OSX in a VM obviously gave false results in testing)
- More time;-)
EDIT: also there seems to be no backchannel for Capslock, OSX is using caps lock as "per" device. (connecting two apple keyboards and Turing caps lock on, doesn't turn it on on the second one.)
This is a very useful hint, seems I have to come up with a new idea ... I am open for suggestions (please be aware of the fact that I can't bring up target OS detection on this level, I need a very general approach or have to introduce a payload option which doesn't rely on "keyboard up detection" for OSX)
I guess the valid quick fix would be to fire the "keyboard up event" based on a timer (RubberDucky like fashion), as fallback for OSX target.