Archive for the ‘Puzzles’ Category

DBIR Cover Challenge 2013

April 29, 2013 1 comment

It’s time for the 2013 edition of the Verizon Data Breach Investigations Report Cover Challenge! This year I didn’t win…but only just barely. It also felt like a bit of a different puzzle this year, not quite as much a series of challenges as just a scavenger hunt with only the barest minimum of breadcrumbs scattered to help us follow the path to victory.

With that in mind, I’ll focus less on the individual puzzle elements, and more on the challenge experience.

My big takeaway this year is: Discipline. Time and again, I found myself stuck, and rather than taking the right approach and stepping back for a moment, I just spun my wheels and got nowhere. While this is well-known weakness of my puzzle-solving skills, it felt more troublesome than usual this time around. Perhaps because each stage had so few obvious next-steps, that once I found the first (obvious) angle, I stopped looking for others. Or perhaps everything was perfectly obvious, and I just Wasn’t Paying Attention. Either way, I know I missed many things along the way, and was lucky to even pull out 2nd place.

The puzzle started, for me, about 9:00 on a Monday night (this particular Monday was April 22). The first thing I did was to try to find hidden text in the report, first by doing a “select all” and copy/paste, then using command line utilities pdf2text and pdf2html. The only thing I found was a single hash: “f38b8e92f812 f9f4f26be4793827d906.” For some reason, I kept getting it copied out with a break in the middle, so I wasn’t sure if it was a single 16-byte string, or a 6-byte and 10-byte together (like a salt and hash).Either way, I couldn’t find any online databases that knew what it was.

I also looked through the document for interesting links, or silly sidebars (like last year’s “Chuck Testa” commentary). I found a github site with a couple of tools put out by the Verizon Risk team, but not much else. Then late that night, the @VZDBIR Twitter feed announced that there was a problem with the document, that something was missing, and they’d post a new version in the morning. What was missing? Usually there’s a big block of hidden encoded text, and I didn’t see anything like that this time. Or perhaps the (fragmented?) hash was an incomplete part of a longer list of hashes, or any of a million things.


Tuesday morning, they published the new version, and immediately I discovered a JPEG image hidden in a large block of base-64 encoded, hidden text. The image sent me to the same github account I’d found the night before, so I spent a little time looking for easy signs of steganography in this image, to no avail. I glanced again at the two repositories, then looked at the account avatar, and noticed that the background was transparent, but there was a solid white block at the bottom. I verified that this appeared to contain some kind of hidden data, and spent some time trying to extract that, or to re-format the size of the image to get something visually recognizable out of it. In the end, I never did figure out what was supposed to be in there. (Incidentally — I just heard from someone on the VZ-Risk team, and he had no idea what was in there, saying “That image had been there long before we planned out this challenge.” So…anyone want to try to figure that one out? The original, and data extracted from the white footer bar, are included below.)



So the grand total progress I had made, after 24+ hours, was: I’m on a github site. Which I’d first visited within probably 20 minutes of first opening the report.

The next morning, I had a little time to poke around before a meeting, and I looked at the incident database in the github “Veris” repository. It contained over 1000 individual files, each representing a particular incident for which they had publicly-releasable data. Far too much to review by hand. So I started sorting the data on individual fields. First, I tried URLs from each file, but there were still too many to look at. I also tried searching for likely words, hints, things like pastebin, but still there was too much to process in the little time I had.

Then I saw a tweet from another Dark Lord of the Sith (@darthmdh – Matthew Hawkins), who said “So I’ve made it to ‘Johnson Packaging’, that wasn’t so hard! #DBIRpuzzle” Bingo! That’s the one. Turns out, he simply searched for the hash value found in the beginning of the doc, and there it was. (In fact, that was the sole purpose of that hash, which I’ve been told was just an MD5 hash of a throwaway text like “this is the text for the marker” or something. Sad, I was hoping it’d be “O HAI HASHCAT”).

Also, it turns out that what I could have done was to sort by the master_id. All of the IDs in the file included “osint” except for one: CC2013 (“Cover Challenge 2013”). That one should have been easy to spot. The incident file contained several clues to lead one to Pastebin, to look for a data dump from the “Case of the Mondays Hacker Troupe” (cotMHT).

This dump file contained 5 password hashes, some silly hacker-esque stuff, and a funny ascii logo. The hashes (4 of which were named after Jackson 5 members) decoded to lyrics from “ABC”: Michael / abc, Tito / easy, Jackie / as, Jermaine / 123, and Danzig / iiiiiiiiiiiiiiiiiiii. So…nothing helpful here either.

At that point, I had to get on a train for a meeting downtown, but I was able to do some digging while en route. The “silly hacker” commentary spoke of “epic ukulele solos on the Tube of You”, which, of course, I’d LOVE to watch that while on a crowded subway train. As it turns out, there wasn’t any real content in they lyrics (that’s okay, there probably wasn’t much real content in the song they were parodying either). All the important bits were on the whiteboard in the background.


Prominent bits on the whiteboard included:

* The latitude and longitude of the site of the Wreck of the Edmund Fitzgerald (/me cues up Gordon Lightfoot)
* A large Canadian flag, and other references to Canada
* A quote from the Chinese MoD in response to the Mandiant APT report
* Setec Astronomy
* Colonel J. Henry Haberdasher

At this point, I had arrived at my lunch meeting, and had to put the iPad away. But shortly after returning to the train (and viewing a tweeted hint: “The Colonel has been busier over the past month”) I searched for the right phrase and found the next stage of the puzzle.


The phone number and address didn’t help any (the address is for the Museum of Civilization in Quebec — another Canadian reference), but the site that was registered certainly did: (again, Case of the Mondays). But there was nothing at the site…just a blank, default “instant site” from GoDaddy. I tried several logins for the owner login panel (names and passwords from the Jackson 5 dump, for example) but eventually decided that it was the actual, legit GoDaddy site management panel and left it alone. I couldn’t view source on the iPad, so I tried several other “obvious” page names, like the unknown hash from before and other words, but found nothing.

I finally returned home, did some work stuff, and quickly decoded a hidden message on the pastebin dump (numbers hidden in the cotMHT logo spelled out “DRINK MORE OVALTINE”), then I dropped the kids off at an evening class and retreated to Panera for a bit. Shortly after sitting down, I looked at the YouTube page again. The ukulele video was posted by “Imstilla Hentz,” obviously a made-up name, but I couldn’t find anything else there, other than a default Google+ account. At this point, I even made a note in my log to check out other social networking / blog sites (I had in mind last year’s use of Pinterest) but didn’t pursue that any further. More on how that cost me first place in a bit.

After some time spent regrouping, trying to figure out just where I was and what I needed to do next, I looked a little more into how the “Instant Site” feature works. Turns out, it can only be used to create single-page sites. So there were no other URLs that one could read at that site, where the next clue might be. Back to square one for

After dinner and the kids’ bedtime, I focused on the supporting files for the Colonel’s website (all the while, @VZDBIR was telling us to search for what he’s been up to…which drove me buggy, as this was all I could find….) The javascript and CSS files all seemed to be the stock templates, the background image exactly matched one I found on another site, etc. I just couldn’t find anything at all.

Then, finally, a little before 11:00 pm on Wednesday, I realized that there was another item from the whois page I hadn’t searched for: The email address “”. Interestingly, Google didn’t give me much for that at all, until I tried searching on a 30-day window (which the hints had been telling us to do), and then I found two hits: One for a userid and password in the bugmenot database (which didn’t work on, and another in “Hank’s Corner,” at “”

Haberdasher Puzzle

Two minutes later, I noticed that this page had been created by “Ima Hintz,” the fictitious user from last year’s puzzle. And it was even available on Ima’s blogspot profile page. Which still contained links to last year’s Cupcake and ASCII Art pages. And the YouTube user “Imstilla Hentz” was, clearly, meant to evoke “Ima Hintz” from last year. If I’d thought that through a bit more while at Panera, I would’ve found this final stage 6 1/2 hours earlier than I did, and probably would have had the puzzle won by 7:00. Blast. Even crazier, if I’d decided to spend some time Monday night reviewing how things worked last year…and visited Ima’s page..I might even have found the puzzle within hours of the report’s release. I’m convinced the Verizon team did this deliberately, just to annoy us. Sneaky, sneaky, you magnificent bastards.

Fortunately, I knew exactly what to do with this puzzle, as earlier in the day my brother had sent me a link to the “Haberdasher’s Puzzle” (incidentally created by someone named Henry). Once the pieces were rearranged in the correct manner, the ciphertext would be readable, and I could proceed.

I took a short break to get prepped for bed (I was dead tired by now) but wanted to keep on until I was done, or fell asleep in my chair. Being so tired made getting the pieces lined up exactly right was difficult. Fortunately, a clear pattern was easy to discern — the numbers went “A, B, C, D-E” over and over. By making sure that I preserved that pattern as I read out the ciphertext, I eventually had a nice file with all the right numbers in the right places.

I quickly surmised that this was a book cipher (like had been used in the 2011 DBIR challenge), but which report is it built against? The “-” in the ciphertext broke the numbers up into 5-element groups, the first of which was probably the page number. Given that information, two of the reports were too short, so I first tried the current report. The first three letters were “EMA,” but the fourth one was broken: “16,26,5,6” didn’t work — there weren’t 26 paragraphs (the 2nd number) on page 16. I glanced at the 2010-2012 reports, they weren’t any better, so I skipped this and tried the next, which was “L,” so this was probably “EMAIL”. (looking back now, I see that a comma got dropped, and I should’ve noticed that “16,26,5,6” really should have been “16,2,6,5,6” and the missing “I” would have been right where I expected it).

Though the final message was clear pretty quickly, I kept on decoding right to the final character, and only then did I send the email. The message read:


Which I did. Then I checked Twitter. And saw that someone else had won almost exactly an hour before me. Arrrgh!!

Still, though I didn’t win first prize, it was a fun puzzle, as expected. As I said earlier, this one felt a little different, with very little real cryptography or even puzzle solving, and a lot of finding exactly the right hint at the right time. It definitely needed a different mindset to attack, and I think that hurt me a bit, especially when I found myself mired in stego and website tarpits. Keeping an open mind and regularly stepping back to look at the big picture was key to finishing this challenge.

For fun, I created a flowchart showing the circuitous path I took to complete this puzzle. It’s especially frustrating to see all the dead ends I visited, compared with the “ideal” path straight down the middle. Even more so when I see visually described the opportunity I missed near the end, and most especially when I think about the “Just skip past the entire puzzle and jump straight to the last stage” troll via last year’s Ima Hintz blogger account.


Congratulations go out to Mike Czumak (@SecuritySift, twice before a DBIR Honorable Mention finisher) and his teammates @Blackjack988 and @LaughingWill. They’ve posted a great writeup themeselves, and it’s definitely worth a read.

I’ll get you next year.

Categories: Cryptography, Puzzles

2012 Verizon DBIR Cover Challenge

March 28, 2012 3 comments

Every year, the Verizon Business Risk Team publishes a Data Breach Investigations Report (DBIR), analyzing trends and other great statistical information gathered from working hundreds of different, well, data breaches. For the past few years, the report has included a puzzle / challenge / crypto contest. I heard about the 2009 puzzle too late to play, gave up in disgust trying the 2010 puzzle, and skipped the 2011 puzzle (’cause I was actually working another puzzle at the time). This year’s report came out a few days ago, and I immediately launched into trying to solve it. It took a few days, but I managed to not only solve the challenge, but I came in first! Of course, as I’m prone to do, for every little step I took forward I first took about three giant steps sideways (often repeated in two or three different directions.)

As always, if you’d like to try to solve this yourself, then STOP now, as the rest of this post is full of spoilers. If you’d like to see just what you need to complete the puzzle, with no spoilers, click here: Verizon 2012 DBIR Sources.

Where do we begin? Looking at the cover, I see some interesting things…but nothing that I can work with right away. In past years, there was a big block of encrypted text hidden in the PDF, so I pull out some tools and find that (actually, simply a select-all and copy would also find it, hidden behind the image on the front cover).


This text decoded, not to an encrypted binary, but to a poem:

Thank you for participating in the 2012 Verizon DBIR Cover Challenge.
We hope you enjoy this challenge as much as we have enjoyed creating it.  

There once was a lady from Nantucket,
With text so wide we could grok it.
we chopped and sliced it all day long,
Only to find she wasn’t all wrong.

With skill and ease we battled this fight,
Except she was not totally right.
Twisting and turning we kept on strong,
We should have been singing all along:

Mary had a little lamb,
little lamb, little lamb,
Mary had a little lamb,
whose fleece was white as snow.

And everywhere that Mary went,
Mary went, Mary went,
and everywhere that Mary went,
the lamb was sure to go.

It followed her to school one day
school one day, school one day,
It followed her to school one day,
which was against the rules.

It made the children laugh and play,
laugh and play, laugh and play,
it made the children laugh and play
to see a lamb at school.

And so the teacher turned it out,
turned it out, turned it out,
And so the teacher turned it out,
but still it lingered near,

And waited patiently about,
patiently about, patiently about,
And w8ed patiently about
till Mary did appear.

"Why does the lamb love Mary so?"
Love Mary so? Love Mary so?
"Why does the lamb love Mary so,"
the eager children cry.

"Why, Mary loves the lamb, you know."
The lamb, you know, the lamb, you know,
"Why, Mary loves the lamb, you know,"
the teacher did reply.

That’s neat. Now what?

Well, there are a bunch of numbers on the cover. There’s a 405 in ‘h4x0r5,’ and phone numbers on another sign. Though these phone numbers are incomplete, and don’t even seem to have a real area code. Maybe I need to use those numbers as an index into the poem — like find the 405th character, the 696th character, etc. If I include the stray “8” in the poem (“and w8ed patiently about”), then I’d have enough for a 5-letter string, maybe as a code at a URL shortener.

But none of this worked, and after a day or so of playing with this a little, a hint was given on Friday night that told us “If you found Mary, you’ve gone too far.” So the whole poem might even be a red herring. This means I don’t have much at all to work with. Just the numbers. And the cover.

Saturday morning, I played a little looking for steganography (looking at the lowest bit, and also treating the three numbers in the phone number as an RGB triplet to search the image for), but gave up on that pretty quickly. Maybe I can get an IP address out of the numbers. I tried factoring the numbers but found nothing obvious. I tried treating it as a single number and converting that to a dotted-quad internet address. That didn’t work. I even tried dropping the first or last number to treat them like hex (0x69651321) but again, no luck.

Finally, I tried (this made some sense, since one copy of the number was torn off leaving only the last digit behind), and found a website that looked promising: An unconfigured WordPress blog, but after several minutes of explorign I didn’t find anything useful there. Then I realized, wait, I haven’t tried yet. Trying that got me “Server 1 online.” I then tried that on port 443, and got a certificate mismatch error — telling me that I was trying to connect to

Alrighty, then! Pastebin! But what paste?

I tried searching for different strings from the signs on the cover, and for things like DBIR and Verizon, but had no luck. Finally, I hit paydirt with “half million personal” — and got a huge list of hashes. There were over 14,000 of them…but as I looked closely, I noticed that one of the hashes was short (the last digit had been dropped). Then I saw that a lot of them ended with the same numbers (which told me they were probably LANMAN hashes), and looking even further, saw there were a lot of full-on duplicates. After passing the list through a couple of awk and sort | uniq -c steps, I found that one hash, and one hash alone, was unique in the entire file.,98B451441C75C9F0F3BD49EDF32EB4A4

It only took another minute to lookup that hash online, and found that the password was “PINTEREST.” Cool! So I dashed off to Pinterest and looked for the name associated with that hash, which was “imahintz” (which, obviously, would’ve been a good clue if I’d taken the time to look at all 14,000+ emails).

The Ima Hintz user had five pin boards: Crafts, Favorite Places, People, My Style, and Recipes. Right off, the Style board catches my attention because of a picture of Chuck Testa, subject of a recent viral Internet meme and mentioned directly in the DBIR. Most of the rest of them just look like silly pictures to help fill out the account. Looking at the activity history, the most recent items to be pinned were four people (Larry Wall, a soccer player, Q-Bert, and Lincoln), then Chuck Testa, something about Oxygen, a couple of recipes (Mojito foam and Cupcakes), and finally, an image of ASCII art spelling “Challenge.” So let’s look at that last one!

That takes me to a blog, where I see the Challenge image (ironically, not even ASCII at all but a .png image), and some DBIR logos, and a big present made out of base-64 looking code, complete with a ribbon and bow. Decoding the base-64 (which I note has only lowercase letters) gives me a big chunk of binary, which I assume must be the ciphertext. I tried a bunch of keys (variants of phrases associated with Chuck Testa, also stuff from other images on the Pinterest account, like Puddy’s Eight-Ball jacket, etc.), not really expecting it to be that easy. It wasn’t.

                               ****       ** **  
                              **  ***   ***  *** 
                             ***    *** **  ***  
                               ***    ***  ***   
                                 ***   *  ***    
                                   *** * ***     

Then I noticed that the cupcake recipe is called “Encryption Cupcake Recipe.” Cool! The recipe has little bits that can help, like -nosalt and “a pinch of OpenSSL” but not much more. And I’d already assumed the -nosalt based on the ciphertext I was working with. I also checked the original recipe that this one credited, and saw that they’d added caramelized bananas, but didn’t think that was significant.

All along, I’ve been keeping @wadebaker informed of my progress (he’s a member of the DBIR team, and seemed to be tweeting the most about the contest). I mentioned that I was thinking the key might be in one of the password hashes, and he told me “I think u prolly got all u needed from that step.” Because I was addled, or hungry, or just stupid, I read that as “Good idea, you have all you need to make that happen.” What he meant, I learned a couple hours and 99% of the passwords later, was “No, you’re done with that step, move on.” D’oh.

So I’m back to looking at “the gift.” Interestingly, it’s almost the same size and shape as the base-64 code that gave us the opening poem — a couple characters too narrow, and a line too short. It’s also all lowercase, which I belatedly realize would be next to impossible to force if you’re encoding a random binary file (which an AES ciphertext would closely resemble). No idea why I didn’t think of that before. So maybe it’s uuencoded, not base-64? No, that has the same problems. Maybe the whole thing is base-36? But how would you convert that back to 8-bit binary? You’d need, maybe, to have two-character pairs (essentially, base-676 digraphs) and as long as no digraph ever reached 512, that’d be a 9-bit value represented by each digraph. String enough of those together, divide into 8-bit chunks, and you’ve got output. Voila! Except…well…that’s a bit crazy, even for me.

After telling Wade all this (and admitting how far afield I’m drifting) he suggests that this step might be “more puzzle than crypto.” So, okay, regroup, and revisit the original poem. It mentioned slicing and chopping, twisting and turning — maybe this is a big transposition cipher, and I need to shift rows around and such. But that seems almost as complicated as my base-676 craziness, and I don’t think much about it. Well, let’s fall back to looking for something hidden behind the text, and look at the HTML source for the gift image.

Interestingly enough, it’s all broken up. There’s an 8, then a bunch of characters in a single SPAN tag, then another 8, then another SPAN of other characters, then another 8…. Not wanting to jump to conclusions, I painstakingly check every single row in the image and, sure enough, every single 8 is separated out from the other characters. There’s something special about the 8s. Which I should have noticed earlier — a bunch of the pictures on the Pinterest site had prominent 8s, the poem had an 8 in ‘w8ed’, and even a couple of the hints on twitter had used 8 (like “devest8”).


Also, the report itself mentioned that they’ve been producing the DBIR for, wait for it, eight years. Another interesting thing, is that when I hide all the other characters (turning them just to dots), there’s a big multi-line gap about 2/3 of the way down without a single 8 in it. None of the other characters show this — they’ve all got more normal looking distributions. Again, clearly, there’s something special about the 8s. But what?

Crazy Eights

I tried resizing the array of characters, thinking that maybe it’s supposed to turn into a picture. Or maybe if I resize it to 8 rows, it’ll be like 8-bit-wide paper tape. Or maybe it’s Morse code. But ultimately, there’s just not enough information there. There are only 32 of the 8s, that’s just not enough to convey anything useful, at least not as bits. But perhaps it’s the spaces between the 8s that matter — and I count them out and convert them to letters, but again, this gives me nothing, even when I try various Caesar shifts on the output. So…Saturday ends with me having made some good progress, but still feeling quite stuck.

I get back at it first thing Sunday morning (after the kids have dragged me out of bed to investigate a robin that’s been attacking its reflection in our dining room window). The ribbon on the gift looks almost like axes on a graph, but I can’t think of how to use that. With nothing else to go on, I tried playing with some of the other images I’d seen — cupcake pictures, etc. — looking for more stego, using the tool they used last year. Then I get a note from Wade: “What does Mary live in?” I immediately think of the original base-64 text from the report cover, and instantly I know what the trick is: A grille cipher. And I realize that I’d, again, been shortsighted: removing the ribbon (as I thought the stars that made it up were just window-dressing) resulted in a gift image that was smaller than the base-64 text that produced the poem. But leaving it in place meant the gift was exactly the same size. Which absolutely should have been something I paid more attention to.

Fifteen minutes later, I’ve written a script to simulate the grille: it converted both the gift and base-64 text to long strings, and counted forward in the grille string. Whenever I encountered an ‘8’ in the first, I output the corresponding character in the second.

Another way to imagine this is to simply layer lines one atop the other:


This gave me a base-64 string:


Which, when decoded, gave another base-64 string:


Just like it’s pretty much impossible to make a random binary encode to an all-lowercase base-64 text, it’s very unlikely that a random base-64 text will decode to another valid base-64 text. So I take this as an indicator that I’ve finished this stage successfully, and go make breakfast. While eating (“Daddy, why do you have your computer at the table?”) I look around the Pinterest page again for other ideas on keys.

Where’s the Key?

Two years, ago, the key was a phrase that you had to find on the web. Last year, they made it somewhat more explicit and had the key hidden as stego text inside an image. So this year, I was looking for something equally clear (and hopefully directly visible). I revisited the script I (unsuccessfully) used in 2010, and added things like “nope! Chuck Testa” (referred to in the DBIR text), “All signs point to ‘Yes!'” (from the page describing Puddy’s Eight-Ball jacket), and several other variants and other phrases and words. All with different uppercase and lowercase and punctuation permutations. None of them worked.

Then I realized I was just spinning my wheels (and was feeling stressed ’cause I just knew someone else must be about to beat me to it). So I stepped back and looked around a little more…and looked more closely at the cupcake recipe. The only thing that was changed from the original recipe was the addition of the bananas. I looked, again, very closely at the image of the torch on the banana slice, and saw nothing. I also looked closely, perhaps for the first time, at the picture of all the cupcakes, and noticed “-base64” written next to one of the banana slices. Superimposed on another was “-rc4-40.” Aha! So now I know exactly what cipher to use (and it wasn’t one I’d been testing against). Updated my script, ran the keylist through again, but still, nothing.

Stepping back for a moment was so helpful that I did it again, and sat staring at Ima Hintz’ home page for a little bit. Wait — there’s an 8 I totally missed. It looks like a bumper sticker, with “Mark it 8, Dude.” on it. I opened up that pinboard, and that image was one of only a few with a caption: “Markitdude.” (was this a pun, to refer to the “marketing dudes” who probably end up paying for the contest prizes?) I added both of those to my list, ran it, and…success!

   **** DINGDINGDING ****

   Password: Markitdude
   Output: email 8trak 2dbir

At 11:40 am on Sunday, after half-hearted poking around on Thursday and Friday and a nearly all-day bender on Saturday, I’ve solved the puzzle.

I immediately sent off a DM to Wade, and followed up with an email to the dbir email address sprinkled throughout the DBIR text. Then I went to my mother-in-law’s house to help with some light fixtures (but I brought my laptop with me, just in case). And waited. And waited. Finally, about 3:00, I heard back — I’d won! Woohoo!

Too Long; Didn’t Read

(Yes, I know that’s supposed to go at the top, so you don’t have to read all the rest of this. Tough.)

  1. Find the base-64 text hidden on the front cover. Don’t bother decoding, the content is a red herring. But do add some newlines so it looks all nice and pretty.
  2. Convert the incomplete phone number (696) 513-216 to the IP address, and go there using HTTPS to get redirected to
  3. Enter the text from the sign which had the phone numbers (“half million personal records”) to get a password dump.
  4. Realize that the dump is full of duplicates, but also includes a single unique hash.
  5. Crack that hash to get pointed to, and use the email address for that hash to get the Pinterest user’s ID.
  6. Find the Challenge picture on the Pinterest site and, clicking on it, find the ASCII “gift” image.
  7. Realize the importance of 8s (by viewing source on the gift image, or by noticing all the 8s in all the pictures, or by looking at the visual distribution of each character in the gift and seeing that 8 is “different” from all the rest).
  8. Realize that the gift, and the base-64 text from step 1, are exactly the same size and shape.
  9. Use the 8s as a grille cipher, and uncover the corresponding characters from the base-64 text.
  10. Decode that string to get another base-64 string. This is the final ciphertext.
  11. Find the “Encryption Cupcakes” recipe on the pinterest page and see the clues in the text and the picture: openssl, -nosalt, -base64, -rc4-40.
  12. Look around the pinterest site some more, and see the “Mark it 8, Dude.” picture, and realize that it’s only one of four pictures with a caption (another was the 3 Wolf Moon t-shirt from last year’s puzzle).
  13. Use that caption as the decryption key.
  14. Win.

For completness’ sake, here’s a command to perform the final decrypt (all one line):

echo 'WXGZlUhjesm8qSUjmSmOveRG' | openssl enc -d -rc4-40 -base64 
    -nosalt -pass pass:Markitdude


This was an excellent puzzle. It had lots of clear indicators of success, but also plenty of distractions. I spent some time searching for things like “wadebaker” and “pirogue” because of random, offhand tweets he’d made. There were lots of interesting looking comments around Figure 42. Chuck Testa satisfied the need for a meme, like last year’s puzzle. Not to mention the cryptic text in the initial red herring poem.

Ultimately, though, everything we needed to win was on some kind of page or document created or maintained by the DBIR team. Nothing came from any 3rd party page (no comments on YouTube videos, or in Amazon listings, or on the Puddy or Chuck Testa pages linked in Pinterest). All clearly marked, and very “conspicuous” (which was the twitter ID used for some of the hints, and the name of the user who posted the password dump). The big trick was simply noticing everything. And, as I’m sure was the case for many other players, I skipped right past most of the clues the first two or three or four times I looked.

It had a modern cipher (the RC4). It had a classic cipher (the grille), which was a little bit obscure, but I was actually thrilled to see it used. It wasn’t easy, but as usual, a large degree of the difficulty was simply My Own Fault, for missing things, or making stupid assumptions, or conveniently overlooking what should have been blazingly-bright red alarm lights that I was Doing It Wrong.

But as I completed each stage, the right answer was clear and hard to miss. The grille and original base-64 text being the same size. The 8s having a markedly different distribution. The base-64 text decoding to base-64. The final key being one of only four captions in the Pinterest account.

Bottom line: I absolutely loved this. Favorite part: The grille cipher, just because it’s a part of cryptographic history and I haven’t seen it used in a puzzle like this before (and it was used, I think, very well).

So, in the end, a big thanks to the DBIR team for a fantastic puzzle, an awesome prize (iPad!), and of course, thanks for the excellent Data Breach Investigation Report itself: for all the effort the whole team put into the collection and analysis of the data, and especially for making the report available to all the world for free.

Hopefully next year I won’t make as many mistakes.

Categories: Cryptography, Puzzles

BSides Phoenix 2012 Badge Puzzle

February 19, 2012 Leave a comment

Sitting at home yesterday morning, watching cartoons with the kids and checking my Twitter feed, I saw a tweet from Georgia Weidman with a picture of the badge from BSides Phoenix. It looked like an awesome badge, made out of hefty chrome and with an integrated bottle opener. It also had a puzzle on it. There goes the rest of my morning….

As always, if you’d like to try to solve this yourself, then STOP now, as the rest of this post is full of spoilers. If you’d like to see just the images needed to solve the puzzle, click here: BSidesPHX 2012 Images.

The badge has a hexadecimal string all around the edge. And also some other text — SNOW, and the con name:

SNOW 0E071A1F4D495C09001848140240462117025EF BSIDES PHX 2012

The first thing I did was to count the hex digits. There were 39. Really, 39? That’s an odd number — usually hex is presented in two-digit pairs (each pair representing a single byte). Why the extra digit?

I looked at two ways to split the string up. Either the trailing “F” was unnecessary (or at least unnecessary for the time being), or the leading “0” was. Splitting the digits up the first way, I got:

0E 07 1A 1F 4D 49 5C 09 00 18 48 14 02 40 46 21 17 02 5E F

Grouping them like this, the first digit of each pair is one of only 5 numbers: 0, 1, 2, 4, or 5. This actually looks very promising, as most ASCII text is limited to only a few initial digits as well (all printible characters being in the 2x-7x range). If this is the right arrangement, then it’s extremely likely that this is a simple XOR code.

But just to be sure, let’s look at it the other way:

E0 71 A1 F4 D4 95 C0 90 01 84 81 40 24 04 62 11 70 25 EF

In this case, the leading character is much more random, being chosen from 13 of 16 possible values: [01246789acdef]. Again, this tells me that the first arrangement was right, and that the string is ASCII, but with bits flipped via XOR.

Naturally, I have a tool that does this for me. The first thing I tried was obvious keys from the badge itself: SNOW, or BSIDES, etc. My tool took each byte in the key and used the eXclusive OR (XOR) operation against corresponding byte(s) in the ciphertext. It occurrs to me that I’ve never explained how this works, so here’s a quick digression.

Take the ciphertext stream 0E 07 1A 1F and look at each
as bits (I'll just do 0E):

    0000 1110  (hex 0E, 1st byte of ciphertext)

Now take the first character of your key and write it
underneath the ciphertext bits. I'll start with "B" 
for "BSides":

    0000 1110  (hex 0E, 1st byte of ciphertext)
    0100 0010  (hex 42, "B" in ASCII)

Now, for each bit position, we XOR the key bit
against the ciphertext bit. This works like a 
normal logical OR operation, except for the 
exclusivity requirement: If BOTH input bits 
are 1, then the output is 0. That is (here I'll 
use ^ to represent XOR), 0^0 = 0, 0^1 = 1, 
1^0 = 1, and 1^1 = 0.  So the result, written 
below, would be:

    0000 1110  (hex 0E, 1st byte of ciphertext)
    0100 0010  (hex 42, "B" in ASCII)
    0100 1100  (hex 4C, or "L")

Repeat this with the next ciphertext byte, and the 
next key byte. When you reach the end of the key, 
start over with the first byte of the key, and keep going.

Trying “BSides” as the key, I get “LTs{(” as the beginning of the decryption. Doesn’t look right. SNOW isn’t much better: “]IUH”. And they both have bunches of control characters and other non-printable bytes in the output. After trying a few different keys, I tried a few different plaintexts. The neat thing about an XOR code is that it works both ways. If you try a plaintext as the key, the result is actually the key that would generate that plaintext. So I tried “WWW” and “” and a few other URL shorteners, but got nothing that looks like a real key.

Now I’m wondering about the non-printable characters, and I begin kind of staring at the 1st character (or nybble) in each byte. They seem to be not randomly distributed, and I kind of separate them like this:

0011 445 001 4 10 44 2 10 5

This looks sort of interesting. But I can’t think of how a key might produce such a pattern — or what kind of plaintext would match it. Four characters in one block (like all caps) then 3 in another block (maybe lowercase?) etc. xxxx-yyy-xxx-y-xx-yy-z-xx-y. In fact, it looks like an all-lowercase key guarantees me all printable characters, but that still doesn’t help. This is getting me nowhere, and the kids are clamoring for lunch. So I make lunch, while staring at the code, and as we’re eating, I cast about on a key hunt.

While looking at the BSides PHX home page, I saw an image with the stenciled, painted words “F SNOW” (the page referenced Snowmageddon from 2010, and how there’d be no snow in Phoenix). So I tried FSNOW as the key, and got this:


Success! No. Didn’t work. I’m still missing something in those unprintable characters… What if…the first “.” after “HTTP” is supposed to be a “:”? What key letter would produce that? Changing my key to “FSNO:”, I get:


So I should use a lowercase w instead of uppercase? Wait, didn’t I already determine that the key should be all lowercase anyway? Stupid me. Let’s try “fsnow”:

There we go, much better. It also fits that “xxxx-yyy-xxx-y-xx” pattern I noticed earlier. Also, I should note that I’d tried forcing keys based on a plaintext that started with www or or other similar URLs, but never tried “http”. If I’d tried that, I would have had the key like 5 minutes into the game.

The URL redirects my browser to a photo of Caesar’s Palace in the snow. Cool, snow in Vegas. Is there something hidden in the image? Using “strings” I find, at the very end of the image file, the following string:


Rot-13? Nope. But it almost has to be a simple shift — after all, it was a picture of Caesar. And turns out ROT-14 was the answer. This would correspond to an encryption offset of 12, which might represent 2012, or might just be a coincidence. At any rate, now I have a new URL to visit:


Hm. Hyphen? That’s weird. And what do I do with the hex? A little playing didn’t get me anywhere, so I tried it as-is, only changed the ‘-‘ to ‘/’ because otherwise it wouldn’t do anything.

This loads up a web page that says, simply, “congrats!” with a link. Clicking that pops up a mail window to a gmail address, with the subject “I win” pre-loaded. Rapidly, I fill out the email (worried that someone else might be beating me AT THIS VERY MOMENT) and ask, is there a prize? (I also mentioned that I’m perfectly happy allowing any prize to go to someone who’s actually AT the con, but at any rate, if they have any extras I’d love one of the awesome badges).

I got a response from Skyler Bingham a few minutes later, saying that I was the first to solve it, and that, certainly, he’d mail me a badge. Cool!!

I announced my victory on Twitter, but quickly followed up with a message that people at the con should keep trying, as it was an easy and fun puzzle. I don’t know if anyone else solved it, but did see a couple people tweeting about it. Of course, this was probably a pretty small event, so I don’t think there were that many people even playing.

But… What about that extra “F” at the end of the hex? I never needed that for anything, did I? Well, about 5 minutes after I’d heard from Skyler, it hit me: The F wasn’t part of the hex, it was part of “SNOW” at the top of the badge. That’s right, it wasn’t “SNOW (hex) F,” it was “F SNOW (hex).” The key was right on the badge all the time. Sneaky!

Thanks for the fun puzzle, Skyler!

ShmooCon 2008 Badge Puzzle

February 4, 2012 4 comments

I’ve been having a great time solving puzzles at security conferences. I think the first significant puzzle I’d seen was at ShmooCon 4, in 2008, but I didn’t even try to solve that, partially because the bug hadn’t yet bitten me, and partially because I didn’t have any computer with me at the time.
So now, four years later, I figured it was time to finally complete this puzzle. They gave a rough outline of the solution at the closing ceremony, but for this puzzle the challenge was less of a mystery than an implementation problem.

As always, if you’d like to try to solve this yourself, then STOP now, as the rest of this post is full of spoilers. If you’d like a copy of just the raw data (a file containing an ASCII representation of all the badge data), click here: ShmooCon 2008 Badge Text.

The puzzle was entirely contained on the badges for the conference — 16 different plastic badges, each with a different pattern of dots. Clearly, these were meant to look like punched cards, though apparently many of the attendees at the conference didn’t recognize them as such. Each card had 30 columns along the long edge of the badge, and 12 rows across the short edge. Generally, punched cards were “read” horizontally, but since the badge included a “ShmooCon 4” logo that needed to be read vertically, that’s how I’ll discuss the cards here. Plus, it’s a lot easier to analyze that way.

Each row (I’ve rotated them, remember?) is therefore a 12-bit word. But which side is the high bit? A little experimentation and analysis of all the cards shows that many cards included “punches” only on the right half of the card. If one interprets those bits as the lowermost 6 bits in the word, then those pretty clearly represent ASCII letters. So it seems that the high bit is on the left (column 0) and least significant bit on the right (bit 11).

This is nice, ’cause that’s also how most people tend to visualize bits in a word.

But two questions remain:

  • How do we put the badges in the right order?
  • What does the non-ASCII code mean?

To put the badges in the right order, the puzzle creators included an extra hint: a series of solid and broken lines at the top of the badge. These represented hexagrams from the I Ching: using the classical King Wen sequence, the badges can easily be placed into the correct order.

The other question is a little more difficult. I couldn’t find an example of this kind of punched card online, and even if I could, the same kinds of cards were frequently used for many different systems. According to the presentation in the closing ceremony, they provided a few hints during the con. One of these told players to think about a “12-bit computer from 1967” and an admonition to “Please Don’t Participate” in the puzzle. These were meant to lead us to the PDP-8 minicomputer.

When working with these cards, it’s important to remember that octal, rather than hexadecimal, was generally used when dealing with the PDP-8, as the 12-bit word is exactly 3 octal digits. So, let’s take the punched cards and figure out what the octal (and, when appropriate, ASCII) values are for each row.

Here’s what the first card in the sequence starts with:

Punches      Octal  ASCII
.....*..**..  0114   L  
.....*...*..  0104   D  
......*.....  0040      
......**..*.  0062   2  
......**..*.  0062   2  
......*.....  0040      
.....*...***  0107   G  
.....*..****  0117   O  
......*.....  0040      
......**.***  0067   7  
......**.*.*  0065   5  
......*.....  0040      


First, I had to find a PDP-8 emulator, and that was troublesome. Eventually, I found one that seemed to run, and seemed to be able to load the data in a format I could readily produce. And, fortunately, it also seemed to be the one they used in the slides in the closing ceremony.

The program, PDP8, was written by Brian Shelburne at Wittenberg university, and while not quite as flashy as some emulators, had the advantage that it worked out of the box. The disadvantage is I had to run it in VMware — a Mac running a Windows emulator running a PDP emulator. Inception, indeed.

Tougher than finding the emulator, though, was figuring out how to get the code loaded up. The different emulators I tried support several object data formats, including several emulated disk and paper tape files, but none of them seemed to work for me. In the end, it turned out that I needed a flat ASCII file formatted like this:


The first word (in octal) gave the memory address into which the second word is to be loaded. But even this didn’t work for a long while, until I realized that the emulator needed the text file in “DOS” mode — with CR/LF for each line ending, instead of the LF-only ending used in UNIX. Once I passed that obstacle, I was able to easily load the data into the emulator. But it still woudln’t work.

The first words on the first card, “LD 22 GO 75” seems to be directed at the player, not at a computer. I interpreted this as “load from word 22 and begin execution at word 75” — meaning skip the first 21 words and begin loading the program from the 22nd word. But several questions remained: Are 22 and 75 in decimal, or binary? Is the 75 before or after you remove the leading 22 words?

After a long while, I looked back at the closing ceremony video, and saw a bunch of what looked like null words at the top of the debug screen (they were hard to read, but looked like they were probalby all 0s). Counting blocks, I saw 18, which, in octal, is 22. So I had it backwards — I had to load the entire data stream, but load it into memory beginning at location 22, instead of starting at zero.

So once I’d worked out the file format and where to load the data, I typed “g 75” and the program ran:

    R:TMW B3M W:412 M:HAK P: S->H M->O
    Passwort eingeben:

This is pretty clearly settings for an Enigma machine (the German password prompt was kind of a hint as well). Wheels 4, 1, and 2, in that order. Ring settings for the wheels at T, M, and W. Stecker connecting S to H and M to O, and finally, set the rotors to HAK. Once all that is set up, type in the ciphertext (MICCKF…) and you get:


So now I’m looking for somethig in some vaguely-defined region in Europe. Of course, there’s one problem: there’s an awful lot of planet that’s both east of Kyrgyzstan and west of Bulgaria. It seems that this is a hint, to read the last word backwards: “ILITAHS” backwards is “SHATILI,” which is a city in Georgia. Entering “Georgia” as the password in the emulator decrypts the final ciphertext and provides the answer:


I sent that message off to Adam Cecchetti, the principal creator of the puzzle, and he confirmed that this was the right answer. He also confirmed that, as far as he knew, I was the first person (outside of the beta testing) to finish the puzzle. Of course, most people have probably forgotten about the puzzle at this point, anyway…

The hardest part of all this was the PDP-8 emulator: both finding one, and getting the code to properly load and execute. Interestingly, it is possible to solve this without ever actually needing the emulator.

PDP-8 operations use the three highest bits to define the operation code, and the lower 7 bits for data and for memory addressing. Stretches of code that contain just ASCII data, then, have those top three bits set to 0 and are therefore fairly easy to detect, especially when looking at punched cards. There are 5 blocks of ASCII data:

    LD 22 GO 75


    Passwort eingeben:

    R:TMW B3M W:412 M:HAK P: S->H M->O

    ^A,!6G1Mg1*>+I)^N(UR4&7^N;R5,%g5& &=$g4:7"'


    HHello World

The first indicated where to load the data in the emulator, the next two blocks are easy to recognize as leading to the Enigma machine, and once one decrypts that, the final key Georgia is found as before. But what to do with it? The last block (Hello World) is an easter egg (a snippet of code just prior to the string actually prints the mssage out). It seems likely, then, that the fifth block (^A,!6G1M…) is a ciphertext. Performing an XOR operation against that string using Georgia as the key produces the final phrase, without ever needing the emulator.

Interestingly, not only was there an easter egg at the end, but a subtle joke embedded in the code. The string “R1JND43L?” was, according to Adam, a reference to earlier plans for the puzzle: They’d first planned to encrypt the final clue with AES (originally named “Rijndael”), then swithced to Lucifer, the precursor to DES. Finally, they simply used XOR.

In the end, this was a fun puzzle, though I have to admit that I’ve criticized it over the last few years. Reliance on a PDP emulator makes for a tough puzzle to solve, and I do prefer those puzzles which can be solved with paper and pencil alone. However, as I mentioned, this can be solved without the emulator, though it requires guesswork and a little luck. Of course, if one were to recognize the code as from a PDP-8, it’s a short enough program that it can easily be figured out just by reading the disassembled instructions.

Either way, I’m glad I finally took the time to finish the puzzle, and wish I’d tried this long ago. Complexity aside, it’s quite an interesting challenge, and I really enjoyed trying to figure out how the PDP-8 instructions worked. (I’d been fortunate enough to do some assembly on a Sperry/Unisys mainframe in college, and this brought back some fun memories).

Thanks especially to Adam Cecchetti (responsible for the PDP-8 code and co-designer of the puzzle), 3ric Jhanson (co-designer), and Aether (badge design), for a great challenge, and my apologies to all for taking four whole years to finish it.

[When trying to finish this, I half-disassembled the code using a script and a whole lot of referring back to Wikipedia. Adam was kind enough to send along a copy of his original source, and I’ve used that as an additional check / reference, and produced a detailed, annotated copy of the badge data. It’s not really meant to be used as a source for an assembler, but instead lets you see what every row on every badge is, both code and data blocks. Click here to download a copy.]

ShmooCon 2012 Badge Puzzle

February 3, 2012 5 comments

For three years running, I (or I with a co-worker) have been the first person to solve the ShmooCon Badge puzzle. (I’m also, I believe, the only outsider to have solved the 2008 badge puzzle, but that’s another post). Seems like it’s time for me to stop playing.

So I asked Heidi if I could do the puzzle this year, and she agreed. We went back and forth many times over a few weeks, and got a lot of advice and suggested changes from G. Mark Hardy (who’d written the last three puzzles). Finally, just a few days before everything had to go to the printers, we put a fork in it and decided the puzzle was “done.”

Since the theme for the con this year was, loosely, gearheads, I chose a puzzle with some mechanical/crypto components. All in all, there were seven gear-shaped badges, several images in the program, and a couple extra bits of crypto text.

As always, if you’d like to try to solve this yourself, then STOP now, as the rest of this post is full of spoilers. If you’d like a copy of just the raw data (ciphertexts and other clues revealed during the contest), click here.

The first element of the puzzle that everyone saw was, of course, the badge. In addition to the “expected” badge elements (ShmooCon, plus Speaker or Attendee or Staff), the badges featured:

  • Letters all around the edge, in the gear teeth,
  • A six-letter string at the bottom, and
  • A four-digit number at the top.

Hidden in the program was the first hint:


The hope was that this hint would encourage players to find the correct order for the badges, as well as the fact that they need to line up in some way. The trouble was, how do you order them? A natural guess would be to use the numbers, but are they supposed to go in numerical order or something else?

That was the point of the “slash or dot” element of the hint. If you were to add a slash to the numbers, where would you put it? Turns out, these numbers (selected by G. Mark) were actually the start dates for ShmooCon 1-7. Put them in the proper order by year, and that’s the order for the badges.

So badge data, in order, looks like this:

               Teeth (clockwise from top)
#  Bottom  Top   0 1 2 3 4 5 6 7 8 9 10 11
1  CGARIN  0204  Y I I E O E O E K T A  T
2  OEDNCE  0113  C O T R T A T U D W A  S
3  NATOKX  0323  H C O T M H C H S A U  C
4  NRONRT  0215  H A O T C N R L E U H  N
5  ESPEEE  0206  L E S K A E O K U D N  B
6  CRTCAT  0205  G A A D E R W W E S E  T
7  TEULDC  0128  A Y S H R H N Y L C S  E

That was “Stage 0.” The goal of Stage 1, then, is to read the message hidden in the six-character badge strings by stacking the badges in order and reading down the columns.

What’s interesting is that you could bypass the entire ShmooCon date index altogether. For example, if you looked at the frequency analysis for Stage 1 (the six-letter strings), you’d see something that looks remarkably like normal English text, with E being the most common letter, and C, N, and T tying for 2nd. It’s a small sample size, but even still definitely doesn’t look like a typical sustitution cipher output. This should tell the player that it’s some kind of transposition cipher — that is, the letters are simply scrambled, not changed.

So to solve this in that way, it’d be necessary to try to re-arrange the letters until you get words. As I mentioned later, “it’s best to try the easy approaches first,” so the easiest approach here would be to assume each six-letter string needs to stick together, and it’s just a question of re-arranging them to build words. If you look at the last letter of each row, there are only 5 letters in use: C, E, N, T, and X. So immediately, one might consider the words “CENT” and “NEXT.”

There are four ways to do this: The N and X remain constant, but you have to try two different rows for E and for T.


In two of these, the 2nd column spells “GSAR,” but in two of them, it spells “GEAR.” The other columns don’t do much, but there are only three other rows to try to add to the bottom to build new words with, so it should fall out pretty quickly. For example, if you add ESPEE next, then the first column becomes “CONCE” or “CONNE”, depending on what you picked for the fourth row, while the 3rd column ends with “TOP.” And so forth.

I don’t know if anyone actually tried this approach. I’m hoping some people at least considered it.

Regardless of whether you used the number index or just brute-forced the strings, the result of Stage 1 is instructions for Stage 2:


Again, thanks to G. Mark for taking one of our rough ideas (“wouldn’t it be cool if people had to actually connect the badges together and turn them to get a message?”) and making it into something that actually works. But how do you connect the gears? There was a hint for that, in the program:

Putting all the gears, in order, in an arrangement like that yields the first “machine” for this puzzle. To read this Stage 2 message, you’d:

  • Look at the top of a gear and read the letter
  • Turn the gears one click (top gears go clockwise, bottom counter-clockwise)
  • Look at the top of the next gear
  • Repeat

At the top of the first gear is “Y.” Turn the gears one click, and now the “O” that was at 1 o’clock on the 2nd gear is now at the top, so write down “O.” Turn gears again, and now the “U” that was originally at 10 o’clock on gear 3 is at the top. Keep doing this and eventually you get the message:


I’d considered several different keys for Stage 3, but eventually picked my own handle. I did this partially because there’s a history of the puzzle-maker using his handle as a key or hint (about half of G. Mark’s puzzles feature GMARK as a key at some point). I also hoped that, in looking up my handle, players would find my writeups from past puzzles and see that one particular cipher appears again and again. That’s the “classic code” that’s used for Stage 3.

Plugging Stage 3 into a Vigenere decoder, then:


Which brings us to Stage 4. As I was wandering around Friday night, I watched a table full of people working on the puzzle, and they’d already figured out how this stage works, even before they’d solved a single stage. Which was vaguely encouraging to me, to know that my contraption wasn’t that obscure.

Stage 4 required three elements: A ciphertext, a cipher, and a key.

The ciphertext was hidden on little “auto repair slips” scattered through the program (the “GATHER VINS” part of the clue). Collecting all 5, and putting the VINs in order based on the number in the middle of each, gives the following final ciphertext:


The cipher is a keystream-based cipher, where the keystream is generated by a 3-gear machine printed in the program.

That machine produces a different keystream (or, more accurately, a different segment of a single very long keystream) depending on what position the gears are initially set to. That starting position is the final “KEY” mentioned in the clue. In the image in the program, the gears are initally set to “TSG.”

But what’s the actual key you need to use? I thought and thought for a while on this one… Originally I wanted to use “OCT” (for ShmooCon 8), and figured that “10” in octal would be an interesting sort of hint, until G. Mark reminded me that “10” also looks like binary. Doh. So after about 20 minutes of brainstorming, we finally came up with “CAR” (Duh!!), and then I decided on something slightly more evil.

The key for the final stage is “KEY.”

I hope that annoyed…er, amused…at least some of the players.

Anyway, once you set the gears to start at KEY, you then read the top of each gear, turn, read the top of each gear, turn, etc. Not quite the same as the first machine, but I thought reasonably obvious (and as I said, at least one team figured that part out on Friday afternoon).

To solve this final stage, you take the ciphertext:


and subtract the keystream:


to get the plaintext. In this case, we’re numbering the alphabet from 0 (so A is 0, and Z is 25). So Z-B is 25-1 or 24, which is Y. F-R wraps around and gets you O., etc. You can also use the standard Vigenere tableau (it’s essentially the same operation, mathematically), or the “One Time Pad” tool on my favorite cipher puzzle site No matter how you attack it, the final ciphertext decrypts to:


I wasn’t in the building when the winning team came in with their answer, but apparently they actually walked up to Bruce and asked him. Informed that he would not be able to answer the question, the winners huddled over the con program for a while, then after additional input from Heidi, went off to “ask the Internet.” Ten minutes later, at about 12:40 on Saturday, they returned with the right answer: “Volvo.”

Congratulations to Mike Herms and Matthew Bocknek for solving the puzzle! I hope you enjoyed it.

(click here for the solution presentation from the closing ceremony.)

How to Lose $1000 in Vegas Without Even Gambling

August 30, 2011 1 comment

On July 15, Fidelis Security Solutions announced that they’d be running a crypto puzzle at Black Hat. And that the prize would be $1000. So, naturally, I was quite interested. I went to their site, downloaded the puzzle, and set to work:


As always, if you’d like to try to solve this yourself, then STOP now, as the rest of this post is full of spoilers. The text above is all that you need to get started, or you can click here to see the ciphertext and the hints that were revealed during the conference.

It’s immediately obvious that we’re not looking at straight ASCII. I figured it would be UTF-8 encoded, and verified that quickly. But the question then was whether the decoding work should be in UTF-8 or if, for example, I needed to convert it to UTF-16 first. I even considered that maybe I needed to look to the official Unicode name for each character, instead of the binary representation of it. Here’s the hexdump of the ciphertext, in UTF-8 (with newlines dropped for clarity):

c2 a5 c3 90 c2 a7 c2 b5 
c2 b6 c2 ae c3 86 c3 a4
c3 a6 c2 a9 c3 97 c3 a4
c3 b7 c4 b3 c5 92 c4 90
c6 86 c4 b7 c4 97 c4 b2
c5 a6 c5 af c5 b6 c5 ab
c6 82 c6 90 c6 94 c6 86
c5 a6 c6 89 c6 b6 c7 b4
c6 86 c6 85 c6 a6 c6 ac
c7 86 c6 b9 c9 87 ca 83

The little ^ character at the beginning made me think of XOR — since in many languages, that’s the operator used for that. So I need to find some binary key stream that, when XORd with the ciphertext, will give me plaintext.

I played with that for a while, then watched their little promo video again. And there, at the very end of the video, the phrase “ALL YOUR ¥Ð§µ ARE BELONG TO US” zooms past the viewer. So “¥Ð§µ” == “BASE”? Okay, that’s something else I can work with.

Another interesting thing that I noticed: in UTF-16, the first byte of each two-byte pair (each character is represented by two bytes) increases gradually over the entire ciphertext:

00A5 00D0 00A7 00B5 
00B6 00AE 00C6 00E4 
00E6 00A9 00D7 00E4 
00F7 0133 0152 0110 
0186 0137 0117 0132 
0166 016F 0176 016B 
0182 0190 0194 0186 
0166 0189 01B6 01F4 
0186 0185 01A6 01AC 
01C6 01B9 0247 0283

In the UTF-8 version, the first byte varies among c2, c3, c4, c5, etc., but is generally increasing (just not quite as clearly in the UTF-8 version). So it seems pretty likely that the first byte is irrelevant.

After a few days, pulling the puzzle out every now and then, the original puzzle page was removed and replaced with something that essentially said “You’re too early. Come back later for the puzzle.” Damn — maybe what I’ve been playing with was just a teaser, and not the real puzzle. Okay, I’ll forget about it for a while (and finish my talk slides…)

Fast forward to Black Hat, I stop by the Fidelis booth. And discover that the original puzzle is in fact the real puzzle. Arrgh! I could’ve been working on this all along!

Every few hours over the course of the conference, they sent out hints via Twitter. Predictably, the first few hints don’t help me at all, though one tweet “get to know xxd” helps. As sending the original ciphertext through xxd would just give me a straight UTF-8 dump in hex, I now know I’m supposed to use that encoding and not convert to UTF-16.

But that’s not helping me any. They tell me in person that the “BASE” bit wasn’t meant to mean anything, so that was just a red herring. They also tweet some of the plaintext (“Fidelis” is in it), but still I’m getting nowhere. I tried writing some tools that’d drag “Fidelis” across the ciphertext, looking at what the XORd keystream would have to be in order to produce that plaintext. That gets me nowhere.

A later tweet says that there are only 20 characters in the plaintext. Ooooh, that changes things. Now I’m playing with XORing two bytes in a row (like A5 ^ D0, then A7 ^ B5, etc.) but again, no luck. Another hint tells me that ¥ and µ are the same, but that doesn’t help either (one’s encoded as A5, the other as B5), and if we’re talking about two-character sequences, then now I’m really confused).

Finally, at 1:07 on Thursday, they released this hint: “‘C2A5’ =~ /.{3}(.)/”. This tells me that for every four-character hex sequence, I only need to look at the last character.

I get off the escalator, pull up the ciphertext hex on my phone, and start decoding ASCII in my head. “P…u…n…d…” Oh, crap. Finding a corner to sit in, I open the hex in a text editor and pull up an ASCII chart. What I end up with is this:

a5 90 a7 b5 
b6 ae 86 a4
a6 a9 97 a4
b7 b3 92 90
86 b7 97 b2
a6 af b6 ab
82 90 94 86
a6 89 b6 b4
86 85 a6 ac
86 b9 87 83


5 0 7 5 
6 e 6 4
6 9 7 4
7 3 2 0
6 7 7 2
6 f 6 b
2 0 4 6
6 9 6 4
6 5 6 c
6 9 7 3

which then becomes:

50 75 6e 64 69 74 ....


Pundits grok Fidelis

I immediately went to the Fidelis booth, walked up to Will (the creator of the puzzle), looked him in the eye, and simply said “Really? REALLY!?” That got a laugh. Apparently, in his words, I gave him “too much credit.” I was looking for an actual, cryptographic solution, when really the answer was staring me in the face THE ENTIRE TIME.

And if I’d taken the time to really think about it, I should have solved this in 10 minutes just by visual inspection. Remember when I said that I’d determined pretty quickly to drop the initial byte of each pair? The “c2” and “c3” and so forth? Well, part of figuring out whether it was UTF-8 or UTF-16 involved me looking at the Wikipedia pages for UTF. Which told me that when a pair begins with c2 through cf, the next byte MUST start with 8, 9, a, or b. So I knew, almost from the beginning, that not only did the first byte have no real bearing in the puzzle, but the next nybble (the first character of the 2nd byte) had no bearing either. But that fact just never registered.

In fact, hindsight has helped me to recognize not just one, but two different ways to look at the data and quickly solve the puzzle. Let’s look at the hex dump again (with column headers to make the discussion easier):

c2 a5 c3 90 c2 a7 c2 b5 
c2 b6 c2 ae c3 86 c3 a4
c3 a6 c2 a9 c3 97 c3 a4
c3 b7 c4 b3 c5 92 c4 90
c6 86 c4 b7 c4 97 c4 b2
c5 a6 c5 af c5 b6 c5 ab
c6 82 c6 90 c6 94 c6 86
c5 a6 c6 89 c6 b6 c7 b4
c6 86 c6 85 c6 a6 c6 ac
c7 86 c6 b9 c9 87 ca 83

Looking at the columns, it should have been even more obvious. I’ve already discussed dropping columns A, B, E, F, I, J, M, and N (I came to this conclusion shortly after I originally started the puzzle). But what I didn’t “grok,” but should have, was that I needed to drop columns C, G, K, and O as well. What’s left after that? Column D is either a 2, 5, 6, or 7. Column H is 0, 3, 5, 7, 9, e, or f. Column L: 2, 4, 6, or 7, and finally the last column, P, which is 0, 2, 3, 4, 5, 6, b, or c. So two columns (H and P) with truly random-looking numbers, and two columns (D and L) with 2, 4, 5, 6, or 7. In ASCII, a byte that begins with 4 or 5 is a capital letter, and 6 and 7 denote lowercase letters. Bytes beginning with 2 are punctuation — in this case, the 2 is always paired with a 0, or a space.

Another way to look at this, mathematically, is in terms of bits of entropy. Columns A, E, I, and M have 0 bits, since they never change. Columns B, F, J, and N have 4 bits, since they’re anything between 2 and a. Similarly, columns C, G, K, and O only bring 2 bits to the game (since 8, 9, a, and b are all 10xx in binary, it’s just the last 2 bits that change). And D and L have only 3 bits of entropy (2, 4, 5, 6, and 7 all fit within 0xxx in binary). Finishing it up, we have:

04 23 04 24 04 23 04 24

One can pretty readily see what might’ve been obscured before: That each line has 2 repeated pairs (04 23 04 24). Looking at the UTF-16 version, again, we see that the characters are taken from increasingly higher code pages in the Unicode alphabet…which further strengthens the supposition that columns B, F, J, and N are all meaningless (since they’re largely derived from the Unicode pages as well). So instead we have “00 23 00 24” or just “23 24”. That’s 11 bits….but we only need 8 bits for letters (or really, 7 bits for ASCII). But wait — the 2s here are also largely driven by the Unicode layout…if we drop those, now our data has “03 04” bits, or 7 bits total. Just enough to build ASCII data. And sure enough, that’s what it does.

The plaintext wasn’t even encrypted. Just hidden in noise.

I should have walked into their booth first thing Wednesday morning, handed them the solution, and walked away $1000 richer.

To say I was frustrated…well….that doesn’t begin to cover it.

So in the end….was this a good or bad puzzle? As much as it pains me to admit it, this was an excellent puzzle. It made me think about UTF-8 encoding (which many, especially us old dumb-terminal types, overlook in favor of flat ASCII). It had a red herring (the ^ making me think of XOR). It had obvious, blatant signs that should have been seen, at least by experienced cryptographers. Like most good riddles, it had a simple, obvious, easy-to-execute solution. Also like most most good riddles, I felt like a complete idiot for having missed the answer.

Thanks, Fidelis, for reminding me to keep my eye on the basics, and for driving home the first rule of cryptanalysis, as defined by the late Robert Morris: “Check for plaintext.”

DEF CON 16 Punch Card Puzzle

July 27, 2011 2 comments

Back in 2008, at DEF CON 16, G. Mark Hardy presented his second crypto challenge. I didn’t go to DC16, so I didn’t see the challenge (and even if I had, I wasn’t really tracking these at the time). But in 2010, at ShmooCon, he dusted the challenge off and handed it out again, as nobody had solved it yet. I’d managed, with a buddy, to solve the ShmooCon badge puzzle that year, and after I got home I started on the DC16 puzzle. It took me a few days, but I managed to beat it.

I’ve held off on writing this one up, because the original included a phone number, and I didn’t want to publish that without G. Mark’s approval. And though we’re in frequent contact, it wasn’t until recently that I remembered to ask him about it. At his request, I’ve modified the puzzle slightly, with a different phone number (which I’m sure you’ll recognize). The method to arrive at the solution is still the same as the original.

The puzzle was handed out in five pieces, each printed on old computer punch cards. Each card included some additional text and two lines of code. Here are the five cards (again, modified for a different endgame):






As always, if you’d like to try to solve this yourself, then STOP now, as the rest of this post is full of spoilers. The text above is all that you need to get started.

One of the first things I did was to try the simple attacks: ROT-13, for example. After those gained me nothing, I wrote a simple python script to output letter frequencies for each card. The results looked something like this:

A :    7     2     9     5     6   
B :    2     5     9     0     0   
C :    0     1     1     3     5   
D :    1     3     3     2     6   
E :    1     4     1     2     6   
F :    6     4     6     2     4   
G :   15     8     2     7     0   
H :    8     1     1     1     1   
I :    5     0     3     1     1   
J :    2     1     5     2     5   
K :    0     0     0     4    12   
L :    7     4     1     2     2   
M :    2    15     2     4     2   
N :    0     3     2     1     2   
O :    4     2     4     1     3   
P :    3     2     5     0     8   
Q :    0     0     5     5     1   
R :    1     7     0    12     1   
S :    2     4     2     6     2   
T :    1     0     5     1     1   
U :    3     4     6     2     0   
V :    4     2     3     3     1   
W :    2     0     2     6     1   
X :    0     4     1     1     4   
Y :    3     2     0     3     1   
Z :    1     2     2     4     5

So the five cards have distinctly different frequency distributions, but none of them are really flat. The first card had more Gs than any other letter, the second, slightly more Ms than Gs, etc. Pretty quickly I’d noticed a pattern: GMARK. I later saw this as a recurring theme in his puzzles, but this was the first time I’d seen it, and so I was kind of stoked. First, I tried shifting the letters back such that the most common letter was E, but that didn’t seem to look right. Remembering that he often uses Z for a space, I then shifted them back to Zs (G -> Z, M -> Z, etc.), and now my texts looked like this:






But this still didn’t give me a cleartext. Some kind of wild guess made me think that I was dealing with a columnar transposition, which I’d never tried to break before. So I resolved to do this one, and to do it “by hand” (without resorting to brute-force computer programs). I tried some simple rearrangements of each card’s text, but got nowhere…

Then I realized, that I might be able to do an attack “in depth”: Since I had 5 different ciphertexts, if they were all encoded with the same key, then I could use bits of one to help solve another. I lined all the text up in five columns, and started trying to rearrange the rows such that words formed. For example, if I found a Q in the first column, I’d then look for another row with a U in the first column, and put them together. I did that for all the Qs I could find, then looked in the other columns to see if other obvious digraphs were being formed.

This way, I figured, I might start with “QUI” in one column, and notice “HIS” in another. Then I’d just have to put a row with “T” above HIS” and I’d have another word built. Repeat, and repeat, and eventually I’d solve all of them.

Except that this wasn’t how the puzzle worked. 😦

As I realized that I was getting nowhere, I noticed that there were two rows which read “Z Y O U Z.” And for the first time, I saw the word “YOU” in the middle of two Zs. And realized that I was being an idiot.

I eliminated some spaces, to make it easier to read, and found the plaintext. [I was working vertically, but to save space I’ll rotate it here, in two blocks. The first block is the 1st half of each card’s shifted text, placed one on top of the next, the 2nd block is the same for the 2nd half of each card].



Reading down each column in the 1st block, then continuing in the 2nd, we get:


Or, cleaned up:






Woohoo! Of course, that’s not all. There’s still a block of text at the end that’s not right:


So there’s more to decode. Fortunately, G. Mark gave us a big hint when he said “NO CHEATING.” That’s his clue, made clear in his Tales from the Crypto talk, that this stage requires the Playfair cipher. But what key? Well, for his Mardi Gras puzzle, he used the title of his talk, so what talk did he give at DEF CON 16? “A Hacker Looks Past Fifty.”

Plugging this into a friendly online Playfair decoder reveals the final cleartext:


Or, cleaned up:


Still not quite finished. So now we’ve got to do some math and number manipulation. At first, I thought it was several different multiplaction operations, somethng like:

7 * 7, 4, 3 * 4, 2, 8, 5, 0, 9 == 49 4 12 2 8 5 0 9 or 494-122-8509

I texted the phrase to that number, but got no response. After a while, I sent an email directly to G. Mark, who confirmed that I’d broken the cipher, but did the math wrong.

It wasn’t a bunch of separate operations, but a single operation, like this:

7 * 743 * 428509

Which yields the following (obviouly faked for this blog entry) phone number:

222 867 5309

This was a fun puzzle! I took some wrong turns, tried some new techniques, had some good luck, and made some stupid mistakes. A little of everything. Of course, tweaking the puzzle so I could (finally) publish the writeup was fun, too, especially factoring numbers to get them to fit into the ciphertext space available. Interesting bit of trivia: Turns out that 8675309 is a prime number. 🙂