iOSクラッシュダンプ内のオフセットを逆アセンブルしたバイナリに一致させる

Question

iostクラッシュダンプのスタックトレース内のオフセットを、otoolの出力としてバイナリの逆アセンブリ内のオフセットと一致させるのに問題があります。

誰でも私がこれらをどのようにして一致させるかを誰でも確認できますか？私はクラッシュダンプで行を取得する場合たとえば、：

0 myapp 0x00005b0a 0x1000 + 19210 

私は、バイナリファイルに問題のある命令のオフセット0x5b0a、0x4b0a ....または何か他のことを期待するでしょうか？ヘッダ情報のその復号において

は、また、（実際のコードは、ファイル内のオフセット0x0000224cから始まる）、例えば、この情報を与えるコマンドotool：

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のどちらの命令も、実際の命令では意味がありません。分岐指示を指す）。

（私が知っているのは、少なくともARMの初期版では、命令パイプラインのためにPCの値と対応するメモリアドレスの間に相違がありました。考慮に入れられていないオフセットを考慮に入れて、またはいずれにせよ、問題のブランチ命令がそのような違いが考慮されていないと指摘された1つの命令の両側のいくつかの命令を参照してください...）

誰でも光を放つことができますか？

Answer 1

ただし、atosを使用できるようになると、myappはシンボルを削除しませんでした。詳細は

あなたは可能常に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で取得した値に加え、16進数に変換します。この例では、は、0x31ff4（16進数）です。

3. otool -tV <application-binary>を使用して、アプリケーションバイナリの逆アセンブリをダンプします。手順2で取得したアドレスを探します（この例では0x31ff4）。コールスタックの一番上のフレームでは、アプリケーションがクラッシュした場所です。他のすべてのレベルでは、計算されたアドレスはスタック内の次の上位レベルに対応する分岐命令でなければなりません。