Extracting data with keyboard emulation

A common challenge for computer security specialists is getting data out of a very locked-down system. Of course all network traffic on these test machines is monitored, and burning a CD or writing to a USB Flash drive is out of the question. Where there’s a will there’s a way, so [András] figured out how to extract data from a computer by emulating a keyboard.

Emulating a USB HID device is nothing new; the newest Arduino can do it, as can any AVR with the help of V-USB. [András]’s build emulates a USB keyboard that can download data from a computer by listening to the NUM, CAPS and SCROLL lock LEDs.

Of course, [András] first needs an app to transmit data through these keyboard status LEDs. To do this, his build carries with it a Windows executable file on the AVR’s Flash memory. After plugging his device into the computer, it writes this program to disk and is then able to send data out through keyboard status LEDs.

It’s not very fast – just over one byte per second – but [András] did manage to extract data from a computer, circumventing just about every anti-leaking solution.

58 thoughts on “Extracting data with keyboard emulation”

This must have been a fun project. and will proboly be obsolete in a matter of weeks because it was posted.

an idea i had when reading it:
what if the usb “keyboard” first emulated as a removable device to transfer the program to the computer, so you only have to plug in one device. (how did you accomplish this feat? if it is done.)

I should also add, a single device can also present itself as multiple devices. So you can create a single device which appears as multiple USB drives, a webcam, a keyboard and a mouse all at the same time.

The problem is with the definition of “new”. If I already have physical access, I can probe the ID numbers of the “authorized” keyboard, program the device with the exact same IDs, and then reboot the PC with only my device connected. From the viewpoint of the OS, nothing’s going to change.

I wonder if you could create a device that sniffs a VGA connection (connects between video card and monitor), and use a program that encodes data over that connection…rather than using caps/num lights, you would have as many pixels as your program is able to fill in terms of bandwidth. capturing this output would be a bit more complicated, but the increase in bandwidth would be spectacular… say you had 512×512 pixels at 60hz and limited yourself to 1 bit on each channel (RGB) per refresh cycle (to be conservative.) That’s nearly 6MB/s if I’m not mistaken? I imagine you could do much better than that with a little more complexity in the capture hardware. You could probably also decrease the pixel density and capture this with a video camera, stabilize it and process it later. That said, it’s still fairly prohibitively difficult, time consuming, and a lot less inconspicuous than the original article.

Nice idea, but if your system is using UAC (which is anything later than XP) in any way, you won’t be able to write to c:\ without starting Notepad with admin privileges. In addition, the system will prompt the user to run the file since there won’t be a digital signature. Also, the binary data pasted into Notepad will be internally converted to whatever ASCII (or Unicode) page it’s using and be useless.

Now, assuming you could surmount all these hurdles, you could easily circumvent system security with Notepad.

I guess you could write to a .com instead (raw binary, no header) and limit yourself to typable ASCII characters. One you have a small binary running you can use it to bootstrap something larger or more useful.

user prompt is easy to get around with a hid device… assuming the system always behaves the same.

Most security pop-up’s have the users focus. If the action you want is selected by default, just hit enter, and it merrily continues, otherwise hit tab first for the other option, then hit enter and voila you now have permission…

As far as the computer is concerned a HID device is direct user input, so any action a human can do say on a keyboard the hid device can.

It doesn’t use Mass Storage, and the EXE can be typed in using Notepad. RTFA, and you’ll see, how binary content can be transferred onto the PC with a vanilla Windows install using VBS. ;) Also, admin privileges aren’t needed, since you don’t have to put the exe into c:\, it works perfectly in the user’s home directory as well.

I find this very interesting but at the same time vague, leaving too many questions here.

Like access to the machine if you have physical access to it am sure there are quicker ways to get the data. you are emulating a keyboard but how do you get that hardware next to this locked down machine to begin with. If a CD can’t even be used how do you switch out there keyboard for your own hardware in there. You do not need Administrator privi but yet you can install software……so its like a portable application doesnt require installation that part makes sense but if the system is truly locked down wont it notice the activity…. Meh this one is awesome but leaves too many variables to chance and uncertainty

You can connect the “keyboard”, because these solutions have to let you connect keyboards, otherwise, most systems are pretty unusable. As you mentioned, admin rights aren’t needed to install software, and running an EXE file is something that most systems like this allow, since they have the assumption, that they’ve covered every aspect of getting files into the computer.

I can easily prevent you from plugging in anything. I just need to put the system unit in a locked part of the desk. Only needs a small hole for the kvm cable to exit and some way of operating the power and reset buttons.

The only way to get around that would involve some form of vandalism, either destroying the desk or the cutting a cable and attaching your device to the wires inside.

I was just confused about how you would get the physical keyboard into a room with a secure computer but from your response I guess in this scenario the system doesn’t have that kind of physical security restriction. Cool hack though!

Seems someone else reads Neil Stephenson. His great work Cryptonomicon includes this very method of extracting data from a computer that is suspected of being observed via Van-Eck Phreaking.

Also to answer the physical access and locked down OS issues above, the program would not need to be installed if there was a leak to in the use of E3 USB devices or if the device plugged in describes itself as an HUD but needs a special driver that by chance is available on an included CD partition.

but you see that still leaves the question. How do you get access to the keyboard to have all that code inserted and when do you swap what they have for your device? after all if its a truly locked down computer would they not pay attention to the physical access as well or is it locked down only Os and software wise. not really locked down if its that

This works because you don’t need any special rights or drivers to access HID on the host computer. However a much faster way is to use SetFeature in the HID protocol to transmit packets of data to your HID device. It is still slow but I’ve managed a few hundred kb/sec a few years ago [1]. I kinda gave up on the project once I knew it was possible, which is a shame.

No, it doesn’t use Mass Storage, as it’s the first thing these DLP and other lockdown mechanisms block. It inputs the EXE file using keystrokes (see base64-decoder VBS solution in the post), then that EXE sends back the data using LED pulses on the keyboard. The device itself presents itself to the PC as a keyboard the whole time.

vsza, sorry I am little unclear about how the file is uploaded. I take it that a Visual Basic program is uploaded with the actual executable encoded in base64. When run, the VB program creates an exe file containing the actual exploit. But what I don’t understand is the sequence of events (or “keystrokes”) that must create a Visual Basic file and then execute it. I am unfamiliar with Windows at this level. Does every machine come with VB built in? Can you do what is essentially like a unix “cat” to a file?

The Visual Basic skeleton and the base64-encoded contents consist of printable (and thus, “keyboard-compatible”) characters, so it can be put into the built-in Windows Notepad application. The Visual Basic interpreter comes with a default Windows install, and is associated with every file that has the extension “.vbs”.

It strikes me that you might also be able to do a hack like this remotely for systems using wireless keyboards or mice. If my memory serves me correctly some of the proprietary radio protocols are unencrypted or have been cracked and they use off-the-shelf parts like Nordic transceivers. Maybe one could build a wireless gizmo that would emulate an existing wireless keyboard and attack a computer from a distance.

You can get a *lot* done in 64k of assembly. Entering binary data with the keyboard won’t work for many characters, such as 0x00. For high ASCII characters, it takes 3 keystrokes : ALT+[Key1Key2Key3]. With DEBUG, each byte is 2 or three characters [if leading 0 is included].

I don’t think you’ve understood the method of input. Binary data is entered base64-encoded, which contains only characters “A-Z a-z 0-9 + / =” (quotes excluded), so it can be typed in one keystroke. For example the bytes 0x14 0x42 0x98 are entered in debug.com as “14 42 98″ (9 characters), while base64-encoded it’s just “FEKY” (4 characters). So if debug.com limits me to 64k AND it requires >50% more keystrokes to enter data, I don’t see why it should be used for this purpose.

Yes, I absolutely understand base64 / MIME encoding [and have implemented encoding and decoding from scratch in several languages]. But, VBScript is more likely to be locked-down. DEBUG is a relic that will usually slip through the cracks.

In any case, I was simply contending that entering *binary* data in NOTEPAD wasn’t feasible. I wasn’t arguing about the efficiency of base64 encoding over hex encoding. Base64 is obviously more efficient from a key count perspective. Implementing your method in VBScript will certainly work well when supported [and the Msxml2.DOMDocument.3.0 automation interface is available on the target].

I was pointing to DEBUG as an option in response to @MarSik’s earlier NOTEPAD suggestion.

When I did it a few years ago you could do it without admin, that is how I achieved it. Haven’t tested it lately. Would be great for a next iteration of your device to go that route. The next step for me was to use a device which looked like a USB stick but had an AVR and MicroSD socket on board. You can get them for only a few dollars as they were often made for that PS3 hack.

Kudos to you for actually completing the project and writing it up – it is hard work and people often don’t appreciate that. Was a nice hack too.

Long time ago, I needed to program my first EPROM. (the famous chicken-and-egg problem of micro controllers). Not being aloud to connect anything up to my dad’s computer, I played with photo-resistors taped to the screen, but had too much noise from the CRT refresh rate. The solution was using the 3 keyboard LED’s to drive a shift register (data+clock) and the 3rd LED for the EPROM program pulse. To make sure the data LED was set before the clock LED was set, it took hours to program a few kB boot-loader into the EPROM. Dumping the EPROM data from the now working microcontroller showed one byte that was not programmed, which was easily fixed by re-programming that byte by hand.

FYI (as I’ve written in my presentation material as well) the same thing could be done with PS/2, the project doesn’t depend on any USB features, just the ones offered by the same keyboard features that PS/2 support.