Writeup: tlsv00

We begin by looking at the protections of the binary.

We have several problems and we can not execute code in the stack due to NX protection and we do not see the possibility of an overflow due to canary. We also have PIE activated and full relro so GOT dereferencing/overwriting will not be possible. We start with option 3 that will call the print_flag function. If we see inside the function we have a buffer called do_comment and also call rdx where we could have some control.

Seeing do_comment we discovered two other buffers of great importance, one called key and another flag. If we start at the beginning of the binary, it calls the function generate_key, generate a key first in the stack, and then copy it with the key to the buffer. In the flag we do not have anything yet because we have not loaded the flag or in other words, we have not made option 2, which is the load flag.

If we press the option "y" will store the function pointer f_do_comment into do_comment buffer. It is also verified that the last byte of the pointer is stored in do_comment will be equal to zero and the beginning of the buffer is zero, so it will not perform the conditional jump JNZ causing the function f_do_comment to call rdx.

We can deduce that we will never enter the f_do_comment function anymore because the last byte is now 0x1f and it is not 0x0 so it will take the jump and call rdx. After several investigations in option one when we generate a new key and specify a lenght if for example we introduce with a length 1 this generate a key of this type 0xa0 being the "a" a random value ​​plus the zero. It always adds to null byte at the end and we can see it in the key that is generated at the beginning as it ends in 0x0 before overlapping with the do_comment buffer. Therefore, if we set length 64 after the key is generated it will overwrite the last byte 0x1f with 0x0 of the pointer corresponding to call rdx in do_comment buffer and if we set so, we can read the encrypted flag because the address ends in 0xb00 and the function that read the encrypted flag is real_print_flag. Boom hikacking redirection flow!. 

Knowing that we can read the encrypted flag we now have to see how it is encrypted and seeing the function load_flag a xor of the content of the flag buffer is performed with an encrypted key in the buffer key. Therefore knowing that it always ends with a null byte can perform the xor with null byte and the value of the contents of the flag. Boom! We have won, simply by executing the binary and going iterating the lenght (1,2,3,4,5,6...) we can know each value of the flag.