secret code in dbir
This morning Verizon Business announced that the DBIR contains a secret code. I promptly set about to try and crack it. I feel that I’ve made significant progress, but I have to stop now and I won’t have a chance to resume for a few days, by which point I’m sure it’ll be over. In the mean time, I’ve decided to share my results so far here in the hopes that my experience will help others, or perhaps others can point out flaws in my logic.
The first thing to note is that on the back cover, in black text on a black background, is the following block of code:
U2FsdGVkX1/igcsdctD3brMu4vDXkswNZZoHL6QVcI6eBlfN4aqvBBowRhf9wfsk hb5RIGVSpphM2bJe33tVKh7koZ85V5ebFI1mPlXEhnKHO+er8EIyDRYuVvju08qv u/jITmGEM4Mpk4gvL7aVeFB5lxoMFo0ds/CEA6zK80QprvV5B+c6+MWciIzLFJWI /4OcO96UGM2riMKj2iy4JgmRxjEUyX/TKQEIB1s7WLh6cW30JpvgAI8wILVdTWpt +gnIfyEGxio4Q2T9LM1ncA5K2P4lg/DsTiDIEEg3Ws4uW5sbz22qfE91frW7NnBg t46Iy0WhZgw0+wj4DCLzF4GBnIkplanSMdA+hiwhdR629KL7O8X1ZLg5eFHmjS6C VCXXuQJVSaVG77/5113N/eNMboD2RhXyq1kWzZZaW/lpJ8vIDs5OK7d1TPG6aVLJ hINx3qPZzNvtK4r4KfZ5fhjUXLcufOpE46gGnD0aHW+SCcGl2k7NPqbYfGtYSwuJ HYne4VTxR772vsV5RFgirw==
Clearly it’s no stretch to imagine that this is a major clue. After spending several hours convinced that there was steganographic data encoded in the image on the front cover, I turned to analyzing the code block. The first several characters – U2FsdGVkX1/ – are the base64 encoding of “salted__”. What I have since learned is that when you encrypt something with a salt, the resulting ciphertext includes that string followed by the actual salt so that it can be decrypted. (Thus an awful lot of cipher text begin with U2FsdGVkX1 – the slash is sometimes a different character that has to do with the peculiarities of base64 encoding). If this has been salted, that means is has been encrypted. If it’s been encrypted, that means it can be….. unencrypted! I tried a lot of educated guesses at the passphrase, none of which have yielded a positive result yet. Part of the problem is that I know neither the key nor the algorithm. My last ditch attempt was to take the DBIR, convert it to text, use it as a dictionary, and then try each word as a key for AES128, AES256, DES, 3DES, blowfish, etc. My quick and dirty shell script is here:
for line in `cat dict`; do `openssl aes-128-cbc -d -base64 -in textblock -k $line` done for line in `cat dict`; do `openssl aes-128-ecb -d -base64 -in textblock -k $line` done repeat for 3DES, blowfish, etc., etc.
I have a feeling that the answer to either the algorithm or the key must be in the report somewhere, I just can’t find it. I hope this helps someone. (And if it does, please let me know).
Tags: contests, dbir, encryption, secrets, verizon
August 11th, 2010 at 2:30 pm
Nice job so far ;-)
August 11th, 2010 at 3:35 pm
The DBIR 2010 challenge so far…
OK, we all know the drill (after 3 Firefox crashes I cba to write up everything again). There’s a crypto challenge in DBIR 2010. This is what I know (or think to know) so far: There’s crypto data on the last page. It’s Base64 en…
August 13th, 2010 at 11:23 am
Nice job so far! Recognizing the encryption algorithm is the tough part, right? I like your dictionary approach, though. How are you determining successful decryption? Manually reviewing the output?
August 13th, 2010 at 9:22 pm
For some reason, I think it has something to do with this sentence, it just sticks out to me. Maybe it’s silver bullet or werewolves?
There is no such thing as a silver bullet and if there were, the werewolves would wear armor.
August 15th, 2010 at 9:15 pm
@JJ: openssl gives an error if the decryption doesn’t go well. I just run the above script and send stderr to /dev/null. Anything that pops out on stdout must be the answer.
#./dictcrack 2>/dev/null
August 17th, 2010 at 12:10 am
My thoughts:
The image on the front has the word openssl written on it.
The block above is probably produced with the “openssl enc” command, since that is what adds the “Salted__” bit. That command has a “derive IV from password” scheme, and defaults for everything else. So you might try the brute force against that variation (if it differs from what you tried).
August 17th, 2010 at 11:41 am
More thoughts:
The encrypted portion of the block is 384 bytes, which would allow a 16-byte block-size cipher like AES. (Though of course a 8-byte one could have happened to come out to an even number of blocks).
The only way the decoder knows that the decrypt was successful is based on the PKCS5 padding ending up correct, which can be correct randomly, especially when the padded block is nearly full. So getting a successful message from openssl doesn’t necessarily mean you found it.
August 19th, 2010 at 12:25 am
A lot of stuff since I last posted (mostly via email), but since #dbir is pretty well anticipating me, this is what I’ve looked at:
Hex codes at the end of the PDF:
3ACEE1B049C842D2BADF125B9AA0272E
0E7AEC3ABAD64A99B9E3674811C8582F
Probably nothing. Not a key at least, even permuting various ways and adding “F”.
Fingerprint is a gray and a blue one. They’re almost identical; I can’t extract much from differences. Tried the circles lined up on other PDF pages. No luck, but could have missed something. Person on #dbir tried it a few hours later and didn’t find much either.
Distortion on the fingerprint lower right might be an image of a horse or dog, need to find a better way to detect and pull out the superimposed image. (F+) is in black, the background isn’t quite black. It is also part of the distorted area.
Other post comment says gray version of fingerprint might have hidden data. I should look at that as well.
August 19th, 2010 at 8:40 am
@Reuven – Those codes are also on line 175 of the PDF. I would guess that they are not part of the contest.
August 19th, 2010 at 9:02 am
Those hex codes are part of the pdf file format. They’re cross references to the xref table, which you can read about here if you’re curious:
http://www.adobe.com/devnet/livecycle/articles/lc_pdf_overview_format.pdf
August 20th, 2010 at 8:26 am
Stuff since I last posted-
(F+) = false positive. Something that seems important at first and then turns out to be nothing. Clever clue. Some noted that it might be probability of false positive, though the p isn’t in the same color as the (F+). Alex also hinted to a probability involved. I calculated the probability of openssl not detecting a failed decryption(PKCS5 padding working out), and it is slightly over 1/256. Long decimal, and didn’t work as the key so far as I could tell.
However so far as I can tell, this hasn’t helped get the key or algorithm. It got tossed on #dbir twitter a few hours after we noticed it, and it doesn’t seem like anybody there figured it out either.
Somebody noted on #dbir that base64 encoding it produces a string starting with KEY. I tried the string as a key, and no dice. Might be a coincidence, or might be important.