Il tipo di attacco sembra essere uno dei soliti: si comincia con lo sfruttare un errore (o una trascuratezza) di programmazione per riscrivere lo stack a runtime e in questo modo trasferire l'esecuzione del codice in un punto diverso da quello originariamente previsto. Ma, invece di inserire nuove istruzioni, il Return-oriented Programming si limita a utilizzare quelle già esistenti, consentendo però la creazione di qualunque tipo di elaborazione.

Si tratta insomma di raggruppare pezzi di codice "buono" per costruire programmi malevoli, che devono terminare con un'istruzione di return; questa strategia era già stata esposta da Hovav Shacham, professore di Computer Science alla UC San Diego, in un lavoro del settembre 2007. Il titolo è un po' curioso — The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86) — ma la sostanza è veramente notevole: si descrive come forzare il comportamento di macchine con architettura x86, in modo che abbiano un certo comportamento malevolo, senza però introdurre nessuna linea di codice "cattivo".

Il metodo richiedeva però una faticosa codifica manuale; ora Erik Buchanan e Ryan Roemer — entrambi graduate student alla UC San Diego — hanno automatizzato la procedura e l'hanno estesa alle macchine con architettura RISC. Il lavoro è stato presentato all'edizione 2008 della ACM Computer and Communications Security Conference. Stefan Savage, professore al Systems and Networking Group della UC San Diego e co-autore della ricerca, spiega che le difese messe in atto dagli antivirus, o le protezioni no execute (NX bit) di Intel e AMD, o il Data Execution Prevention di Windows XP SP2, non sono sufficienti; tenere fuori dalla porta il codice malevolo non basta per avere un comportamento "buono".

Per esempio, un web browser può essere istruito a registrare password digitate dall'utente o a inviare e-mail spam, utilizzando unicamente il codice del browser stesso; è un po' come scegliere parole e frasi da un libro di 700 pagine per costruire una storia di 50 pagine, che non ha nulla a che vedere con la storia originale. Gli autori, che chiamano gadget i loro exploit, dicono che queste vulnerabilità erano state inizialmente sottovalutate; i rimedi non sono semplici e prevedono meccanismi hardware e software per il controllo di flusso di un programma; addirittura si potrebbe essere costretti ad abbandonare il concetto di codice statico malevolo o meno, e focalizzare l'attenzione su modelli dinamici di valutazione del codice.