La memoria utilizzata da un programma include sia ciò che si potrebbe pensare come "dati" (il testo che hai scritto, un'immagine che stai visualizzando, il codice sorgente dello script scaricato dal tuo browser web, una stringa di testo che viene costruita da quel script ...), cosa si potrebbe pensare come "metadati" (una mappatura di blocchi di memoria liberi e usati, puntatori all'inizio di quei blocchi di memoria, puntatori che collegano quella stringa di testo alle funzioni che possono essere eseguite su di esso, puntatori alle librerie caricate come jscript.dll di IE che analizza e compila JavaScript) e al codice eseguibile (il codice binario effettivo che la CPU esegue, inclusi i contenuti della DLL, il risultato della compilazione del JS e le funzioni sugli "oggetti" nei dati) .
Quando si verifica il danneggiamento della memoria, un utente malintenzionato di solito può esercitare un certo controllo su dove e come si verifica. Ad esempio, se l'utente malintenzionato trova un modo per causare la cancellazione di alcuni dati ma il programma lo considera ancora presente (chiamato vulnerabilità "use after free" e relativamente comune nei motori JavaScript), lo script dell'attaccante potrebbe quindi creare un nuovo oggetto dati (come una matrice di byte scelti con cura) di dimensioni simili e verrà creato nello stesso posto dell'oggetto cancellato, ma ancora utilizzabile. L'utente malintenzionato potrebbe quindi attribuire un valore all'oggetto eliminato, ma poiché la memoria che definisce l'oggetto contiene ora dati completamente nuovi (l'array predisposto per l'attacco), in realtà modifica alcuni valori che l'utente malintenzionato non è in grado di controllare come l'estensione dell'array. L'attaccante usa quindi l'array - che il programma ora pensa sia super-lungo, estendendosi ben oltre il frammento di memoria assegnato che è effettivamente memorizzato e in memoria utilizzato per altre cose - e fa qualcosa come cambiare i metadati "return pointer" che dice "quando finisce questo blocco di codice, continua ad eseguire il codice qui". L'attaccante cambia questo puntatore di ritorno in modo che il codice che verrà eseguito dopo la fine della funzione corrente faccia qualcosa come lanciare un programma che l'autore dell'attacco ha scritto, eseguendo codice arbitrario sul computer della vittima.
Questo tipo di attacco (uso-dopo-libero per ottenere una lettura / scrittura di memoria offset arbitraria, usando quello per sovrascrivere l'indirizzo di ritorno in una funzione desiderata da attaccante) è solo uno dei tanti, molti modi per sfruttare il danneggiamento della memoria . Alcuni altri vulns di corruzione della memoria sono double-free (tentando di eliminare due volte lo stesso blocco di memoria, il che è pericoloso perché si potrebbero trattare i dati controllati dagli hacker come se fossero in realtà metadati relativi alle allocazioni di memoria e quindi modificare i dati che l'utente non dovrebbe 't have access to), buffer overflow nello stack o heap (due diversi dati del programma vengono pubblicati, lo stack è dove troverete anche cose come return pointers e heap dove troverete cose come le tabelle delle funzioni e arbitrarie- array di lunghezze) in cui è possibile scrivere oltre la fine di un'allocazione di memoria e modificare altri dati, overflow di numeri interi in cui il programma esegue alcuni calcoli su due numeri che si conclude con un risultato troppo grande per il programma da mantenere nello spazio riservato a tale numero, quindi perde parte di quel numero e tratta il numero totalmente diverso come un puntatore nella memoria sicura quando in realtà potrebbe essere qualsiasi cosa, e così via.