Con paciencia, tienes que parar justo cuando en la pila te salga algo asi ojo lo estoy poniendo a boleo pero es algo así, saca imagen.

| call to strcpy
| src = 00331274
| dst = 0012FF28

He visto en tus imagenes que el buffer se ha copiado con exito en la pila asi que habrá pasado por ahí, aunque que no te pare en strcpy al darle a run me parece muy raro.

Puede ser que no te este marcando strcpy por tener alguna opción desactivada..

+1

Primero que nada, muchas gracias por la ayuda que me estáis dando. Me quiero dedicar a la seguridad pero nunca he podido completar ningún exploit por cosas de estas...

Hecho:
1. Jumps'n'calls coloreados (pero me refería a que no veía ningún call que ponga a la derecha strcpy funtion, como pasa con las otras funciones de las DLLs de Windows).
2. Destildadas todas las excepciones (sólo tenía tildada la opción "ignore memory access violations in KERNEL32").

¿Compilado con alguna opción extraña? Qué raro... sólo lo compilé como código C (cl.exe /TC vuln1.c).
Aunque con gcc creo que va bien, el problema es compilar con MCV++.

Respecto a esto:
¿Te refieres al desensamblado, no a la pila, verdad?
Bueno, abro vuln1.exe en el OllyDbg parcheado contra IsDebuggerPresent, pongo un breakpoint en strcpy y F9.
Vale, ahora se detiene el programa en:  00401032 - CALL 0040150
F7 (entro en el CALL)
Ejecuto algunas instrucciones y entro en el bucle donde se copian los carácteres (podríamos decir que está ejecutando la función strcpy)
Ejecuto unas cuantas veces el bucle y esta esto es lo que veo

Continúo ejecutando el bucle --> Continúa sobreescribiéndose la pila

Continúo ejecutando el bucle hasta el JE SHORT 004010E9 que esta vez NO coge, y si yo he introducido 90 As, en la pila veo 22 valores 41414141 en la pila (aunque 90As/4Bytes=22.5 direcciones con 41414141, no sólo 22, pero bueno). Imagen de donde me encuentro ahora:


Continúo ejecutando y ya se llena el 0.5 que faltaba en la pila (byte,byte,41,41). Me encuentro en  00401041 - CALL 0040120D
Lo cojo! Entro al call a ver qué pasa
Veo muchos MOVs de registros a direcciones que me quitan mis 41414141 de la pila, sigo ejecutando, hago un F8 (ejecutar sin entrar) al CALL de IsDebuggerPresent y sigo ejecutando instrucciones.
Bien, me veo un CALL, y después POP ECX y PUSH 0, luego SetUnhandlerExceptionFilter, luego UnhandledExceptionFilter,ExitCode=C0000409, luego GetCurrentProcess y TerminateProcess, así que entro a ese call a ver qué pasa.
Ese CALL contenía un AND y una instrucción RET, pues nada, sigo ejecutando y termina el programa.


¿Y ahora qué? :/

Abro Olly parcheado
Arguments -> 76As
Restart
Pongo un BP en el CALL a strcpy (00401032). Pero una pregunta, si yo hago Search for --> Name in all modules, busco strcpy y le pongo un breakpoint, me pone un breakpoint a 7C90248D, no a 0040120D. Entonces, ¿cómo supiste que tenía que hacer un breakpoint a 0040120D a partir del breakpoint a la otra dirección?
RUN
Entro al CALL strcpy y se pushea 0012FF1C - RET ADDRESS 00401037
Continúo ejecutando el CALL
Se ponen todas las As en la pila y llego al JE SHORT que no coge el salto:



Ahora llegamos a JE SHORT 00401140, y entro a ver qué ocurre dentro
Ejecuto la primera instrucción, que era un MOV, y ahora los dos ASCII "AAAA..." que había en la pila tienen la misma longitud
Ejecuto algunas instrucciones hasta llegar a una instrucción RET, entonces la ejecuto y el RET ADDRESS 00401037 se quita de la pila.
Ahora estoy así:


Ejecuto ADD ESP,8
y desaparecen los dos ASCII "AAAA..." que había en la pila

Entro al último CALL (CALL 0040120D), continúo ejecutando y llega SUB ESP,328
lo ejecuto y desaparecen todos los 41414141 de la pila :/


Salimos del CALL y unos cuantos CALLs e instrucciones después salimos del programa con nuestro querido ExitCode C0000409