Differenza tra indirizzi gdb e indirizzi "reali"?

Question

Se eseguo un programma C/C++ in gdb (dopo aver compilato con il flag -g) ed esamino gli indirizzi di determinate variabili, argomenti ... ecc. E quindi lo eseguo all'esterno di gdb (usando ./) questi gli indirizzi sono gli stessi di quelli che ho visto in gdb? Se sono diversi sono di solito simili o saranno drasticamente diversi?

Chiedo questo perché ho un programma di buffer overflow che funziona perfettamente in gdb (con e senza punti di interruzione), tuttavia quando provo ad eseguirlo al di fuori di gdb non funziona.

Answer 1

Esamino gli indirizzi di alcune variabili, argomenti, ecc ..., e poi ho eseguito al di fuori del gdb (utilizzando ./) saranno questi indirizzi essere lo stesso di quelli che ho visto in gdb

Dipende.

variabili

1. globali definiti nel eseguibile principale rimarrà allo stesso indirizzo (a meno che l'eseguibile è costruito con -fpie e collegato con -pie bandiere.
2. variabili globali definiti in altre librerie condivise possono avere indirizzi drasticamente diverse a causa di ASLR.
3. variabili e parametri locali possono spostarsi da più K-byte a causa di ASLR.
4. Heap-assegnati variabili possono anche spostare drasticamente a causa di ASLR, o se il programma è multi-threaded.

Nota che GDB su Linux di default disabilita ASLR, per semplificare il debug. È possibile riattivare ASLR in GDB con set disable-randomization off. Ciò potrebbe consentire di riprodurre il problema in GDB.

Ho un buffer overflow

Si noti inoltre, che strumenti come Valgrind e Address Sanitizer sono spesso significativamente più efficace per la ricerca di buffer overflow che correre sotto GDB. In particolare, il Sanitizer Address è great in quanto trova buffer overflow in globals e stack (Valgrind non lo fa).

Answer 2

La compilazione con il flag -g aumenta le dimensioni del codice poiché si blocca nelle informazioni aggiuntive dell'eseguibile.

Per quanto riguarda il problema del buffer, sarebbe utile pubblicare uno snippet di codice in cui le cose vanno male.

Answer 3

Non si dovrebbe mai presumere che un determinato codice o VAR si troverà in un posto fisso.

Questo era vero in passato nella maggior parte degli OS, ma è un buco di sicurezza. il software dannoso usa questo per incalzare i programmi. Il sistema operativo tenderà a codificare gli indirizzi per aumentare la sicurezza.