In base a questa risposta, è possibile compilare un'applicazione basata su GCC senza alcune tecniche di buffer overflow. Forse questo è persino possibile con Visual Studio.
Come posso controllare un dato EXE o DLL se ha le tecnologie di overflow anti-buffer in esso contenute? È persino possibile?
ASLR è una funzionalità di runtime fornita dal sistema operativo quando viene eseguito il file binario; se il sistema operativo lo decide, lo applicherà alla DLL caricata dall'eseguibile, indipendentemente da come sono stati compilati l'eseguibile e la DLL. Quello che può essere visto nell'eseguibile è se è esso stesso "ricollocabile" (cioè come una DLL), nel qual caso ASLR può anche essere applicato al codice EXE stesso.
La situazione con DEP è per lo più simile: dipende dal sistema operativo (aiutato da ciò che l'hardware può fare) se il divieto di "eseguire" le pagine di dati verrà applicato o meno. Il meglio che si possa trovare controllando un EXE è che potrebbe includere caratteristiche che non possono funzionare in presenza di un vero DEP, ad es. un compilatore JIT per alcune lingue, che non ha avuto cura di avvertire il sistema operativo in merito alle transizioni tra l'accesso ai dati e l'esecuzione.
Secondo Microsoft, SEHOP è di nuovo una funzionalità fornita dal sistema operativo che non dipende da come è stato compilato il file binario.
Ci sono tecniche di "buffer overflow" di protezione che possono essere viste guardando il codice compilato, ad es. i "canarini" , perché fanno affidamento su alcuni controlli extra che devono essere presenti nel codice prodotto. Disassemblare il codice li rivelerà, ma l'ispezione è noiosa. Alcune altre protezioni sono puramente in fase di compilazione, ad es. quando il compilatore avverte sull'utilizzo potenzialmente non sicuro di una funzione printf() -like, anche in questo caso, questo tipo di protezione non può essere visto nell'eseguibile compilato.
Leggi altre domande sui tag windows windows-8 audit programming buffer-overflow