April 14th, 2003, 11:25 PM
why can't i kill my stack!!??!!??
shouldnt this get a segmentation fault:
running RH8 compiling it with gcc
for (i=0; i<=4030; i++)
April 14th, 2003, 11:32 PM
when i change it to an integer array, and set the loop to run until i=15, then i get a segmentation fault. but when i = 14 it runs perfectly fine...im confused? why wouldnt it fault at i = 10,11,12,13, or 14, but instead at 15? and why only with a int array instead of a char one?
// C++ version /////////////
using namespace std;
int i = 0;
for(i; i <= 15; i++)
buffer2[i] = 2;
cout << buffer2[i] << " ";
cout << endl;
Last edited by infamous41md; April 15th, 2003 at 01:06 AM.
April 15th, 2003, 02:46 AM
some compilers add extra elements to prevent buffer over runs
the buffer may be byte aligned to 15 bytes and a terminator (for a total of 16 bytes).
The essence of Christianity is told us in the Garden of Eden history. The fruit that was forbidden was on the Tree of Knowledge. The subtext is, All the suffering you have is because you wanted to find out what was going on. You could be in the Garden of Eden if you had just kept your f***ing mouth shut and hadn't asked any questions.
April 15th, 2003, 09:53 AM
hmm, how smart of them! perhaps if i turn off optimization that will help. the funny thing is that any time this has accidentally happened to me in MSVC++ and i overstep by even one element, it would crash. and now im trying to make it crash and it wont let me
back to WinBlows for a bit i guess
April 15th, 2003, 11:52 AM
Hey, infamous41md, are you testing what buffer overflows are "good" for? LOL
April 15th, 2003, 04:45 PM
MHirsch<< well, i know what they're "good" for, ehehh , but currently i'm too newbish to do anything like that b/c i'd be afraid of funkin up some poor guys system and not even know it. right now im just trying to get a hang on exactly how the stack responds and where the eip points to. i m sure there are plenty scripts-in-a-can but that's not really any fun.
edit: bah this is freaking hard
Last edited by infamous41md; April 15th, 2003 at 09:03 PM.
April 16th, 2003, 01:41 AM
I think noone here would to this to "some poor guys system". But it is really an interesting area to test on your own programs & for learning purposes. Also, sometimes you are challenged to prove that a certain system is not secure ...
I heard they canīt disable code execution on the stack globally in linux eg. because some programs do rely on that. Still wondering which they are and why they do that...
April 16th, 2003, 12:15 PM
yea this is very interesting, but damn is it complicated. im still trying to understand what is going on in the code in my above posts. its very strange. when i use integer arrays, i can cause an overflow at , but when i use char arrays, i have to go all the way up to ! so, this has got me thinking... an integer is 4 bytes, and a character is 1 byte, correct? so in the integer array,  is 6 indices past the last "good" one, so that's 24 bytes. in the char array, it is 130 indices past the last good one, 130 bytes? but obviously that is a huge discrepancy (130 to 24), so i cant seem to understand why it behaves that way.
ps. to make it even more complicated... sometimes  doesnt cause a fault! and i have to change it to !! wtf??!!
April 16th, 2003, 12:28 PM
Could be because of this:
Segmentation faults donīt say that you accessed a part of the array that does not exist. It says that you accessed a part of your memory that does not.
So: if the array coincidently points to a valid memory address, it will not cause a segfault. For example if other variables are in memory after the array (or code - here we are back on the buffer overflow subject and its security problems)
April 16th, 2003, 09:59 PM
April 17th, 2003, 03:02 PM
GNU: wow, great link! that will help a lot in my quest to learn... for some strange reason my teacher doesnt like it when i bring up this idea in class so i must seek alternative sources!