It is amazing how quickly you get used to a car that starts as long as you have the key somewhere on your person. When you switch vehicles, it becomes a nuisance to fish the key out and insert it into the ignition. Biometrics aims to make it even easier. Why carry around a key (or an access card), if a computer can uniquely identify you?
[Alexis Ospitia] wanted to experiment with vein matching biometrics and had good results with a Raspberry Pi, a web cam, and a custom IR illumination system. Apparently, hemoglobin is a good IR reflector and the pattern of veins in your hand is as unique as other biometrics (like fingerprints, ear prints, and retina vein patterns). [Alexis’] post is in Spanish, but Google Translate does a fine job as soon as you realize that it thinks “fingerprint” is “footprint.” The software uses OpenCV, but we’ve seen the same thing done in MATLAB (see the video below).
Continue reading “Getting Biometrics in Hand”
[Veghead] recently went to a surplus warehouse filled with VHS editing studios, IBM keyboards, electronic paraphernalia from 40 years ago, and a lot of useless crap. His haul included a wooden keypad from an old alarm system that exuded 1980s futurism, and he figured it would be cool to hook this up to an alarm system from 2015. How did he do that? With software defined radio.
After pulling apart the alarm panel, [Veghead] found only a single-sided board with a 9V battery connector. There were no screw terminals for an alarm loop, meaning this entire system was wireless – an impressive achievement for the mid-80s hardware. A quick search of the FCC website showed this alarm panel was registered to two bands, 319MHz and 340MHz, well within the range of an RTL-SDR USB TV tuner dongle.
After capturing some of the raw data and playing it back in Audacity, [Veghead] found a simple OOK protocol that sends two identical binary patterns for each key. A simple program takes the raw bit patterns for each key press and codes them into a map for each of the twelve buttons.
Although the radio still works, [Veghead] found the waveforms captured by his RTL-SDR were an abomination to RF. All the components in this security system are more than 30 years old at this point, and surely some of the components must be out of spec by now. Still, [Veghead] was able to get the thing working again, a testament to the usefulness of a $20 USB TV tuner.
Thanks [Jose] for sending this one in
With the summer’s big security conferences over, now is a good time to take a look back on automotive security. With talks about attacks on Chrysler, GM and Tesla, and a whole new Car Hacking village at DEF CON, it’s becoming clear that autosec is a theme that isn’t going away.
Up until this year, the main theme of autosec has been the in-vehicle network. This is the connection between the controllers that run your engine, pulse your anti-lock brakes, fire your airbags, and play your tunes. In most vehicles, they communicate over a protocol called Controller Area Network (CAN).
An early paper on this research [PDF] was published back in 2010 by The Center for Automotive Embedded Systems Security,a joint research effort between University of California San Diego and the University of Washington. They showed a number of vulnerabilities that could be exploited with physical access to a vehicle’s networks.
A number of talks were given on in-vehicle network security, which revealed a common theme: access to the internal network gives control of the vehicle. We even had a series about it here on Hackaday.
The response from the automotive industry was a collective “yeah, we already knew that.” These networks were never designed to be secure, but focused on providing reliable, real-time data transfer between controllers. With data transfer as the main design goal, it was inevitable there would be a few interesting exploits.
Continue reading “The Year of the Car Hacks”
[Ido Gendel] was thinking about new and interesting ways to send data between devices, when he realized that the answer was right in his hand. Literally: he decided to try sending data using the mouse pointer. What he came up with was an interesting hack that uses small movements of the mouse pointer to send data at up to 1200bps, or about 150 bytes per second.
The way he did this was very, very clever. He used an Arduino Leonardo that is set to emulate a mouse, working alongside his existing mouse. This setup means that he can use his existing mouse: the system just sees the Arduino as a second mouse, and the pointer just looks a little jerky when you zoom in. That is because the Arduino is just sending tiny movements, each of which is a code that represents a nybble (4 binary bits) of data. By using both a combination of three left-right or up-down movements, he was able to create 16 movements, each of which can encode 4 bits of data. Each of these encoding movements also returns the mouse to its origin point, so the mouse doesn’t mysteriously scroll off the screen when data is being sent.
Continue reading “Use Your Mouse Pointer to Send Data”
[Mary Ann Davidson], chief security officer of Oracle, is having a bad Tuesday. The internet has been alight these past few hours over a blog post published and quickly taken down from oracle’s servers. (archive) We’re not 100% sure the whole thing isn’t a hack of some sort. Based on [Mary’s] previous writing though, it seems to be legit.
The TL;DR version of Mary’s post is that she’s sick and tired of customers reverse engineering Oracle’s code in an attempt to find security vulnerabilities. Doing so is a clear violation of Oracle’s license agreement. Beyond the message, the tone of the blog says a lot. This is the same sort of policy we’re seeing on the hardware side from companies like John Deere and Sony. Folks like [Cory Doctorow] and the EFF are doing all they can to fight it. We have to say that we do agree with [Mary] on one point: Operators should make sure their systems are locked down with the latest software versions, updates, and patches before doing anything else.
[Mary] states that “Bug bounties are the new boy band”, that they simply don’t make sense from a business standpoint. Only 3% of Oracles vulnerabilities came from security researchers. The rest come from internal company testing. The fact that Oracle doesn’t have a bug bounty program might have something to do with that. [Mary] need not worry. Bug Bounty or not, she’s placed her company squarely in the cross-hairs of plenty of hackers out there – white hat and black alike.
Ahh DEF CON! One group of hackers shows off how they’ve broken into all sorts of cool devices and other hackers (ahem… “security professionals”) lament the fact that the first group were able to do so. For every joyous “we rooted the Nest thermostat, now we can have fun” there’s a doom-mongering “the security of network-connected IoT devices is totally broken!”.
And like Dr. Jekyll and Mr. Hyde, these two sides of the hacker persona can coexist within the same individual. At Hackaday, we’re totally
paranoid security conscious, but we also like to tinker with stuff. We believe that openness and security are best friends forever. If you can open it, you can see if it’s well-made inside, at least in principle. How do we reconcile this with the security professional’s demand for devices that only accept signed binary firmware updates so that they can’t be tampered with?
We’ve got no answers, but we’ve got plenty of questions. Read on, and let us know what you think.
Continue reading “DEF CON vs IoT: On Hackability and Security”
[Simon] has been using his home alarm system for over six years now. The system originally came with a small RF remote control, but after years of use and abuse it was finally falling apart. After searching for replacement parts online, he found that his alarm system is the “old” model and remotes are no longer available for purchase. The new system had similar RF remotes, but supposedly they were not compatible. He decided to dig in and fix his remote himself.
He cracked open the remote’s case and found an 8-pin chip labeled HCS300. This chip handles all of the remote’s functions, including reading the buttons, flashing the LED, and providing encoded output to the 433MHz transmitter. The HCS300 also uses KeeLoq technology to protect the data transmission with a rolling code. [Simon] did some research online and found the thew new alarm system’s remotes also use the same KeeLoq technology. On a hunch, he went ahead and ordered two of the newer model remotes.
He tried pairing them up with his receiver but of course it couldn’t be that simple. After opening up the new remote he found that it also used the HCS300 chip. That was a good sign. The manufacturer states that each remote is programmed with a secret 64-bit manufacturer’s code. This acts as the encryption key, so [Simon] would have to somehow crack the key on his original chip and re-program the new chip with the old key. Or he could take the simpler path and swap chips.
A hot air gun made short work of the de-soldering and soon enough the chips were in place. Unfortunately, the chips have different pinouts, so [Simon] had to cut a few traces and fix them with jumper wire. With the case back together and the buttons in place, he gave it a test. It worked. Who needs to upgrade their entire alarm system when you can just hack the remote?