[Lain]

Okay I lied.
I'm not actually using an Arduino board this time.
Why?
Because they're bulky. 
And if you're going to try to do something questionable that might end up pissing off the person you're doing it to, then you want to be as discreet as possible, and fitting a MEGA2560 to the back of someone's computer isn't really the way to go about that.

Note:
This is a Work-In-Progress, basically a project journal that I'll be updating hopefully over the next week until I have a working prototype.
When it's complete, it'll probably look a lot more like my hash-cracking guide in terms of formatting and style.
For now, these are all ideas that I have in my head on how it will work and how I'm going to make it work.

So, without further ado, let's get into it.

Keyloggers:
What is a keylogger?
The short answer is, something that logs all the keys you press on your computer, in an attempt to grab sensitive data that might be unobtainable by any other means, due to encryption and whatnot. You might grab someone's email password and screw their life up from there, or maybe you just want to see what kind of 'videos' they watch in their downtime. 

Typically, keyloggers are pieces of software that just run silently in the background. The only problem with this is that antiviruses exist and keylogger detection rates are pretty high nowadays if you don't have code-signing certificates or driver-level execution. Both are relatively hard to pull off, so keyloggers aren't as popular as they used to be.

Background:
A couple years ago, one of my internet friends (in the security field) was recruiting people involved in electronics manufacturing and embedded development to come up with an undisclosed product. A year later, he came out with a Hardware Keylogger, with a nice shopify site and everything.

The cost was probably what a Rubber Ducky from Hak5 costs, about 50$ or so, and as we all know, Hak5 products are scams if you have the capability to make them yourself. I mean, you can basically create a Rubber Ducky using a 1$ digispark which already comes with a USB connector anyway so it's more or less just as discreet (if you're willing to 3D print a case for it or something to make it look like a normal USB drive.)

So, that got me thinking if there was a way for me to also recreate that product for 50x less cost and a little elbow grease. In the spirit of cyberpunks being hi-tech lowlifes, and without wanting to give up my hard-earned dollars on something I can probably make myself, I came up with the general idea of what the device did.
But, as that was years ago before I actually got decently good at embedded development, I put it off for a while.

So here I am now, with the general planning done and the materials acquired (rather, they were sitting around gathering dust and I figured I should probably put them to use and make something cool.) Here they are:

• 1 x Teensy 2.0 (AtMEGA32u4 16MHz)
  
• 1 x Female USB header/connector/port
  

Very minimal.

I had USB headers lying around from that time I got increasingly paranoid about public charging stations and wanted to make myself some USB condoms. Still haven't gotten around to it though because I'm scared of breaking everything while soldering, even though it's probably the easiest thing to make. Maybe sometime in the Summer when I can take my soldering iron outside or into the garage without freezing to death so I don't carbon monoxide myself from the flux fumes.

Now, the Teensy (by PJRC but primarily sold by Adafruit) isn't exactly the cheapest device you can get, sitting at around 16$USD + shipping, but I snagged one on AliExpress a while ago for about 7$ and free shipping, so I'm still keeping the price at bay by being about 5-6x cheaper.

USB headers are pennies each, but you usually need to buy 5 minimum or something so it'll be a dollar (way cheaper in bulk, but how many times are you going to have to resolder a USB port?)

So under 10$. Not bad.


USB 3.0
When I received my USB3.0 ports, I had no idea how to use them.
This is because typical USB3.0 ports you buy have a generic pinout on the back.
See here:



Note how all the connectors on the back are basically aligned nicely?
Mine looks more like this:



Except directly on the back, not the bottom.
But, in short, five on top, four on the bottom.

Code:

X X X X X
 X X X X

And every visual pinout picture I saw online only looked like this:


No good. I didn't want to short everything on day one and screw up my boards, so I decided to 'verify' which pins connected to which, uh, err, pins?
So, I used a little bit of brute force and ripped one of the ports apart:


And sure enough, the four on the bottom turned out to be the ones I was most interested in, VCC, GND, D-, D+

The header still works, I guess, but I probably won't be using it in this case unless I really need to to save space.

Side Notes: Why only those four pins?

Those pins are universal in the USB standard. All the way from the first USB devices to the new ones, those four pins are present, and are still the most commonly used for everything from serial communication, PS/2 or RS232 emulation, etc.

To ensure that devices would work with older hardware, most peripherals like keyboards and mice will transmit most of their data over these pins, using the D+ and D- pins.
The power pin is, to, well, power the device being connected. That should be self explanatory, and if I need to explain what GND is used for you might want to look up how electricity works first.

How is it going to work?
Like this, I hope:

The main idea is that the keyboard connected to the computer (a USB device) will first send its data to the Teensy which will read and store the data, then the Teensy will also forward the data to the computer with (hopefully) minimal interruption or delay.

Now, if you're familiar with Arduino programming, you're about to say that doing keyboard operations is pretty hard or downright impossible with most Arduino devices.
The keyword is MOST.
The Teensy uses the AtMEGA32u4 which does actually support keyboard emulation to an extent. I'm not too sure about all the pitfalls and benefits of using Keyboard.h, but it's possible on the 32u4 at the very least. We'll see how it goes later on, maybe I'll need to make a modification to allow function keys or holding keys.

Who knows, maybe it'll be perfect out of the box. I know people use the Teensy to build custom keyboards so there's hope in the statement.

So this is probably going to eat my free time for the next week or so. 
I'll be writing everything in Arduino's language if I can help it because I don't feel comfortable enough writing C and using avrdude or butterfly or whatever the 32u4 compiler/uploader is called. I'd be rewriting my hash cracker before I try to write this.

Since I don't have actual headers on this Teensy board (never got around to soldering, again) I might need to pick up the iron later on. Would have been way easier to prototype with the use of some F-F dupont jumpers, but who knows.

[Lain]

First update:

I decided that I don't want to do too much soldering if I'm just prototyping and it's the middle of Winter in Canada. Don't want to freeze to death if something breaks and I need to resolder, so I decided to freeze to death today to save it for later.

I soldered the (broken/brute-forced) USB header to some wires, and soldered some headers to the back of the Teensy which contains the VCC, GND, and two digital pins so that I could prototype with a breadboard.

Schematic (Fritzing):


Image:


And then I plugged in a microUSB STM32 NUCLEO32 F303 device to test if it was soldered correctly. I connected the data pins to nothing and just wired up VCC and GND to the Teensy, to ensure that the Teensy alone was powering the device:


Success!

---

While researching a bit more, I found one kinda big tradeoff for using the Teensy 2.0 which was changed in 3.6(++) and the new Teensy 4 (which I want to get my hands on, it's 600MHz and full 32bit! Embedded Linux NOW!)
It can only use 3.3V power. If you feed it 5V or more, it'll fry the chip.
Negligible for out use-case, probably, but if you plug it into a keyboard that needs 5V (think: fancy gaming keyboards with all the lightning and features) then it'll probably kill the device.
But, in an office setting, most keyboards are pretty basic so there will be no issues there.

[Darth-Apple]

It must be... cold in Canada...

What exactly are the alternative pins used for nowadays? Are they a USB 3.0 addon or a USB 2.0 addon? Very nice post by the way!

[Lain]

It must be... cold in Canada...

What exactly are the alternative pins used for nowadays? Are they a USB 3.0 addon or a USB 2.0 addon? Very nice post by the way!

-20C isn't too bad unless there's lots of wind, but when you can't wear gloves for the sake of precision (i.e. soldering) it's pretty bad and almost makes you want to just grab the iron to warm up your fingers a bit :/

If by alternative you mean the other 5 pins, one is a second ground pin (the middle one of the five,) and on each side is a separate data stream channel, RX/TX.
I always thought one of the extra five pins was for more power, like for fast-charge devices but I guess that's not the case and they exist solely for faster data transfers, like copying over my entire music library in under an hour to a new drive.

And yeah, those five were new to USB3.0. USB 1, 1.1, 2.0 all had just the four pins, although USB2 for some reason was able to support faster transfer speeds and more power and current, but that was probably because of the technology on the other side of the port.

[Darth-Apple]

Technology has gotten more precise over the years. You can transmit quite a bit of data over just a single serial wire. They've more or less figured out how to encode quite a bit of data accurately. In the USB 1.0 days, not so much...

That's interesting that they added five pins for USB 3.0. I suppose that USB 3 devices then must have to have a mode where they can send their data using only the original four wires (for backwards compatibility purposes), and only use the extra wires if they detect that they are running on a USB 3 port.

[Lain]

Technology has gotten more precise over the years. You can transmit quite a bit of data over just a single serial wire. They've more or less figured out how to encode quite a bit of data accurately. In the USB 1.0 days, not so much...

That's interesting that they added five pins for USB 3.0. I suppose that USB 3 devices then must have to have a mode where they can send their data using only the original four wires (for backwards compatibility purposes), and only use the extra wires if they detect that they are running on a USB 3 port.

Yeah, it's a nice conveinence not needing to buy all-new hardware to fit your USB ports.
Mom got herself a MacBook recently and was pissed off that all it has are two USB-C ports on the side. I'll have to get her a USB hub sometime, seen some decent ones on Amazon that I could probably get for free

But buying the headers as 3.0 or 2.0 had absolutely no significant impact on the final cost of everything, so I figured I should just pick up the 3.0s instead if I want to try making some fast-charge USB condom for my phone. Have yet to get around to that, I'm just hoping that fast-charging doesn't only work if the SSRX/SSTX pins are connected because that involves more soldering and the entire point of it is that the data pins are shorted to stop unwanted data transfer. More research needed.

[Darth Makestation]

Figure it out? Oh did you now?

TypeError: Unable to cast to type $mybb->String in showthread.php, line 39.

[Lain]

Update 2:
The ground pin on the USB header broke off because I suck at soldering.
To be fair, I use a really cheap (<10$) iron from china with a really thick tip that somehow makes the flux flow upwards on the tip somehow.
I need to just invest in a heat gun and some paste, smh. Probably exponentially safer to use indoors as well.

So instead I decided to start playing around with the programming part of things.
First, I want to make sure that the Teensy can actually send keystrokes, so I hooked up my breadboard with a pushbutton and used the builtin LED on the board to make sure that I was writing my pushbutton logic correctly (d*** pullup resistors always screw with me.)

That worked, using pins 10 and 11 (the corner pins that I attached the headers to.)
So now that I had pushbutton logic, now I need keyboard logic. I don't actually need to import anything fancy, luckily:

Code:

void setup() {
    pinMode(10, INPUT_PULLUP);
}

void loop() {
    if(!digitalRead(10) == HIGH) {
        Keyboard.print('a');
    }
}

My one gripe is that it was a little too fast.
At least now I have a cool autoclicker or I can fill up a megabyte of 'a''s in under a minute by literally holding down a button.

So, now that keyboard logic works, I should start setting up the rest of the board for general logic I'm just going to need to implement later anyway.

Code:

char *keyBuffer;
void setup(){
    keyBuffer = (char *) malloc(2048);
    pinMode(10, INPUT_PULLUP);
}

void loop() {
    input.readAvailableBytes(keyBuffer, 32) //Generic, haven't figured out the USB interfacing part.
    if(keyBuffer){
        for(int i = 0; i < 2048; ++i) {
            Keyboard.print(keyBuffer[i])
        }
    }
}

That won't compile. Don't try.
It's also going to be ridiculously slow for that loop. I'll come up with a better solution, since malloc() returns a pointer to the allocated memory, so maybe I could make a function that returns the pointer + 1 for iterating over each byte, and the readAvailable() or whatever can also write to memory that way as well.
I wonder if Arduino supports lambdas, might be a good opportunity to practice...

The important part is that I need to store keyboard data somewhere, and simple local variable memory (and flash memory) simply isn't enough. I need to be using malloc() to directly make some space in RAM instead. I mean, I have 256KB available there, might as well use a bit of it.

Realistically, that's going to be prone to change. If you unplug the device, you lose the data in RAM. You can't access it any other way than, like, using the serial monitor or something. I'll need to find a way to connect a microSD to the device and write to a file.

---

So after some more review of tech specs, I was wrong about the power issue. Teensy 2.0 does in fact support 5V. No worries about shorting and frying. Only the 3.1 and LC had the 3.3V limit.

I've also been researching how I could connect a USB device and be able to interpret it. Teensy does actually have separate serial channels available as another built-in, full UART control (USB without the annoying/bulky port) so maybe I could try to make use of that.
Unfortunately that would also mean more soldering...

So I won't be adding a microSD card to this, as I don't have a shield for it surprisingly enough. That could be one of your own mods if you decide to make this (or at the very least until I get the funding I need for New Breakthroughs in Technology™ ).

I have keyboard output working, now it's time for interfacing.

[Lain]

Update 3: No Time to Freeze Edition.
I resoldered GND and it's 100x more sturdy this time.
I reckon it breaks so much because I use basically 100% tin so it's pretty weak for joints. Need to get something a little heavier. Touched up the other joints as well because I got this one done really quick.
Shouldn't have any more issues with breaking.

I also managed to get a keyboard connected, more on that next time.
The thing is I've hit a major roadblock. I've tested two keyboards and both of them power on for a good second or so, then immediately turn off until I pull out the power pin and out it back in, then repeat.
I figured it might be a voltage issue, so I added a 100 Ohm resistor and instead it would turn on for half a second, blink, then turn back off. So voltage isn't the issue.
I suspect the problem is the current passed through the device. From the tech specs on PJRC's site, the Teensy can output a maximum of 27.something mA. Most USB keyboards need at least 30, and in some cases 55.

That would explain why it shuts off after a second, once it realizes there's not enough current to power it properly.
So I've plugged the F303 NUCLEO board in one of the pictures in Update 1 in hopes that it'll have enough current. I mean, the STM32 pulls 300mA from the USB port.
Teensy 2.0 doesn't support 3.3V, before you ask. The STM32 does, but I might have issues because the digital IO pins on this board are hardly 5V tolerant and 3.3v is recommended, whereas keyboards might want 5V.

Bleh, electronics should just be standardized.

Edit:
I also have the option of just pulling whatever the Teensy needs from the USB if I want to do some more soldering.
Not exactly an ideal solution but it would certainly work since USB2/3 ports can push up to 900mA.

[SpookyZalost]

@Lain, have you considered running a bodge wire/jumper wire between the input from the USB port going into the teensy, and the output going to the keyboard, thus side stepping needing the power from the arduino?

it would also allow you to remain the small form factor and only need the one cable.

effectively wire the input/output power and the teensy power in series thus not having the current pass through the device.

[Lain]

@Lain, have you considered running a bodge wire/jumper wire between the input from the USB port going into the teensy, and the output going to the keyboard, thus side stepping needing the power from the arduino?

it would also allow you to remain the small form factor and only need the one cable.

effectively wire the input/output power and the teensy power in series thus not having the current pass through the device.

Yeah I mentioned that in the edit.I'm gonna see if I can get something working with the F303, though, and test more with USB power.
If all else fails, that'll be the last hope.

Next edit:
Guess that didn't work. Seems that the Nucleo32 has the same mA output (ballpark range, ofc.) since I get the same issue.
Someone online mentioned that when using a logic analyzer, they also encountered that the keyboard would send 0xAA every 0.6sec, which would indicated the BAT power success from the PS/2 protocol.
Too bad logic analyzers are too f*** expensive for hobbyists like me.

But of course it could very well be the same issue I'm having. Or maybe it's that the keyboard shuts itself off after failing to interface with whatever it's connecting to.
This has been helpful so far: https://www.avrfreaks.net/sites/default/...yboard.pdf

[Lain]

Update 4: One more before I need to get back to doing my course work Edition

Seems that power might not actually be the issue.
I think the keyboard is turning itself off because of its inability to communicate properly with the device.
I really need a logic analyzer for this, might see if any friends have access to one at the university so they can let me in to the lab (clandestinely) so I can poke around.
Swapping around D+ and D- pins (for Data and IRQ, because IRQ handles the clock as the differential/parity signal) makes it start blinking every second or so, turning the keyboard on and off.

I've tried this on both a backlit keyboard as well as an older one that only has lights on the Num/Caps/Scroll lock keys to verify this, and they all turn on briefly when the keyboard is plugged in.
And no, the keyboards aren't faulty, I've connected both to my computer just fine.

There are a bunch of PS2 libraries around online that I've been able to play around with and none of them seem to work properly according to examples and schematics when I wire them up (and of course swap D+/D- pins in case I have them backwards.)

Generally people try this with the Arduino Uno so I dug out my Uno (the first MCU I ever got as a Christmas gift from parents) to test it out and also no luck.
None of the LEDs on the board dim down when I plug the device in, so it's not drawing too much power or anything. They were when I was plugging the keyboard into the Teensy, though.

I'll put this project on hold for now until I can get a proper USB Host shield (with U(S)ART support).
Time to go shopping.