HDMI Splitter Is Also A Decrypter

March 12, 2015 by Elliot Williams 47 Comments

It warms our hearts when the community gets together. [esar] needed to get a decrypted HDMI stream for his home theater system. A tip-off in the comments and a ton of good old-fashioned hacking resulted in a HDMI splitter converted into a full-featured HDMI decrypter. Here’s the story.

His amazing custom Ambilight clone got profiled here, and someone asked him in the comments if it worked when High-bandwidth Digital Content Protection (HDCP) is on. [esar] lamented that it didn’t. Hackaday readers to the rescue. [Alan Hightower] and [RoyTheReaper] pointed [esar] to the fact that HDMI splitters need to decrypt and re-encrypt the signal to pass it on, and pointed him to a trick to knock out the on-board microcontroller. [esar] took off from there.

Unfortunately, taking the micro out of the picture messed with a lot of other HDMI functionality. So [esar] started digging in the datasheets for the HDMI splitter chip, looking for registers relevant to the re-encryption. If he could get in between the microcontroller and the splitter chip on the I2C bus and disable the re-encryption, he’d be set.

If you’re at all interested in I2C hacking or abusing HDMI splitters, you need to read his post because he details all of the tribulations and triumphs. He first tries just brute-forcing the I2C by overwriting a 1 bit with a 0. This (correctly) signals the micro that there’s been a conflict on the bus, so it re-sends the command again. Dead end.

He then found another signal that the receiver could use say that it wasn’t decrypting. He tried sending this continuously to the splitter so that it would stop encrypting. That worked, but only for one channel, some of the time. It turns out that his code was taking too long in his bit-banged I2C code. He fixes this up and all is well? Well, 90% of the way there.

To hammer down the last 10% of the functionality, [esar] buys a couple more splitters, experiments around with another splitter chipset that works with 3D, and solders some more wires to enable the Audio Return Channel. And after a ton of well-documented hard work, he wins in the end.

Crypto Photography And Custom Firmware

December 18, 2014 by Brian Benchoff 13 Comments

Imagine a camera that took encrypted pictures. If your camera is stolen, the only thing on the memory card would be random data that can only be unlocked with a key. If you hire a photographer, those images cannot be copied without the key. At the very least, it’s an interesting idea made impressive because this actually exists.

[Doug] recently got his hands on a Samsung NX300, a nice camera for the price that conveniently runs Linux and is kinda open-sourced by Samsung. With special firmware, [Doug] created public/private key encryption for this camera, giving only the person with the private key the ability to unlock the pictures taken with this camera.

[Doug] started his build by looking at the firmware for this camera, figuring out how to take everything apart and put it back together. With a few modifications that included encryption for all images taken with this camera, [Doug] repackaged the firmware and upgraded the camera.

The encryption firmware is available on the site, but considering how easily [Doug] was able to make this hack happen, and a great walkthrough of how to actually do it raises some interesting possibilities. The NX300 is a pretty nice camera that’s a little bit above the Canon PowerShot cameras supported by CHDK. It also runs Linux, so if you’re looking for something cool to do with a nice camera, [Doug] has a very good resource.

Reverse Engineering Capcom’s Crypto CPU

December 12, 2014 by Brian Benchoff 26 Comments

There are a few old Capcom arcade titles – Pang, Cadillacs and Dinosaurs, and Block Block – that are unlike anything else ever seen in the world of coin-ops. They’re old, yes, but what makes these titles exceptional is the CPU they run on. The brains in the hardware of these games is a Kabuki, a Z80 CPU that had a few extra security features. why would Capcom produce such a thing? To combat bootleggers that would copy and reproduce arcade games without royalties going to the original publisher. It’s an interesting part of arcade history, but also a problem for curators: this security has killed a number of arcade machines, leading [Eduardo] to reverse engineering and document the Kabuki in full detail.

While the normal Z80 CPU had a pin specifically dedicated to refreshing DRAM, the Kabuki repurposed this pin for the security functions on the chip. With this pin low, the Kabuki was a standard Z80. When the pin was pulled high, it served as a power supply input for the security features. The security – just a few bits saved in memory – was battery backed, and once this battery was disconnected, the chip would fail, killing the game.

Plugging Kabuki into an old Amstrad CPC 6128 without the security pin pulled high allowed [Eduardo] to test all the Z80 instructions, and with that no surprises were found; the Kabuki is fully compatible with every other Z80 on the planet. Determining how Kabuki works with that special security pin pulled high is a more difficult task, but the Mame team has it nailed down.

The security system inside Kabuki works through a series of bitswaps, circular shifts, XORs, each translation different if the byte is an opcode or data. The process of encoding and decoding the security in Kabuki is well understood, but [Eduardo] had a few unanswered questions. What happens after Kabuki lost power and the memory contents – especially the bitswap, address, and XOR keys – vanished? How was the Kabuki programmed in the factory? Is it possible to reprogram these security keys, allowing one Kabuki to play games it wasn’t manufactured for?

[Eduardo] figured being able to encrypt new, valid code was the first step to running code encrypted with different keys. To test this theory, he wrote a simple ‘Hello World’ for the Capcom hardware that worked perfectly under Mame. While the demo worked perfectly under Mame, it didn’t work when burned onto a EPROM and put into real Capcom hardware.

That’s where this story ends, at least for the time being. The new, encrypted code is valid, Mame runs the encrypted code, but until [Eduardo] or someone else can figure out any additional configuration settings inside the Kabuki, this project is dead in the track. [Eduardo] will be back some time next week tearing the Kabuki apart again, trying to unravel the mysteries of what makes this processor work.

Yik Yak MITM Hack (Give The Dog A Bone)

December 10, 2014 by Rick Osgood 24 Comments

Yik Yak is growing in popularity lately. If you are unfamiliar with Yik Yak, here’s the run down. It’s kind of like Twitter, but your messages are only shared with people who are currently within a few miles of you. Also, your account is supposed to be totally anonymous. When you combine anonymity and location, you get some interesting results. The app seems to be most popular in schools. The anonymity allows users to post their honest thoughts without fear of scrutiny.

[Sanford Moskowitz] decided to do some digging into Yik Yak’s authentication system. He wanted to see just how secure this “anonymous” app really is. As it turns out, not as much as one would hope. The primary vulnerability is that Yik Yak authenticates users based solely on a user ID. There are no passwords. If you know the user’s ID number, it’s game over.

The first thing [Sanford] looked for was an encrypted connection to try to sniff out User ID’s. It turned out that Yik Yak does actually encrypt the connection to its own servers, at least for the iPhone app. Not to worry, mobile apps always connect to other services for things like ad networks, user tracking, etc. Yik Yak happens to make a call to an analytics tool called Flurry every time the app is fired. Flurry needs a way to track the users for Yik Yak, so of course the Yik Yak App tells Flurry the user’s ID. What other information would the anonymous app have to send?

Unfortunately, Flurry disables HTTPS by default, so this initial communication is in plain text. That means that even though Yik Yak’s own communications are protected, the User ID is still exposed and vulnerable. [Sanford] has published a shell script to make it easy to sniff out these user ID’s if you are on the same network as the user.

Once you have the user ID, you can take complete control over the account. [Sanford] has also published scripts to make this part simple. The scripts will allow you to print out every single message a user has posted. He also describes a method to alter the Yik Yak installation on a rooted iPhone so that the app runs under the victim’s user ID. This gives you full access as if you owned the account yourself.

Oh, there’s another problem too. The Android app is programmed to ignore bad SSL certificates. This means that any script kiddie can perform a simple man in the middle attack with a fake SSL certificate and the app will still function. It doesn’t even throw a warning to the user. This just allows for another method to steal a user ID.

So now you have control over some poor user’s account but at least they are still anonymous, right? That depends. The Yik Yak app itself appears to keep anonymity, but by analyzing the traffic coming from the client IP address can make it trivial to identify a person. First of all, [Sanford] mentions that a host name can be a dead giveaway. A host named “Joe’s iPhone” might be a pretty big clue. Other than that, looking out for user names and information from other unencrypted sites is easy enough, and that would likely give you everything you need to identify someone. Keep this in mind the next time you post something “anonymously” to the Internet.

[via Reddit]

THP Semifinalist: NSA Away

September 26, 2014 by Brian Benchoff 49 Comments

Back when we started The Hackaday Prize, security, big brother, and the NSA were making headlines every day. Since that time, there has been enough bread and circuses in the news to wipe the consequences of these leaks out of the public consciousness, but work is still being done by hackers and tinkerers the world over to give you the tools to protect your data.

NSA Away is one of these tools. The first part of the project is a standalone key generator that writes the same random bits to a pair of SD cards simultaneously. With their random number generator, this is perfect encryption. The only way to crack the one time pad the team is using for encryption is to 1) use parts of the pad more than once, 2) have a terrible RNG, or 3) do something really stupid like sell the one time pad in a store.

The other part of the build is an Android-based encryption device with a camera, keyboard, SD card reader, and a USB port. This device reads the ‘OTP SD cards’ and reads data with the camera using OCR and decrypts it on the screen. Provided the OTP doesn’t fall into the wrong hands, this is a perfectly secure way to transmit data to anyone.

As far as progress goes, the members of the team have a fully functional pad generator, writing random data to SD cards. This device can also output random bits to a computer as a USB HID device, should you want to transmit your pad over unsecured mediums.

It’s an impressive bit of work, especially in the RNG department. The team is using eight avalanche noise generators in the circuit description. This part of the build isn’t quite working yet, but that’s really not needed for a proof of concept.

The project featured in this post is a quarterfinalist in The Hackaday Prize.

Hacklet #10 Cryptography And Reverse Engineering

August 8, 2014 by Adam Fabio 25 Comments

In honor of DEFCON, this week we’re looking at some cryptography and reverse engineering projects over at Hackaday.io Every hacker loves a hardware puzzle, and [Tom] has created a tool to make those puzzles. His Hardware Reverse Engineering Learning Platform consists of a shield with two ATmega328 chips and an I2C EEPROM. The two Atmel chips share a data bus and I2C lines. Right in the middle of all this is an ST Morpho connector, which allows an ST Nucleo board to act as a sniffer. The platform allows anyone to create a reverse engineering challenge! To successfully reverse engineer a board, it sure helps to have good tools. [coflynn] is giving that to us in spaces with The ChipWhisperer. ChipWhisperer is an open source security research platform. The heart of the system is a Xilinx Spartan 6 FPGA. The FPGA allows very high speed operations for things like VCC and clock glitching. ChipWhisperer is an entire ecosystem of boards – from LNA blocks to field probes. The entire system is controlled from an easy to use GUI. The end result is a powerful tool for hardware attacks. On the Encryption side of the house, we start by keeping the Feds at bay. The [Sector67] hackerspace has collectively created NSA AWAY. NSA AWAY is a simple method of sending secure messages over an insecure medium – such as email. A one-time use pad is stored on two SD cards, which are used by two Android devices. The message sender uses an Android device to encrypt the message. On the receive side, the message can be decoded simply by pointing an android device’s camera at the encrypted data. So easy, even a grandparent could do it! Next up is [Josh’s] Bury it under the noise floor. “Bury it” is an education for cryptography in general, and steganographic software in particular. [Josh] explains how to use AES-256 encryption, password hashing, and other common techniques. He then introduces steganography by showing how to hide an encrypted message inside an image. Anyone who participated in Hackaday’s ARG build up to The Hackaday Prize will recognize this technique. [yago] gives us encrypted voice communications with his ZRTP Hardphone. The hardphone implements the ZRTP, a protocol for encrypted voice over IP communications. The protocol is implemented by a Raspberry Pi using a couple of USB sound cards. User interface is a 16×2 Line character LCD, a membrane keypad, and of course a phone handset. Don’t forget that you need to build two units,or whoever you’re trying to call will be rather confused!

Finally we have the Mooltipass. Developed right here on Hackaday by [Mathieu Stephan] and the community at large, Mooltipass is a secure password storage system. All your passwords can be stored fully AES-256 encrypted, with a Smart Card key. Under the hood, Mooltipass uses an Arduino compatible ATmega32U4 microcontroller. UI is through a OLED screen and touch controls. That’s it for this week! Be sure to check out next week’s Hacklet, when we bring you more of the best from Hackaday.io!

HOPE X: Wireless Tor Proxies And Sharing TrueCrypt Volumes

July 23, 2014 by Brian Benchoff 16 Comments

When you’re at HOPE, of course you’re going to see a few Tor proxies, but [Jose]’s is top-notch. It’s a completely portable Tor proxy (.br, Google translation), battery-powered, with a connection for 4G networks.

[Jose]’s OnionPi setup is based on the Adafruit version, but adds a few interesting features that make it even more useful. It’s battery-powered with about a day of charge time, has a built-in battery charger, Ethernet pass through, external 4G and WiFi antennas, all in a sealed case that makes the entire build impervious to the elements.

While this isn’t much of a hack per se, the amount of integration is impressive. There are switches to turn off each individual networking port, and all the relevant plugs are broken out to the front panel, with the AC input and USB serial connection using screw connectors that are supposedly very popular in Brazil.

[Jose] also brought along a new device that isn’t documented anywhere else on the web. It’s called NNCFA, or Nothing New Crypto For All. Using a Cubieboard, an interesting ARM single board computer with a SATA connector, [Jose] created a device that will mount TrueCrypt volumes on a hard drive and share them via Samba.