Il percorso di base per sfruttare una vulnerabilità legata all'overflow è trovare un arresto anomalo (spesso tramite fuzzing), valutare l'arresto anomalo e se presenta un percorso di attacco e quindi creare qualcosa per sfruttarlo.
A volte dove uno guarda può coinvolgere la conoscenza dell'architettura, come quando Charlie Miller ha notato che iOS 4.3 ha una sezione di memoria che esegue codice non firmato . Nel caso di tutti i suoi attacchi Apple, credo che la fonte sia stata chiusa. I punti deboli dell'iniezione SQL sono simili: stai iniziando con una greppia sapendo dove è un buon posto dove guardare.
Mentre è più semplice identificare e correggere un bug via fonte dopo aver trovato un crash, il lavoro per configurare l'ambiente può essere privo di valore se l'obiettivo è semplicemente scrivere un exploit funzionante. Spesso, lo spazio rilevante di un programma riguarderà meno di 1 KB di codice macchina.
Dal mio punto di vista, l'open source consente di visualizzare i bug che vengono aggiunti mentre accadono e dire, "Ehi, quel po 'di codice sembra assurdo." Oltre a ciò, il lavoro per sfruttare il lavoro closed-source e open-source è spesso lo stesso. Per quanto riguarda il reverse engineering, è raro a meno che tu non stia tentando di modificare o ricreare un'applicazione piuttosto che lanciare un exploit da essa.
Non sottovaluterei la capacità dei gruppi di hacker di dedicare molte risorse di elaborazione a un'attività. I gruppi Warez sono stati conosciuti nel corso della storia di Internet per raccogliere risorse di storage e larghezza di banda considerevoli. Potrebbe essere ingenuo pensare che i gruppi di hacker non accumulino la stessa potenza della CPU.
Infine, la maggior parte delle persone che fanno questo per un tempo abbastanza lungo mantengono un exploit scoperto o due in alto piuttosto che rilasciandolo.