Da French?

TL;DR

Reverse executable that uses AES encryption and decrypt network traffic

Description

This was one of the harder challenges for the XMAS-CTF 2020 and I actually managed to be the third one that solved it. In the end, the challenge only had around 15 solves, which shows that many people did not see that the binary was using AES encryption. The challenge gives us an ELF executable as well as a network capture which we can use to solve the challenge

Network capture

When we open final.pcap (the provided network capture) we can see two TCP streams. The first one looks like this:

Not much to see here, except that the connection kind of drops at some point. This is where we can find the packets for the second TCP stream which looks like this:

Now this one looks more interesting. It starts off with some readable text, however most of the rest is illegible, which shows us that probably some kind of encryption was involved. We cannot extract any more information out of the pcap file at this point so let’s tackle the executable.

Basic Dynamic Analysis

First of all, when we run the binary, nothing seems to happen. If we investigate it with strace, we get the following output:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(1337), sin_addr=inet_addr("111.161.162.163")}, 16

We can see here that the executable tries to connect to a server sitting at 111.161.162.163 on port 1337. Because we don’t have access to that server, let’s patch the binary and make it connect to 127.0.0.1 (the localhost address) so we can interact with the program by spinning up a listener on port 1337.
After that, the executable waits for input from the remote end and exits if we give it some random input. Let’s try to find out what we need to put in so the executable keeps running.

Disassembly

The executable first calls a user-defined function. If we take a look at it, we see that this function connects to the server.

After that, we have calls to geteuid, getpwuid, srand and rand (further analysis of this will be done further down).
Then we have another call to a user-defined function which looks like this:

What we have here are the calls to recv and then after that a call to strcmp. If we check what our input is compared against, we find the string “name and the confidential info\n”. This is also the string that we found earlier in our network capture, so we know that the second TCP stream was established by our executable. The code goes on and sends something to the remote end, in my case this was the string “root”. Now that we have this information, let’s see what the earlier library calls achieved.

Generation of seed

geteuid is a call you don’t see that often in programs. It returns the user ID of the calling process. In my case, it was 0. getpwuid on the other hand takes a user ID and returns the associated entry in the /etc/passwd file. This means that it returns the username, the user shell as well as other stuff for the calling process. After that, the process takes the first 4 bytes of the output of getpwuid (the first four characters of the username) and combines them into a single value by shifting them and adding them together. For example, it takes the third character and shifts it by a value of 0x10 to the left. If we take the username root as an example, we get a generation that looks like this:

r    o    o    t
0x72 0x6F 0x6F 0x74
bit-shifting and adding together:
  o o t r 
0x6F6F7472

Here’s the implementation of this generation in python:

def seed_username(name):
    fourth = ord(name[3])
    fourth = fourth << 8
    first = ord(name[0])
    second = ord(name[1])
    third = ord(name[2])
    second = second << 0x10
    third = third << 0x18
    sum_1 = second + fourth + first + third
    return sum_1

After that, the executable simply seeds the pseudo-random generator with this value and calls rand() once. We now also know what the executable sends to its remote server. It’s the username for the calling process which means that in the case of the packet capture, the username was flow. (This will be important later on)

Further disassembly

We can now take a look at the bottom half of the main function.

We can see a simple decryption stub that xors some string that’s stored in memory, then calls a function with that string as an argument. If we use dynamic analysis, we quickly find that the encrypted string reads ./confidential. The function that uses it is also rather simple:

It basically just opens a file named confidential in the current directory, reads it and then returns to main. The last thing we have to analyse is the last function call before the end of main.

Encryption

Unfortunately, this is by far the longest and most complicated function in the program but we’ll go through it step by step to understand it. The first thing that we need to understand is the following bit of code:

This loop executes four times and each time generates a new random number. After doing that, it basically turns the generated number around. The last byte becomes the first byte, the second byte becomes the second last byte and so on. Here’s a sample implementation in C that generates four random bytes:

#include <stdio.h>
#include <stdlib.h>

int main()
{
    srand(1869379430); /*seed for username:flow*/
    rand();  /*first random is not used*/
    printf("%x ", rand());
    printf("%x ", rand());
    printf("%x ", rand());
    printf("%x\n", rand());

}

And here’s the python implementation that takes these four random numbers and flips them around:

randoms = "56e6ebe3 023e65c2 0f1a8ae0 6b9d0011" #random numbers you get when you use flow as a username

def first_line(random_numbers):
    liste = random_numbers.split(" ")
    supere = ""
    for number in liste:
        result = ""
        result += number[-2:]
        result += number[-4:-2]
        result += number[2:4]
        result += number[0:2]
        supere += result
    return supere

After doing some more operations, the executable calls another function with our earlier generated four random numbers as an input. This function is in fact the AES key schedule algorithm. Before I went into this CTF, I’d heard of AES but I never actually knew how it worked or the actual details of it. So I painstakingly tried to understand the whole algorithm and I even rewrote it in python without knowing that it was AES. I managed to entirely reverse the key schedule algorithm, however the next part of the function was a call to the encryption routine of AES which employs a lot of lookup tables and bit shifting, so it was nearly impossible to keep track of everything that was happening. At that point, I took a break which gave me the idea that this whole algorithm could be AES. After taking a look at what lookup table AES used, I was able to find the same table in the executable’s memory, also known as Rijndael S-box:

There were some other ways you could detect that the executable was using AES. For example the key schedule algorithm returned 11 16-bytes keys (our old key and 10 new keys) which were later used in the 10 AES rounds. At some point, the executable was padding the text contained in ./confidential to have a length of 16 bytes (AES operates on blocks of 16 bytes)

Decryption

After realizing that the program was using AES, I only had to find out what key and mode were employed. I already knew that the key used were the four random bytes shifted around which also added up to a length of 16 bytes, one of the possible key lengths for AES. I guessed that the program was using the ECB mode and tested this by running a few tests in python with the username root and trying to decrypt the output that the executable gave me with the generated key. After all of this was successfull, I generated the key for the username flow which turned out to be e3ebe656c2653e02e08a1a0f11009d6b. After having all of this, the solution of the challenge was trivial. Extract the encrypted content from the packet capture, put it into a python script and run it to get the solution. Here’s my python script:

from Crypto.Cipher import AES

key = b"\xe3\xeb\xe6\x56\xc2\x65\x3e\x02\xe0\x8a\x1a\x0f\x11\x00\x9d\x6b"

print(key)

cipher = AES.new(key,AES.MODE_ECB)
ciphertext = b'\xbd\x68\x96\x01\x30\xa6\x1e\x0d\xce\x86\xf0\xbb\xf9\x3e\x05\x94\xbc\x44\x00\x29\x4e\xa5\x42\x13\xea\x3a\x23\x31\x64\x1f\xfb\x65'
ciphertext += b'\x40\x71\x31\xd6\x9f\xd2\xc2\x09\xa6\x7d\x46\x8d\x8c\x85\x78\x4f\xd2\xee\x4d\xd8\x02\x30\xab\x34\x25\xc5\xb4\x24\x4c\xc6\x55\xd6'
print(cipher.decrypt(ciphertext))

Running this finally gives us the flag X-MAS{d0nt_buy_bitcoin_cause_th3_bogdanoffs_will_find_out}

Conclusion

I really liked this challenge as it was hard but at the same time not impossible to solve. It taught me great lot about AES and its exact inner workings and even though solving this challenge took me around 6 hours and I was close to giving up at multiple points, I managed to get through. Tenaciousness ultimately often pays off in CTFs and I still sometimes give up too early because it gets too hard but I hope I will see challenges through more often now. Hope you liked this writeup.
-Trigleos

Thou shall pass?

TL;DR

Reverse executable that uses clever function renaming techniques

Description

This was a challenge from the X-MAS CTF 2020. It was the easiest one in the Reversing category but I still think it was pretty fun because it introduced me to an interesting obfuscation technique.

Challenge Description

For thou to pass, the code might not but be entered

Author: Th3R4nd0m
The challenge provides us with a simple ELF binary to run

Basic Dynamic Analysis

Let’s run the binary and see how it works:

./thou_shall_pass 
Thou shall  not pass  till  thou say the code
X-MAS{test}
Thou shall pass! Or maybe not?

We can see that the program asks us for input, then checks it and based on those checks probably returns either true or false.
A first thing we can do to see what the binary is doing is to run ltrace and see which library functions the program calls:

ltrace ./thou_shall_pass 
ptrace(0, 0, 0x7ffdce31de58, 0x7f1b479c9718)     = -1
printf("Pls no")                                 = 6
exit(1Pls no <no return ...>
+++ exited (status 1) +++

Here we can see the first anti-analysis measure, a call to ptrace which basically tries to attach itself as a debugger on the running process. This call fails when there’s already a debugger attached (in our case ltrace) and returns -1. The program detects that and prints “Pls no” and aborts. To solve this, we can patch out the call to ptrace or do something else so the program doesn’t exit. Let’s have a look at where the binary calls ptrace. I’ll be using radare2 throughout this writeup as I think it’s a great reverse engineering tool for dynamic analysis as well as ghidra for a more high-level overview of the source code

Locating ptrace

This binary has been stripped, which means that all symbols that don’t have anything to do with dynamic linking have been removed. Basically, the only function or variable names that still remain are those from external libraries like strcmp or printf.
Let’s take a look at the main function for our binary:

As we can see here, the main function is rather short but seems to contain a lot of library calls but we can’t find a call to ptrace. The only other function we can find is a call to fcn.00401211 so let’s take a look at that.

Here we can see the call to ptrace, followed by a check whether rax is zero. Let’s patch that check out so we don’t exit when we debug. As we can see, the binary uses jns (jump if not sign) to check if the result of the call to ptrace is negative and then skips the exit routine if it isn’t. To patch this, we’ll just replace the opcode for jns (0x79) with the opcode for jmp (0xeb) and we can finally debug our program.

Further dynamic analysis

Now that we can use ltrace, let’s see what we can find:

ltrace ./thou_shall_patch 
ptrace(0, 0, 0x7fffd0fc3248, 0x7f988bddf718)                = -1
puts("Thou shall  not pass  till  thou"...Thou shall  not pass  till  thou say the code
)                 = 46
fgets(X-MAS{test}
"X-MAS{test}\n", 31, 0x7f988bddf980)                  = 0x7fffd0fc3120
strchr("X-MAS{test}\n", '\003')                             = "\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !""...
system("\302ij\n\232\333\243+\233\243\353P")                = -788778691
strrchr("\307om\002\223\321\250'\226\255\344@\021\022\023\024\227\276\025\030\031\032\033\034\233\236\035 !"", '\002') = "\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !"...
strcmp("\361\333[\200\344t*\311\245k9\020D\204\304\005\345\257E\006F\206\306\a\346\247G\bH\210", "\373\321Q\212\356~Ti\233ow\260\200\356p\301)gq\344\234\352r\355\223_\021\352\244x" <unfinished ...>
strncmp("\373\321Q\212\356~ \303\257a3\032N\216\316\017\357\245O\fL\214\314\r\354\255M\002B\202", "\373\321Q\212\356~Ti\233ow\260\200\356p\301)gq\344\234\352r\355\223_\021\352\244x", 31) = -52
<... strcmp resumed> )                                      = 0
puts("Thou shall pass! Or maybe not?"Thou shall pass! Or maybe not?
)                      = 31
+++ exited (status 0) +++

We can see several calls to C library functions like strchr and strcmp that apparently change our string. However, we can see that the call to strchr (which normally returns the first occurence of a substring in a given string) doesn’t even return a number but instead takes our input and seems to transform it into something longer.
Let’s investigate the function we saw earlier that gets called after the ptrace check, fcn.004011b2:

Something interesting happens here. Basically, the program loads the addresses of 4 library functions, system, strchr, strrchr and strcmp into rax, then loads the addresses of 4 other functions into rdx and finally replaces the library function addresses with the 4 other functions. (These addresses are saved in the GOT, the Global Offset Table). This means that every time one of those library functions gets called, the binary actually calls one of the other 4 functions. This also explains why the call to strchr produced such a weird result. The way forward should seem clear now, we need to reverse each one of the four functions and see what they are doing. So let’s start doing that:

strchr

In the following cases, I’ll use ghidra to simplify the task a bit. When I was originally solving the challenges, I was using a combination of the decompilation provided by ghidra together with dynamic analysis with radare2 to check my findings. For the strchr function, ghidra gives us:

  while (local_c < 0x1e) {
    local_10 = 0;
    while (local_10 < param_2 - ((int)(uVar1 << 3) - (int)uVar1)) {
      *(byte *)(local_c + param_1) =
           *(char *)(param_1 + local_c) * '\x02' | *(byte *)(param_1 + local_c) >> 7;
      local_10 = local_10 + 1;
    }
    local_c = local_c + 1;
  }
  return;

This is a lot of code and it’s also not that easily readable so I’ll talk you through it. Basically, the code loops over each character provided to it as param_1 (our input). For each character it does param_2 iterations (param_2 is always 3 in our case) of the following procedure:
It multiplies the char by two, then ORs it by the character’s value shifted to the right by 7. This means that if the character is bigger than 0x7F (binary: 0111 1111 >> 7 = 0000 0000), we add 1, if not we add nothing. This process is easily reversible, following the python decryption code that takes as input a hex string (excuse my laziness, I actually just generated a lookuplist for each input character):

dictionary = {}
for i in range(40,128):
    char = chr(i)
    encrypted = encrypt(char,3) #encrypt is an implementation of the encrypt routine described above
    dictionary[encrypted] = char # you can find the code for the encrypt function in the PS section

def decrypt(strings):
    result = ""
    for i in range(len(strings)//2):
        char = strings[i*2:i*2+2]
        try:
            result += dictionary[char]
        except KeyError:
            result += "?"
    return result

Now we can reverse the first encryption function, so on to the next

system

Again, decompiled ghidra output:

  while (local_c < 0x1e) {
    *(byte *)(param_1 + local_c) = *(byte *)(param_1 + local_c) ^ (char)local_c + 5U;
    local_c = local_c + 1;
  }

This time, the code is really short and easy to understand. It loops over the input array and xors each value with 5 + the iteration. This means that the first char is xored with 5, the second with 6 and so on.
Here is the decryption routine implemented in python:

def decrypt2(strings):
    result = ""
    for i in range(len(strings)//2):
        char = strings[i*2:i*2+2]
        number = int(char,16)
        number = number ^ (i+5)
        if len(hex(number)) < 4:
            result += "0" + hex(number)[2:]
        else:
            result += hex(number)[2:]
    return result

The function again expects a hex string as parameter and the small construct at the end makes sure that each hex output is also two chars long (This caused me a few headaches when I couldn’t get the correct output).
Alright, on to the next encryption.

strrchr

ghidra:

  while (local_c < 0x1e) {
    local_10 = 0;
    while (local_10 < param_2 - ((int)(uVar2 << 3) - (int)uVar2)) {
      bVar1 = *(byte *)(param_1 + local_c);
      *(byte *)(param_1 + local_c) = *(byte *)(param_1 + local_c) >> 1;
      *(byte *)(param_1 + local_c) =
           *(byte *)(param_1 + local_c) | (byte)((int)(char)(bVar1 & 1) << 7);
      local_10 = local_10 + 1;
    }
    local_c = local_c + 1;
  }
  return;

This part also isn’t too hard. The code basically does some bit-shifting. For each iteration, which is defined by param_2 which in our case is always 2, it takes an input byte, shifts it one to the left and then puts the lowest bit of that input byte in the highest bit place. As an example, we can take 0xA7 which is 1010 0111 in binary. The resulting binary number after the bit shifting would be 1110 1001 which is 0xE9 in hexadecimal.
A decryption function in python could look like this:

def decrypt3(strings,loops):
    result = ""
    for i in range(len(strings)//2):
        char = strings[i*2:i*2+2]
        number = int(char,16)
        for i in range(loops):
            left = number & 0x7F
            left = left << 1
            right = (number & 0x80)>>7
            number = right + left
        if len(hex(number)) < 4:
            result += "0" + hex(number)[2:]
        else:
            result += hex(number)[2:]
    return result

This just shifts the bits in the opposite direction and again expects a hex string as input.

strcmp

We’re now close to the finish line, the only function that still needs to be analyzed is strcmp. ghidra gives us:

  while (local_c < 0x1e) {
    param_1[local_c] = param_1[local_c] ^ 10;
    local_c = local_c + 1;
  }
  iVar1 = strncmp(param_1,param_2,0x1f);
  return (ulong)(iVar1 == 0);
}

Again quite a short function, that does a little bit of encryption as well as the final check.
First, the encryption that is done here is a simple xor with 10 on each character, easily reversible with the following code:

def decrypt4(strings):
    result = ""
    for i in range(len(strings)//2):
        char = strings[i*2:i*2+2]
        number = int(char,16)
        number = number ^ 10
        if len(hex(number)) < 4:
            result += "0" + hex(number)[2:]
        else:
            result += hex(number)[2:]
    return result

After that, the binary calls strncmp which compares two strings for a given length, in out case a length of 0x1f. The function then checks if the output is equal to zero, so if the two strings are equal and returns to main.
What we need to do now is to extract the string it’s compared against, we can find in the main function that it’s located at 0x404080. In radare, the memory at that address looks like this:

Having that we can finally solve the challenge by chaining the decryption calls. In my example, the code looked like this:

encoded = "fbd1518aee7e54699b6f77b080ee70c1296771e49cea72ed935f11eaa478"
print(decrypt(decrypt2(decrypt3(decrypt4(encoded),2))))

Running this gives us the flag X-MAS{N0is__g0_g3t_th3_points}

Summary

Great challenge to start off the CTF even though it was already quite tough for only 50 points. In general, the challenges in this CTF were way harder than at any others I had previously participated in but it was nice to just be tenacious and not give up even if it took more than 5 hours to finally get the solution (one of the other challenges in this CTF). The next writeups won’t go into this much detail, I just always think it’s nice to explain the first challenge extremely clear so people that couldn’t solve it can learn new stuff and tackle it at the next CTF.Hope you liked this writeup
-Trigleos

s3-simple-secure-system

TL;DR

Extract RSA keys from executable and decrypt encrypted document

Description

This was a challenge at the ENISA Hackfest 2020, which posed as a replacement for the ECSC 2020 that was supposed to be held in Vienna but unfortunately got cancelled due to Covid19. This challenge was marked as easy. However, it took me quite some time to figure it out, mostly due to the different meanings that ‘word’ can have for different developers (more on that later). 39 people managed to solve this challenge with a final score of 120 points.

Challenge Description

During an investigation we noticed that one of the employees used to this tool to encrypt some sensitive information. However, we were not able to recover the original information to see what has been leaked. Can you develop a decryptor for this?

Flag format: CTF{sha256}

Author: BIT SENTINEL

Basic Dynamic Analysis

Let’s begin by running the executable through ltrace and check if we can find anything interesting. We need to provide a valid file as an argument or the executable won’t run completely. When doing that, we get the following output:

strlen("")                                       = 0
strlen("")                                       = 0
fopen("flag.txt", "r")                           = 0x55a9844142a0
__isoc99_fscanf(0x55a9844142a0, 0x55a9837e0e02, 0x7fffa6c9c5c0, 1) = 1
fclose(0x55a9844142a0)                           = 0
BIO_new_mem_buf(0x7fffa6c9b100, 1193, 0, 0x55a984414010) = 0x55a984414490
d2i_PrivateKey_bio(0x55a984414490, 0x7fffa6c9b0e0, 0x7fffa6c9b0e0, 0x55a984414620) = 0x55a98442cc00
EVP_PKEY_get1_RSA(0x55a98442cc00, 3, 0x55a98442c750, 0x55a984414010) = 0x55a98442cdf0
RSA_check_key(0x55a98442cdf0, 3, 0x55a98442c750, 0x55a984414010) = 1
RSA_public_encrypt(0, 0x7fffa6c9c5c0, 0x7fffa6c9b5b0, 0x55a98442cdf0) = 256
fopen("encrypted.txt", "wb")                     = 0x55a9844142a0
fwrite("\221\375\370w\333z\027NH\021\300\227\313", 1, 256, 0x55a9844142a0) = 256
fclose(0x55a9844142a0)                           = 0
RSA_free(0x55a98442cdf0, 1, 0, 0x55a984414010)   = 1
EVP_PKEY_free(0x55a98442cc00, 1, 0, 0x55a984414010) = 0
BIO_free_all(0x55a984414490, 2, 0x55a98442c110, 0x55a984414010) = 1
+++ exited (status 0) +++

A few things to note here are that the executable opens flag.txt and encrypted.txt, scans from flag.txt and writes to encrypted.txt. We can assume that it does something to the content of flag.txt and writes the output to encrypted.txt, so we need to reverse that process. A last thing to note is the utilisation of several RSA functions like RSA_public_encrypt and RSA_check_key that are probably used for the encryption.

Reverse Engineering

When we open the file in radare2 we get a similar picture to when we ran it through ltrace. At this point, it is probably a good bet to try to extract the RSA keys out of the running executable and use them to decrypt the file. In order to do that, we need to find out where they are saved and used so we can analyse the memory at that address. A quick web search for RSA_public_encrypt reveals that the function is part of the OpenSSL toolkit for C: https://www.openssl.org/docs/manmaster/man3/RSA_public_encrypt.html. The function description looks like this:

Looking into the preparation for the call in the executable, we see the following:

Putting this information together with the C calling convention on x86-64 systems that puts arguments consecutively into rdi, rsi, rdx, rcx and r8 , we know that rcx must point to an RSA object before the call to RSA_public_encrypt so the RSA object is saved in the variable var_24d8. Let’s take a look at what this variable points to just before the program executes the encryption function:

While we can’t see any clear indication of an RSA key, there seem to be several pointers to objects. Let’s check what an RSA object looks like (we can find this again in the docs for OpenSSL at https://www.openssl.org/docs/man1.0.2/man3/rsa.html):

As we can see, the RSA object is a struct containing addresses to several BIGNUMs, each BIGNUM representing one factor of the RSA key (I still don’t know why the RSA object in memory has 24 bytes that are not used for anything) . In my first run through, I extracted p,q and n to check if I extracted in the right way, however, as only the private key d and the public key n are needed to decrypt the file and the process is the same, we will focus on d for this writeup. So let’s look what the address that’s designated as d (0x5632c50d4810) points to:

Again, what looks like another struct and still no key in sight. As we know from earlier, this struct is a BIGNUM so let’s search what that looks like: https://www.openssl.org/docs/man1.0.2/man3/bn_check_top.html. (This took me some time and I found conflicting sources on this so I lost most of my time here.)

It finally looks like we’re close to the end. The first field (0x5632c50bce40) is a pointer to an array of chunks and the third field contains the size of the array. In our case that means the size is 0x20 = 32. However, what does that 32 mean? 32 bytes? 32 words? 32 double words? So I had to look for another source that clarifies this. I found the following webpage: https://linux.die.net/man/3/bn_internal that seemed to solve my problem. I quote directly:
The integer value is stored in d, a _malloc()_ed array of words ( BN_ULONG ), least significant word first. A BN_ULONG can be either 16, 32 or 64 bits in size, depending on the ‘number of bits’ ( BITS2 ) specified in “openssl/bn.h”.
However, as I was already quite tired, I didn’t even read the second part that specified that in this case, a word can have different sizes (2, 4 or 8 bytes) and just assumed that it was 2 bytes because that’s what I was used to. So after extracting p and q and checking that they were indeed not prime, I knew that something had gone wrong and I went back to the defintion of a “word” and took a look at the array in memory. I wish I had done this earlier because you could easily see where it stopped:

We cleary see that we get a lot of 0x00 bytes after an array size of 256 bytes. Divide that by the earlier established length of 32 and we see that in this case, a word is 8 bytes long (I still think that’s weird). 256 bytes is quite safe for an RSA key though so I guess this would closely remember real life conditions. Now that we know that the key is 256 bytes long, we just need to extract it (easier said that done, this involved a lot of copy-pasting and reversing the bytes because of endianness). After doing that we finally get d which is the glorious number

13242780575016631121007479458750836510201287903770587799422460380939567854868574792397941824867360331144478429113840623971492738297234451139859241839168378713484112202543233717163557823499902460065918395255054938719512509645605536663786638012933431481065441250286873370736039376072124019805982690045324448840584099629026161825831273851957612805673365273520117577764033680727193566316713813055607197671025790385182072240740451394950345647793538733126077154308585814366642816043725010389255832688248284885710351416852440042663301147377791076232453145659185003475038106730305346131734111066504896486992177730814699913985

Doing the same for n, we get

24677759121523641666736818825902174425461679471961472109265255935216709559683863236639765514411333675174604987597991781774281884323860622262587936319303307905985619762235943817616312351181810899523446611215290042903144568928432712227660294448338545280633109363929904748441178668419312231966353537419330330793495007040123186586486143837302323885733197008630567172471971841027861712951190275075531165655055520235384630893075777672420016071702164555300181008372286489221013065438746310174580938927903748737004904042045912024248087581766732714598781661338003772040007474963065518714021592324888601144706354320303587618037

That’s all we need in order to decrypt the file. The remaining work is writing a simple RSA decryption script in python:

n = ***
d = ***

f = open("encrypted2.txt","rb")
data = f.read(256) #encrypted file is 256 bytes long
secret = int.from_bytes(data, "big")

decrypted = pow(secret,d,n) #this is the whole RSA decryption
result = ""
while(decrypted>1):    #translating the resulting number into ascii text
    ascii = decrypted%256

    result += chr(ascii)
    decrypted = decrypted//256


print(result[::-1])

And finally, running this script gives us:

ÌN`\¯ÖïëKò%è,Ô(Æv§èxÒò· 1Hm`aoza­9YNÕ×=ÛOÚÇ�C0kì¡4=K¡qJÅðÿìfókAFH|µµÿsðY4uu½¢¾Fö"¥æ
                             ~è·+î¶>Rð6-Yº3ê[ré    ÀCTF{67131493f75e92a06c5524b7c4c2be3513d992dafeb03e0e0296df0c5716155b}

so the flag is CTF{67131493f75e92a06c5524b7c4c2be3513d992dafeb03e0e0296df0c5716155b}

Summary

I really liked this challenge as it combined Reverse Engineering with Cryptography and showed me how to extract RSA keys and scavenger the internet for documentation on obscure structures. It took me some time but I’m happy that I didn’t give up after not seeming to know what a word is anymore. Hope you liked this writeup. Until next time,
Trigleos

castorsCTF2020

TL;DR

Investigating a Ransomware attack and trying to reverse the process

Description

This is the second part of a two part series. In this part, we’ll apply the knowledge we got from analysing the executable in part 1 and reverse the encrypted image

Recap

In part 1, we discovered that the executable contacts a server to get a seed and that that seed is then used to encrypt the flag using simple xor encryption. So let’s start by investigating the pcap that is part of the challenge

Network analysis

We already discovered that the executable is contacting a server sitting at the IP address 192.168.0.2. The pcap file confirms this as well as the exact http call.

From the investigation of the executable, we know that the seed is only accepted if the server sends back an “ok” at the end of the exchange. Let’s see if we can find one.

The capture contains 5 GET requests. However, only the last one is followed by POST sent from the client executable (the actual ransomware). If we take a look at that POST request, we can find the chosen seed

Now that we know that the seed is 1337, we can finally start to write the programs that help us decrypt the image

Generating the random sequence and decrypting the image

In order to get the random sequence that was used to encrypt the image, we need to write a Go program that generates it. You could easily write the entire solution in Go and let it also decrypt the file but before this challenge I had never used Go so I just limited myself to writing a function to generate and output the numbers. The last thing we need to find out is how long the image is so we know how many numbers we need to generate. A simple ls -l shows us that the image is 1441 bytes big (fairly small).With this info we can now write the Go program

package main

import (
    "fmt"
    "math/rand"
)

func main() {
    rand.Seed(1337) //the seed
    for i := 0; i < 1441; i++ {  //the size of the image
        fmt.Print(rand.Intn(254))  //the range of random numbers
        fmt.Print(" ")
    }   
}

Compiling this gives us a working program so let’s save the output to xor_key. I’ll write the main solution script in python because it’s the language I’m the most comfortable with.

xor_key = open("xor_key","r")
xor_list = xor_key.readlines()[0] #read in key
xor_key.close()
xor_list = xor_list.split(" ")
with open("flag.png","rb") as encrypted:
    with open("output.png","wb") as output:
        byte = encrypted.read(1)
        index = 0
        while byte != b"":
            first = int.from_bytes(byte,"big") #transform byte of image to integer
            second = int(xor_list[index]) #take integer that was generated
            res = first ^ second #xor both
            print(res, first, second)
            output.write(res.to_bytes(1, byteorder="big")) #write result to output image
            byte = encrypted.read(1)
            index += 1

Running this gives us an output.png file so let’s try to open it.

We managed to recover the encrypted file and defeat the ransomware. I hope you liked this detailed looked into reverse engineering. I’ll try to write some more posts about it because I’m very passionate about these types of challenges and I hope you’ll come back to read them as well.

-Trigleos