Let's say for instance I have some USB devices I suspect of being programmed for to execute keystroke injection. If I were to load a live OS and switch it to runlevel 1, then logged into an unpriviledged user and ran a text editor like nano before plugging one of the devices in, would this be a good way to catch a keystroke injection attempt and see what it's typing?

Are there any keystroke combinations useful for or used in keystroke injection that might make it past this?

  • 2
    Control keys will "make it past" the text editor. Like Alt-Tab .... – schroeder Sep 24 '19 at 6:36
  • 3
    As @schroeder says a text editor probably ain't optimal, but the idea is good. I use screenkey a lot (mostly for testing keyboards though), that shows almost everything, but requires X to be running, so there are downsides, and probably ways around it. – Henrik supports the community Sep 24 '19 at 9:00
  • @schroeder Hi. Thanks for answering. Correct me if I'm wrong, but in the example of running nano in runlevel 1, unless either Ctrl+o -> Ctrl+x or Ctrl+x -> y -> ENTER were keyed in in those exact sequences, nano keeps running, no new shell or terminal is opened, and whatever subsequent keystrokes(barring control keys) injected are displayed in nano anyway. Am I correct in assuming switching to runlevel 1 will block any other possible avenues for commands to be typed in and executed? – user942937 Sep 26 '19 at 1:02

I suggest you to use a virtual system to make a separate lab to test that drive. After that you can check the system log, and look for modified parameters, as recently executed commands. Besides, you should see the actual keystroke injections, if there are any. You also should have access to the drive, am I right? Try to disassembly, and look for a microSD card. That way - if it is really a bad usb/rubber ducky/malduino - you can read the payload directly from the microSD card.


If the USB Mass Storage device has been reprogrammed as a "BadUSB," like a Rubber Ducky or Bash Bunny, it may mount as a serial device when connected. If that happens (check Device Manager -- I'm assuming you are in Windows) load up Putty, set it to Serial, and enter the Serial line of the device (COM#) and baud speed that the device communicates at (typically 9600 or 115200). If there is any output, you will see it in the putty session screen.

Also, check the Hardware Ids in the properties of the Mass Storage Device to find out the vendor and device ID, then google that info to find out if the controller's chipset is a Phison 2303, which is what would be needed to "easily" (I'm using this term loosely) create a BadUSB. If the controller's chipset is different, then it would be doubtful that your USB controller's firmware would have been reprogrammed, unless you are a high value target, like a nation-state VIP.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.