測試平臺是windows 32bit。「66：PUSH 08」中的66代表什麼？
我使用IDA pro反彙編PE文件，做一些非常繁瑣的轉換工作，並將它重新組裝成一個新的PE文件。
但在重新組裝的PE文件中的一些差異，如果我用OllyDbg的
調試新的PE文件（儘管在裝配文件中沒有這部分的差異我轉化）
原來這裏是其中的一部分： 
見
PUSH 8
PUSH 0
是正確的。
這是我的新的PE文件的一部分：
現在看到的
PUSH 8
PUSH 0
改爲
66:6A 08
66:6A 00
，它導致的失敗新的PE執行。
基本上，從我所看到的，它導致堆棧的未對齊。
那麼有人知道這部分有什麼問題嗎？我沒有看到我轉換的彙編代碼有任何區別......
任何人都可以給我一些幫助嗎？謝謝！
66h是操作數大小覆蓋前綴。在32位代碼中，它將操作數大小從默認的32位切換爲16位。所以在這裏發生的是PUSH指令在棧上而不是在32位上的16位值，ESP減少2而不是4。這就是爲什麼你會在調用後得到不平衡的棧。
您應該檢查彙編器的文檔，看看如何強制執行PUSH imm指令的32位操作數大小。不同的彙編程序使用不同的約定。例如，在NASM中，你可能會使用類似push dword 8的東西。
是否真的把ESP減2，而不是4？我不認爲x86-32架構會允許人們這樣做;如果機器在那個時候發生中斷會發生什麼？ –
@Igor，謝謝！我發現我的轉換代碼存在問題並修復它！ – computereasy
這是一個 「前綴」 操作碼字節：見http://wiki.osdev.org/X86-64_Instruction_Encoding#Legacy_Prefixes
0x66意味着 「操作數大小覆蓋」。您的代碼顯然是在32位模式下運行;沒有前綴的PUSH將推送一個32位的值。我認爲這樣做會導致PUSH獲取一個位值，並將其作爲32位值推入堆棧。 （我寫了很多彙編代碼，並且從未需要這樣做）。
謝謝你的回答@Ira！ – computereasy
聽起來像OpCode的32位版本。看看：http://stackoverflow.com/questions/11291151/how-push-imm-encodes。 – sircodesalot