为什么我的 char[30] 堆栈增加到 0x38

Question

在这个方法中

void lame(void) {
 char small[30];
 gets(small);
 printf("%s\n",small);
}

我希望堆栈增加 0x20

但 gdb 显示它增加了 0x38

0x08048450 <+3>:  sub $0x38, %esp

我不太确定需要什么信息来回答这个问题，所以如果我遗漏了什么，请告诉我，我会补充：

• Ubuntu 140.04 32 位
• 编译命令：cc -ggdb -fno-stack-protector blah.c -o blah
• CC --version - 4.8.2
• 在 Oracle Virtual Box 4.3.20 中运行

我在做什么 只是想玩弄缓冲区溢出并找到我正在关注的this 示例

disas lame

Answer 1

对于初学者，您的缓冲区向上舍入到 0x20 字节，这并不奇怪。传出参数还需要 4 个字节。所以我们有0x24字节的净需求。

更新后的调用约定要求堆栈指针必须保持 16 字节对齐。由于 push %ebx 使用 4 个字节，另外 4 个用于由 call 指令放入堆栈的返回地址，因此调整必须从 16 的倍数中减去 8 个字节。这与我们的最低要求相结合0x24 字节意味着分配 0x28 应该足够了。 gcc 为总共 0x38 分配 16 个额外字节似乎是至少 gcc 版本 4.4 到 4.9 所展示的错误或特性。请注意，clang 和 llvm-gcc 都分配了预期的 0x28 字节。

我的测试排除了与使用 gets 或编译器将 2 参数 printf 优化为 1 参数 puts 相关的额外空间。

Answer 2

您最好的选择是简单地查看函数的汇编代码，并找出它对从esp 和ebp 偏移的区域做了什么（取决于您的调用约定）。

例如，它可能会将它们用于各种临时用途。或者它可能正在为要发送到gets 和/或printf 的参数预先分配空间。或者它可能试图将堆栈指针与某个“分辨率”对齐，例如，放宽 SSE 对象对齐。

或者它可能意识到使用gets 的人往往不了解缓冲区溢出的危险，它给了你一点额外的空间作为喘息的空间:-)

归根结底，如果不查看编译器生成的内容，我们将无法判断。然而，即使有这些信息，编译器分配的为什么可能并不明显，因为我们可能仍在处理不完整的信息。

根据您添加的汇编程序转储，gets 和 printf 的缓冲区（已偷偷地优化为 puts）在堆栈指针之上 18 个字节，没有立即使用由中间区域组成。

所以，除非gets/puts 将它用于某事（不太可能）或过程链接表确实（仍然不太可能，但它是convoluted beast），否则您可能只需要假设它对您的平台来说是矫​​枉过正或对齐要求，生成自编译器。

您当然可以使用各种数组大小对其进行测试，以了解这对分配的空间有何影响。这可能至少会提供一些额外的信息，使理论更可行。

根据您对char[15] 分配0x28 和char[16] 分配0x38 的评论，这似乎是堆栈指针的16 字节对齐要求（它以8 结尾，因为有八个已用作调用一部分的字节：返回地址本身，以及之前的 ebx)。

事实上，如果你在网上搜索gcc 16 byte alignment stack pointer，你会发现一些关于gcc 是否在这里做正确的事情的非常激烈的讨论，但是，在所有这些讨论中，@987654339 的基本事实@确实将堆栈对齐到 16 个字节（正确或错误）。