x86 assember – Windows下的非法操作码0xff / 7

发布时间：2020-12-14 01:36:05 所属栏目：Windows 来源：网络整理

导读：我正在开发一个x86反汇编程序,我开始拆解win32 PE文件.大多数反汇编的代码看起来不错,但是有一些非法的0xff / 7操作码出现(/ 7表示reg = 111,0xff是操作码组的inc / dec / call / callf / jmp / jmpf / push /非法操作数) r / m 16/32).第一个猜测是,/ 7是po

我正在开发一个x86反汇编程序,我开始拆解win32 PE文件.大多数反汇编的代码看起来不错,但是有一些非法的0xff / 7操作码出现(/ 7表示reg = 111,0xff是操作码组的inc / dec / call / callf / jmp / jmpf / push /非法操作数) r / m 16/32).第一个猜测是,/ 7是pop指令,但它是用0x8f / 0编码的.我已经根据官方英特尔架构软件开发人员手册第2卷：指令集参考检查了这一点 – 所以我不仅仅是误导了.

示例反汇编:( S0000O0040683a是由另一条指令跳转到的标签)

S0000O0040683a: inc    edi                      ; 0000:0040683a  ff c7
                test   dword ptr [eax+0xff],edi ; 0000:0040683c  85 78 ff
                0xff/7 edi                      ; 0000:0040683f  ff ff

顺便说一下：gdb同样反汇编这个(除了bug 0xff在我的反汇编中没有产生-1)：

(gdb) disassemble 0x0040683a 0x00406840
Dump of assembler code from 0x40683a to 0x406840:
0x0040683a:     inc    %edi
0x0040683c:     test   %edi,0xffffffff(%eax)
0x0040683f:     (bad)  
End of assembler dump.

所以问题是：Windows的非法操作码异常处理程序中是否存在任何默认处理程序,它实现了此非法操作码中的任何功能,如果是,那么会发生什么？

此致,Bodo

解决方法

经过许多额外的时间让我的反汇编程序以与gdb完全相同的语法生成输出,我可以区分这两个版本.这揭示了我的反感中一个相当尴尬的错误：我忘了考虑,0x0f 0x8x跳转指令有一个TWO字节操作码(加上rel16 / 32操作数).所以每个0x0f 0x8x跳转目标都被一个导致代码实际上无法访问.修复此错误后,不再反汇编0xff / 7操作码.

谢谢大家回答我的问题(并评论答案),因此至少试图帮助我.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!