尝试使用 ROP 进行利用时 gdb 和直接执行的不同行为答案

【问题标题】：difference behaviour of gdb and direct execution while trying to exploit with ROP尝试使用 ROP 进行利用时 gdb 和直接执行的不同行为
【发布时间】：2019-05-10 15:37:51
【问题描述】：

我最近在学习一些关于 ROP 的概念。
并在一些提供源代码的网站上进行挑战

#include <stdio.h>
#include <string.h>

int main (int argc, char ** argv){
    char message[20];

    if (argc != 2){
        printf ("Usage: %s <message>\n", argv[0]);
        return -1;
    }

    strcpy (message, argv[1]);
    printf ("Your message: %s\n", message);
    return 0;
}

堆栈不可执行，所以基本上我试图通过系统 libc 函数的地址覆盖返回地址，不使用 aslr。
我使用的是环境变量 SHELL，我用 gdb 找到了地址。
消息地址与返回地址的距离为32字节。
所以我的shellcode如下：'a' rep32 + @ofSystem + '4byteJUNK' + @SHELL

问题是，当我直接使用这个 shellcode 时，我得到分段错误，因为系统函数被成功调用，但没有使用环境变量提供的方便参数“/bin/bash”，它被另一个非可打印的字符串，但是当我使用 gdb 时，我验证调用约定是否得到遵守（参数在堆栈上传递），并且使用适当的字符串“/bin/bash”成功调用了 shell。
我找不到检查问题根源的方法，因为在 gdb 和没有 gdb 上的行为是不一样的。

【问题讨论】：

标签： gdb reverse-engineering exploit

【解决方案1】：

问题是，当我直接使用这个 shellcode 时，我得到了分段错误，因为系统函数被成功调用，但没有使用方便的参数“/bin/bash”...

我找不到检查问题根源的方法，因为 gdb 和没有 gdb 的行为不一样。

在 GDB 内部和外部运行程序可能存在许多细微差别。

例如，GDB倾向于通过全路径调用程序，即：

gdb a.out
(gdb) run
... invokes /full/path/to/a.out

环境，例如$_也可能不同。

您需要更有创意来解决您的问题。您可以尝试将差异最小化（例如，在 GDB 外部调用程序时使用 /full/path/to/a.out），或启用 core 转储，并在 GDB 外部生成的核心中进行探索，这样您就可以了解不同之处（以及还可以找到你在 GDB 下找到的距离——在 GDB 之外运行时可能会改变）。

【讨论】：