【好玩】缓冲区溢出攻击实验

aero

原帖由 "Solaris12" 发表：


deadbeef的意思是使用了已经被free了的内存，
当然会有段错误了！

不是吧。上面win_hate已经说的很明白了，是因为后面的'\0'会破坏test压入的ebp，以致于无法在返回main函数的时候，进入正确的“轨道”。

aero

原帖由 "Solaris12" 发表：


抱歉，刚才没仔细看，呵呵
这个出题目的一定是老美，
deadbeef在Solaris的调试器里面有特殊含义，抱歉

哦，虾米特殊含义啊？说来听听。   

aero

^_^，原来还有典故的说。

aero

^_^，你要先明白啥是缓冲区的概念，然后知道为什么会溢出，然后分析明白栈帧的哪里到哪里是表示什么的。

呵呵，看看偶blog上对这个问题的详细分析。应该对你有帮助。

aero

看源码啊，然后结合编译器的对齐规则。^_^，其实，各种不同的编译优化选项也可以使它不同呢，甚至可以不使用ebp呢。

看源码，然后编译，然后调试，然后确定，然后实验，然后去试目标。

aero

大致看了一下，发现有以下问题：
>;>;前面大家都是修改了test的返回地址，修改getbuf的返回地址大家觉得可以么？
都是修改的getbuf的返回地址啊！可以看看我的blog上的一篇详细分析，一种方法是修改getbuf的返回地址并修改val的值。另一种方法是修改getbuf的返回地址并修改test种的ebp使改变val的位置使之与buf重合。

>;>;我的想法是应该可以在gdb下运行bufbomb程序，在getbuf处设断点，当运行到getbuf时
>;>;print /x $ebp
>;>;得到getbuf frame pointer值
打印出的ebp是test中的ebp值，不是getbuf中的ebp值，要用s执行一下后才是。因为这个时候还没有执行movl    %esp, %ebp这条指令。

>;>;大家觉得这个方法可不可能行得通？我试过将return address覆盖为任意一条已编译好的instruction的地址，能够成功。但将return address覆盖为buf[]地址的话，就会在getbuf ret回test时发生segmentation fault.这里为什么会发生segmentation fault?怎么才能够ret回这个stack frame部分呢？
正如converse说的，堆栈的地址是从高到低的，而指令的执行是从低到高的。将返回地址覆盖成buf地址后，由于buf中全是空指令，不会有什么问题。但是，堆栈的上面是存储的test中的ebp的值，这个值一般并不会是一个可以执行的机器指令，或者是取什么地址了吧？反正就是fault了。^_^，猜的。

aero

看了，converse的解释，明白了。好！又是一种思路！

试验成功了！不知道你们错哪里的。仔细做应该没问题的，思路是对的。我也做了好久，后来发现把一个e8写成f8了。

另外，发现gdb中，用b getbuf和b 38（用行号）设置的断点是不一样的，后者设置的就是没执行pushl %ebp指令的，而前者就是执行了的。

aero

我的填充串是这样的：b8 ef be ad de 68 bf 84 04 08 c3 00 01 02 03 04 05 06 07 08 09 10 11 12 e8 ef ff bf c0 ef ff bf
1、前11个字节就是那三条指令，而指令的地址也正是用objdump看出来的，这里是080484bf。
2、后面的13个字节是buf中剩余的字节和gcc为了对齐（也许不全是，因为整整空了12个字节不使用）而空出来的12个字节。
3、接下来的4个字节就是原来堆栈里的ebp（test函数的STP的ebp，就是getbuf函数开始push进去的ebp）。
4、然后的4个字节就是getbuf返回的eip，修改它，将它修改成buf的起始地址，这个是通过在gdb中使用p &buf命令看出来的（这个地方还有一个问题不明白，一会说）。
5、后面的4个字节是同2一样的无用空间。然后的4个字节就是val了。由于getxs函数会在buf的末尾加上一个'\0'，所以将这个'\0'放在这个无用的空间是无害的。
整个填充串就这样完成了。

我开始的时候把3中的ebp搞错了，搞了好常时间没出来。后来用gdb的x命令观察堆栈，并单步执行，发现ebp的值不是我原来的那个了（写blog上那篇文章中的时候），和那个不一样了。^_^，偷懒偷不得啊！

aero

>;>;我就是在运行到getbuf的断点时(此时已执行了push %ebp和movl %esp,%ebp)
print /x ($ebp-24) 来得到buf[]地址的,我感觉应该也没有错

的确，感觉这样也没有错啊！呵呵，今天上班有点忙，就没多看，明天到公司在看看。

另外，我说的那个问题就是：当用b 38（行号）设置断点的时候，r到这里的时候是刚刚执行完毕call指令（可以用x命令看堆栈看出来）。在这个时候执行p &buf得出的地址值并不是buf的真实地址。而n了一步以后，就实执行了建立getbuf函数的STP后执行p &buf得出的才实真是的buf地址。不知道为什么。那么前面的那个buf是哪个buf呢？如果没有可见的变量，gdb应该报变量未知啊，而它却打出了数值。