Hey Everyone, This is my first ever write-up. I hope it will be useful to you. I would like to Thank the Infosec community for sharing their precious knowledge which eventually helps me to learn about CTF and all other infosec stuffs. So lets Start.
BountyCon is an invitation-only application security conference arranged by Facebook annually in Singapore for the BugBounty Community of Asia-Pacific region and BountyCon2020 is the second edition of their conference.
For more information about it, click here
Unfortunately, I didn’t get an invitation but still, it was a great learning experience for Noobies like Me :)
One of the Binary Reversing Challenge ‘Anti What’ was easier one. Challenge says ‘ ‘What do you mean a debugger is already attached?’’ which means there could be an anti-debugging code, Anyways after downloading binary. I quickly fired up IDA Disassembler to disassemble it. then I noticed the main function has ptrace call which indicates anti-debugging.
So, when we try to debug this binary it simply close and delete(unlink) itself. Now we have to bypass it, Simplest way is a patch or modify the binary.
so We will replace from first _ptrace call to jmp before function RC4_set_key
with NOP(No Operation) which is 0x90. I will use the HxD editor to modify it.
Now we can debug it without Problem and now if we check it IDA. It creates a nice NOP slide.
There is a function RC4_set_key which takes a global variable key as a parameter. which is an array of bytes. then it writes to memory location [rbp+0x110] from the first parameter, looks like a c++ object. Now after that function RC4 called with the same object pointer and global variable ptext as a parameter and writes output to the location of ptext so replaces the encrypted text with decrypted one. Execution flow looks normal till now.
Then runPayload function called, by looking into that function we can see that it dynamically allocates memory location into a heap by custom wrapper function around mmap syscall named rwxmalloc. then one more function unpackPayload called, which jumbles bytes of plaintext ptext with bytes from other locations and write result onto newly allocated memory address. then it calls from that memory address.
So It's clear that we have to use a debugger to look into that dynamically allocated memory address to find out the flag. So I started gdb on binary. and set 1st breakpoint after function rwxmalloc and 2nd after unpackPayload.
Ooops 😬, If this happens, set a breakpoint on the main function first, then run binary. which will stop execution at the main function now we can set a breakpoint to other instructions.
😮It unpacks raw machine instructions and call instruction transfers Program Counter to that address. These instructions perform a xor operation to decrypt data. So we can now quickly set a breakpoint on ret instruction and look into the returned address and We have successfully found the Flag 😃
I hope you learn something from this. Thanks for reading my write-up! Cheers! 🍺