The "guts" of USB

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of these days I am going to start on a rather unusual USB application using an ATMega88. I know it is easy to make the AVR act as a simple HID device and near impossible to make it host a HID device, but what I want to do is something in the middle of the two.

I want to transparently read keyboard data in order to store keystrokes. AKA... keylogger.

When I say transparently, I mean for the AVR to simply sniff out keyboard data and store the relevant info to an eeprom. I know there will be a LOT of traffic on the USB port, but there should be a way to just filter out keyboard data without having my device register as another HID. I think this is also called a USB sniffer of sorts.

I have a long way to go before starting on the hardware, but I think this can be done using some clever hacks and tricks. It may even be possible to use some other clock rate than the usual 12MHz since the "sniffer" will be searching for clock pulses, not trying to sync with them.

The PS2 keylogger took only a few hours to design and code, but i can imagine I have a bit to chew on this project.

Any thoughts?

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But surely you don't need this to be "serial"? But instead (as long as it doesn't disrupt the USB +/- signals) it can just be in parallel and watch for transitions on the data line like a scope or logic analyser.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you can make sure that your sniffer is placed downstream of just the keyboard and not downstream of any hubs, you don't have to filter out any data at all - it will be only the data to and from the keyboard! I would also recommend modifying VUSB to act in a purely sniffing role instead of making a pass-through device.

Math is cool.
jevinskie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Placing the logger in front of a hub, where it will see an aggregate of data is going to pose a difficult challenge, as you will need to know the device ID of device you want to log from. Whereas if you do as Jevin suggests, you know that only the one device exists, so you can simply parse the packets to interpret & log, the key-strokes.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even if you don't know the ID of the keyboard couldn't you observe aggregate data initially eliminating non-keyboard behavior devices and narrow down possible keyboards?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you were stuck with a hub between your target device and your sniffer, rather than adaptively deciding which packets are to be ignored, by judicious reconnection you could watch it enumerate and get its ID from that. But, as R. Nixon noted, it would be wrong.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it garantied, that a keyboard will operate
as slow-speed device ? If not you are probably
in trouble.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting ideas.

Seems like the "easiest" method would be to have it install between the keyboard plug and computer like conventional PS2 loggers that look like some kind of RF filter.

I also figured the device would have to "listen" and narrow down the keyboard by looking for "keyboard like" data. Keyboard data should be unique... small bursts of data happening at typical typing rates.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

small bursts of data

But tricky with an AVR if those bursts happen to be at 480MHz - the point being made above.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rwcjunglist wrote:
Even if you don't know the ID of the keyboard couldn't you observe aggregate data initially eliminating non-keyboard behavior devices and narrow down possible keyboards?

Possibly, but how do you plan on establishing what is keyboard data and what isn't? This would require stateful packet inspection of all data. [at least for a period of time]

ossi wrote:
Is it garantied, that a keyboard will operate
as slow-speed device ? If not you are probably
in trouble.

No it isn't guaranteed, but it is highly likely that it will be low speed device.

AtomicZombie wrote:
Seems like the "easiest" method would be to have it install between the keyboard plug and computer like conventional PS2 loggers that look like some kind of RF filter.

I'm starting to have issues with this thread as your motives appear to be illegal acquisition of data not educational or research. Had it been either of the latter you wouldn't care what the device looked like.

As such... I'm out!

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My motives are just entertainment really. I did a book for McGraw Hill entitled "101 Spy Gadgets For The Evil genius" that included a PIC based PS2 keylogger and thought I might update it to USB and AVR just for fun and release it on my website as open source.

I do like my spy toys. kind of a strange hobby I guess. Good thing I did not mention my "Laser listener"... now that gadget is some real fun!

Brad

glitch wrote:

I'm starting to have issues with this thread as your motives appear to be illegal acquisition of data not educational or research. Had it been either of the latter you wouldn't care what the device looked like.
As such... I'm out!

I Like to Build Stuff : http://www.AtomicZombie.com