Se passi attraverso un'istruzione alla volta e il segfault si verifica immediatamente dopo il salto (e non quando colpisci qualche shellcode potenzialmente rotto alla fine della slitta NOP, che potrebbe anche causare un segfault), e sei sicuro che l'indirizzo sia corretto, punta alla memoria valida e che la tua slitta NOP non è rotta, quindi sì sembra plausibile che il segfault sia causato da DEP.
Tuttavia, le altre cose che elenco sopra sono più probabilmente a mio parere, e ci sono molti altri motivi per cui potrebbe apparire un segfault.
Solo così siamo certi di avere tutto a posto in gdb;
Dovresti avere un breakpoint appena prima che l'istruzione di ritorno che hai danneggiato. Puoi farlo tramite i comandi disas e break .
Una volta che il programma ha raggiunto il tuo punto di interruzione, vuoi controllare la posizione del terreno. Controlla eip con il comando info r . E dai un'occhiata al tuo stack usando cose come x/40x $esp . Dovresti essere in grado di vedere ripetutamente la tua slitta di Nop, lo shellcode e l'indirizzo di ritorno. Un'altra nota che mi è venuta in mente; l'indirizzo di ritorno deve essere allineato correttamente, solitamente questo significa mettere 1-3 nops dopo lo shellcode per inserirlo in posizione.
Se tutto sembra in ordine, è ora di eseguire un step . Se info r ora segnala che eip contiene un indirizzo che si trova sulla tua slitta di nop, controlla questo con x %eip , dovresti vedere 0x90909090 . Quindi premi nuovamente step . Se a questo punto ottieni un segfault, allora sì (per rispondere alla tua domanda originale : P) hai DEP attivato su IMHO.
Scusa se era tutto ciò che già sapevi, è fondamentale controllare tutto più volte quando giochi con gli exploit di memoria.