Сопоставление смещений в дампе сбоя iOS в дизассемблированном двоичном файле

Question

У меня возникли проблемы с сопоставлением смещений в стеке следов аварийных дампов iOS с смещениями при разборке двоичного файла как вывода otool.

Может кто-нибудь подтвердить, как в принципе я согласен с ними. Например, если я получаю строку в дампе:

0 myapp 0x00005b0a 0x1000 + 19210 

я бы ожидать, что смещение инструкции нарушившей в бинарном файле, чтобы быть 0x5b0a, 0x4b0a .... или что-то еще?

В его декодировании информации заголовка, otool также дает, например, эта информация (фактический код начинается со смещением 0x0000224c в файле):

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 

Таким образом, я не был на 100% уверен, Я правильно интерпретировал это, но, похоже, он говорит, что код в файле + 0x224c в файле заканчивается со смещением 0x124c в памяти, но тогда я точно не знал, как это связано, например, с местоположением 0x1000.

Проблема, которую я имею, заключается в том, что данный, скажем, смещение 0x5b0a, ни инструкция там ни в 0x4b0a, ни в 0x6b0a не имеет смысла как фактическая инструкция, о которой идет речь (включая тот факт, что, например, места дальше по стеку, 't указывать на инструкции ветвления).

(я знаю, что, по крайней мере, на ранних воплощениях ARM, существует расхождение между значением ПК и соответствующим адресом памяти в связи с конвейером команд. Я был предполагая, что такая разница будет принято во внимание в смещениях, о которых сообщалось в дампе сбоя, или, во всяком случае, я видел бы инструкцию о филиале несколько инструкций с одной стороны от той, на которую указывалось, если такая разница не была учтена ...)

Может ли кто-нибудь проливать свет?

Answer 1

При условии, что myapp не вычеркнул символы, вы сможете использовать atos.

Вы всегда можете man atos для получения более подробной информации, но это должно быть достаточно для вашей проблемы:

-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 

Этот вывод должен быть список имен символов на терминал. Опять же, это требует, чтобы у myapp не было выделенных символов.

Answer 2

Добавить виртуальный адрес сегмента __TEXT к относительному адресу, указанному в дампе аварий. Результатом является адрес для поиска при разборке. Вот шаги:

1. Используйте otool -lv <application-binary> сбросить команды загрузки из приложение бинарного. Найдите команду загрузки для сегмента __TEXT и связанного с ним значения для vmaddr, обычно 0x1000. Вам не нужна информация о __textраздел, который показан выше, только информация о сегменте .

2. В дампе аварии адреса в стеке вызовов приведены в форме 0x00124ff4 0xf4000 + 200692. Последняя часть представляет собой смещение в двоичном формате в десятичном значении. Добавьте это значение, полученное на шаге 1, и конвертируйте в шестнадцатеричный. В этом примере мы вычисляем 0x1000 + 200692, который равен 0x31ff4 в гексагоне.

3. Использовать otool -tV <application-binary> для демонтажа демонтажа для двоичного приложения. Найдите адрес, полученный на шаге 2 (0x31ff4 в этом примере). Для самого верхнего кадра стека вызовов это приложение разбилось. Для всех других уровней на вычисленном адресе должна быть инструкция перехода, которая соответствует следующему более высокому уровню в стеке.