A few days ago, we saw a project that used a Teensy to build a Universal 2nd Factor (U2F) key. While this project was just an experiment in how to implement U2F on any ‘ol microcontroller, and the creator admitted it wasn’t very secure, the comments for that post said otherwise: “making your own thing is the ONLY way to be secure,” read the comments.
In a stunning turn of events, writing comments on a blog post doesn’t mean you know what you’re talking about. It turns out, to perform a security analysis of a system, you need to look at the code. Shocking, yes, but [makomk] took a good, hard look at the code and found it was horribly broken.
The critical error of the Teensy U2F key crypto is simply how U2F is performed. During authentication, the device sends the U2F key handle to whatever service is trying to authenticating it. Because the key in the Teensy implementation is only ‘encrypted’ with XOR, it only takes 256 signing requests to recover the private key.
The original experimentation with using the Teensy as a U2F key was an educational endeavor, and it was never meant to be used by anyone. The attack on this small lesson in security is interesting, though, and [makomk] wrote a proof of concept that demonstrates his attack. This could be used to perform attacks from a remote server, but hopefully that won’t happen, because the original code should never be used in the wild.
It used to be that you had to spend real money to get an alternative controller for your electronic musical arsenal. These days, with cheap microcontrollers and easily-accessible free software libraries, you can do something awesome for pocket change. But that doesn’t mean that you can’t make a sexy, functional piece of art along the way! [Jan Godde] did just that with his cleverly named Wooden Sensor Box With Two Rotary Disks. (If you’ve got a better name for this thing, toss it in the comments.)
From what we can see, the box has two potentiometer sliders, two touch-sensitive potentiometers, two force sensitive resistors, a slew of knobs, and a whole bunch of (capacitive?) touch points. In short, a ton of continuous controllers of all sizes and shapes in an aesthetic case. But stealing the show, and giving the device its name, are two platters from old hard drives that serve as jog wheels.
As shown in the video below the break, the two jog wheels are covered with alternating stripes on the underside. Each platter has a dedicated pair of IR LEDs and photodetectors underneath serving as a quadrature encoder that allows [Jan] to tell which direction the platters are rotating, and how far.
Continue reading “Two Turntables and No Microphone”
Last month, GitHub users were able to buy a special edition Universal 2nd Factor (U2F) security key for just five bucks. [Yohanes] bought two, but wondered if he could bring U2F to other microcontrolled devices. he ended up building a U2F key with a Teensy LC, and in the process brought U2F to the unwashed masses.
Universal 2nd Factor is exactly what it says on the tin: it doesn’t replace your password, but it does provide a little bit of extra verification to prove that the person logging into an account is indeed the person that should. Currently, Google (through Gmail and Google Drive), Github, Dropbox, and even WordPress (through a plugin) support U2F devices, so a tiny USB key that’s able to provide U2F is a very useful device.
After digging into the U2F specification [Yohanes] found the Teensy LC would be a perfect platform for experimentation. A U2F device is just a USB HID device, which the Teensy handles in spades. A handy library takes on ECC for both AVR and ARM platforms and [Yohanes’] finished U2F implementation is able to turn the Teensy LC into something GitHub was selling for $5.
It should be noted that doing anything related to security by yourself, with your own code is dumb and should not be considered secure. Additionally, [Yohanes] didn’t want to solder a button to his Teensy LC, so he implemented everything without a button press, which is also insecure. The ‘key handle’ is just XOR encryption with a fixed key, which is also insecure. Despite this, it’s still an interesting project and we’re happy [Yohanes] shared it with us.
Many moons ago, [Joe Grand] built an adapter that turns Atari 2600 joysticks to USB controllers. Now it’s open source.
Hackaday Overlord [Matt] is holding an SMT and BGA soldering workshop in San Francisco on October 4th. Teaching BGA soldering? Yes! He made a board where the BGA balls are connected to LEDs. Very, very clever.
Our ‘ol friend [Jeremey Cook] built a strandbeest out of MDF. It’s huge, heavy, about the size of a small car, and it doesn’t work. [Jeremy] has built beests before, but these were relatively small. The big MDF beest is having some problems with friction, and a tendency to shear along the joints. If anyone wants to fix this beest, give [Jeremy] a ring.
Everyone loves the Teensy, and [Paul] has released his latest design iteration. The Teensy 3.2 isn’t that much different from the Teensy 3.1; the bootloader has changed and now USB D+ and D- lines are broken out. Other than that, it’s just the latest iteration of the popular Teensy platform.
The DyIO is a pretty neat robotics controller, a semifinalist for the Hackaday Prize, and now a Kickstarter. The big win of the Kickstarter is an electronics board (with WiFi) that is able to control 24 servos for all your robotics needs.
[pighixxx] does illustrations of pinouts for popular electronics platforms. Everyone needs a hobby, I guess. He recently put together an illustration of the ESP8266. Neat stuff is hidden deep in this site.
You would not believe how much engineering goes into making snake oil. And then you need to do certifications!
[David] identified a problem, created a solution, got a patent, and is now manufacturing a product. The only problem is the name.
After the release of Mortal Kombat X, [Zachery’s] gaming group wanted to branch out into the fighter genre. They quickly learned that in order to maximize their experience, they would need a better controller than a standard gamepad. A keyboard wasn’t going to cut it either. They wanted a fight stick. These are large controllers that look very much like arcade fighting controls and include a joystick and large buttons. [Zachery’s] group decided to build their own fight stick for use with a PC.
[Zachery] based his build around the TeensyLC, which is a 32 bit development board with an ARM processor. It’s also compatible with Arduino. The original version of his project setup the controller as a HID, essentially emulating a keyboard. This worked for a while until they ran into compatibility issues with some games. [Zachery] learned that his controller was compatible with DirectInput, which has been deprecated. The new thing is Xinput, and it was going to require more work.
Using Xinput meant that [Zachery] could no longer use the generic Microsoft HID driver. Rather than write his own drivers, he decided to emulate the XBOX 360 controller. When the fight stick is plugged into the computer, it shows up as an XBOX 360 controller and Windows easily installs the pre-built driver. To perform the emulation, [Zachery] first had to set the VID and PID of the device to be identical to the XBOX controller. This is what allows the Microsoft driver to recognize the device.
Next, the device descriptor and configuration descriptor had to be added to the Teensy’s firmware. The device descriptor includes information such as USB version, device class, protocol, etc. The configuration descriptor includes additional information about the device configuration. [Zachery] used Microsoft Message Analyzer to pull the configuration descriptor from a real XBOX 360 controller, then used the same data in his own custom controller.
[Zachery] programmed the TeensyLC using the Arduino IDE. He ran into some trouble here because the IDE did not include the correct device type for an Xinput device. [Zachery] had to edit the boards.txt file and add three lines of code in order to add a new hardware device to the IDE’s menu. Several other files also had to be modified to make sure the compiler knew what an Xinput device type was. With all of that out of the way, [Zachery] was finally able to write the code for his controller.
[pmf], like most of us, I’m sure, spends most of his days on a computer. He also has a smartphone he keeps at his side, but over the years he’s grown accustomed to typing on a real keyboard. He came up with the idea of making a USB switch that would allow his keyboard to control either his computer or his phone, and hit upon a really neat way of doing it. He’s using a BeagleBone Black and a Teensy to switch his keyboard between his computer and his phone with just a press of a button.
This homebrew smart KVM uses a BeagleBone Black for most of the heavy lifting. A keyboard and mouse is connected to the USB host port of the BeagleBone, and the main computer is connected to the device port. The BeagleBone is set up to pass through the USB keyboard and mouse to the computer with the help of what Linux calls a ‘gadget’ driver. This required an update to the Linux 4.0 kernel.
With the BeagleBone capable of being a USB pass through device, the next challenge was sending keypresses to another USB device. For this, a Teensy 2.0 was connected to the UART of the BeagleBone. According to [pmf], this is one of the few examples of the Teensy serving as a composite USB device – sending both keyboard and mouse info.
There are a few neat features for [pmf]’s build: the keyboard and mouse don’t disconnect when switching, and thanks to a slight modification of the USB OTG adapter, this will also charge a phone as well as allow for the use of a keyboard. Because the BeagleBone Black has more than one UART this build can also switch keyboards and mice between more than two computers. For those of us who invest heavily in keyboards, it’s a godsend.
With Arduino library support on an ARM Cortex M4 processor, it’s no surprise that we’re fans of the Teensy 3.1. And lately, [Paul Stoffregen] has been building out the Audio Library for this platform, making it even more appealing to the synth / audio geeks among us. And now, with just the addition of a highfalutin LED and some software, the Teensy can output digital audio over optical fiber.
S/PDIF, and more specifically optical TOSLINK, uses LED light sent down an optical fiber to encode audio data. The advantage of this over any voltage-level signals (like with regular wires) is that the source and destination devices aren’t electrically connected at all, which gets rid of the dreaded ground loop hum and any RF interference.
An S/PDIF audio data stream is a bit complex, but if you’re interested [Micah Scott] has a fantastic dissection of it up on her blog. Of course, you don’t have to know anything about any of that to simply use S/PDIF with the Teensy Audio Library.
We love open source hardware and software because of the collaborations that make ultra-rapid development of niche stuff like this possible. You can follow along with the development of the Teensy’s S/PDIF capabilities on the PJRC forum. Contributor [Frank B] modestly claims that “everything was already on the internet”, but that doesn’t make it any less cool that they got from zero to working library in a few weeks. (And note the clever use of a precomputed lookup table for speed.)
On the hardware side, [Paul] has posted up his adapter board for a cheap, but very professional looking, optical TOSLINK sender. But if you’re feeling ghetto, you can simply use a red LED pointed just right into the optical cable.
The end result? Lossless transmission of CD-quality audio from an Arduino-esque microcontroller, sent on a beam of light, for less than the cost of a latté.