Writeup – Crack This Crypto, EME2 (websec.tech)

Over the past several weeks, team farmingsimulator2015 participated in the Websec CTF. This CTF was a solid CTF with a wide variety of content, but unfortunately plagued by a multitude of technical issues, meaning that sometimes, only a single team was able to solve a given challenge before it went down:

websec_lolscoreboard

As always, I’ll present some of the more interesting writeups for reference below. Without further ado:

crack the crypto

The websec CTF presented a number of cryptography challenges. Many of these were based on classic “CTF-style” problems:

  • rot-based ciphers
  • vignere cipher
  • rail fence cipher

The final challenge was the “crack the crypto” challenge, which was presented as a single base64 string:

2v2w3z2yJsJwajTiaqIpILErELEM5pyqyo0

The clue was to “retrace your steps” (paraphrased). As a starting point, I thought this clue meant to back-track through the cryptographic operations in the other cryptography challenges, so I tried to use combinations of the previous string transforms, but I gave up as the potential search space was too large without some manner of “key” or “indicator”.

My second approach was to try a “known plaintext” style approach, with a few assumptions:

  • Given the character set, we can assume that we’re looking at a base64-encoded string *somehow*. Simply base64-decoding the string doesn’t result in a valid flag.
  • Given the other challenges in the CTF, we can assume the first part of the flag is “websecctf{“.
  • Given the clue, we can assume that a rail fence, Vignere or rotation-based cipher is involved, or a combination of these.

I started off by base64 encoding “websecctf{“, and recording the first characters:

websecctf{ -> d2Vic2VjY3Rme...

From here, I couldn’t see these characters within the original character set, but I assumed by applying some form of rail fence or transposition-based cipher, we’d arrive at an input which could then be transformed to this string (“d2Vic2VjY3Rme”). Assuming it was a simple transformation (i.e. a rot-based Caesar cipher), it would be likely that the position of numbers and upper/lower case would remain static, as follows:

d2Vic2VjY3Rme
q2Ivp2IwL3Ezr

This is because Caesar ciphers often have problems with numbers, or omit numbers intentionally – it’s easy to misinterpret where numbers lie in the character-shifted alphabet compared to alphabetical characters.

A Vignere cipher at this point would be impractical, as we wouldn’t know any text to “anchor” against (ie. no text to check that we’ve got the right key / key length, aside from the websecctf{ string – it may as well be blind brute force).

I then used the excellent Rumkin.com toolset to apply a manual brute force, as if this input were rail fence encoded:

websec_crackthiscrypto

We can immediately notice that the start of this string bears similarities to the encoded “websecctf{” string shown earlier (this was the example string provided above): the numbers are in the same place, and so is uppercase vs lowercase.

From here, it’s a simple matter to apply a rotation-based cipher, and de-base64 the key:

websecctf{dead_encryption}

eme2 (evil mutator enhanced 2)

This reverse engineering program was provided as an archive, containing three files: eme2. The clue was something like “attackers like to send their payload in separate pieces”.

While this challenge looks intimidating, a quick “file” shows the truth:

websec_eme2

From here, it’s simple enough to cat the files together (the correct order is “activator” -> “server” -> “client”, from first chunk to last) to build a valid x64 executable. Opening this up in IDA Pro, we can immediately see that trivial attacks (i.e. bit flips, strings) won’t work, because this simply checks that your key is legitimate.

The overall structure of the executable is clear, and it is unobfuscated: we can start at the key generation function (0x400E93). The program appears to follow a strange, hand-crafted flow:

eme2_flow

In the above diagram, completing a series of checks (the yellow blocks) adds one to a stack-based counter, and when t his counter is 2, it gets reset, and the green blocks get run, performing checks and incrementing the counter until 0x0A.

Fortunately, instead of actually understanding the code, we can leverage the design of this executable to our advantage: this executable checks our input character by character using a “cmp” instruction.

We simply breakpoint each “cmp” instruction, and check our input against the “key” it’s being checked against, one character at a time (alternatively, as per the below example, you can view multiple characters at a time, by viewing more than one “variable” at once):

websec_compares

This quickly reveals the username, and the correct key:

websec_compares_finalkey

 

tooling update – attackrsa

During this CTF (and the last one), I discovered the attackrsa toolkit. The attackrsa toolkit is a Python module, as well as included binary (I don’t know what this does – but I hear it’s pretty useful), which implements a number of common attacks against RSA. I found this to have an easier interface to use than RsaCtfTool, depending on what inputs you have.

As always, a huge thankyou to the organisers for putting on this event and giving us all fun things to play with. I hope that next year you have better luck with the technical / hosting issues 🙂

About Norman

Sometimes, I write code. Occasionally, it even works.
This entry was posted in Bards, Computers, Jesting and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s