Corrispondenza di offset in iOS crash dump in binario smontato

Question

Sto riscontrando problemi nell'abbinare gli offset nelle tracce di stack degli arresti anomali di iOS con offset nello smontaggio del file binario come output di otool.

Qualcuno può confermare come in linea di principio li abbino. Per esempio, se ho una linea nella crash dump:

0 myapp 0x00005b0a 0x1000 + 19210 

dovrei aspettare l'offset dell'istruzione incriminata nel file binario di essere 0x5b0a, 0x4b0a .... o qualcosa d'altro?

Nella sua decodificazione delle informazioni di intestazione, otool dà anche, ad esempio, queste informazioni (il codice vero e dalle ore 0x0000224c offset nel file):

Section 
    sectname __text 
    segname __TEXT 
     addr 0x0000224c 
     size 0x00063ad2 
    offset 4684 
    align 2^2 (4) 
    reloff 0 
    nreloc 0 
     type S_REGULAR 
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS 
reserved1 0 
reserved2 0 

Quindi, non ero sicuro al 100% Stavo interpretando correttamente, ma sembra che il codice, con + 0x224c nel file, finisca con l'offset 0x124c in memoria, ma poi non ero esattamente sicuro di come fosse adattato, ad esempio, alla posizione 0x1000.

Il problema che ho è dato, ad esempio, dall'offset 0x5b0a, né l'istruzione lì né a 0x4b0a né a 0x6b0a ha senso come l'effettiva istruzione in questione (incluso il fatto che ad es. 't indicare le istruzioni di ramo).

(so che, almeno su precedenti incarnazioni di ARM, c'era una discrepanza tra il valore del PC e l'indirizzo di memoria corrispondente a causa della pipeline. Ero assumendo che tale differenza si svolgerà in considerazione negli offset riportati nel crash dump, o in ogni caso, vedrei le istruzioni di ramo in questione alcune istruzioni su entrambi i lati di quella puntata a se tale differenza non è stata presa in considerazione ...)

Qualcuno può far luce?

Answer 1

A condizione che lo myapp non abbia eliminato i simboli, sarà possibile utilizzare atos.

Si può sempre man atos per maggiori dettagli, ma questo dovrebbe essere sufficiente per il vostro problema:

-o symbol_file # debugging information output by the compiler this may be a dSYM or the binary itself depending on who you saved symbol information 
-l load address # the base address in the process space at which your library is loaded into the springboard process (Looks like 0x1000) 
Also a list of addresses you wish to symbolicate 

Usage: 
    atos -o myapp -l 0x1000 0x00005b0a 0x0005bca ... etc 

che la produzione dovrebbe essere una lista di nomi di simbolo al terminale. Di nuovo, ciò richiede che allo myapp non siano stati estratti simboli.

Answer 2

Aggiungere l'indirizzo virtuale del segmento __TEXT all'indirizzo relativo indicato nel dump di arresto anomalo. Il risultato è l'indirizzo da cercare nello smontaggio. Ecco i passaggi:

1. Usa otool -lv <application-binary> per eseguire il dump dei comandi di caricamento dal binario dell'applicazione. Cercare il comando di caricamento per il segmento __TEXT e il valore associato per vmaddr, in genere 0x1000. Non hai bisogno delle informazioni sulla sezione __text che è mostrata sopra, solo le informazioni sul segmento .

2. Nel dump dello schianto, gli indirizzi nello stack di chiamate sono indicati nel modulo 0x00124ff4 0xf4000 + 200692. L'ultima parte è un offset all'interno del binario in decimale. Aggiungi questo al valore ottenuto nel passaggio 1 e converti in esadecimale. In questo esempio, calcoleremmo 0x1000 + 200692 che è 0x31ff4 in esadecimale.

3. Utilizzare otool -tV <application-binary> per scaricare il binario dell'applicazione. Individuare l'indirizzo ottenuto nel passaggio 2 (0x31ff4 in questo esempio). Per il frame più in alto dello stack di chiamate, questo è il punto in cui l'applicazione si è bloccata. Per tutti gli altri livelli, all'indirizzo calcolato deve essere un'istruzione di ramo che corrisponde al livello successivo più alto nella pila.