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 directoryPerhaps it wants a flag.txt file? Let's create one with the words FwordCTF{flag_flaggety_flag}:
$ ./task
input :
test
4
input :
pao
2This 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?