Tag Archives: cryptography

Solving the THOTCON 0×2 Pre-Sale Puzzle

Posted by Jon Janego on November 2, 2010 1 comment

Earlier this year, some folks in the Chicago security community got together and organized a conference called THOTCON, which turned out to be a resounding success.  It took place in April and drew several hundred people together for a day filled with some great talks, beer, and general hacking socialness.

To gather some early buzz (as well as to have some fun) for the follow-up next spring, the organizers decided to do an early pre-sale puzzle.  Of course, like many things in the security community, the hints were leaked only to their twitter stream.  Inspired by a few of my friends poking at it, and with some free time to spare, in the spirit of learning (and a chance to save about $20!) I decided to take a stab at the puzzle.

By the time I started working on it, the organizers had leaked a few hints.  Here’s where it was at when I began:

Puzzle -> FAW2GlImKsT3BL8yKQF= zf-c75-sb-j 60max #thotcon0x2

Hint #7 – I am the answer to my own puzzle. You just need to look at me the right way
Hint #6 – Decrypt, then decode
Hint #5 – The coolest thing about part 2 is… You dont have to do ANYTHING. (Put it somewhere and tada!)
Hint #4 – Part 2: I’m not a cipher, I’m a conversion. You have the tool to convert me. In fact, you don’t have to convert me.
Hint #3 – Part 1: He is dead
Hint #2 – What do you mean I was part of the Reichstag zu Worms?
Hint #1 – I was born on April 5th. #thotcon0x2 <— puzzle hint?

So, to break it down, the hints indicated a 3 step process to solve the initial hint string.

Step 0:

Working from the string:

FAW2GlImKsT3BL8yKQF= zf-c75-sb-j 60max #thotcon0x2

To be honest, I wouldn’t have had much to go from here were it not for the hints, and my twitter addiction.  I picked out the ‘zf’, ‘c75′, ‘sb’, and ‘j’ as being the handles of several of the organizers – @zfasel, @c7five, @sak3bomb, and @jaku.  So we could drop that.  ’60max’- this is cleartext and probably not a code, so dropped.  ‘#thotcon0x2′ – again, twitterese – a hashtag used to talk about the conference.  Dropped.

So we’re left with the cipherext to decode,

FAW2GlImKsT3BL8yKQF=

I suppose that’s a start.

Step 1:

I’m not much of a cryptologist, but I do know a bit of the history, mostly thanks to reading Simon Singh’s excellent The Code Book.  I figured it was a reasonable assumption that this is a classical cipher, breakable by hand.  So, poking a bit around Wikipedia for famous classical ciphers, a bit of digging came up with April 5th being a reference to Blaise de Vigenère, whose name is attached to the famous Vigenere Cipher.

This cipher is a relatively straightforward method of letter substitution, which a dedicated person could do by hand.  However, being a citizen of the 21st century, I wanted to put computers to work for me – so I found a site to decode it!

http://sharkysoft.com/misc/vigenere/

Problem was… a Vigenere cipher requires you to use a known key to decode it.  Which I didn’t have, so I began guessing.

This required jumping ahead a little bit – what to do with the decoded ciphertext?  The hint to part 2 indicated that it was a conversion… so my natural first guess was Base64, just because it’s so common.  So I began working on the assumption that my decoded ciphertext would be Base64 encoded.  I found an online decoder and began guessing away.

Now, a Vigenere cipher would be relatively easy to bruteforce in the age of modern computing, but I didn’t honestly expect the organizers to force people to write a brute forcer.  Instead, I began guessing words associated with the security community.  Eventually, after guessing many words… I tried the name of the conference itself – THOTCON0x2.  And bingo!  I had cleartext that also decoded to Base64:

MTI2NjUzNzM3NS8wWDI=

Step 2:

I suppose this is a bit redundant since I had been testing my cleartext in the Base64 decoder the entire time.  Using this online decoder:

http://www.motobit.com/util/base64-decoder-encoder.asp

I ended up with some very promising text:

1266537375/0X2

Step 3:

In the spirit of full disclosure here, step 3 was where I performed a bit of ‘social surveillance’.  Following the #thotcon hashtag on twitter and saw Nick, one of the organizers, post a hint saying something to the extent of, “is it alive?”

How do you check if a computer is alive?  Usually a good first step is to ping it.  I already had my suspicions about this string, but this gave me the idea to just run a ping at the decimals in that address (the ’0X2′ was clearly intentional and I dropped it from consideration).

ping 1266537375

Pinging 75.125.211.159 with 32 bytes of data:
...

Ping did the translation for me, nice!  Now I have a more easily readable IP address.

This string was a decimal representation of an IP address.  Not commonly used, but still valid – and if it’s used commonly anywhere, it’s with spammers/phishers who like to obscure their targets from cursory glances.  You can read more about it here.

Step 4:

So now we had an IP address.  Now what?  A nmap scan showed a webserver running on port 80, so I sent my browser there…. and got a blank page.

But wait a minute…. wasn’t there a string I dropped from that address?  ‘/0X2′.  After kicking myself for the brain fart, I navigated to…

http://75.125.211.159/0X2/

And had what looked like a winner!

There were three images there – unfortunately not loading at the time – and a link to the registration page.  When doing a mouseover the three images, some codes were revealed:

VEHPVE
NPTJB4M
I0YMDEX

I moved on over to the registration page, concatenated these strings together… and success!  The discount code was accepted.

Conclusion

This puzzle was a fun one, which pushed you to think a bit outside the box.  Also, because it was released ‘into the wild’, the internet was at your full disposal to track down hints.  So while it may have been shortcutting a bit, I didn’t see anything wrong with spying on @c7five as he gave hints to other players ;-)

I don’t know how many pre-sale tickets that they ended up selling, but the initial hint was that they only were offering 60 of them at the discounted price.  So, having solved it before they publicly revealed the pre-sales code, I felt pretty proud of myself.  Perhaps I was just lucky to have the free time to poke at it.  I’ve also gotta thank my friends for pointing me in the right direction after I got stuck (and way to go, Rudy, Jeff and Jim for being more clever than I and figuring it out faster!).

The puzzle appears to have been primarily created by Sak3bomb, who is clearly a brilliant individual, much more clever than those of us trying to work backwards.  Major props to him and his collaborators for putting together a fun puzzle.   He archived the hints on his webpage here:

http://www.haxbysakebomb.com/thotcon.html

I’m really looking forward to the next THOTCON, and general sale tickets are available now – so go on and buy em.  I’ll see you there!

Quick and Easy Portable Media Encryption

Posted by Walter Goulet on February 25, 2010 1 comment

As part of my personal service delivery process, I have a need to store sensitive information for client engagements (vulnerability assessment results, network diagrams etc). To avoid having a dependency on specific test systems, I prefer to use portable USB drives to store data in the event that I need to switch to another system. However, I don’t want to risk losing this drive with confidential data on it. My solution is to create an encrypted partition on the disk in such a fashion that I can quickly mount the drive on another system without downtime.

To meet these requirements, I use a combination of Dropbox (http://www.dropbox.com), Keepass (http://keepass.info/), and Truecrypt (http://www.truecrypt.org/). I use Dropbox as a portable ‘Program Files’ directory where I install portable versions of Keepass and Truecrypt. This allows me to have my ‘Program Files’ directory replicated on all systems where the Dropbox client is installed (for backup purposes, I usually have my Dropbox account synchronized to 2 different systems).

I use Truecrypt to create an encrypted partition on the USB drive (using AES for encryption and HMAC-SHA-512 as a hash algorithm). The volume key used to encrypt/decrypt the partition is then stored as a password in my Keepass database (which is also stored in my Dropbox).

As long as the Dropbox is synchronized between my test systems, switching from one system to the other is as simple as plugging the USB drive in and launching Truecrypt/Keepass from my Dropbox.

Here’s my step by step instructions to replicating this setup on a Windows XP/Vista/7 system (I assume you already have Dropbox installed on your system):

  1. Create a ‘Programs’ directory in your Dropbox folder. In this folder, create 2 subdirectories, ‘Keepass’ and ‘Truecrypt’.
  2. Copy the portable versions of these programs into their respective folders (Truecrypt does not have an explicit ‘portable’ distribution, rather download the setup file here and choose the ‘Extract’ option when running the setup, Keepass on the other hand provides a portable version that can be downloaded here).
  3. Launch Keepass and create a new password entry for the portable drive. I suggest using the Password generator function to generate the password. Note that since this password is used as an encryption key, I recommend selecting all available characters for generating the password and using the maximum key length (64 characters).
  4. Plug in the portable USB drive that will contain the encrypted partition (note: this has only been tested with USB hard drives; I have not tested this with smaller USB flash drives).
  5. Launch TrueCrypt and use the ‘Create Volume’ button to launch the new volume creation wizard. I recommend writing down the path to the volume being created to make it easier to mount later. For my personal setup, I chose to create a regular (non-hidden) partition using AES and SHA-512 for encryption and as a hash algorithm. When prompted for the volume password, use the password entry created in Keepass.
  6. The volume is now created!

To actually mount the encrypted partition, start Truecrypt and select an available drive entry. Select the encrypted volume from the Volume list then click ‘Mount’. When prompted, enter the password from the Keepass password entry.

Note that regardless of which system was used to create the encrypted partition, you can mount it on any other system as long as you have access to Truecrypt and your volume password.

Hashes – not just for breakfast

Posted by Walter Goulet on January 28, 2009 No comments

Consider the problem where you need to know for sure that information you are looking at has not been altered since it was first created. A simple example that kids can relate to is a report card from school. The model for report cards is that the school gives a kid his/her report card, they bring it home and their parents sign it to show that they read the report card. An obvious problem that the school has is to be certain that the report card isn’t changed while the kid has it.

In cryptography, this problem is referred to as ‘data integrity.’ Cryptographic systems solve this problem by creating a representation of the information that is unique. This representation is referred to as a ‘hash’ (or checksum). A good way to think of a hash is as a digital fingerprint that looks totally different for each set of data that it represents. Functions that are used to create hashes from information are called hash functions. There are a couple of important points about hash functions:

  • The result of the hash function MUST be unique for each message that it processes. That is, you should never be able to get the same result from a hash function if you feed in two different messages.
  • The result of the hash function MUST not look anything like the message that it processed.
  • It MUST be impossible, given the result of a hash function, to determine what the original message was.
  • The result of the hash function is usually smaller than the message that it processed.

If you wanted to exchange a message with another person and be sure that the message hasn’t been changed along the way, you could use a hash function as follows:

  1. Create a message.
  2. Feed that message into a hash function.
  3. Send the message to the recipient along with the hash.
  4. The recipient feeds the message into the same hash function used by the sender.
  5. The recipient compares their hash with the sender’s hash. If they are identical, the recipient is sure that the message wasn’t changed.

Of course this exchange isn’t secure as the hash could be changed in transit as well, but it illustrates how such a system works. I’ll explain how to make this exchange secure in a future post. To find out more about the basics of hash functions, read more.

Read more »

Clock arithmetic and security

Posted by Walter Goulet on January 21, 2009 No comments

Quick quiz, what do the following sequence of numbers have in common: 19, 3763, 31, and 67? The answer is, they are all the same! Ok, well obviously that’s not strictly true. More correctly, these numbers all represent the same value in modular arithmetic (7 modulo 12). When you take each of these numbers and divide them by 12, you end up with a remainder of 7 (19 / 12 = 1 remainder 7, 3763 / 12 = 313 remainder 7, 31 / 12 = 2 remainder 7, and 67 / 12 = 5 remainder 7).

Another simple way to think of modular arithmetic is clock arithmetic. Consider the problem when you are looking at an analog 12 hour clock. You need to figure out what time it is going to be 7 hours from now. If the current time is 3 o’clock PM, you add 7 hours and end up with 10 o’clock PM. But, what if it’s 8pm? You don’t simply add 7 hours as there is no such thing as 15 o’clock pm. Instead, when you pass 12 o’clock AM, you restart your counting. So 8 o’clock PM + 7 hours = 12 o’clock AM + 3hrs = 3 o’clock AM.

So what does clock arithmetic have to do with security? Going back to our original sequence of numbers, notice that you cannot possibly determine that these numbers all represent the same mathematical value without having a key piece of information, the modulo value (which in this case is 12). When you think about it, this property is useful from a secrecy perspective because you have 2 pieces of information that have a common value, but you can’t tell what that common value is unless you know some other information. This basic property of modular arithmetic forms the basis of many of the key negotiation and encryption algorithms in use today.

So, for fun, here’s a simple cryptosystem (secure enough to keep your 10 year old little sister from reading your journal) that uses this property. Note this cryptosystem doesn’t authenticate the two parties, but it at least allows them to exchange a pair of secret keys no matter who is listening.

  • Alice and Bob want to exchange a secret message, but they can only talk to each other over an open communication channel.
  • Beforehand, Alice and Bob agree to use the current time as the modulo value for determining the secret value. For example, if the current time is 4pm and Alice and Bob want to agree on a secret key, they will divide their values by 4. Note that the method they are using for choosing a modulo value must remain secret for this system to work.
  • Alice sends her value to Bob in an open channel. Bob calculates the value she sent modulo the current time. The result is Alice’s encryption key.
  • Bob sends his value to Alice again in an open channel.
  • Alice calculates the value she got from Bob modulo the current time. The result is Bob’s encryption key.
  • Now, Alice and Bob can communicate securely using each other’s encryption key to encrypt messages being sent back and forth (using some pre-determined encryption algorithm).

To see the system in action:

  1. The current time is 9pm.
  2. Alice picks a value of 84.
  3. Bob picks a value of 1156.
  4. Alice and Bob send a message to each other via a open channel (normal phone call, ads in the newspaper, or even yelling at each other in a park!).
  5. Alice get’s Bob’s value of 1156 and calculates 1156 / 9 = 128 remainder 4. 4 is Bob’s encryption key.
  6. Bob get’s Alice’s value of 84 and calculates 84 / 9 = 9 remainder 3. 3 is Alice’s encryption key.
  7. Now Bob and Alice can encrypt their messages using their respective encryption keys.

The real beauty of this type of system is that no matter who learns the values that Alice and Bob selected in steps 2 & 3, they will never be able to figure out how they are related without knowing what the modulo value is. In a future post, I’ll expand on this a bit more to show how modular arithmetic is used in non-toy cryptosystems.