XO

Messing with the XOR

Overview

Let's try running the file:

$ ./task 
Error while opening the file. Contact an admin!
: No such file or directory

Perhaps it wants a flag.txt file? Let's create one with the words FwordCTF{flag_flaggety_flag}:

$ ./task 

input : 
test
4
input : 
pao
2

This isn't quite counting the number of letters we enter. Let's see if the disassembly can shed any light on it.

Disassembly

First thing we notice is that every libc function is built into the binary due to the stripped names. We can confirm this with rabin2:

Cleaning Up

Many of the functions can be handled using the return address and the general context. Some of the decompilation - especially the references to strings - may not have loaded in yet; make sure GHidra finishes analysing. We don't even need the exact C names, as long as we get the general gist it's all fine.

The python equivalent of this is roughly

In short, it's an XOR function.

Working out the Flaw

To calculate the length of the string it uses

The key here is strlen stops at a null byte. If you input a character with the same value as the flag character in that position, it will XOR to become \x00.

Using the Flaw

We can test every possible character. If the returned value is one less than the length of the string, the last character is correct as it XORed to create a null byte.

To test different offsets we can pad using a value definitely not in the flag, such as #.

Exploit

Local

Now we can just switch out the process type on the remote server.

Remote

Flag: NuL1_Byt35?15_IT_the_END?Why_i_c4nT_h4ndl3_That!

Last updated

Was this helpful?