Si está siguiendo una instrucción a la vez, y la falla de seguridad se produce inmediatamente después de saltar (y no al golpear un código de shell potencialmente roto al final del sled NOP, lo que también podría causar una falla de seguridad), y está seguro que la dirección es correcta, apunta a una memoria válida y que su sled NOP en sí no está roto, entonces sí parece plausible que la falta de seguridad sea causada por DEP.
Sin embargo, las otras cosas que enumero arriba son más probables en mi opinión, y hay muchas otras razones por las que puede aparecer una falla de seguridad.
Así que estamos seguros de que tienes todo correcto en gdb;
Debería tener un punto de interrupción justo antes de la instrucción de retorno que ha dañado. Puede hacerlo a través de los comandos disas y break .
Una vez que el programa llega a su punto de interrupción, desea verificar el terreno. Verifique eip con el comando info r . Y echa un vistazo a tu pila usando cosas como x/40x $esp . Debería poder ver su ned sled, shellcode y dirección de retorno varias veces después. Otra nota que me vino a la mente; la dirección de retorno debe alinearse correctamente, por lo general, esto significa colocar 1-3 nops después de su código de shell para colocarlo en su lugar.
Si todo se ve bien, es hora de ejecutar un step . Si info r ahora informa que eip contiene una dirección que está en su nop sled - verifique esto con un x %eip , debería ver 0x90909090 . Luego presiona step otra vez. Si en este momento obtiene un fallo de seguridad, entonces sí (para responder a su pregunta original: : P), DEP ha activado la IMHO.
Lo siento, si eso era todo lo que ya sabías, es vital revisar todo varias veces cuando juegas con exploits de memoria.