大會/ GDB：添加行爲

在運行與GDB的ELF程序，我目前正在經歷一個相當意外的行爲，爲特定的加法指令：大會/ GDB：添加行爲

Intel語法：add cl,BYTE PTR [eax]

AT & T語法：add (%eax),%cl

我希望這條指令的含義與gdb的set $cl=$cl+*((char*) $eax)（無論觸發標誌是什麼）具有相同的含義。但是某個調試會話的行爲不同（參見下文）：（char）* $ eax的值是0xb8，$ cl的值是0，但$ cl的結果值是0xcc。

我的問題是：這個0xcc來自哪裏？爲什麼結果不是0xb8？

這個程序只是另一個破解程序，可能是here。

要回答以下小丑的評論，下面的GDB會話可以作爲人們的預料之中：

(gdb) b *0x08048119 
Breakpoint 1 at 0x8048119 
(gdb) r 
Starting program: /tmp/ch20.bin 
Welcome to Root-Me Challenges 
Pass: foo 

Breakpoint 1, 0x08048119 in ??() 
(gdb) x/i $eip 
=> 0x8048119: add (%eax),%cl 
(gdb) x/bx $eax 
0x8048080:  0xb8 
(gdb) p/x $cl 
$1 = 0x0 
(gdb) si 
0x0804811b in ??() 
(gdb) p/x $cl 
$2 = 0xb8

但我不明白，爲什麼下面的人不產生相同的結果：

(gdb) b *0x8048080 
Breakpoint 1 at 0x8048080 
(gdb) r 
Starting program: /home/baz1/Downloads/ch20.bin 

Breakpoint 1, 0x08048080 in ??() 
(gdb) ni 
0x08048085 in ??() 
(gdb) 
0x0804808a in ??() 
(gdb) 
0x0804808f in ??() 
(gdb) 
0x08048094 in ??() 
(gdb) 
Welcome to Root-Me Challenges 
Pass: 0x08048096 in ??() 
(gdb) 
0x0804809b in ??() 
(gdb) 
0x0804809d in ??() 
(gdb) 
0x080480a2 in ??() 
(gdb) 
0x080480a7 in ??() 
(gdb) 

0x080480a9 in ??() 
(gdb) 
0x080480ab in ??() 
(gdb) 
0x080480b0 in ??() 
(gdb) 
0x080480b5 in ??() 
(gdb) 
0x08048115 in ??() 
(gdb) 
0x08048117 in ??() 
(gdb) 
0x08048119 in ??() 
(gdb) x/i $eip 
=> 0x8048119: add (%eax),%cl 
(gdb) x/bx $eax 
0x8048080: 0xb8 
(gdb) p/x $cl 
$1 = 0x0 
(gdb) si 
0x0804811b in ??() 
(gdb) p/x $cl 
$2 = 0xcc

非常感謝您的幫助。

來源

2016-01-24 cymbaz

發佈完整的gdb會話記錄。檢查你是否只加一條指令。還要確保內存中的值不會改變（例如，由於多線程程序或訪問無效內存）。 – Jester

該網站似乎已關閉或鏈接已損壞。至於gdb日誌，我希望看到你的聲明（寄存器和內存之前和指令本身）的證明。作爲一個裂縫，它可能會做一些棘手的事情:) – Jester

我上傳了我的vps文件並更改了鏈接;它現在應該工作。 – cymbaz

b *0x8048080將軟件斷點放入內存中，該內存碰巧是帶有操作碼0xcc的int3指令。然後add指令將讀取此內容而不是原始內存。您可以在斷點被刪除後刪除斷點或使用不修改代碼的硬件斷點。

來源

2016-01-24 19:44:48 Jester

非常感謝您的回答小丑！我想程序不會經常閱讀他們的代碼，以證明額外的檢查來防止這種問題。我仍然覺得很奇怪，儘管gdb在評估* $ eax時會執行檢查;它會在我們看到的和從指令的角度看實際發生的事情之間產生某種不一致...... – cymbaz

大會/ GDB：添加行爲

回答

相關問題