Assembly cmpxchg esp、eax指令是否与ICEP指令相同？_Assembly_X86_Gdb

Assembly cmpxchg esp、eax指令是否与ICEP指令相同？

assembly x86 gdb

Assembly cmpxchg esp、eax指令是否与ICEP指令相同？,assembly,x86,gdb,Assembly,X86,Gdb,接下来，我们知道icepp指令与int1指令类似在这种情况下，我正在做一个愚蠢的实验，比如在没有输入的情况下进行比较和交换： global _start section .text _start: cmpxchg esp, eax 使用以下内容构建：nasm-f elf example.asm&&ld-o example.o 当我进行调试时，它将执行ICEP指令 % gdb -q cmpxchg Reading symbols from cmpxchg...(no debugging

接下来，我们知道

icepp

指令与

int1

指令类似

在这种情况下，我正在做一个愚蠢的实验，比如在没有输入的情况下进行比较和交换：

global _start
section .text

_start:

cmpxchg esp, eax

使用以下内容构建：

nasm-f elf example.asm&&ld-o example.o

当我进行调试时，它将执行

ICEP

指令

% gdb -q cmpxchg
Reading symbols from cmpxchg...(no debugging symbols found)...done.
gdb-peda$ r
Starting program: /home/user/assembly/cmpxchg 

Program received signal SIGTRAP, Trace/breakpoint trap.

[----------------------------------registers-----------------------------------]
EAX: 0xbfffee18 --> 0x3fffcc2b 
EBX: 0x0 
ECX: 0x0 
EDX: 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0x0 
ESP: 0xbfffee00 --> 0x1 
EIP: 0x8048093 --> 0x12ff
EFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x804808e:   add    BYTE PTR [eax],al
   0x8048090:   add    al,0x0
   0x8048092:   icebp  
=> 0x8048093:   call   DWORD PTR [edx]
   0x8048095:   add    BYTE PTR [eax],al
   0x8048097:   add    BYTE PTR [eax],al
   0x8048099:   add    BYTE PTR [eax],al
   0x804809b:   add    BYTE PTR [eax],al
No argument
[------------------------------------stack-------------------------------------]
0000| 0xbfffee00 --> 0x1 
0004| 0xbfffee04 --> 0xbffff013 ("/home/user/assembly/cmpxchg")
0008| 0xbfffee08 --> 0x10 
0012| 0xbfffee0c --> 0xbffff044 ("XDG_SEAT=seat0")
0016| 0xbfffee10 --> 0xbffff053 ("XDG_SESSION_ID=c2")
0020| 0xbfffee14 --> 0xbffff065 ("LC_IDENTIFICATION=id_ID.UTF-8")
0024| 0xbfffee18 --> 0x3fffcc2b 
0028| 0xbfffee1c --> 0xbffff0a6 ("DISPLAY=:0")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGTRAP
0x08048093 in ?? ()
gdb-peda$

我的问题是，它是如何发生的？

您忘记了执行

cmpxchg esp，eax

指令的单个步骤执行远远超出了这一范围，直到它碰巧碰到了一个
f1
操作码。

使用

starti

从第一条用户空间指令开始，然后使用

si

通常，如果让执行陷入一堆

字节中，您的进程将出错，因为在Linux静态可执行文件的开头，这些字节将被解码为

add[eax]、al

和eax=0。（您没有从

\u start

进行

\u exit

系统调用）

但将EAX设置为有效指针。（隐式操作数EAX最初不等于ESP，因此出现了“清除ZF并将r/m32加载到EAX中”。EAX作为显式源操作数给出的事实与此无关，顺便说一句。）

通过一组解码为

00 00

add的

指令继续执行。然后进入显示的块，其中出现故障的第一条指令恰好是

f1

字节，该字节位于

.text

部分结束后的可执行文件中。

当然，

cmpxchg

不会作为

icepp

int1

执行。如果你真的在cmpxchg指令下，你的反汇编是不可能的。这

cmpxchg

的长度为3字节，但相邻指令的地址之间的距离仅为1字节。所以不可能是GDB误判了。

不，它们不相似，我也无法重现你的结果<代码>0f b1 c4在GDB 8.3.1中显示为

0x8049000 cmpxchg esp，eax

在一个32位静态链接的Linux可执行文件中，该可执行文件由

echo“cmpxchg esp，eax”>foo.asm构建。（我使用的是普通的GDB，而不是GDB-peda）。显示机器代码（GDBdisas/r
）和/或source+build命令，使其成为一个。我想知道你是否看到了GDB设置的软件断点的反汇编？你的结果甚至不可信；调用
在添加
之后只有2个字节，这意味着ICEP
的长度只有1个字节（正如预期的那样）。除非GDB的地址计数/打印有其他错误，否则这不可能只是一个在cmpxchg
上的软件断点被反汇编。我的意思是，当指令被执行时，它将执行ice
指令（编辑的问题）不，这是不可能的cmpxchg esp，eax
的长度为3字节，因此您的GDB输出不可能显示包含该指令的机器代码的反汇编。@彼得命令这是一个错误？或