Brute Forcing A GPS PIN

January 5, 2013 by Brian Benchoff 120 Comments

[JJ] picked up a Garmin Nuvi 780 GPS from an auction recently. One of the more frustrating features [JJ] ran into is it’s PIN code; this GPS can’t be unlocked unless a four-digit code is entered, or it’s taken to a ‘safe location’. Not wanting to let his auction windfall go to waste, [JJ] rigged up an automated brute force cracking robot to unlock this GPS.

The robot is built around an old HP scanner and a DVD drive sled to move the GPS in the X and Y axes. A clever little device made out of an eraser tip and a servo taps out every code from 0000 to 9999 and waits a bit to see if the device unlocks. It takes around 8 seconds for [JJ]’s robot to enter a single code, so entering all 10,000 PINs will take about a day and a half.

Fortunately, the people who enter these codes don’t care too much about the security of their GPS devices. The code used to unlock [JJ]’s GPS was 0248. It only took a couple of hours for the robot to enter the right code; we’d call that time well spent.

You can check out the brute force robot in action after the break.

Continue reading “Brute Forcing A GPS PIN” →

Building A Hardware Security Module

December 31, 2012 by Brian Benchoff 32 Comments

[Stefan] was nervous about putting the secret key for his Amazon Web Services account in his config file. In the security world, storing passwords in plain text is considered a very bad thing. but luckily there are ways around it. [Stefan]’s solution was to make a hardware security module out of the newest ARM-powered Arduino Due.

The build puts the secret key for [Stefan]’s AWS account right in the firmware of the Arduino Due (with the security bit on the Arduino flipped, of course). A Python web service then receives sign requests and talks to the Due over a serial port. The Due then signs the request and sends it off to another bit of Python code that handles the AWS API.

Hardware security modules are frequently used by three-letter government agencies to manage cryptography keys and ensure their data are encrypted properly. Instead of a hardware module costing tens of thousands of dollars, [Stefan]’s only cost the price of an Arduino Due; not too shabby for a hardware security module that can sign more than 2000 requests per second.

25 GPUs Brute Force 348 Billion Hashes Per Second To Crack Your Passwords

December 6, 2012 by Mike Szczys 66 Comments

It’s our understanding that the video game industry has long been a driving force in new and better graphics processing hardware. But they’re not the only benefactors to these advances. As we’ve heard before, a graphics processing unit is uniquely qualified to process encryption hashes quickly (we’ve seen this with bitcoin mining). This project strings together 25 GPU cards in 5 servers to form a super fast brute force attack. It’s so fast that the actual specs are beyond our comprehension. How can one understand 348 billion hashes per second?

The testing was used on a collection of password hashes using LM and NTLM protocols. The NTLM is a bit stronger and fared better than the LM, but that’s not actually saying much. An eight character NTLM password will fall in 5.5 hours, while a 14 character LM hash makes it only about six minutes before the solution is discovered. Of course this type of hardware is only good if you have a copy of the password hashes themselves. Login protocols will lock out after a certain number of attempts and have measures in place to slow down automated systems like this one.

[via Boing Boing]

Burglar Suspected Of Using Arduino-Onity Hack To Rob Hotel Rooms

November 29, 2012 by Mike Szczys 54 Comments

Can anyone argue against this being the least-secure hotel room lock on the market? Regular readers will recognize it as an Onity key card lock. A few months back a glaring flaw in the security was exposed that allows these locks to be opened electronically in less than a second. So we are not surprised to hear that a series of hotel room robberies in Houston are suspected to have been performed using this technique.

The image above is from a demonstration video we saw back in October. That hack used an Arduino-compatible chip inside of a dry erase marker as an end-run around the lock’s electronics. It reinforced the warning sound by [Cody Brocious] when he presented the exploit at this year’s Blackhat conference. The barrel jack on the outside of the door lock doubles as a 1-wire communications port and that is how an attacker can gain access. Investigators can find no other means of entry for these thefts.

We applaud one of the victims in this story. At the end of the article she is asked if the information about the Onity flaw should have been kept secret. She said that if there’s a vulnerability that’s not being fixed people have a right to know about it. Bravo [Janet Wolf]!

[Thanks Andrew]

Hacking BodyBugg Fitness Sensors To Get Around Subscription Fee

November 28, 2012 by Mike Szczys 83 Comments

This arm cuff is a sensor package which logs data whenever you’re wearing it. It records accelerometer data, skin temperature, and galvanic skin response. That data can then be analyzed to arrive at figures like calories burned. But… The company behind the device seems to have included a way to keep the cash flowing. Once you buy it you can read the data off of the device using a Java program they supply. But you can’t erase the data from the device unless you subscribe to their online service. Once it fills up, it’s useless. [Doug] wasn’t happy with this gotcha, so he reverse engineered the technique used to clear the BodyBugg’s memory.

There had been a few previous attempts at reverse engineering the device but that groundwork didn’t really help [Doug] on his quest. He ended up disassembling the Java classes from the original program. This helped him figure out how to initialize communications. Once there he was happy to find that the device will tell you how to use it. If you issue an invalid command it will respond with a list of all valid commands. Everything you need to get up and running can be found in his github repo.

DIY TSA Backscatter Body Scanner

November 27, 2012 by Eric Evenchick 39 Comments

[Ben Krasnow] built his own version of the TSA’s body scanner. The device works by firing a beam of x-rays at at target. Some of the beam will go through the target, some will be absorbed by the target, and some will reflect back. These reflected x-rays are called ‘backscatter‘, and they are captured to create an image.

In [Ben]’s setup a rotating disk focuses x-rays into beams that travel in arcs across the X-axis. The disk is moved along the Y-axis to fill in the scan. On the disk assembly, there is a potentometer to measure the y-axis position of the beam, and an optical sensor to trigger an oscilloscope, aligning the left and right sides of the image. Using these two sensors, the scope can reconstruct an X-Y plot of the scan.

To detect the x-rays, a phosphorous screen turns the backscattered x-rays into visible light, and a photo-multiplier amplifies the light source. A simple amplifier circuit connects the photo-multiplier to a scope, controlling the brightness at each point.

The result is very similar to the TSA version, and [Ben] managed to learn a lot about the system from a patent. This isn’t the first body scanner we’ve seen though: [Jeri Ellsworth] built a microwave version a couple years ago.

The impressive build does a great job of teaching the fundamentals of backscatter imaging. [Ben] will be talking about the project at EHSM, which you should check out if you’re in Berlin from December 28th to the 30th. After the break, watch [Ben]’s machine scan a turkey in a Christmas sweater.

Continue reading “DIY TSA Backscatter Body Scanner” →

A Better Way To Hack IClass RFID Readers

November 20, 2012 by Mike Szczys 18 Comments

iClass is an RFID standard that is aimed at better security through encryption and authentication. While it is more secure than some other RFID implementations, it is still possible to hack the system. But initial iClass exploits were quite invasive. [Brad Antoniewicz] published a post which talks about early attacks on the system, and then demonstrates a better way to exploit iClass readers.

We remember seeing the talk on iClass from 27C3 about a year and a half ago. While the technique was interesting, it was incredibly invasive. An attacker needed multiple iClass readers at his disposal as the method involved overwriting part of the firmware in order to get a partial dump, then patching those image pieces back together. [Brad] makes the point that this is fine with an off-the-shelf system, but high-security installations will be using custom images. This means you would need to get multiple readers off the wall of the building you’re trying to sneak into.

But his method is different. He managed to get a dump of the EEPROM from a reader using an FTDI cable and external power source. If you wan to see how he’s circumventing the PIC read protection you’ll have to dig into the source code linked in his article.