The Solution To The 10th Anniversary Code

October 27, 2014 by Brian Benchoff 16 Comments

A few weeks ago, [1o57], a.k.a. [Ryan Clarke] gave a talk about puzzles, DEFCON, and turning crypto puzzles into an art form at our 10th anniversary party. Ever the trickster, [1o57] included a crypto challenge in his talk, and a few days after our little shindig, nobody had yet solved the puzzle. Finally, someone bothered to sit down and figure it out. We don’t know what [tahnok] won, but as [1o57] said, solving it is its own reward.

Some of the slides in the presentation had a few characters sitting off to the side for no apparent reason. [tahnok] put these together and came up with:

DOXIYLDCYVDKIKNKUMKRYDNBYGONYMNXOC

In cases like this, you might try a Caesar cipher, or just shifting characters to the left or right a certain number of places. Since [1o57] noted this was the tenth anniversary of Hackaday, [tahnok] tried that first:

TENYOBTSOLTAYADAKCAHOTDROWEDOCDNES

It doesn’t look like much, but that’s only because the string is backwards. Tricky, tricky. tricky. With instructions to send a codeword to an email address, [tahnok] now needed to find a code word. There was one picture [1o57] put up on twitter that was still an unsolved part of the puzzle:

With no idea what these little stickmen are, he scoured google with variants of ‘stickmen code’ and ‘semaphore’ until he hit upon the Sherlock Holmes story, The Adventure of the Dancing Men. It’s a simple substitution cypher, translated to, “codeword psychobilly ciphers”

And that’s the entire puzzle. As far as we know, this took about a month to solve, and compared to the DEFCON challenges, was fairly simple. [1o57] will probably chime in down in the comments to tell everyone how many people have picked up on the clues and sent an email.

The CryptoCape For BeagleBone

July 20, 2014 by Brian Benchoff 14 Comments

[Josh Datko] was wandering around HOPE X showing off some of his wares and was kind enough to show off his CryptoCape to us. It’s an add on board for the BeagleBone that breaks out some common crypto hardware to an easily interfaced package.

On board the CryptoCape is an Atmel Trusted Platform Module, an elliptic curve chip, a SHA-256 authenticator, an encrypted EEPROM, a real time clock, and an ATMega328p for interfacing to other components and modules on the huge prototyping area on the cape.

[Josh] built the CryptoCape in cooperation with Sparkfun, so if you’re not encumbered with a bunch of export restrictions, you can pick one up there. Pic of the board below.

Continue reading “The CryptoCape For BeagleBone” →

Hackaday At DEF CON 21

August 1, 2013 by Eric Evenchick 30 Comments

I’ve arrived at the Rio Casino in Las Vegas, Nevada for DEF CON 21. Over the next couple of days, I’ll be talking about what I get up to here.

The main event today is registration, which means getting a neat badge. This year’s badge was designed by [Ryan Clarke]. According to the DEF CON booklet, they are “non-electronic-electronic” badges this year, and DEF CON will be alternating between electronic badges every other year.

The playing card design is printed on a PCB, and uses the silkscreen, solder mask, and copper layers to provide three colors for the artwork. The badge is a crypto challenge, featuring some cryptic characters, numbers, and an XOR gate. I don’t have any ideas about it yet, but some people are already working hard on cracking the code.

Tomorrow, I’ll be heading to a few talks including one on hacking cars that we discussed earlier, and one on decapping chips. I’ll also be checking out some of the villages. The Tamper Evident Village is premiering this year, and they’ll be showing off a variety of tamper proofing tech. I’ll also try to get to the Beverage Cooling Contraption Contest, where competitors build devices to cool beverages (ie, beer) as quickly as possible.

If you have any DEF CON tips, let me know in the comments.

HDMI Breakout Lets You Sniff HDCP Crypto Keys

February 18, 2013 by Mike Szczys 31 Comments

There’s two really useful parts to this hack which involves sniffing the HDMI protocol’s HDCP security keys. The first is just getting at the signals without disrupting communications between two HDCP capable devices. To do so [Adam Laurie] started by building an HDMI breakout cable that also serves as a pass-through. The board seen above is known as an HDMI screw terminal board. The image shows one cable connecting to itself during the fabrication process. What he did was cut one end off of an HDMI cable, then used a continuity tester to figure out which screw terminal connects with which bare wire. After all the wires are accounted for the end with the plug goes to his TV, with a second cable connecting between the board’s socket and his DVD player.

The rest of his post is dedicated to sniffing the security keys. His weapon of choice on this adventure turns out to be a Bus Pirate but it runs a little slow to capture all of the data. He switches to a tool of his own design, which runs on a 60MHz PIC32 demo board. With it he’s able to get the keys which make decrypting the protected data possible.

Zigbee AES Key Sniffing

March 15, 2009 by Eliot 8 Comments

zigbeesniffing

[Travis Goodspeed] posted a preview of what he’s working on for this Summer’s conferences. Last weekend he gave a quick demo of sniffing AES128 keys on Zigbee hardware at SOURCE Boston. The CC2420 radio module is used in many Zigbee/802.15.4 sensor networks and the keys have to be transferred over an SPI bus to the module. [Travis] used two syringe probes to monitor the clock line and the data on a TelosB mote, which uses the CC2420. Now that he has the capture, he’s planning on creating a script to automate finding the key.

TEMPEST: A Signal Problem

January 25, 2009 by Eliot 12 Comments

TEMPEST is the covername used by the NSA and other agencies to talk about emissions from computing machinery that can divulge what the equipment is processing. We’ve covered a few projects in the past that specifically intercept EM radiation. TEMPEST for Eliza can transmit via AM using a CRT monitor, and just last Fall a group showed how to monitor USB keyboards remotely. Through the Freedom of Information Act, an interesting article from 1972 has been released. TEMPEST: A Signal Problem (PDF link dead, try Internet Archive version) covers the early history of how this phenomenon was discovered. Uncovered by Bell Labs in WWII, it affected a piece of encryption gear they were supplying to the military. The plaintext could be read over that air and also by monitoring spikes on the powerlines. Their new, heavily shielded and line filtered version of the device was rejected by the military who simply told commanders to monitor a 100 feet around their post to prevent eavesdropping. It’s an interesting read and also covers acoustic monitoring. This is just the US history of TEMPEST though, but from the anecdotes it sounds like their enemies were not just keeping pace but were also better informed.

[via Schneier]

Use The CPU Cache To Prevent Cold Boot? No.

January 18, 2009 by Eliot 21 Comments

coldboot

Frozen Cache is a blog dedicated to a novel way to prevent cold boot attacks. Last year the cold boot team demonstrated that they could extract encryption keys from a machine’s RAM by placing it in another system (or the same machine by doing a quick reboot). Frozen Cache aims to prevent this by storing the encryption key in the CPU’s cache. It copies the key out of RAM into the CPU’s registers and then zeroes it in RAM. It then freezes the cache and attempts to write the key back to RAM. The key is pushed into the cache, but isn’t written back to RAM.

The first major issue with this is the performance hit. You end up kneecapping the processor when you freeze the cache and the author suggests that you’d only do this when the screen is locked. We asked cold boot team member [Jacob Appelbaum] what he thought of the approach. He pointed out that the current cold boot attack reconstructs the key from the full keyschedule, which according to the Frozen Cache blog, still remains in RAM. They aren’t grabbing the specific key bits, but recreating it from all this redundant information in memory. At best, Frozen Cache is attempting to build a ‘ghetto crypto co-processor’.

We stand by our initial response to the cold boot attacks: It’s going to take a fundamental redesign of RAM before this is solved.

[via Slashdot]