I added one to the schematic.
3 Likes
Outstanding! Well done on getting this up and running so quickly!
2 Likes
the trigger PIN pull/up to VOUT instead of VDD (Remember that there are scenarios where the I/O buffers are at a different voltage than the board’s VDD—for example, in USB we might have 5V for VDD and 3.3V for the I/O buffers, slide switch must be used to disconnect VOUT from VDD in this scenario)external pins to add external power supply to plank
Working out some fine details for the next revision with @dreg
1- For ALL SCENARIOS: The trigger must always stay tied to Bus Pirate’s VREF_PIN
2- For ALL USB HOST SCENARIOS WE NEED EXTERNAL SUPPLY – 5V Plank’s VCC but 3v3 IO BUFF: We should add two 2.54 mm header pins (an external Plank’s VCC + GND supply) —or an extra USB-C connector (EXTERNAL PWR): , e.g., Host → a gaming-keyboard that draws up to 500 mA.
—
Option 0 - Keep the slide switch
DANGER: 5 V may hit the D+ and D− lines and the USB sniffer could stop working (the user forgets to move the slide switch, So Bus Pirate’s VREF_PIN is connected to Plank’s VCC)
—
Option 1 – Keep the slide switch + add a low-drop diode
Add an SS14 (or similar) diode in series with Bus Pirate’s VREF_PIN → Plank’s VCC. PS2 & USB Devices should still run at ≈ 4.7 V. The user can inject a solid 5 V through the external supply pins if 4.7 Plank’s VCC isn’t enough.
- Pros • Simple, In PS2 host mode, the slide switch plus the Bus Pirate can power the target device directly (with only the diode’s voltage drop).
- Cons • drop volt for USB & PS2 devices
—
Option 2 – Remove the slide switch altogether
Disconnect Bus Pirate’s VREF_PIN from Plank’s VCC. Forever
- Pros • Safest approach—IO reference is isolated, and the sniffer always works.
- Cons • In PS2 host mode, the target must be powered via the external PSU pins (like in ALL USB HOST SCENARIOS)
—
Option 3 – Keep the slide switch + replicate the Bus Pirate cut-off circuit ← Probably the best solution.
On the plank, duplicate the Bus Pirate’s backflow protection so Bus Pirate’s VREF_PIN is disconnected from Plank’s VCC whenever Plank’s VCC > Bus Pirate’s VREF_PIN – the cut-off will always happen in all USB Host & USB Device scenarios (because IO BUFF is 3v3).
- Pros • Safe and no diode drop. Even if the user forgets the slide switch, everything keeps working. In PS2 host mode, the slide switch plus the Bus Pirate can still power the target, and the USB sniffer always works.
- Cons • Requires more work, more complexity, and more components than simply adding an SS14.
| Bus Pirate | Mode | BPIO | VOUT | VEXT | SW1 POS |
|---|---|---|---|---|---|
| PS2 | Sniff | 5.0V | – | 5.0V | EXT |
| PS2 | Host | 5.0V | 5.0V | – | VOUT |
| USB | Sniff | 3.3V | 3.3V | 5.0V | EXT |
| USB | Host | 3.3V | 3.3V | ERR! | EXT + 5V external? |
So if I understand:
- If SW1 POS is VOUT and the board is setup as a USB sniffer: IO pins at 3.3volts, USB device and host cables connected
- The IO pins go to 5volts, which is out of USB spec (3.3volts).
This is a user error we are trying to prevent?
I looked at diodes quickly, not sure there is a cheap one that won’t drop too much voltage.
At 100mA at room temperature (lowest defined for this diode) the drop is already < 0.25volts. Would the PS2 host mode keyboard tolerate that?
ETA: can’t forget about the awful reverse current, especially at higher temperatures. This may still result in some higher voltage on the pins than expected.
This may be the best option. The BCM857BS is expensive, but we buy them in bulk already.
Normally I’d say the user should just be aware, but if we’re pumping 5volts into a laptop 3.3v usb line - I do think that is something to be concerned about.
Changes for the next version:
- The TRIGGER pin must be connected with a pull-up to the VOUT pin of the Bus Pirate, and after this connection, the cut-off protection should be placed.
- Add cut-off protection by copying the implementation used in the Bus Pirate itself.
- Add 2 pins for VCC + GND to allow the use of an external power supply when needed.
- Remove slide switch.
right @ian ?
1 Like
Schematic updated. I’ll sit on it for the night and then ask Supul to route it tomorrow if there are no other changes.
1 Like
So that everyone understands the current risk with the slide switch, a simple example:
If I configure an SPI mode at 3V on the Bus Pirate and suddenly 5V enters through the VOUT pin, the I/O buffers of the Bus Pirate will immediately start operating at 5V!
Look CS changes (3–>5) when I connect +5v to VOUT:
Whatever you previously configured (3v) doesn’t matter—whatever is connected to the Bus Pirate’s VOUT pin takes control!
That means Bus Pirate’s 10k-internal pull-ups + OUTPUT pins will be at +5V, and also, smaller voltages from +3V3 devices might no longer be recognized as a logic 1 (two problems).
This is exactly what we’re trying to prevent with the proposed changes—to avoid a scenario where the user accidentally leaves the SLIDE switch in a position that connects the +5V USB SOCKET to the Bus Pirate’s VOUT, causing the BIO pins to start running at +5V, with all the risks and issues that come with that.
If the sniffer or something else doesn’t work, that’s not a big deal—but sending +5V to the D+ and D− lines of the user’s PC definitely is.
But then why did you add the slide switch? in USB Host & Device it’s useless—since the BIO buffers run at 3.3V and you can’t use VOUT 3v3 to power USB devices. In USB Device mode, the +5V comes from the user’s PC, and in USB Host mode, we’d need an external power supply.
Well, it was useful for when the plank works as a PS2 Host, and you want to power, for example, a keyboard from the Bus Pirate’s VOUT at +5V (in that protocol the I/O lines also operate at +5V).
But with the cut-off circuit, we get the best of both worlds: You’ll only need external power in the case of USB Host mode (That’s why @ian just added two pins to allow connecting an external PSU)
1 Like
Test firmware is merged into the ps2_usb_sniffer branch, and I merged it with the latest main.
A PS2 to USB keyboard adapter should arrive in a moment, then I can start testing 
2 Likes
I am able to capture USB frames and see the buffer No idea what it means, I don’t know USB very well. The trigger doesn’t seem to work with my keyboard/setup, it hangs until I unplug the board. Do I need to enable some pull-up or something?
For some reason it didn’t occur that the silicon keyboard would actually type into my computer, caused much chaos 
Doh! I totally forgot about the male to male cable! I’ll have one shipped with rev1 of the plank. REV1 just went for assembly.
3 Likes
I’ve got the new plank at home now—did a quick and superficial test of the new cut-off circuit and it seems to behave as it should. The trigger is also where it needs to be. I’ll start testing and improving the firmware soon—thanks, @ian !
3 Likes
Nice! Mine hasn’t arrived yet 
1 Like
bp5_bp6_firm_usb2_ps2_v1.zip (1.1 MB)
I’ve taken a few weeks off to work on pending Bus Pirate things, which I’ve been procrastinating a lot on. Sorry @ian and the community for this. I’d like the plank to go on sale as soon as possible so you all can play with it, I think it’s a cool project.
Type (PS2 keyboard, menu->PS2->sniff): dre
Type (USB keyboard, menu->USB->sniff->‘k’): dreg
Key Trackers
Both the PS/2 and the USB sniffers decode raw bus traffic into keystrokes, but reading a scrolling dump of packets is not how you find out what somebody typed. The key tracker solves that: it is a running reconstruction of the typed text, rebuilt from the wire and reprinted every time a new key is resolved, so the transcript is always on screen next to the raw traffic that produced it.
Each mode keeps its own 320-byte tracker buffer. Characters are appended as they are decoded and the buffer is printed as a plain string between two ********** rules:
**********
key break tracker (limit 0x13F bytes): hello world
**********
The two implementations share that idea but arrive at it from opposite directions, because PS/2 and USB describe a keyboard in fundamentally different ways.
The PS/2 key tracker
A PS/2 keyboard is event-driven. It transmits a make code when a key goes down and a break code (the byte 0xF0, or the sequence 0xE0 0xF0 for extended keys) when it comes back up. The sniffer accumulates incoming bytes and matches them against a scan-code-set-2 table, holding off until exactly one entry matches the sequence so that multi-byte extended keys are never mistaken for the single-byte keys they begin with.
The important design decision is that the tracker records on key release, not on key press. This is why it is labelled the key break tracker. A key held down under typematic auto-repeat emits its make code over and over, which would flood the transcript with duplicated characters, but it emits exactly one break code when it is finally released. Recording the break gives you one character per physical keystroke, regardless of how long the key was held.
Only keys with a printable representation reach the buffer. Modifiers, function keys and navigation keys are shown in the packet log but deliberately left out of the transcript.
The USB key tracker
A low-speed USB keyboard does not announce events at all. The host polls it on a fixed interval, and the keyboard answers each poll with an 8-byte HID boot-protocol report that is a snapshot of the current state: byte 0 is a modifier bitmap, byte 1 is reserved, and bytes 2 through 7 hold the usage IDs of up to six keys being held down at that instant. Nothing in the report says “this key was just pressed”.
The tracker therefore has to derive events by comparing each report against the previous one. A usage ID that appears in the new report but was absent from the last one is a newly pressed key; anything present in both is simply still held and is ignored. This is the exact mirror image of the PS/2 approach: USB gives you state and you compute the transitions, PS/2 gives you transitions directly.
Characters are resolved from the HID Usage Tables, which are a completely different numbering scheme from PS/2 scan codes — usage 0x04 is a on USB, whereas 0x1C is a on PS/2. Shift is read from the modifier bitmap (either the left or the right bit), Caps Lock is tracked as a toggle when usage 0x39 is pressed, and the two combine the way a real keyboard does: letters are uppercased when shift and caps disagree, while non-letters take their shifted symbol only when shift is held. Named keys such as <ENTER>, <F5> or the arrows are printed in the packet log but, as on the PS/2 side, kept out of the transcript.
Practical notes and limits
The buffer is circular over 319 bytes, with the final byte always left as a terminator so the contents can be printed as a string. Once 319 characters have been captured, the tracker wraps and begins overwriting from the start without clearing, so a very long session will show newer text spliced over older text rather than a clean truncation. Treat the tracker as a live window on recent typing, and the raw packet log as the authoritative record.
Both trackers assume a US English layout, since they map codes straight to ASCII with no national keymap in between. A keyboard set to another layout will produce a transcript in which letters are broadly right but punctuation and symbols are not.
The USB tracker additionally requires a low-speed keyboard using the HID boot protocol, which covers the great majority of USB 1.1 keyboards. Full-speed devices and keyboards that only expose vendor-specific report descriptors are captured on the bus but will not be decoded into text.
PS2 SETUP
(PS2 KEYBOARD, PS2 MALE-MALE CABLE, AND PS2 TO USB ADAPTER):
Connect all 3 USB MALE cables exactly as you see them in the photo, directly into the PC. Do it exactly like this, doing it this way makes everything work correctly.
USB SETUP
(LOW SPEED USB KEYBOARD)
Connect all 2 USB MALE cables exactly as you see them in the photo, directly into the PC. Do it exactly like this, doing it this way makes everything work correctly.
Kane is using a fork of the USB keylogger code to display on screen what the Nintendo Switch controller is doing!
So as far as I’m concerned, I think the code is good enough to merge into main. @ian @mbrugman @henrygab & others can you test the firmware I uploaded in this post and give me feedback on the USB key tracker (make sure it’s low speed) and PS2 key tracker?
DOC PR:
CODE PR:
3 Likes
I got tired of testing this plank by hand, so I built a keyboard that types by itself: a Pro Micro on perfboard that takes TYPE hello over a 9600 baud serial line and types it into the target as a real keyboard, either low speed USB HID or bit-banged PS/2. It lines up nicely with what the plank needs, low speed by default, boot protocol by default, PS/2 scan code set 2, plus separate DOWN/UP and repeat counts so you can hit the typematic path the break-code tracker was designed for. Put it on the pass-through, script hours of known text, and diff what the key tracker rebuilt against what you actually sent. Last unattended run: 4,558 keystrokes, 22,389 bytes on the wire, 0 framing errors, 0 resends. One caveat, my firmware types in es-ES and both trackers assume US, so stick to a-z/0-9/space and the transcript comes out clean.
9 HID formats
NKRO
@mbrugman take a look AVR atmega32u4 CODE 
1 Like
DIY USB & PS/2 keyboard injector (FULL&LOW SPEED)
I’ll show you the sloppy mess I’m embarrassed about underneath… I did it in a rush without any care… long live signal integrity!
3 Likes
Wow… 9 HID format variations. That knowledge alone makes me want to build this.
Very nice, detailed instructions. Wish there were options to easily change to en-US (at compile-time, obviously), but … just … Wow! Nicely done!
1 Like
That’s very cool! The perfboard wiring looks fine - it’s a perfectly good way to prototype stuff and 100 times better than breadboarding.
Impressive USB and low level knowledge on display here!
1 Like
Your wishes are my command (BUT RUNTIME IMHO is better), done @henrygab ! It’s already in the repo. I’m genuinely glad you find it useful.
The idea is for the plank to support every possible keyboard in infinite loop sniffer mode with key tracker, that’s why I made it, so that over time I can keep refining the Bus Pirate firmware. If you think of anything else that would be useful, let me know.
I want users to be able to connect different modern keyboards to the plank (6KRO, NKRO…), as many as possible, and have everything just work automatically. We’ll see how far we can take it, I’ll keep expanding the HID injector to simulate more useful things…
NOTE: Why this exists, and why it is not a Rubber Ducky. The usual keystroke injectors, Rubber Ducky and friends, replay a script off a microSD card or over WiFi, and they are judged by one thing only: did the text land in the OS. This board is the opposite instrument. Here it does not matter whether the keys reach the operating system, it matters how they arrive on the wire: which of the nine HID report formats carries them, at low speed or full speed, with what polling interval, how long each key is held down, how big the gap between keys is, boot protocol or report protocol, 6KRO or NKRO, USB or PS/2. That is the whole point of the tool, fine grained control over exactly those details, so the USB sniffer can be pushed through every shape a real keyboard can take, one variable at a time.
2 Likes
Classic Hacker style :). my prototype wiring often looks similar. it just needs to work.
1 Like