Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

One way to detect hardware keyloggers Other Hardware
Hardware keylogging devices create serious issues for all security-conscious computer users. A hardware keylogger is a small, inconspicuous USB device that can be hot-plugged into any computer between the keyboard and the host controller. Some actually function as USB hubs that can be connected anywhere in the bus. A keylogger may be physically indistinguishable from a USB extension cable or some other innocuous device. Once installed, it automatically begins to capture all keystrokes into its internal NVRAM, which may be up to 2MB in capacity. The device is completely self-contained and platform independent, needing no software to operate apart from its own firmware. It works just as well on a Mac as on a Windows box.

The weakness of the hardware keylogger, at least the kind that's available on the open market, is that it's not remotely accessible. The attacker who installed it has to return to retrieve the device or the data. Therefore, if you detect the keylogger before the attacker comes back for it, you can defeat the attack. Physical detection isn't reliable, because as noted above the device may look just like a component you already have, such as an extension cable, or may be hidden inside a keyboard enclosure or out of sight behind a desktop computer. What you need is some sort of warning that the topology of the USB bus has changed unexpectedly.

While there is no perfect solution to this problem, it's easy to take a first step that will eliminate most of the threat. The POSIX utility system_profiler is the command-line equivalent of the System Profiler application that runs when you select "About This Mac" from the Apple menu, and click the "More Info..." button in the resulting dialog. The advantage of system_profiler is that it allows finer control over the output.

In a Terminal window, type or paste the following command:
system_profiler SPUSBDataType
When you press Return, you'll see a descriptive list of all USB devices connected to the host. It's the same information you get from System Profiler by selecting Hardware » USB. Save this output to a file with this command:
system_profiler SPUSBDataType > ~/.usb
This creates an invisible file named .usb at the root level of your home directory; you can change the name or the path to anything you like. Now suppose you come back to your Mac after it's been out of your sight for a while. Run the following command:
system_profiler SPUSBDataType | diff ~/.usb -
This will give you the difference, if any, between the saved state of the USB buses and their present state. (Note that the BSD package must be installed for this to work. It's installed by default in Mac OS X 10.4.x, but not in earlier versions.) If a USB device has been added or removed, you'll know. If there's no good reason for such a change to have taken place in your absence, you can investigate further.

Instead of having to retype these commands every time, you can use Automator to create a saved workflow, or the freeware CLIX to create a pallette of saved POSIX commands. You will, of course, have to re-save the state of your USB buses whenever you make an intentional change, such as adding a storage device or replacing a mouse.

[robg adds: As best as I can recall, the BSD Subsystem has always been installed by default (though it can be disabled) -- certainly at least since the days of 10.1; someone please feel free to correct me if I'm wrong.]
    •    
  • Currently 2.25 / 5
  You rated: 3 / 5 (8 votes cast)
 
[50,714 views]  

One way to detect hardware keyloggers | 21 comments | Create New Account
Click here to return to the 'One way to detect hardware keyloggers' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Another method
Authored by: pub3abn on Sep 14, '07 09:46:34AM

The method above sounds adequate for techie types. I propose the following alternate method:

1. Buy a cat. This also necessitates cat food, litter box, etc., to meet said cat's needs. The cat must be installed at the same facility as the computer, and with access to the computer at will.

2. Spray the computer keyboard with catnip scent, and optionally decorate the keyboard and surrounding area with items likely to attract the kitty.

3. While away from your computer, switch to an application that can accept random input without harm to your system or files. Leave the keyboard out in the open.

While you are out, the kitty will play on your keyboard, filling up the memory buffer of any USB intercept device that may be present. Eventually the memory of the device will be full of complete nonsense keystrokes, thus rendering it useless to the perpetrator.



[ Reply to This | # ]
Another method
Authored by: thomaschina03 on Sep 14, '07 11:13:34AM

I suspect techies and non-techies alike will find this method a bit hariy.



[ Reply to This | # ]
Another method
Authored by: rmessnerjr on Sep 14, '07 01:34:04PM

Of course, if the cat fails to walk on the keyboard that may necessitate a CAT SCAN.

sorry...so sorry...

---
RalphM



[ Reply to This | # ]
Automator version
Authored by: hamarkus on Sep 14, '07 11:34:42AM

Cool. Works fine at the command line. Tried to put it into Automator. Used 'Run Shell Script' and 'View results'. Runs fine as long as there is nothing to report. If something is reported, the 'Workflow Execution Failed'? Any idea why?



[ Reply to This | # ]
Automator version
Authored by: lincd0 on Sep 14, '07 05:00:07PM

Probably because diff returns a non-zero exit status if a difference is found between its arguments. Try adding || true to the end of the command.

[ Reply to This | # ]

Reboots
Authored by: lincd0 on Sep 14, '07 05:13:14PM

When you reboot, the USB devices may be enumerated in a different order than before, even though nothing has changed. I'm not sure why this happens, but it does. You may therefore get a false positive, in the sense that the post-reboot state will be different from the pre-reboot state. However, it shouldn't be too hard to verify that you have the same list of devices in a different order.

If someone wanted to write a Perl or Python script to fix this, it would be a nice contribution.

[ Reply to This | # ]

Reboots
Authored by: sweth on Sep 15, '07 01:50:56PM
As long as you don't care about the PCI version numbers and the like, you can just use
system_profiler SPUSBDataType | perl -ne '/^s{8}w/ && print' | sort
and you should get a list of attached devices that stays stable across reboots (assuming Apple doesn't change the formatting of the output of system_profiler in a new revision).

[ Reply to This | # ]
Reboots
Authored by: lincd0 on Sep 15, '07 02:28:00PM

I thought of doing something like that, but with sed instead of perl. What I'd really like, though, is to take the output of system_profiler as a plist (with the -xml option) and parse that to create a searchable database of known USB devices. Then you could add and remove those devices without raising a false alarm. You can read the plist output with defaults.

[ Reply to This | # ]

ARD Task Server ???
Authored by: rbsandkam on Sep 14, '07 08:49:55PM

Off the top of my head, I am thinking that this could be combined with ARD Task Server, to have daily changes of reporting clients emailed to an administrator.
Unfortunately, I have not yet actually worked with an ARD Task Server.
Can anyone confirm or deny that this would actually be possible?

If yes, it could be huge for large installations, such as an educational institution.
As it stands, our only defense is making physical inspections of lab computers on a periodic basis (which is hardly effective unless periodic means every day).
Obviously, you will receive false positives when scanners are moved from one lab computer to another.
But, the benefits of this possibility would far outway the extra emails.
Any thoughts?



[ Reply to This | # ]
One way to detect hardware keyloggers
Authored by: drmacnut on Sep 15, '07 01:43:53AM

@robg "As best as I can recall, the BSD Subsystem has always been installed by default...since the days of 10.1…."

That has been true since 10.4 (Tiger); but previous OS X installs required one to choose "Customize…" in the OS installer to add the BSD subsystem.

Personally, I am glad it's now installed by default.



[ Reply to This | # ]
One way to detect hardware keyloggers
Authored by: Fairly on Sep 15, '07 02:55:14PM

A snip above the usual fare. Kudos to the author.



[ Reply to This | # ]
One way to detect hardware keyloggers
Authored by: Fairly on Sep 15, '07 02:59:14PM

I'd add that after publishing this it's perhaps best to save the profile in an off-system location behind an authentication or burn it to a CD-R where it can't later be tampered with.



[ Reply to This | # ]
Does this really work?
Authored by: robophilosopher on Sep 15, '07 08:49:36PM

Has anybody tested this with an actual keylogger? It seems to me (disclaimer: I don't know much about the digital espionage business per se, but bear with me) that just because a keylogger needs no interaction with the computer, this technique won't work to detect an adequately designed device. Theoretically (and I wouldn't be surprised if practically) a keylogger can be a pass-through conductor, with the "device" bit independent of the main USB line. I would suspect that if the device doesn't have a USB ID or interact with the computer in any way, the computer won't see it. (For example, would this file change if you added a USB extension cord and left all else the same?)

If you were really dedicated, you might find a way to determine the small power consumption difference, but this is probably practically impossible to detect given the fluctuations going on in that system anyway.

Just the humble opinion of a physics undergrad student :-)



[ Reply to This | # ]
One way to detect hardware keyloggers
Authored by: lincd0 on Jul 09, '08 11:55:17AM

Since people still seem to be reading this hint, I'll update it with the scripts I now use to update and check the list of USB devices.

To create or update the saved state:

system_profiler SPUSBDataType | grep ID: | grep -v PCI | awk -F: '{ print $2 }' | paste -s -d '\t\n' - | sort > ~/.usb

Each line of the saved file has the hexadecimal product and vendor ID's of a device. To compare the current and saved states:

usb=$( system_profiler SPUSBDataType | grep ID: | grep -v PCI | awk -F: '{ print $2 }' | paste -s -d '\t\n' - | sort )
echo "$usb" | cmp -s ~/.usb - && exit
echo " Added\n\t Deleted\n"
echo "$usb" | comm -3 ~/.usb -

This produces no output if the current and saved states are the same. Otherwise, it prints a header, then the product and vendor ID's of each device that has been added or deleted. The lines representing deleted devices are indented.

[ Reply to This | # ]

Update for 10.5.6
Authored by: lincd0 on Dec 16, '08 09:42:55AM

system_profiler has changed in 10.5.6, and the above script no longer works. Now I use:

system_profiler SPUSBDataType | grep ID: | grep -v 'Location\|PCI' | cut -d: -f2 | paste -s -d '\t\n' - | sort > ~/.usb

to save the state, and

usb=$( system_profiler SPUSBDataType | grep ID: | grep -v 'Location\|PCI' | cut -d: -f2 | paste -s -d '\t\n' - | sort ) ; echo "$usb" | cmp -s ~/.usb - & echo " Added\n\t Deleted\n" ; echo "$usb" | comm -3 ~/.usb -

to compare.

[ Reply to This | # ]

One more update
Authored by: lincd0 on Sep 01, '09 06:41:00PM

Surprisingly, people are even now reading this two-year-old hint. So I'll offer one more update.

The question was raised in a comment as to how you can reduce false positives from known devices being moved around.

Below is part of the script I now use to check the USB buses. The value of the variable KNOWN is the path to a list of known USB devices that I use, identified by the vendor and device codes.

system_profiler SPUSBDataType | grep ID: | grep -v 'Location\|PCI' | cut -d: -f2 | paste -s -d '\t\n' - | sort | grep -v -f $KNOWN

The effect of this is that known devices are ignored. Only the presence of a previously unknown device will cause an alert. I create the $KNOWN file by running the above command with all devices plugged in and the last pipe omitted.

[ Reply to This | # ]

One more update
Authored by: lincd0 on Sep 01, '09 06:43:35PM

I'm still using 10.5. The script will probably have to changed slightly for 10.6.



[ Reply to This | # ]
every found a hardware keylogger
Authored by: alec kinnear on Jan 19, '10 06:21:38PM

This is a great technique for finding a hardware keylogger. Has anyone actually found such a device attached to their Mac via software inspection (or for that matter via hardware inspection).

I'd be a lot more worried about software keyloggers. I looked at all of them and there would be no issue in disguising the process name and running incognito at least in the case of the freeware and open source OS X keylogger logKext.

The only way to really secure a computer would appear to limit physical access to the machine. Still I'd love to hear some real life war stories.

---
Moving the world to freedom, one Typepad weblog to Wordpress at a time.


[ Reply to This | # ]
every found a hardware keylogger
Authored by: lincd0 on Feb 05, '10 11:25:57AM

You should have no expectation of privacy when using a computer of which you aren't the sole administrator. Never do any personal business on a public machine. Carry your own laptop or smart phone around.

For your own system, to be as secure as you can be from physical attack you have to use either whole-disk encryption or some sort of tripwire, with the ability to boot from a separate storage device such as a USB key to verify that the state of the device hasn't changed unexpectedly. Before PGP whole-disk encryption was available, I used mtree for this purpose, but it was awkward. Even PGP isn't completely safe, because of the Evil Maid attack (replacing the bootloader with a trojan.)

The real issue is not to defeat any possible attack, but to defeat the easy attacks. Hardware keyloggers are as easy as it gets, and not very easy to beat.



[ Reply to This | # ]
great advice
Authored by: alec kinnear on Feb 05, '10 11:36:33AM

but every time I've tried disk encryption I've ended up losing my data to disk corruption or some such thing.

physical security is important. i think the next step is to be careful what you write into a computer which ever touches the Internet or leaves home.

thanks for sharing your experiences though.

---
Moving the world to freedom, one Typepad weblog to Wordpress at a time.



[ Reply to This | # ]
What do do with these changes ?
Authored by: coccinaile on Sep 05, '11 04:30:55PM

I read your article and I used the command terminal and compared the results with a system profiler done last years. It's not good. First : I have now an Internal Memory Card Reader and a USB2.0 hub, both not mentioned last year. And some more changes too : the USB High-Speed Bus's PCI Device Id has changed. In fact last year there were two different High-Speed Bus, one apparently is gone. And the PCI Device Id of the USB Bus has also changed. So now : what do I do ?

Thanks



[ Reply to This | # ]