Coincidencia de compensaciones en el volcado de emergencia de iOS con el binario desmontado

Question

Tengo problemas para hacer coincidir las compensaciones en las trazas de los volcados de bloqueos de iOS con compensaciones en el desensamblaje del binario como salida por otool.

¿Alguien puede confirmar cómo, en principio, juego esto? Por ejemplo, si consigo una línea en el volcado de bloqueo:

0 myapp 0x00005b0a 0x1000 + 19210 

habría que esperar que el desplazamiento de la instrucción infractora en el archivo binario para ser 0x5b0a, 0x4b0a .... o algo más?

En su decodificación de la información de la cabecera, otool también da, por ejemplo, esta información (el código real comienza a 0x0000224c desplazamiento en el fichero):

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 

Por lo tanto, no estaba 100% seguro Estaba interpretando esto correctamente, pero parece decir que el código, en + 0x224c en el archivo, termina en un offset de 0x124c en la memoria, pero entonces no estaba exactamente seguro de cómo encajaba esto, por ejemplo, con la ubicación 0x1000.

El problema que tengo es que dado, por ejemplo, el desplazamiento 0x5b0a, ni la instrucción ni en 0x4b0a ni en 0x6b0a tiene sentido como la instrucción real en cuestión (incluido el hecho de que, por ejemplo, ubicaciones más abajo en la pila no apunte a instrucciones de bifurcación).

(sé que, al menos en encarnaciones anteriores de ARM, había una discrepancia entre el valor de la PC y la dirección de memoria correspondiente debido a la tubería de instrucción. Estaba asumiendo que se tomaría una diferencia tan en cuenta en las compensaciones informadas en el vertedero, o en cualquier caso, vería las instrucciones de la rama en cuestión unas pocas instrucciones a cada lado del señalado si tal diferencia no se tuviera en cuenta ...)

¿Alguien puede arrojar algo de luz?

Answer 1

Con la condición de que myapp no haya eliminado los símbolos, podrá usar atos.

Siempre se puede man atos para más detalles, pero esto debería ser suficiente para su 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 

que la producción debe ser una lista de nombres de símbolos a la terminal. De nuevo, esto requiere que el myapp no tenga símbolos eliminados.

Answer 2

Agregue la dirección virtual del segmento __TEXT a la dirección relativa indicada en el volcado de emergencia. El resultado es la dirección para buscar en el desmontaje. Estos son los pasos:

1. Uso otool -lv <application-binary> para volcar los comandos de carga de la aplicación binaria. Busque el comando de carga para el segmento __TEXT y el valor asociado para vmaddr, generalmente 0x1000. No necesita la información sobre __textsección que se muestra arriba, solo la información sobre el segmento .

2. En el volcado de bloque, las direcciones en la pila de llamadas se dan en el formato 0x00124ff4 0xf4000 + 200692. La última parte es un desplazamiento dentro del código binario en decimal. Agregue esto al valor obtenido en el paso 1 y conviértalo a hexadecimal. En este ejemplo, calcularíamos 0x1000 + 200692 que es 0x31ff4 en hexadecimal.

3. Utilice otool -tV <application-binary> para volcar el desmontaje de la aplicación binaria. Ubique la dirección obtenida en el paso 2 (0x31ff4 en este ejemplo). Para el marco más alto de la pila de llamadas, aquí es donde se colgó la aplicación. Para todos los otros niveles, en la dirección calculada debe haber una instrucción de bifurcación que corresponda al siguiente nivel más alto en la pila.