Whatever system you are using, if it is having some sort of data input interface, an external power supply and potentially a connection to the net – it can be hacked. Period.
What I describe here is a simple method to circumvent most protective means, let these be software or hardware-based ones. It needs no code to run on the system and consequently there is no defense against it (alas, there is some, all based on the multi-layered virtualization of machines). Mostly used on the x86 architect, but it has derivatives on all widespread systems.
It is no other than tinkered keyboards and/or mouses. Once these are connected to a system they act like normal peripherals (for example by identifying itself as an Intellimouse (0x03) upon the GetDeviceID (0xF2) command), only these are having some extras. The extras are some custom algorithms, which are directing the collection efforts that these devices are designed to be capable of.
There are two families of these that I know of, the first family is called ‘Impetus’, which is now a perhaps discontinued line. These were using the serial PS/2 (6-pin mini-DIN) connector and there were pointer devices and keyboards of this line, used together in most cases. These were built into legit peripheral hardware.
The collection of data with the ‘Impetus’ devices is rather crude. It is done by recording a set of commands sent by the device to the host controller over a longer period, calculating the necessary commands to be sent when the pointer (in the case of a mouse) is in the initial position (this is when after the power-up there is no user input for a set number of clock cycles) to open programs via moving the pointer and clicking on the desktop icons, then highlight text, copy it, opening the email client, sending the text, etc. Of course the actions are visible to anyone in front of the screen, but as it is done using the default ‘Set Sample Rate’ (e.g. 100 samples/second) at the default ‘Set Resolution’ value (a resolution of 4 counts/millimeters), the predetermined pointer movements are seen as a sole momentary vibration.
These actions are directed by an extended EPROM. The ‘Impetus’ was developed over the PS/2 protocol mainly because it is the same protocol that had been used by the so-called ‘AT keyboards’ as well – so the ‘Impetus’ was able to control the most important input vectors once these were physically connected to a system. In the case of the mouse, it used the ‘Reset’ (0xFF) command received on start-up to enter its own collection mode rather than to run the Basic Assurance Test that would have been the norm. ‘Impetus’ is able to count clock cycles after the host controller sends the ‘Enable Data Reporting’ (0xF4) command in the stream mode, thus it can guess after a set number of clock cycles (that the mouse generates and not the host controller)that the user is not around the computer. Also it has some sniffing capabilities by recording and evaluating wrap mode echoes – and by recording all counters instead of resetting. Later versions of the ‘Impetus’ mice and keyboards have a built-in emulation capability of the start-up communication between the host and the peripherals, which needs something like 25 command & report line pairs.
The ‘Impetus’ keyboards were using the same PS/2 protocol, but these were actually either keystroke recorders (using an extra built-in power supply and a memory capable of holding the last n keystrokes) or the necessary means to help out a broader action by reporting given keystrokes once a given sequence of commands are arriving from the host controller (like 4 in a row of ‘Resend’ (0xFE) or ‘Set/Reset Indicators’ (0xED) followed by a specific argument byte to switch the CapsLock LED for example).
The ‘Impetus’ devices were manufactured somewhere in Europe, starting in 1990, by some suddenly jobless experts. Very soon, however they found their way back in to state organizations. The first models were created in a high school lab, but later on the manufacturing moved to a clandestine site. A few hundred of these might be completed in at least a dozen variations but I have no information regarding their possible uses. According to someone involved in making these the project was abandoned with the wide scale availability of the USB peripherals in the early 2000s.
Errr, the project wasn’t actually abandoned, but was replaced by a newer one aimed at fooling systems by tinkering with USB peripherals. So, the modus operandi remained, only the tools changed.
This new family of tinkered hardware is called ‘Harpoon’ – because of the resemblance of the USB trident logo to a harpoon. The ‘Harpoon’ family is still developing and is based on the many possibilities the Universal Serial Bus standards represent. The first steps were to created devices that are able to report multiple Device Descriptor values and could act accordingly. In other words it could now be externally a mouse, a keyboard, a flash memory stick, or both in a Bluetooth package, a webcam or whatnot. Anything that has a USB connector, that is. Their initial capabilities included the ability to measure window sizes, locate interaction fields (using mouse events), creatively using the possibilities of text storage on the clipboard, the use of power supply modes for sniffing purposes, etc. but now it evolved into a huge system encompassing custom zero day-driven codes, stolen or generated certificates, botnets to liaise between the controllers and the target systems, etc. Since it is a method that is being used one can’t tell what are the capabilities of the latest models. But it ain’t necessary to know that. They all still masquerade themselves as either mouses or keyboards during the POST period after power on, or after being hotplugged into a system already running its OS.
Starting from the 1960s a race started to gather intelligence trough recording keystrokes at places where some secretive was typed. The early attempts already bore fruit – just remember that the Soviets successfully used such hardware against US diplomats already in the 1970s, by physically installing devices fed by the own electric supply of the Selectric II & III electric typewriters. These bugs transmitted the logged data over to a transmitter located a few hundred meters away.
In the 1990s and the 2000s, most endeavors in this field were directed towards developing software solutions. These solutions were constantly evolved for example to be able to:
By the last few years the vulnerability / threat intel / anti-virus industry developed a symbiosis with the threat actors by following a timeline of:
-
identifying faulty codes,
-
understanding the vulnerability,
-
building an exploit,
-
selecting or making a payload,
-
targeting the desired target,
-
finding it,
-
naming it,
-
publishing it,
-
forcing vendors to patch the vulnerability,
-
and having the story shredded in the past as newer vulnerabilities emerge.
But some techniques were never intended to follow these guidelines. And these techniques are the custom-built tools that are targeting specific persons or institutions.
It is imperative to recite the first sentence of this writing: Whatever system you are using, if it is having some sort of data input interface, an external power supply and potentially a connection to the net – it can be hacked. Period.
And: What you have to bear in mind is that actual hacking is not doing something that everyone does, actual hacking is doing something that no one does.
Be the first to comment on "The hack-anything mouse & keyboard combo"