Esta prueba muestra la vulnerabilidad que puede haber en cadenas de caracteres que no estan bien definidas y como se pueden modificar.
Nota importante: Cada vez que hago esto, coloco intrucciones a gdb que creo son muy necesarios, ya que cada que el debugger abre una aplicación, lo hace en un espacio de memoria relativa y al colocarle, unset env LINES y unset env COLUMNS, GDB muestra el uso de memoria real o muy cercano al que usa realmente la aplicación, facilitando la explotación de la vulnerabilidad.
Ejecutamos la aplicación para ver que hace.

Colocamos formatos al azar para ver si encontramos una vulnerabilidad.

Al parecer el vulnerable, vamos a separar los bytes para que sea más sencillo de ver los 41414141.

Ok, pero... ¿cómo sería en el debugger?, hay que ver primer de cuanto es el buffer que dice ebp-0x1008, que sería 4100 - ebp - ret = 4096, es argc y la instrucción es que si es más grande que 16, entonces se saldrá.

Perfecto, vamos a llenar el buffer para encontrar la vulnerabilidad del printf de bounce.

Bien, Podemos ver como abre un espacio en ebp+0x8, y un call, recordemos que call se invoca con +1, osea call + 1, eso significa que call invoca una dirección e ejecuta la instrucción de siguiente o de abajo, en este caso "add esp, 0x10", veamos.


Ya vimos donde se guardan los caracteres, si lo sobreescribirmos posiblemente lleguemos a la función congratulations, hagamos el intento.



Pero no funciona, veamos que pasa.

Como se puede ver, aunque lograramos hacerlo funcionar, se saldría ya que exit no es una condicional, es constante, terminando el prinf, termina la ejecución, entonces tendremos que hacer un método llamado GoT (Global Offset Table), que es sobreescribir @plt para lograr la ejecución de la función "congratulations".

Parece hay suerte, ahora parece otra tediosa tarea de buscar byte por byte hasta encontrar la manera de que salte a la función que buscamos.

Nos ayudamos con python poco a poco.




Listo.