Let's say I've got a generic, cheap mouse.

It's a USB-device. Any USB-device may contain memory, so how to know if the manufacturer didn't embed any memory with malware software in a device? (on Linux preferably)

  • 1
    Having memory is not the problem. Having malware in memory is not the problem. Executing the malware in the mouse's memory is the problem. How would it get executed? Typically through a BadUSB type attack. And we have tons and tons of questions about that.
    – schroeder
    Commented Apr 14, 2020 at 21:29
  • @schroeder thank you for the hint. But I think everybody understand that a memory isn't a problem... Fleas isn't a problem, the problem is having them on yourself. I mentioned memory in case if somebody would ask: how do you think mouse can do that?
    – R S
    Commented Apr 14, 2020 at 21:49
  • 1
    Devices like mice have had memory for a long time: to store device drivers and vendor software to install.
    – schroeder
    Commented Apr 14, 2020 at 21:54

3 Answers 3


Watching your system and kernel log seem appropriate.

  • On linux:

    tail -f /var/log/kern.log /var/log/syslog

    before inserting device, then look output when inserting USB device... Care to stay watching for some minutes after plug.

When USB device is plugged, logs show what kind of device is recognized. Required drivers will be loaded, if needed.

  • If usb storage is recognized as a network devices, holding a full network, with upnp servers, who send automatically media. This could be something harmful.

  • If device trig your system to load many different drivers, when they are only simple storage device, this look abnormal.

  • If device trig your system to load only one driver, corresponding to device purpose, this look fine (Nota: A cheap mouse won't require specific driver!! If yes, this could look suspicious).

You even could use lsusb before and after plug USB device, then look for differences. (Do this in a second console, while watching your logs as previously recommended)

  • On linux:

    lsusb >lsusb-before.txt

    Plug device

    lsusb  | diff lsusb-before.txt -

About your cheap mouse: If you see two devices: one mouse and one data storage, containing mouse driver, this could be ok, but if the mouse won't work on your system and you decide to install embed driver, you will do this at your own risk!!

But care!

Some bad device, like USB Killer v3, could burn your hardware at time they are plugged!!!

When plugged into a device, the USB Killer rapidly charges its capacitors from the USB power lines. When the device is charged, -200VDC is discharged over the data lines of the host device. This charge/discharge cycle is repeated many times per second, until the USB Killer is removed.

Addendum: Little reflexion about Failure to detect malicious functions does not prove their absence. and comment from user10216038:

Yes: I could imaging such malicious device:

  • When plugged, the cheap mouse is registered as a standard mouse device, but
  • They embed a strong malicious process, waiting for february 29th at 03:00 AM for
    • Generate a pseudo keyboard, hitting something like Ctrl+Alt+F2, then root and brute force password, for finally encrypt whole /home (even run at 3AM, brute force may take a lot of time with 3 try every 5 minutes... This may become visible) or
    • Generate a strong virtual network with media server who trig upnp service to send malicious drivers for pseudo media files...

Some murderer take seconds, other take minutes, some murderer take hours, now this murderer take years!


  • All this seem very hard and expensive to create, require strongly experienced programmer (team)!

  • You have to use weak password (better if malicious device already know your password) or you have to enable upnp and accept automatic installation of drivers and networks.

  • But if you keep regular backups, saving syslogs too, and use read-only devices on critical hosts, with remote syslog,

at time the malicious process begin, they will be logged anyway and I think they will have poor chance to harm correctly protected system.

So yes this could be an issue, but very expensive for targeting home desktop without regular protections, with a very small chance to success.

Again and again

  • Keep your backups up to date, on many different devices! (Make tests and verification against your backups)

  • Don't use weak password!!!

  • Disable automatic services like upnp on sensible hosts!


You cannot scan a device until you have access to it's storage or memory.

Ideally, USB/IoT devices comprise of flash based microcontrollers. In other cases, let's assume there's some sort of processing and storage entity present in them. In either case, the manufacturer certainly has an ability to backdoor the USB peripheral and it can achieved in the following ways:

  1. Malicious software inside USB peripheral.
  2. Malicious hardware inside USB peripheral.

In any case, this topic is not of interest unless it can steal your information and communicate it back to them (manufacturer) or cause some kind of harm to you or your computer.

If it was to harm you, you would have known it by now. In rest of the cases, it will have to communicate to your computer system to cause harm. The device can communicate via: 1. USB Cable 2. Bluetooth 3. NFC 4. Wifi 6. some "xyz" medium. Let's use a blanket term "channel" for them. Now, USB manufacturer can accomplish it's goal to cause harm (or steal information) in following ways:

  1. Using a malicious device driver. (USB driver for Widows) [SOFTWARE]
  2. Using a malicious device software for operating system. [SOFTWARE]
  3. Using a malicious device firmware. [SOFTWARE/HARDWARE]

For 1, USB manufacturer always has option to provide custom driver for USB peripheral instead of using a generic Windows USB driver. USB manufacturer can not choose to auto-install custom driver unless it is WHQL certified. Obtaining this certification, considering the fact that device software itself is malicious, is highly unlikely. In all other cases, it will have to exclusively ask for user permission in the form of a UAC prompt to install driver. Once installed, the driver will be loaded into the memory. This can solved if your antivirus solution supports scanning memory for both user and kernel space.

For 2, all device user software is usually checked for malware by anti-virus solutions. You can double check to be sure about your anti-virus solution.

For 3, the device firmware will interact with windows operating system based on the standard windows APIs. In order to exploit this behavior, it will have to find vulnerability in standard/windows software or the "channel" itself. This is highly unlikely but if this is the case, then trust me, Microsoft is in a bigger fix than you.

In any way, I know you do realize that above trouble can be avoided just by choosing a trusted vendor or manufacturer for the USB peripheral.

You might also would want to consider the possibility in which attackers can actually break into your system because of a security vulnerability in the manufacturer software. Here, the manufacturer does not necessarily need have a malicious intent. This kind of attack would mostly likely be the case if you get hacked because of a USB peripheral.


You can't!

At best you can discover that it is malicious or has other unintended functions.

Failure to detect malicious functions does not prove their absence.

  • 1
    I didn't get you. First, you said that I can't, then that at best I can.
    – R S
    Commented Apr 14, 2020 at 21:33
  • 3
    @R S - You asked if you can check if a device is NOT malicious, you cannot. You may detect that a device IS malicious, but absence of proof is not proof of absence. Fundamentals of Logic Commented Apr 15, 2020 at 3:06
  • what the difference between check and detect? No questions about absence and proof.
    – R S
    Commented Apr 15, 2020 at 11:59
  • @R S - Perhaps Wikipedia can explain it to you: en.wikipedia.org/wiki/… Commented Apr 15, 2020 at 16:00
  • 3
    @R S - F.Hauri answered how you might detect malicious, not your original question. Let's try a simple example: Suppose that there is a malicious function present that only activates at 3am Feb 29. Unless you happen to test then, you see nothing. Commented Apr 16, 2020 at 17:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .