Hardware Keylogger

[kirtcathey]

Don't jump into this too far without purchasing a USB node controller chip such as the USBN9604, or even better, the Viniculum chip. Putting the code together to interface an 18F2550 and a USBN9604, and will post later.

I've found this schematic that helped with the wire-up between an 18F2550 and a USBN9604.
<a href="http://www.massmind.org/images/www/hobby_elec/e_pic6_f1.htm">http://www.massmind.org/images/www/hobby_elec/e_pic6_f1.htm</a>

The way all is hooked up, I had assumed that communication would be via SPI, but now do not think so. I have read the USBN9604 data sheet (a couple times) and it appears that I need to send commands in order to receive data via microwire... versus just wait for SSPBUF to fill.

Does anybody have sample code for a PIC and USBN9604? Any language will be fine, but PBP would be even nicer.

Or, even a pointer as to what to use. Such as, would SPI work fine? Or, should I do a byte level shiftin and shiftout, with commands on the first two bits as described in the microwire section of the USBN9604 data sheet?

Any help is appreciated. The finalized USB key logger code with schematic will be posted back into this forum.

[magestik]

I can already tell you that any FTDI chip (Viniculum uses FTDI chips) are designed so that they are recognized as a USB device, it is their non reprogrammable firmware, so you won't be able to put this between a keyboard and a host, it will interfere and thus make the keyboard not working. I just bought a couple to try and use it, and contacted their tech support, which confirmed this

As for the other chip, USBN9604, i didn't look at it yet, but there is a good chance it works the same, therefore unusable for such applications.

[kirtcathey]

Well... the USBN9604 is working as expected - hosting a keyboard and passing on the signals. More details with a drawing within the next couple days. I am fairly certain that this (http://www.vinculum.com/prd_vnc1l.html) Vinculum chip will work as a host as well, since that is what we are using for hot-pluggable components that plug into a 16F877A.

Doh! I just re-read magestik's post above.... you mean that vinculum chip, while hosting USB, will also be recognized as a USB device by Windows? I just realized that the rig with the 877A mentioned above does not plug directly into a PC.

[magestik]

you mean that vinculum chip, while hosting USB, will also be recognized as a USB device by Windows?

That's right. All FTDI chips contains enumeration functions, so the chip, associated with a controller, will be recognized by windows, i tried it myself, therefore, if you plug it on the USB line of the keyboard, you will disconnect your keyboard, because of the presence of two devices for one line.

You can plug the chip + pic into a computer, as a USB device of its own, but you can't "monitor" an existing USB line with it.

I wonder if with the 18F4550, you can't just take off the enumeration function, and just use functions such as get_usb_packet().

[kirtcathey]

This is great timing. When this came across the forum, I was ready to purchase a couple of those Vinculum chips, thinking they would be easier to deal with than the USBN9604. One more question....

Even if you put the 18F2550/184550 between the vinculum and the PC this happens?

What I am doing with the 9604 is exactly that....
The keyboard plugs in and enumerates with the USBN9604, then as the user inputs keystrokes, this input is sent via microwire signal to the 18f2550, which is then sent to the PC that has enumerated the PIC as a keyboard and handles the PIC as a keyboard. Can you confirm that this is the way that the Vinculum is setup? Don't understand why the PC would be visible to the vinculum at all. Unless, it was in the circuit so that it connected directly to the host.

This is a big help. Thank you for sharing the experience.
--Kirt

Vinculum.... sounds like medicine. Doctor says, "Take two vinculum and call me later today."

[magestik]

The Vinculum contains all the enumeration protocol, whenever wherever you use the chip, it will appear as a USB device, so told me the FTDI support, which a verified unfortunately.

hmmm ok, i see, i'm not doing the exact same thing for the moment, i'm not trying to place the PIC between the line, but on the line, quite like this :



Could you post a quick schematics of your connections, like mine, so i can see better ?

If i understand well, you have :



Is that right ? Did you connect it and this works ?

I don't know if this could work, i don't know if the chip would enumerate with a keyboard, with the computer yes.

[kirtcathey]

Yes, the second drawing is what I am doing. Late last week in a forum exchange with Darrel and after some extensive research, we concluded that since USB is packet-based and such high speed, that filtering information on a tap-wire would be computationally impossible for a PIC. Even if computationally possible, writing the filter in program code would be like trying to write something to filter fiber connections.... possible, but....

Also, through connection analysis, we discovered first-hand that what comes across a tap-wire is just about everything on the bus except information that you're looking for.

I'll post a drawing and some complete code soon, but in the mean time, have a quick question. The USBN9604 has a microwire interface that we are trying to implement, instead of a parallel interface that is available. I have no experience programming for SPI, and am still new to PBP... but have coded quite a bit in MPASM. Attached is some rough code put together for this project. The code does no recording of keystrokes, it just takes one byte in from the USBN9604 and sends that byte out to the PIC USB connection.

The 9604 data sheet is here, which says that I have to send a read/write command before executing such read and writes. Also, it says, "1 cycle = 8 SK clocks. Data is transferred after the 8th SK of 1 cycle."

This is code that has been snipped from all over, then peppered with morsels fixing, then cut, replaced, and interrogated. I will not be able to test it on the PIC until tonight. But before that, can somebody take a look and critique?

What is the difference between hardware SPI and software SPI? I think my code might be a mix of both.... which probably will not work. In other words should I be observing SSPBUF for changes, or should I use an interrupt? Also, how do I tie the SPI interrupt to a particular pin? A solid code example or link to would be appreciated.

USBN9604 Data Sheet:
http://www.national.com/ds/US/USBN9604.pdf

Thanks all.