Re: [問題] int 0x03 (IA86)
※ 引述《suhorng ( )》之銘言：
: int $3 的 op code 是 0xCC
: 但我用 0xCD 0x03 去跑的時候，在 OllyDbg 下正常，在 debug (16bit) 下就出問題了?
: 這讓我很疑惑，到底是 debug 的bug，還是跟 32-bit, 16-bit 有關？
: 附上 debug 的測試結果：
: -
: Microsoft Windows [???? 6.0.6000]
: Copyright (c) 2006 Microsoft Corporation. All rights reserved.
: C:\>debug
: -e 100
: 179E:0100 00.cd 00.03 00.b8 00.00 00.4c 00.cd 00.21
: -u 100 105
: 179E:0100 CD03 INT 03
: 179E:0102 B8004C MOV AX,4C00
: 179E:0105 CD21 INT 21
: -r
: AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
: DS=179E ES=179E SS=179E CS=179E IP=0100 NV UP EI PL NZ NA PO NC
: 179E:0100 CD03 INT 03
: -p
: AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
: DS=179E ES=179E SS=179E CS=179E IP=0101 NV UP EI PL NZ NA PO NC
: 179E:0101 03B8004C ADD DI,[BX+SI+4C00]
: DS:4C00=0000
: -
: 但是我用
: int main() {
: __asm(".byte 0xCD, 0x03");
: return 0;
: }
: 在 OllyDbg 下測試就正常…
這個不是bug,而是設計上的選擇.
x86在interrupt發生時,會把下一個指令的地址與flag放進stack,並將IP改為ISR的位置.
一般ISR不需要知道是哪個指令或原因呼叫它,只需執行完呼叫IRET就回覆原指令流程.
而INT 3的ISR也是一樣, 當ISR執行起來時, 它也只能拿到呼叫它的那個指令的下一個指令
的位置. 而DEBUG需要知道呼叫它的那個指令位置, 而且要把從那裡開始的指令反組譯出來
. 而DEBUG的設計者假設, INT 3 只會由指令碼CC的指令所呼叫, 所以它就直接把stack上
的地址減1之後,開始反組譯. 當然遇到 CD 03 時就會從 03那個指令開始反組譯, 而03開
頭的指令是ADD, 這就是你例子裡ADD DI,[BX+SI+4C00]的由來了.
而OllyDbg是32Bit的程式, 它認為執行它的機器應該夠快, 記憶體應該夠多, 所以它的設
計者決定, 在遇到 INT 3時, ISR會檢查它到底是由CC觸發的還是由CD 03所觸發的, 所以
它能正確的處理CD 03觸發的interrupt.
這跟32bit還是16bit是沒有關係的,只是設計時的選擇,不過別抱怨,不是DEBUG.COM的作者
不好,而是他的設計選擇, 當年我還在PC XT上執行DEBUG.COM這個程式時, 我可是非常願
意犧牲這個少見的特例來加快它的執行速度並減少記憶體消耗量的. 也許DEBUG.COM的作者
的想法也跟我一樣.
--
Do not depend on others without effort...
當我年輕時,請教別人問題時常聽到上面那句話. 當時心裏偶而會有些小小抱怨.
當時間過去,我偶而會想到上面那句話, 心中十分感謝當初告訴我那句話的人.
當發現問題時,最有價值的不是問題的答案,
而是找到解決的方向,並在努力的過程裡具備解決問題的能力.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 221.169.217.133
推
07/16 14:03, , 1F
07/16 14:03, 1F
推
07/21 23:34, , 2F
07/21 23:34, 2F
→
07/21 23:35, , 3F
07/21 23:35, 3F
→
07/21 23:35, , 4F
07/21 23:35, 4F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 2 篇)：