为什么 int 变量在寻址方面不会出现在 char 数组之前,无论我如何在 C 中编码?

发布于 2024-09-14 11:10:36 字数 875 浏览 14 评论 0原文

我正在阅读黑客:利用的艺术(第二版),目前正在阅读有关缓冲区溢出的部分。

在第一个示例中,变量按以下顺序声明/初始化:

int auth_flag = 0;
char password_buffer[16];

该示例继续说明您可以使用 gdb 检查 auth_flagpassword_buffer 的地址,以及您会注意到 auth_flag 的地址高于 password_buffer 的地址。需要记住的事情:我在 Macbook Pro(Intel 处理器,64 位)上的 Virtualbox 内的 Ubuntu 中运行所有这些。

我编译了第一个示例的代码,如下所示: gcc -g -fno-stack-protector -o auth_overflow auth_overflow.c

正如预期的那样,auth_flag 的地址高于 password_buffer 的。

为了解决上述问题,作者解释说您应该切换声明的顺序:

char password_buffer[16];
int auth_flag = 0;

我以相同的方式编译了代码:gcc -g -fno-stack-protector -o auth_overflow2 auth_overflow2.c

不幸的是,我没有看到 auth_flag 的地址低于 password_buffer 的地址。事实上,它仍然更高。这是为什么呢?我做错了什么?

I'm reading Hacking: The Art of Exploitation (2nd Edition), and I'm currently on the section about buffer overflows.

In the first example, the variables are declared/initialized in this order:

int auth_flag = 0;
char password_buffer[16];

The example goes on to explain that you can use gdb to examine auth_flag and password_buffer's addresses, and you'll notice that auth_flag's address is higher than password_buffer's. Things to keep in mind: I'm running all of this in Ubuntu within Virtualbox on a Macbook Pro (Intel processor, 64-bit).

I compiled the first example's code like this: gcc -g -fno-stack-protector -o auth_overflow auth_overflow.c

As expected, auth_flag's address is higher than password_buffer's.

To remedy the problem presented above, the author explains you should switch the ordering of the declarations:

char password_buffer[16];
int auth_flag = 0;

I compiled the code the same way: gcc -g -fno-stack-protector -o auth_overflow2 auth_overflow2.c

Unfortunately, I did not see auth_flag's address being lower than password_buffer's. In fact, it was still higher. Why is this? What am I doing wrong?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

风情万种。 2024-09-21 11:10:36

编译器可以选择它想要的任何顺序,以便提供更优化的代码,甚至只是随机的,因为它更容易实现。您可以尝试的一件事是 -O0 标志,它会禁用所有优化。

The compiler is allowed to choose whatever order it wants, in order to provide more optimal code, or even just random because it's easier to implement. One thing you might try is -O0 flag which disables all optimizations.

江城子 2024-09-21 11:10:36

编译器可以自由地重新排列他们认为最好的变量。我相信唯一的限制是结构成员的顺序。它们在内存中的顺序必须与结构中声明的顺序相同。

Compilers are free to rearrange variables as they feel is best. I believe that the only restriction in the order of struct members. Those must be in memory in the same order as declared in the struct.

一笔一画续写前缘 2024-09-21 11:10:36

我发现这个线程非常有趣:

http://www .mail-archive.com/[email protected]/msg05043.html

Quote: 理论上可以做到

-fdata-section

I found this thread quite interesting:

http://www.mail-archive.com/[email protected]/msg05043.html

Quote: In theory it can be done

-fdata-section
心病无药医 2024-09-21 11:10:36

Apple 有一项安全功能,可以防止您正在谈论的那种类型的黑客攻击 - 所有内容存储在内存中的位置都具有一定程度的随机性,因此您无法找到为某个程序分配的内存,然后转到打开高安全性金库锁的函数所在的第 1502 个字节,因为它并不总是位于内存中的同一位置。

有关其工作原理的详细信息,请参阅 http://en.wikipedia.org/wiki/Address_space_layout_randomization

有趣的是,你会遇到这个,而马特·乔伊纳在试图烧苹果时偶然发现了答案。

Apple has a security feature to prevent just the type of hacking you are talking about - There is a degree of randomization to where everything is stored in memory, so you can't for example find the memory allocated for a certain program, and go to the 1502nd byte where the function to open the high security vault locks sits, cause it isn't always in the same place in memory.

See http://en.wikipedia.org/wiki/Address_space_layout_randomization for details on how this works.

Funny coincidence that you would encounter this, and that Matt Joiner would stumble on the answer while trying to burn apple.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文