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

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了。^_^，猜的。

zne

to aero:

一 呵呵不好意思,看错啦

二 从到达断点时的提示信息来看，此时程序停在0x080484bf处(下一条要执行的指令是0x080484bf处的指令)，这时打印出的ebp感觉就是getbuf的frame pointer值(%ebp),因为0x080484bd处的指令movl %esp, %ebp 应该已经执行了，从图中打印出的(%ebp+4)地址处的内容也可以看出（打印出的就是getbuf返回test的return address 0x80484e9）

三 关于机器指令的排列顺序，我感觉第三个图中的排列顺序应该是对的,不过由于让程序转去执行buf[]中的内容这个尝试总不成功，也不好说，也可能是错的。不过感觉如果指令排列顺序错了，不应该会在getbuf的ret语句处就出现segmentation fault吧，感觉ret "buf地址" 时系统就取不到buf[]地址处的内容似的...

由于原题目（前面贴出了）中提示说让在buf[]中输入机器指令，觉得这个做法（修改getbuf返回地址，让程序转去执行buf[]中内容的方法）应该是对的。但不知道为什么实现不了...

converse

我试了N次,觉得理论上应该是没有问题的,可是就是不行.

zne的思路是往缓冲区写如如下的代码:

1. 
   
2. asm("movl $0xdeadbeef,%eax");
   
3. asm("pushl $0x080484e9");
   
4. asm("ret");
   

复制代码

其中的$0x080484e9具体情况下不尽相同,这个是test函数在调用完getbuf以后下一条指令的地址,就是说他的想法是在test函数中插入
movl $0xdeadbeef,%eax
这条指令.

上面这三条汇编码的机器指令是:

1. 
   
2. b8 ef be ad de
   
3. 68 e9 84 04 08
   
4. c3
   

复制代码

所以只需要往缓冲区里写入这三条机器码然后把getbuf的返回地址改为这三个机器码的起始位置就可以了,我原来认为他把机器码的顺序写反了,可是我自己写了写还是不行..........

aero

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

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

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

zne

成功了^_^ 好啊好阿，帮我看看吧

就是我贴的第一副截图和第三副截图，看第三副截图的操作有什么错误么，是不是机器指令顺序错了呢？
我照第三幅图的做法试过挺多次的了... 各种地址和指令应该都没错的

converse

aero截图来说明,夹叙夹议带抒情的那种

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上那篇文章中的时候），和那个不一样了。^_^，偷懒偷不得啊！

zne

>;>;我的填充串是这样的：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

b8 ef be ad de 68 bf 84 04 08 c3 00 01 02 03 04 05 06 07 08 09 10 11 12 这部分没意见,下面的test的frame pointer我觉得我输入的也是对的(不过这里有个问题,一会会提到),关键就在buf[]的地址上,是怎么来得到的?

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

但是有一个问题,我看有一些书里写对每个linux程序来说,代码段都从0x08048000开始,stack frame段都从0xbfffffff开始,
aero得到的test 的frame pointer是0xbfffefe8,buf[]地址是0xbfffefc0,显然是符合这个说法的
而我打印出的test 的frame pointer是0xfeeb7ff8,buf[]地址是0xfeeb7fc0,跟书上的说法不符,都比0xbfffffff大出很多... 不知道converse你的情况怎么样?

我的系统是fedora core 2,去年10月买的,就图书城里买的那种9张cd一张dvd的那种,有没有可能是这个系统不许程序执行数据段,尤其是堆栈段的内容呢?

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应该报变量未知啊，而它却打出了数值。

victoryMa

各位大侠，我是一个新手，按照你们写的调试完了，基本上通过了，可是不知道为什么我的main函数的ebp值老是在变？
大侠帮帮忙,小的先谢了