I’m developing a PLANK and the necessary firmware to enable sniffing of PS/2, USB Low-Speed, and Full-Speed with Bus Pirate. I’m adapting two of my existing projects for this.
The Plank features:
2 USB connectors for sniffing
2 PS/2 connectors for sniffing
Any ideas or suggestions?
I expect to have everything ready in about a month, and I’ll be posting updates here!
For the PS2 version, I would use the opposite PS/2 gender to connect directly to the PS2->USB cable, without the extra adapter cable. That may reduce some of the weird stuff you observed decoding it. Getting the breadboard out the equation will probably also help.
Had a quick look and could not find the other gender (not sure what to call it) PS/2 connector in PCB mount.
Btw, the glitches and weird stuff are caused by bad-designed-adapters, not by the cable / breadboard / setup (tested on the final okhi keyboard implant, with short traces → direct solder and everything properly done).
After one year++ of testing every PS/2-to-USB adapter on the market and trying out every motherboard with PS/2 connectors from my friends and cybercoffee (yes, they still exist!), my PIO-based PS/2 implementation works perfectly. So, glitches & weird stuff is not problem (I hope).
Even things that the Saleae decoder misses (bad adapters), my PIO-based PS/2 implementation processes correctly!. The glitches & weird stuff don’t affect the keyboard’s functionality, and the operating system processes everything correctly, it’s only a problem for the “attacker” / logic analyzer.
it was hilarious to see the cybercoffee owners’ faces when I walked in with my PS2 keyboards, sniffing boards, keyboard implants, logic analyzer… and started connecting everything
Building things for the real world use is sometimes a pain, and unexpected things always happen. On paper, it seemed much easier!
I prefer to use generic components at first and avoid inventing too many custom hw-phys-cable-solutions. If there’s a lot of interest in this later, we can iterate and improve.
@ian If after a few years someone wants one, and we’re the only ones making that cable, what will happen?
The DIN connector housings are pretty common, and come from Aliexpress, etc. Similar to some of the adapter boards you use. It isn’t as plug and play, I get that.
Another option is a simple M:M short adapter cable used with an existing 1M:2F Y cable.
This would be an interesting option for a combined plank with only a USB A port for input, but these seem rare enough that the PCB mount DIN connector is probably the better option.
Yep, all in the same Plank, but the order of IO matters, and I need keep some free BIO (order of free also matters) for internal PIO stuff.
I want to use different BIO conn-track for each protocol, keeping the tracks short, etc.
Let me build a first prototype at home, and once I have it working, I’ll let you know what I think is best.
I don’t like designing everything just in my head.
Why + USB-C? I want it to be TRACK CONNECTOR → BIO (short and direct).
If they want to use a different type of USB, they can just buy a cheap
USB-A->C adapter.
I want to keep my code as close as possible to the Bus Pirate fork to make it easier to maintain and less prone to human-git-cherry-pick-error. So I’ll design the Plank with this in mind.
By the way, let’s make (as command line option) the Bus Pirate able to power the +5V VCC of PS/2 + pull-ups, so users can connect a keyboard directly and sniff PS/2 without needing to connect the keyboard to a PC.
The good thing about a PS/2 keyboard is that is super simple protocol and it generates the clock signal itself, making it super easy to act as a PS/2 host. USB, on the other hand, is a pain.
They could even control the Bus Pirate with the PS/2 keyboard.
I’m going to start porting the firmware. The way I’ve wired it, everything should work fine (I HOPE).
I’ve secured it with hot glue (paranoic mode) so nothing comes loose / break because I’m heading to a “cybersecurity” conference today, and I’m bringing it along to program it there, it’s going to “suffer” a lot of handling.
The soldering and overall build are pretty rough, but it’s good enough to test everything.
I left the wires a bit long to have some flexibility in case I need to reconnect them to another BIO.
It looks pretty rough, doesn’t it?
I’m bringing a mini soldering iron, desoldering wick, and some solder, just in case!
I love the male-pins with colored plastic, this way, I can instantly tell which one is VCC and which one is GND without labeling anything!
Since both PS/2 and USB use 5V VCC, the VCC rail is shared.
btw, @ian I added a red LED (VCC–GND) and a switch to connect it to the VCC->VCC OUT of the Bus Pirate.
Do you think it’s worth adding resistors for impedance matching on USB signals?
I don’t use them (sometimes) in my hardware implants because there’s no space. Remember: we’re only supporting sniffing: USB Low-Speed and Full-Speed (12 MHz).
Do you think it’s worth adding a capacitor between VCC → GND?
Considering this will be used with keyboards with LEDs that draw up to ~500mA (crazy trend), plus various other USB devices, do you have any ideas to improve the final Plank design?
(Aside from the usual USB best practices like keeping the tracks short and close, symmetrical, etc.)
I don’t think additional USB resistors are needed if we’re just tapping into the signals. There should already be some on the DUT.
Assuming the power for the keyboard is coming from the PC end (normally, I understand you can also power PS/2 from Bus Pirate without a PC, that is just the standard W command) I don’t think a cap is needed. It don’t think it would hurt either.
For what it’s worth, I still think a USB C out to the PC would be handy and almost no extra cost. I don’t carry USB B cables, but I usually have a c cable to charge my phone.
In terms of availability, I will make some prototypes for testing and we can take it from there.
I concur with ian that there is no need for them on the plank because the host and device both already have them.
The trace between the plank and the BusPirate will create a small wire stub that creates some reflections. One could improve this by placing a buffer IC on the plank. But I don’t think this is really an issue for low speed and full speed USB up to 12 MBit/s.
The BusPirate itself doesn’t have a lot of capacitance on Vout because that would negatively effect some use cases. So when you want to power something from the BusPirate, like the keyboard, it doesn’t hurt to add some if you have some space left on the PCB.
Take for example 2 or 3 Samsung CL21A226MAYNNNE in parallel and you should be good.
But powering a keyboard that needs like 500 mA from the BusPirate won’t work either way. But I guess this is just an issue with modern keyboards full with blinky LEDs and these will be USB and not PS/2. So powering a PS/2 keyboard from the BP should work.
Regarding other improvements to your plank design - do you have published schematics somewhere in Kicad or PDF format? Then I can take a look.
yeah, USB1 is not very picky on that topic. did worse stuff with jumper cables and branchoff to a microcontroler to wiggle some chip pins to get it into debug mode where it enabled USB to talk with it
I mentioned it in case someone later wanted to use it as a USB “OTG-LIKE-HOST” (using PIO or something) on those pins.
I was thinking of something crazy… for example, being able to send commands to a BP through a USB keyboard.
The PS/2 keyboard can use the Bus Pirate as a PS/2 host without any issues…
That’s why I brought up the power consumption, etc.
Nice! thx, @ian Do you take this into account along with the manual VCC switch?
I just wanted to avoid a USB data track running from the PC to the Plank, then from the Plank to the target device, while also to one USB connector + another USB connector + and the BIO pins… And there are the USB cables in between as well.
But just add it and that’s it!
@electronic_eel Give me a few days to propose the best BIO order … I want to run tests, make sure everything works, and ensure easy maintenance. After that, @ian can design the Plank, and we can review everything before manufacturing.
Thanks, everyone, for your comments!
This community is amazing, and every day I learn something new just by reading your discussions!
Good luck!
