在这个x86 ASM代码难题中发生了什么?

时间:2016-08-17 22:12:43

标签: assembly x86

这是我所接受的一个难题,但对x86来说还是一个新手,因为我并不是很了解它。

好像我们正在堆栈上构建一个字符串,然后调用一个系统调用来对它做一些事情?

如果有人能够解释一下代码中发生了什么,那将会有所帮助。

mov eax, 0xaf7a9e11           Move 0xaf7a9e11 into eax register.
xor eax, esi                  XOR eax with esi (should be empty?) into eax
push eax                      Push eax onto the stack
mov eax, 0xc6749612
xor eax, esi
push eax
...
Lots more instances where we mov xor and push.
...
xor eax, eax                  XOR eax with itself (essentially inverting it?)
mov ebx, eax
inc ebx
add al, 4
mov ecx, esp
push 52
pop edx
int 0x80                      Call the interrupt handler for syscall 52?

1 个答案:

答案 0 :(得分:0)

推送内容看起来像是在esi中使用XOR键对一个直接字符串进行去混淆。这样的事情使得在二进制文件上找到strings(1)的ASCII字符串变得更加困难,但实际上被称为加密则很弱。

在Linux上,int 0x80 eax = 4ssize_t write(int fd, const void *buf, size_t count)。 args是:

  • fd = ebx=1:stdout是FD 1
  • buf = ecx=esp:我们推送的数据缓冲区
  • count = edx=52:52个字节。

因此它写入了52个字节的数据,这些数据作为立即操作数存储在指令流中。我假设您可以理解这些价值是如何到达那里的,并且只是在寻找原因/发生的事情。另请参阅标记wiki以获取大量内容,包括Linux系统调用ABI和参考手册。

  

XOR eax with esi (should be empty?)

注册不能为空。它们总是保持32位。但它们可以为零。许多这些十六进制字节看起来像是在可打印的ASCII范围内,所以这可能会将一个人类可读的字符串输出到stdout。

如果这确实是入口点,那么Linux确实提供了一个初始进程状态,其中包含归零寄存器。 ABI表示它们未被定义(并且在动态链接器运行之后就是这种情况),但Linux在执行后通过将寄存器归零来避免泄漏内核数据。

相关问题