weird behaviour by gcc

[gautam]

can anyone pls tell me y is the memory allocation not alligned to 4 Bytes.
Note : compiled with gcc in linux 9
void function(int a,int b,int c)
{
char buffer1[5];
Bytes allocated(as shown by gdb)
/*buffer1[4] ---------------------> 4
buffer1[8] ---------------------> 8
buffer1[5|6|7|9...18] ----------> 18
buffer1[19...] -----------------> 28
int *ret;
ret = buffer1+28;
(*ret) += 0xa;
}
int main()
{
int x;
x=0;
function(1,2,3);
x=1;
printf("%d\n",x);
return 0;
}
I was trying the article from phrack 49 (Smashing the stack for fun n
profit) when I noticed this behaviour by gcc.
Is something wrong with gcc or am I missing on some knowledge here....

Thanks in advance.

 

[Malcolm]

can anyone pls tell me y is the memory allocation not alligned to 4
Bytes.
Note : compiled with gcc in linux 9

The compiler can align memory as it chooses. If there is no hardware
advantage in aligning objects on 4 byte boundaries it typically won't do so.

void function(int a,int b,int c)
{
char buffer1[5];
Bytes allocated(as shown by gdb)
/*buffer1[4] ---------------------> 4
buffer1[8] ---------------------> 8
buffer1[5|6|7|9...18] ----------> 18
buffer1[19...] -----------------> 28
*/

These numbers could represent anything, such as random results from the
previous program, or they could be hardwired into the program, or they could
be stack return addresses and change on every run.

int *ret;
ret = buffer1+28;
(*ret) += 0xa;

Now you are attempting to convert buffer1+28 to an integer, and add 10 to
it. If this works and ints are 4 bytes then the highest (little-endian) or
lowest (big-endian) bytes will be modified. However if the hardware doesn't
allow 32-bit writes to non-aligned addresses, and it happens that the value
doesn't fall on a boundary, anything could happen, from program termination
to memory corruption.

}
int main()
{
int x;
x=0;
function(1,2,3);
x=1;
printf("%d\n",x);
return 0;
}

function() performs an illegal operation, so anything is allowed to happen
(undefined behaviour). Since you set x to 1 after the call then, if the
program doesn't crash, it is unlikely that the prinf() call will print a
value other than 1.

I was trying the article from phrack 49 (Smashing the stack for fun > n

profit) when I noticed this behaviour by gcc.

Is something wrong with gcc or am I missing on some knowledge
here....

It's good to hack about with C to see how your platform implements the
language. However unless you are a hacker who likes writing security
exploits, such programs are useless for real purposes. In particular,
results don't generalise. gcc might align objects on 4 byte boundaries
whilst MSVC might not. As long as conforming C code does what the ANSI
standard says it should there is no problem here.

 

[J. J. Farrell]

can anyone pls tell me y is the memory allocation not
alligned to 4 Bytes.

Why do you think it should be?

Note : compiled with gcc in linux 9

This is an implementation-specific question. The C
language doesn't much care about alignment as long
as it's done such that the language works. I suggest
you ask in a newsgroup that discusses the compiler in
question.

 

[CBFalconer]

can anyone pls tell me y is the memory allocation not alligned to 4 Bytes.
Note : compiled with gcc in linux 9
void function(int a,int b,int c)
{
char buffer1[5];
Bytes allocated(as shown by gdb)
/*buffer1[4] ---------------------> 4
buffer1[8] ---------------------> 8
buffer1[5|6|7|9...18] ----------> 18
buffer1[19...] -----------------> 28
int *ret;
ret = buffer1+28;
(*ret) += 0xa;
}
int main()
{
int x;
x=0;
function(1,2,3);
x=1;
printf("%d\n",x);
return 0;
}
I was trying the article from phrack 49 (Smashing the stack for fun n
profit) when I noticed this behaviour by gcc.
Is something wrong with gcc or am I missing on some knowledge here....

You are missing some knowledge, also the ability to spell, and the
proper attitude. I hope nobody will tell him what is going on.

 

[Barry Schwarz]

can anyone pls tell me y is the memory allocation not alligned to 4 Bytes.

Nothing in your code or post indicates how you determined memory
alignment. What memory are you talking about? On most of the popular
systems in use today, ret will be aligned on (at least) a four-byte
boundary and buffer will not have any special alignment required.

Note : compiled with gcc in linux 9
void function(int a,int b,int c)
{
char buffer1[5];
Bytes allocated(as shown by gdb)

I assume your comment really starts with this line and

/*buffer1[4] ---------------------> 4
buffer1[8] ---------------------> 8
buffer1[5|6|7|9...18] ----------> 18
buffer1[19...] -----------------> 28

ends with this line.

int *ret;
ret = buffer1+28;

I'm not sure if this is legal (assigning a pointer to a "non-existent"
address and/or one that is possibly improperly aligned) but

(*ret) += 0xa;

this definitely is not. ret points to memory you don't own. Any
attempt to dereference it invokes undefined behavior. Even if you
defined buffer to be 28+sizeof(int) bytes, the contents of buffer is
uninitialized. To attempt to evaluate any of the bytes, as += will,
would also invoke undefined behavior.

}
int main()
{
int x;
x=0;
function(1,2,3);
x=1;
printf("%d\n",x);
return 0;
}
I was trying the article from phrack 49 (Smashing the stack for fun n
profit) when I noticed this behaviour by gcc.
Is something wrong with gcc or am I missing on some knowledge here....

function() invokes undefined behavior. After that, all bets are off.


<<Remove the del for email>>