Chameleon Emulates Contactless Smart Cards


Researchers at Ruhr University of Bochum in Germany have been busy working with RFID and related devices for quite some time now. They call the fruit of their labors Chameleon, a versatile Contactless Smart Card Emulator. Contactless Smart Cards are RFID style devices that also contain a smart card style memory. These cards are often used for payment, replacing mag strip style credit cards. Philips MIFARE Classic cards are a common example of contactless smart cards. The Chameleon is set up to emulate any number of cards using the common 13.56MHz frequency band. Adding a new card is as simple as loading up a new CODEC  and application to the firmware. Currently Chameleon can emulate MIFARE cards using the ISO14443A.

The Chameleon is completely open source, and can be built for around $25 USD. The heart of the system is an Atmel ATxmega192A3 microcontroller. The 192 is a great microcontroller for this task because it contains hardware accelerators for both DES and AES-128. An FTDI USB interface chip is used to provide an optional communication link between a host computer and the ATxmega. The link can be used for debugging, as well as manipulating data in real-time. A host PC is not necessary for use though – the Chameleon will operate just fine as a stand alone unit. We definitely like this project – though we’re going to be doubling down on the shielding in our RF blocking wallets.

Ambient Computer Noise Leaks Your Encryption Keys

RSA Key extraction

[Daniel, Adi, and Eran], students researchers at Tel Aviv University and the Weizmann Institute of Science have successfully extracted 4096-bit RSA encryption keys using only the sound produced by the target computer. It may sound a bit like magic, but this is a real attack – although it’s practicality may be questionable. The group first described this attack vector at Eurocrypt 2004. The sound used to decode the encryption keys is produced not by the processor itself, but by the processor’s power supply, mainly the capacitors and coils. The target machine in this case runs a copy of GNU Privacy Guard (GnuPG).

During most of their testing, the team used some very high-end audio equipment, including Brüel & Kjær laboratory grade microphones and a parabolic reflector. By directing the microphone at the processor air vents, they were able to extract enough sound to proceed with their attack. [Daniel, Adi, and Eran] started from the source of GnuPG. They worked from there all the way down to the individual opcodes running on the x86 processor in the target PC. As each opcode is run, a sound signature is produced. The signature changes slightly depending on the data the processor is operating on. By using this information, and some very detailed spectral analysis, the team was able to extract encryption keys. The complete technical details of the attack vector are available in their final paper (pdf link).

Once  they had the basic methods down, [Daniel, Adi, and Eran] explored other attack vectors. They were able to extract data using ground fluctuations on the computers chassis. They even were able to use a cell phone to perform the audio attack. Due to the cell phone’s lower quality microphone, a much longer (on the order of several hours) time is needed to extract the necessary data.

Thankfully [Daniel, Adi, and Eran] are white hat hackers, and sent their data to the GnuPG team. Several countermeasures to this attack are already included in the current version of GnuPG.

Google Security Certificates Forged

Chain of Trust

Recently, Google discovered that a certificate authority (CA) issued forged certificates for Google domains. This compromises the trust provided by Transport Layer Security (TLS) and Secure HTTP (HTTPS), allowing the holder of the forged certificates to perform a man-in-the-middle attack.

To validate that the website you’re visiting is actually who they claim to be, your browser ensures that the certificate presented by the server you’re accessing was signed by a trusted CA. When someone requests a certificate from a CA, they should verify the identity of the person making the request. Your browser, and operating system, have a set of ultimately trusted CAs (called root CAs). If the certificate was issued by one of them, or a intermediate CA that they trust, you will trust the connection. This whole structure of trust is called a Chain of Trust.

With a forged certificate, you can convince a client that your server is actually You can use this to sit between a client’s connection and the actual Google server, eavesdropping their session.

In this case, an intermediate CA did just that. This is scary, because it undermines the security that we all rely on daily for all secure transactions on the internet. Certificate pinning is one tool that can be used to resist this type of attack. It works by associating a host with a specific certificate. If it changes, the connection will not be trusted.

The centralized nature of TLS doesn’t work if you can’t trust the authorities. Unfortunately, we can’t.

SkyJack: A Drone to Hack All Drones


Quadcopters are gradually becoming more affordable and thus more popular; we expect more kids will unwrap a prefab drone this holiday season than any year prior. [Samy's] got plans for the drone-filled future. He could soon be the proud new owner of his own personal army now that he’s built a drone that assimilates others under his control.

The build uses a Parrot AR.Drone 2.0 to fly around with an attached Raspberry Pi, which uses everybody’s favorite Alfa adapter to poke around in promiscuous mode. If the SkyJack detects an IEEE-registered MAC address assigned to Parrot, aircrack-ng leaps into action sending deauthentication requests to the target drone, then attempts to take over control while the original owner is reconnecting. Any successfully lassoed drone doesn’t just fall out of the sky, though. [Samy] uses node-ar-drone to immediately send new instructions to the slave.

You can find all his code on GitHub, but make sure you see the video below, which gives a thorough overview and a brief demonstration. There are also a few other builds that strap a Raspberry Pi onto a quadcopter worth checking out; they could provide you with the inspiration you need to take to the skies.

[Read more...]

Bypassing Seagate ATA Security Lock


Here’s a common story when it comes to password retrieval: guy sets up a PC, and being very security-conscious, puts a password on his Seagate hard drive. Fast forward a few months, and the password is, of course, forgotten. Hard drive gets shuffled around between a few ‘computer experts’ in an attempt to solve the problem, and eventually winds up on [blacklotus89]‘s workbench. Here’s how he solved this problem.

What followed is a walk down Hackaday posts from years ago. [blacklotus] originally found one of our posts regarding the ATA password lock on a hard drive. After downloading the required tool, he found it only worked on WD hard drives, and not the Seagate sitting lifeless on his desk. Another Hackaday post proved to be more promising. By accessing the hard drive controller’s serial port, [blacklotus] was able to see the first few lines of the memory and the buffer.

Two hours and two Python scripts later, [blacklotus] was able to dump the contents of his drive. He then took another Seagate drive, locked it, dumped it, and analyzed the data coming from this new locked drive. He found his old password and used the same method to look for the password on the old, previously impenetrable drive. It turns out the password for the old drive was set to ’0000′, an apparently highly secure password.

In going through a few forums, [blacklotus] found a lot of people asking for help with the same problem, and a lot of replies saying. ‘we don’t know if this hard drive is yours so we can’t help you.’ It appears those code junkies didn’t know how to unlock a hard drive ether, so [blacklotus] put all his tools up on GitHub. Great work, and something that didn’t end up as a Hackaday Fail of the Week as [blacklotus] originally expected.

ScareMail Tries to Disrupt NSA Email Surveillance


Are you on the NSA’s email watchlist? Do you want to be?  This project is called ScareMail and it’s designed to mess with the NSA’s  email surveillance programs.

[Benjamin Grosser] has written it as a plugin for many popular web browsers, and it uses an algorithm to generate a clever but ultimately useless narrative in the signature of your email using as many probable NSA search terms as possible. The idea behind this is if enough people use it, it will overload the NSA’s search results, ultimately making their email keyword tracking useless.

So how does it work? The algorithm starts with natural language processing (NLP) and an original source of text — he picked Ray Bradbury’s Fahrenheit 451. Using the processor it identifies all nouns and verbs in the original text and replaces them with properly formatted and conjugated “scary” words that he’s indexed from a list of hypothetical NSA key words. To ensure each signature is unique, he makes use of a Markov chain to generate new texts that are completely different each time. The result is a somewhat coherent paragraph that doesn’t make any real sense.

But wait! Surveillance like this is bad, but hypothetically it could work! Well, maybe. But the point is: 

ScareMail reveals one of the primary flaws of the NSA’s surveillance efforts: words do not equal intent.

Stick around after the break to see a proper video explanation of ScareMail by [Ben] himself.

[Read more...]

Update: SD Card Locker Now Supports Password Protect


[Karl Lunt] has updated his Secure Digital Card locker to support password based locking. [Karl's] original design only supported write locking via the TMP_WRITE_PROTECT  bit. The new design gives the user an option: TMP_WRITE_PROTECT, or password protection. [Karl] goes into further detail this time around about the bit fields used with CMD42, and how they are set. The passwords in this case are up to 16 bytes. The bytes don’t necessarily have to be printable characters – any binary value can be used. Unfortunately, [Karl's] locker doesn’t utilize a user interface beyond the buttons, so any password must be “baked in” to the SD Card locker firmware. We would love to see the option of even a basic serial interface for entering a password (most likely in hex).

[Karl] tried his device out with several different cards, and several computers. While not an exhaustive test, he did find that the computers always behaved the same: A locked SD card would not show up. In the case of windows, no beep, no drive, nothing. He goes into the security possibilities of using password locking: Financial data could be stored and physically transferred via SD or microSD, with the password sent separately (say in an email or SMS). Any unenlightened data thief attempting to use the card would think they have a broken device on their hands.

We don’t know how secure the password lock feature is – brute forcing a variable length 16 byte binary password would take some time. It all comes down to how quickly each password attempt takes. Some cursory web searching didn’t bring up any information about successful SD card password cracking. Sounds like a challenge for our readers!