To capture the flag it is enough to jump into code that is a part of command_PASS function - system("cat flag.txt") įirst idea - leak some memory to obtain address of. It is not necessary to create a shellcode using ROP technique. It reads 4096 bytes to password which is only 128 bytes long.
Indeed, function command_PASS is prone to buffer overflow. It is reasonable to expect that buffer overflow vulnerability is present. It only reads user input to stack buffers and what’s more, canaries are not present on the stack. The program use neither heap buffers nor prints user input. text section is placed at different address on every execution of the program (note that when you run binary in gdb, it disables PIE and also ASLR). Security protections of the binary can be listed using checksec command:īinary is protected with PIE which makes that. I started to think where vulnerability can be located. I didn’t find vulnerability when reverse engineering the first time. I created a file flag.txt and placed fake flag inside.
It calls function which I have called real_main. It does some initialization which I was not analysing.
I simplified it to avoid distracting readers with irrelevant details.
My C code is not 100% the same as original binary. This can be done by chosing Edit -> Segments -> Rebase Program and typing an address to be used as base - 0x555555554000.īelow I present my interpretation of reverse engineered binary. I’ve set up IDA Pro to show the same addresses when binary is loaded in the memory when PIE is disabled (for example when you run binary in gdb, or disable ASLR in your system).
0 kommentar(er)
