Foro de elhacker.net

qué, tal cómo va? Una vez más tengo una duda con un codigo, en este caso estoy intentando seguir el ejemplo de rojodos para hacer un stack overflow. El programa en cuestión es el del ejemplo:
#include <stdio.h>
#include <string.h>

int main (int argc, char **argv)
{
   char buffer[64];
   if (argc < 2)
   {
      printf ("Introduzca un argumento al programa\n");
      return 0;
   }
   strcpy (buffer, argv[1]);
   return 0;
}

al ejecutarlo funciona tal y como era de esperar, y peta cuando se le pasan más de 64 a's como argumento.

Pero al depurarlo con olly meda un error que aparece reflejado en la pantalla de los registros. el error es FILE_NOT_FOUND y soy incapaz de encontrar cual es la funcion que produce el error ya que es increíble la de llamadas a funciones anidadas y sin anidar, a las que llama el programita. Y eso que sólo hace un if y un printf. Es imposible seguir el manual de rojodos ya que como he dicho el número de funciones llamadas es increíble.
Lo estoy complilando con dev c++ pero si lo compilo con visual c++ es todavía mayor el numero de subfunciones a las que se llaman.

Por qué este tan alto número de llamadas a funciones y apis? estoy utilizando windows7, y he comprobado que los únicos programas que se pueden seguir sin perderse son los creados con masm. Los creados con dev c++ y visual c++ son un auténtico laberinto.

estricamente no es un laberinto, eso lo hace el compilador estructurar el codigo con saltos indirectos, llega a ese punto y mira que hay en cada salto uno de ellos es tu codigo, creo que es el salto @main, pero no debuggeo un programa vc++ ya hace buen tiempo.

Salu2!

no, si lo que parece ser el main ya lo he encontrado, está en el segundo salto. Lo que pasa es que ahí no aparece ninguna orden reconocible, (el printf por ejemplo), aparece dentro de una función con un nivel de anidamiento cinco o seis, y antes de ella hay montones de llamadas con subllamadas anidadas, lo que me hace imposible debuguearlo, primero porque si lo hago con f8, no entra en las funciones y por lo tanto no veo como se llena la pila de a's y segundo porque con f7 creo que no me llega un día entero para hacerlo con f7. No se si algo va mal con mi compilador pero es así, parece un sueño dentro de otro sueño como en la película.

Por si fuera poco (aunque parece que se ejecuta sin problemas desde la linea de comandos) al depurarlo, me aparece un error (FILE NOT FOUND) en la ventana de registros. Como inteneté buscarlo pero imposible, está dentro de una llamada a una api del kernel32 y ahí no me deja poner breakpoints con lo cual tendría que ir manualmente con f7/f8 y es imposible ya lo he dejado porque despues de horas intentandolo encontraba que el error estaba siempre dentro de una subfunción.

En ningún tutorial he visto que haya este tipo de problemas a la hora de depurarlo, ni siquiera en las preguntas del foro, y me ha extrañado bastante. ¿será cosa del windows7(32)?

Usa GDB (General Debugger). El Olly es un GDB con gráficos...

o ps claro que se ve!, en el main vas a haber una llamada hacia la funcion... y si la seguis encontraras alli la funcion por ejemplo printf... y claro en el mismo main es donde le dan los parametros a la pila.

y para llegar al main solo pongo un BP al iniciar la funcion y ya estas parado alli =/

Salu2!

he conseguido ver el overflow en la pila.

La función printf la he encontrado sumergiendome en varias llamadas a funciones pero el olly lanzaba un mensaje de FILE NOT FOUND antes de llegar al printf (por supuesto en este caso no metía a's a destajo para hacer overflow sino que no metía parámetros ninguno para que se ejecutara el printf). Poniendo como parámetro aaaa (caso en el que no hay overflow) tambien mostraba ese error (FILE NOT FOUND) al finalizar. Y en el caso del overlow tambien el mismo mensaje. Es algo que no he conseguido entender y que me ha despistado mucho.De todas formas no tiene importancia pues lo único importante es ver el overflow de la pila.

de todas formas sigo pensando lo mismo que al principio, es decir es imposible seguir este programa, no se como os aparecerá a vosotros pero el mio tiene INNUMERABLES calls, y cuando digo innumerables digo más de 20 seguros, y pueden ser muchos más.

Tengo que decir que noy newbie en esto de la programación a bajo nivel y que quizá esto sea lo normal. Pero es que no me imaginaba que un programa tan simple pudiese tener taaaanto código. Hay una diferencia enorme con respecto a los programas en assembly con masm en los cuales lo que pones es lo que aparece en olly.

Probaré ese otro depurador que me recomendais a ver que tal.

Un saludo.