Reverse Engineering CTF. 

These are a series of challenges which need to be solved. We will be using Binary Ninja to reverse engineer the program. The program looks as follows with 3 different sections: 

Lets begin with section 1) x64_ASM. After pressing 1, we are presented with the following screen which asks for 2 args: 

Lets begin reverse engineering. 
The source code shows this function which handles the logic. 

As we can see the instruction_test(arg1, arg2) function plays a crucial role. Lets take a look at its assembly 

Very simple. If the result of the function does not equal 0x7a69 (31337), evaluation failed. Going back to the assembly provided in the first screenshot, some quick maths gives us the answer 30569. Therefore arg1 = 0 and arg2 = 30569

The second challenge asks for a serial.

Source code below:

As you can see, the check_serial(serial) function does the heavy lifting. Lets analyse its assembly.

The check_serial function looks to see if each value of arg1 is a particular number converting these hex to ascii gives us the following serial number: ​189715

The third and final challenge asks for a password 

If you provide a password of the wrong length you receive this error:

Lets look at the code and begin reverse engineering. As we can see from the code below, the password needs to 14 characters long (0xe = 14).

Providing a password of length 14 gives us this screen.

It appears to check each character. Analysing the earlier source code and assembly shows the check is done under encryption_check(password). Lets disassemble this function. 

Following the logic of the disassembled function, we can see that it takes our arguments and encrypts them via XOR against 0x17. If the output does not equal gW""`xesHav{~s, then it goes to the invalid_encryped_char() function. 
Therefore gW""`xesHav{~s is our encrypted string and with this, we can write a very simple decryption routine to obtain the password.

Quick C++ program I wrote to decrypt and encrypt the strings for demo purposes. The decrypt function essentially reverses the XOR encryption routine. Encrypt function shows how the CTF challenge encrypts the password in the first place. Running the program outputs the following. 

1) The decrypted string = p@55w0rd_valid
2) The encrypted string = gW""`xesHav{~s

Entering the decrypted string into the CTF challenge shows us:

Finished. Hope you enjoyed it.

​This level was also simple although a bit harder than the previous levels.
 
The main function is extremely short, passing off much of the work to the login function.
Here it prints out the a series of strings using a puts function. The most important string being:
 
“Remember: passwords are between 8 and 16 characters:”.
 
Due to this we can assume some kind of overflow is expected. Later on within the function it tries to compare hex value 0x11 with memory address &0x2410.
To do so, the final (17th) character would need to be a hex encoded character. This would be 11

Password: ​4141414141414141414141414141414211

​Today we are going to talk about analysing the Kovter malware. For those unfamiliar with Kovter, it gained fame in 2015 for being one of the more prominent attacks which utilised living of the land attacks.  Before we begin, there are several concepts which must be explained

1) living off the land – Living off the land refers to using native or signed scripts/binaries to further an attackers goal 

2) Sysmon – Sysmon refers to a tool created by Microsoft which enhances Microsoft wineventlog by providing addition logging based on event codes. It also allows for the customisation as it can ingests a XML with custom command which can monitor select files/ports as shown below 
​

Lab Setup
​

As you can see, the fields all appear to have data in the fields. However clicking on the value htavir (probably after hta virus, why though?) shows no data. In fact clicking and attempting to edit the box failed. After dumping the registry hive to disk and analysing, I believe the issue is this highlighted below:​

​This the second level of Microcorruption. If you haven’t seen the first level, please go back.
Let’s Begin!
 
This level is slightly more difficult than the previous level, but again nothing strenuous. Scrolling through the disassembly we again see the check_password function. Quick analysis of it shows several compare functions (cmp). This shows us its comparing our input to a hard-coded password little by little.
​ 

​Converting these Hex values gives us the following password: Sl)pQ/*b
However, we must take into account the endianness of the system. Simply put, there are two ways to arrange data in memory, big endian and little endian.
In big-endian the most significant byte, the byte containing the most significant bit (the leftmost byte), is stored first, at the lowest address. The least significant byte, then, has the higher address.
In little-endian the least significant byte, (the rightmost byte) is stored first, at the lowest address. The most significant byte, then, has the higher address.
The diagram below explains how this works. 
​

​This essentially means we have to change the alphabetical order of our passwords around. E.g the first hex value may be “0x536c = Sl”, this in reality should be “lS”. The endianness switches the position of the letters around. Doing this for all hex values gives us the correct password: lSp)/Qb*

So this is the beginning of the Microcorruption CTF. It’s a embedded reverse engineering minigame. Please complete the Tutorial if you haven’t already before reading this. I recommend you read the lock manual as well. This will give you a basic understanding of LockIT and MSP430 Assembly.

DISCLAIMER: I’m really not an expert at reverse engineering/ assembly. If you notice a error on my behalf please tell me.

Lets begin

This level is very easy and can be solved in two different ways.
 
1) Check_password Function
First method is by analysing the check password function. Here we can see the compare being used between register r13 (your input) and memory address 0x2400. Going to the memory address reveals the password.



























2) Create_Password Function
 
In the previous method the password was found in memory, this method shows us that the password was actually hard-coded into the assembly and written to memory address 0x2400. 

​
The first instruction of the function moves r15 to the memory address. The remaining functions write the hardcoded password in. If your new, the hardcoded password is written in hex and highlighted in the yellow box.
 
Password: [mHub71