崩潰報告中的CPU寄存器地址如何在分析中有用？

Apple生成這些崩潰日誌，我的線程0崩潰了，但這個問題不是這個問題。這是一般性問題，我想知道如何在碰撞分析中使用這些處理器寄存器值？他們如何幫助你調查你的崩潰？唯一出現在我腦海的是如果任何一個寄存器都有NULL指針，如下面的rcx，它提供了一個關於代碼中可能的空指針解引用的想法，那是正確的假設嗎？崩潰報告中的CPU寄存器地址如何在分析中有用？

Thread 0 crashed with X86 Thread State (64-bit): 
    rax: 0x00000001046e17a0 rbx: 0x00000001043665f0 rcx: 0x0000000000000000 rdx: 0x00000001046e14f0 
    rdi: 0x00000001046e14e0 rsi: 0x00000001046314e8 rbp: 0x00007fff5b89f890 rsp: 0x00007fff5b89f7e0 
    r8: 0x00007fff686a7690 r9: 0x0000000000000250 r10: 0x00007fffa2478201 r11: 0x000000000009ea18 
    r12: 0x00000001046b11d8 r13: 0x00007fff686a75c8 r14: 0x00007fff686ae638 r15: 0x0000000000000000 
    rip: 0x00000001043601be rfl: 0x0000000000010206 cr2: 0x0000000000000060 

Logical CPU:  0 
Error Code:  0x00000004 
Trap Number:  14

來源

2016-09-30 PnotNP

他們以各種方式幫助;事實上，你可以看到存儲器地址或寄存器的值是多少...... –

@ l'L'l那是真的，但是你有什麼方法使用它？ – PnotNP

您可以使用寄存器RIP（指令指針）來確定失敗的機器指令。我不確定GDB是否可以在Mac OSx上運行，但是在Linux中可以使用GDB（GNU Debugger），然後分析彙編指令以找到產生錯誤的確切指令。此外，寄存器RBP（幀指針）和RSP（堆棧指針）分別指向堆棧的底部和頂部。瞭解所有這些，您可以準確查看堆棧在崩潰時的內容以及哪條指令導致崩潰。

來源

2016-09-30 03:01:26 nrabbit

OS X用於使用gdb，但是，現在lldb是標準的。 –

'-fomit-frame-pointer'在幾年前就已經默認（即使是32位代碼），所以RBP只是另一個寄存器（如RBX或R12-R15），而不是幀指針。這種堆棧展開需要元數據（來自'.eh_frame'部分）和堆棧內存的內容，所以如果你有一個核心轉儲，你可以得到它。 –

除了@nrabbit表示的內容，您還可以使用寄存器來了解函數的某些參數的值是什麼以及函數調用的結果是什麼，如果您知道代碼的調用約定。 Here are some examples of Intel calling conventions。例如，eax寄存器通常在32位程序中保存一個函數結果。

來源

2016-09-30 03:20:23 user1118321

只有當您知道崩潰發生在函數CALL或RET指令時。在函數內部，這些寄存器都是暫時的暫存空間，直到eax的最終修改產生返回值。函數也修改它們的arg寄存器。所以你只需要在崩潰位置看看asm就可以知道對於涉及到的C變量意味着什麼。 **如果不仔細查看圍繞RIP值的代碼的asm，沒有什麼用處。 –

崩潰報告中的CPU寄存器地址如何在分析中有用？

回答

相關問題