It doesn’t have buckling springs, Cherry blues, or even the wonderful if forgotten Alps switches, but the keyboard found in ThinkPads has the best keyboard action of any laptop around. They would make a great USB conversion keyboard, but the board to board connector is very hard to find, and no one has yet managed to get the keyboard and track point working as a USB HID device. Until [rampadc] came along, that is.
[Rampadc]’s keyboard adapter is built for the ThinkPad T60 keyboard, which is shared between the Lenovo T60, T61, Z60, Z61, R400, R500, T400, T500, and X41 laptops, among many others. The connector is an extremely odd proprietary deal, that can be found through the usual channels for about $5 in quantity 100. On top of this, the keyboard doesn’t have a controller – that’s offloaded to the laptop’s main board. The only electronics in this keyboard is just a matrix. Despite all this, [rampadc] managed to create a breakout board with a decade counter and an SPI GPIO expander.
The board [rampadc] made features one of the proprietary connectors, a few chips, and a receptacle for an Arduino Micro. With just a little bit of code, the old keyboard becomes one of the best portable keyboards in existence, and probably a bit cheaper than the official Lenovo USB-bound ThinkPad keyboard.
[rampadc] has a few of the expansion boards available over on Tindie should you want to build your own. It’s only cost-effective if you have one of these T60 keyboards sitting around in a junk pile; not a likely situation because these machines just don’t die.
Continue reading “Using A ThinkPad Keyboard Over USB”
Like many of us, I’m sure, [Nick] doesn’t like digging around behind his computer case for a spare USB port and ended up buying a small USB hub for his desk. The hub worked perfectly, but then [Nick] realized an Ethernet port would be a nice addition. And a DC power supply. Then feature creep set in.
What [Nick] ended up building is a monstrosity of a desk hub with two 24V, 5V, 3.3V 50 Watt DC outputs on banana plugs, a five-port USB hub, four-port Ethernet switch, three mains sockets, 32 digital I/Os, UART, SPI, and I2C ports, a 24×4 LCD or displaying DC current usage and serial input, cooling fans, and a buzzer just or kicks.
The case is constructed out of 6mm laser cut acrylic, and the electronics are admittedly a bit messy. That said, this box does seem very useful and even plays the theme from Mario Brothers, as seen in the video below.
Continue reading “Overengineering A USB Hub”
Moore’s law is the observation that, over the history of computing hardware, the number of transistors on integrated circuits doubles approximately every two years. This rapid advancement is certainly great for computing power and the advent of better technology but it does have one drawback; otherwise great working hardware becomes outdated and unusable. [Dave] likes his flight simulators and his old flight sim equipment. The only problem is that his new-fangled computer doesn’t have DA15 or DE9 inputs to interface with his controllers. Not being one to let something like this get him down, [Dave] set out to build his own microcontroller-based interface module. He calls it the Multijoy_Retro.
Continue reading “Multijoy_Retro Connects Your ‘Wayback’ to your ‘Machine’”
After reading an April Fools joke we fell for, [Mortimer] decided to replicate this project that turns the common USB mouse into a powerful tool that can bring down corporations and governments. Actually, he just gave himself one-click access to Hackaday, but that’s just as good.
The guts of this modified mouse are pretty simple; the left click, right click, and wheel click of the mouse are wired up to three pins on an Arduino Pro Micro. The USB port of the ‘duino is configured as a USB HID device and has the ability to send keyboard commands in response to any input on the mouse.
Right now, [Mortimer] has this mouse configured that when the left click button is pressed, it highlights the address bar of his browser and types in http://www.hackaday.com. Not quite as subversive as reading extremely small codes printed on a mousepad with the optical sensor, but enough to build upon this project and do some serious damage to a computer.
Video of [Mort]’s mouse below.
Continue reading “A Real Malware In A Mouse”
Keyloggers, in both hardware and software forms, have been around for a long, long time. More devious keyloggers are smart enough to ‘type’ commands into a computer and install Trojans, back doors, and other really nasty stuff. What about mice, though? Surely there’s no way the humble USB mouse could become an avenue of attack for some crazy security shenanigans, right?
As it turns out, yes, breaking into a computer with nothing but a USB mouse is possible. The folks over at CT Magazine, the preeminent German computer rag, have made the Trojan mouse (German, terrible Google translation)
The only input a mouse receives are button presses, scroll wheel ticks, and the view from a tiny, crappy camera embedded in the base. The build reads this camera with an Arduino, and when a certain pattern of gray and grayer pixels appear, it triggers a command to download a file from the Internet. From there, and from a security standpoint, Bob’s your uncle.
Looking through the camera inside a mouse is nothing new; it’s been done over the Internet and turned into the worst scanner ever made. Still, being able to process that image data and do something with it is very cool. Just don’t accept mouse pads from strangers.
Danke [Ianmcmill] for the tip.
[Wyager] was shopping around for a mechanical keyboard, and after noticing custom PCB manufacturing had come down in price so much, he decided to build his own. The end result is a keyboard that’s so elegant in its design, that it could, with a little work, become a very interesting Kickstarter project.
The design had three requirements: cheap, mechanical switches, and extremely customizable. The cheap requirement was solved by splitting the keyboard into two parts with a master/slave arrangement. The boards are connected by a 1/8″ TRRS jack conveying an I2C bus. Since both boards are identical except for the code running on the Teensy dev boards, [Wyager] saved a bit of cash by using two of the three PCBs that came with his OSHPark order.
The mechanical switches – Cherry MX Blues – are rather expensive parts for a failed project. For fear of failure, [Wyager] first ordered a PCB containing the footprint of only one key. With the footprint correct, he graduated to a 2×2 matrix. Once that was verified, the 6×5 matrix was ordered. Everything worked perfectly the first time, something we can’t say about many of our projects.
The code, board files, and schematics are available over on the github
[Craig Heffner] has been busy with his Linksys WRT120N router. When we last checked in on [Craig] he had reverse engineered the obfuscation techniques used in the router’s firmware. Since then, he’s re-enabled JTAG, cracked the “encryption” used for saving configuration backups, and now he’s devised a simple attack to change the admin password. With the firmware unlocked, [Craig] went after the hardware JTAG. His first hurdle was a missing jumper connecting the TDI pin to the processor. With a solder blob making the connection, he then found the router would connect to his JTAG debugger, and immediately reset. TDI had been re-used as a GPIO in software, and assigned to the reset button on the back of the router. [Craig’s] JTAG pod was pulling the pin low and causing the reset. To make matters worse, the bootloader also redefined and checked for the reset button. If the button were pressed it would boot into a recovery mode. [Craig] patched the bootloader with a little help from IDA pro. He then desoldered the router’s flash and programmed it outside the system. The firmware required a similar patch. Rather than desolder the flash chip again, [Craig] created a firmware update the router would accept and flashed it via the router’s web interface.
Since he already was deep into the Linksys Firmware, [Craig] looked for any obvious attack vectors. He found a big one in the /cgi/tmUnBlock.cgi. Inside the firmware, the URL sent to the CGI would be sent through sprintf(). In plain english, it means that no input length checking was happening – so a URL longer than the firmware engineers expected (in this case 256 bytes) would overflow into areas of memory it wasn’t supposed to – in this case, the stack. For an astute attacker, that’s a wide open door. [Craig] was able to use find some Return Oriented Programming (ROP) gadgets and created an input value that would cause the router to reset its own administrator password. After running the exploit, a quick trip to the router’s webpage proved his attack was successful.
If that wasn’t enough, [Craig] also spent some time looking at the patches to the router’s firmware. The release notes of one of the patches mentioned encrypting configuration files. The WRT120N, like many routers, allows the owner to download and save the configuration as a file. It turned out that the “encryption” scheme was nothing more than an exclusive OR with 0xFF. A pretty weak encryption scheme by any standards. To [Craig] we send our congratulations. To the WRT120N software engineers, we’d suggest taking one of [Craig’s] embedded device exploitation classes.