Qual è un buon modo di eseguire il debug quando un valore specifico viene inserito nello stack nel codice assembly?

4

Attualmente sto eseguendo il debug di un gioco molto vecchio (quindi non c'è un supporto clienti) che continua a bloccarsi in determinate condizioni e ho scoperto che è perché la conversione da unsigned short a unsigned è avvenuta con la conversione firmata (possibilmente codice simile a "short int x = 0x8000; unsigned int y = (unsigned int) x" che porta a y = 0xffff8000 invece di 0x00008000)

Ora devo eseguire il debug del gioco nel codice di disassemblaggio per scoprire tutto il comando movsx che esegue la conversione sbagliata e cambiarli in comando movzx (ci sono molti punti in cui la conversione firmata è corretta, quindi non posso semplicemente cambiare tutti i movsz in MOVZX).

Il problema è che quando mi trovo su un frame in crash (dove un'altra funzione tenta di accedere all'indirizzo 0xffff8000, ad esempio), la funzione di arresto anomalo potrebbe essere a miglia di distanza dal codice movsx originale che esegue la conversione. La funzione di arresto anomalo (e i relativi chiamanti) viene chiamata migliaia di volte, quindi non è possibile inserire un punto di interruzione prima di un certo punto e vedere come cambia il valore del registro. Sembra che, ogni volta che eseguo il programma, l'indirizzo dello stack sia diverso dalla precedente, quindi i punti di interruzione dei dati non funzionano anche perché non conosco l'indirizzo da interrompere prima che si verifichi l'arresto anomalo.

Ho bisogno di un buon metodo (un modo che abbia il 100% di possibilità di trovare il bug in un tempo relativamente costante) per scoprire quando il valore 0xffff8000 viene inserito nello stack. Se qualcuno con esperienza nel debug di asm può darmi alcune tecniche per ottenere questo, lo apprezzerò molto.

EDIT: (Sebbene la domanda nel titolo non sia ancora stata risolta, le seguenti informazioni che ho trovato, che mi aiutano a correggere lo scenario specifico, potrebbero essere utili a qualcuno in futuro)

Ho scoperto che Visual Studio fornisce talvolta lo stack di chiamate errato. Sembra trovare il callstack basato sulla ricerca del valore del puntatore dello stack, quindi se una funzione inizia con qualcosa come "sub esp, 2Ch", allora il callstack sarà rovinato.

Per eseguire il debug di questo problema, è necessario impostare manualmente un punto di interruzione prima dell'arresto anomalo, a condizione che il registro abbia il valore sbagliato e, quando viene raggiunto, è necessario modificare manualmente il registro sul valore corretto; dopo di che esegui la funzione fino alla fine e vedi dove ritorna.

    
posta cr001 29.08.2016 - 14:23
fonte

1 risposta

1

Che dire dello stack di chiamate quando si verifica l'arresto anomalo?

In gdb puoi ottenerlo con il comando backtrace .

Dovresti essere in grado di vedere l'indirizzo del chiamante della funzione di arresto anomalo e così via in modo ricorsivo.

È possibile verificare se prima che la chiamata fatale si verifichi, è possibile trovare il codice che esegue la conversione sbagliata.

Modifica

La posizione di memoria con i dati errati è stata riparata?

Se è così, guardalo con il debugger e guardando lo stack delle chiamate prova a settare i punti di interruzione per codificare le posizioni che vengono eseguite prima della funzione fatale.
Dovresti inserire un punto del flusso di codice in cui quella posizione di memoria non è stata ancora inserita con il valore errato.
Una volta che sei lì, mentre stai guardando la posizione del codice, esegui alcuni passaggi e identifica la chiamata che fa cambiare il contenuto della posizione della memoria.
Una volta trovato, posiziona un punto di interruzione, riesegui tutto ed esegui le stesse azioni sul codice interno di quella funzione.
Ripetendo questa operazione in modo iterativo, è necessario convergere nella posizione in cui si verifica la modifica della posizione di memoria effettiva.

Strumenti

IDA Pro (Disassemblatore) link

OllyDbg (Debugger) link

    
risposta data 29.08.2016 - 15:30
fonte

Leggi altre domande sui tag