Torniamo alle nostre vulnerabilità.
Possono essere di vari tipi ma la più sfruttata è il Buffer Overflow (BOF).
Per prima cosa bisogna individuare la presenza di un BOF cioè di un buffer riempito senza controllare la lunghezza dei dati in ingresso.
Analizzare direttamente il codice assembly alla sua ricerca sarebbe da suicidio! In teoria e' possibile ma sarebbe un lavoro mostruoso e probabilmente infruttuoso.
Provando invece a mandare input particolarmente lunghi o malformati è possibile rendersi conto che qualcosa non funziona correttamente. Se cio' succede abbiamo probabilmente scoperto un BOF. Ovviamente ci vuole esperienza e volte anche un po' di fortuna.

La cosa più difficile è far si che il BOF possa essere utile per l'hacker e quindi trovare il metodo per sfruttarlo per eseguire codice remoto. Questa è tutto una altra faccenda..

Oviamente stiamo supponendo che l'hacker stia facendo dei test preliminari sul suo sistema.

Uno strumento utile a questo punto è il Debugger. Questo tipo di software permette di disassemblare in tempo reale un programma in memoria e simulare passo passo la sua esecuzione. Immagina di dire tu al programma quando avanzare di una istruzione, quando fermarsi etc. Per tutto il tempo il debugger ti da la possibilità di analizzare la memoria e il codice assembly attualmente eseguito.

Tutto questo permette di individuare la posizione esatta nel codice in cui si verifica l'errore, cioè il blocco del programma.

In base alle informazione del mio primo post l'errore avviene in genere quando nello stack si trova un errato indirizzo di ritorno per la funzione poichè questa è stata sovvrascritta dall'eccesso di dati forniti al buffer. Questo indirizzo errato sarà in generale casuale poichè tali erano i dati in ingresso e in tale punto in memoria non saranno presenti istruzioni valide. Sia ha quindi il blocco del programma o la segnalazione da parte del sistema operativo... (il programma XXX ha eseguito una operazione illegale.... ti dice qualcosa?)

Attraverso il debugger è possibile individuare dove si verifica l'errore e quindi dove è memorizzato l'indirizzo di ritorno.

Ora possiamo forgiare i dati in ingresso in modo che nella posizione che sovvrascriverà l'indirizzo incriminato ce ne sia uno che punta ad una nostra funzione.

Come vedi una volta indviduato il BOF non è stata necessaria l'analisi di tutto il codice... solo un po' di ingegno.

In generale comunque le cose possono essere molto più complicate di quanto ti ho detto ma le linee guida sono queste.