C 在gdb中查找环境变量地址时的奇怪事情

最近，我正在用我的Ubuntu11.10在论文的基础上做一些返回libc攻击的实验。

实验前，我关闭了ALSR。

根据本文，我可以在gdb中找到环境变量SHELL=“/bin/bash”的地址（使用gdb调试我要攻击的程序）：

但是当我试图使用它返回到libc实验时，我发现这个地址是错误的 然后我编写了一个简单的程序来获取环境变量地址：

当我在终端上运行这个程序时，我得到了正确的地址：



我可以用这个地址进行攻击。

我也发现了与此相关的问题。但是这些答案并没有真正意义（第二个可能更好）。

---

请告诉我一些细节。

从您的屏幕截图，我假设您运行在32位intel平台上。我还没有花时间全面研究这个问题的答案，但有几点值得注意：

我敢打赌，您的整个环境都在同一个位置，并且像c风格的字符串一样紧密地打包在一起。（试试

x/100s**（char***）和environ

）

当我在x86-64安装上尝试ths时，我在环境之后看到的唯一东西是命令行和一些空字符串

在

0xbfff47a

处，您非常接近用户地址空间的顶部（在

0xc000000

处结束）

我猜这里发生的是：

在启动过程中的某个时刻，环境块和命令行参数以压缩形式推送到用户地址空间的末尾

在GDB或终端中运行程序时，环境的内容是不同的。例如，当在gdb下运行时，我注意到“

”=/usr/bin/gdb

，我打赌只有在gdb下运行时才会出现

---

结果是，当你的固定指针倾向于在某个环境块中间某个地方时，它不会每次都在同一个地方，因为环境本身在运行之间变化。

只是一个迂回的注释：你应该投到<代码>（空洞*）< /代码>，在使用

%p

和

printf

@SethCarnegie时，不使用

unsigned int

。谢谢您的注释。我也同意环境不同。那是不是意味着我读的报纸错了？@KUN:错了？呃，总的想法是有道理的。但是，正如您所演示的，他们的利用示例需要改进。这些东西都是出了名的精巧（毕竟，你真的不“应该”以这种方式与程序交互），而且通常需要大量的专业知识才能完成。我怀疑作者理解你所经历的困难可能存在，并认为解决这些困难是“留给读者的练习”。@KUN:噢，看来我在这方面读得不够多。他们确实遇到了这个问题（下一页）。他们还讨论了他们是如何解决的。实际上，gdb再次解决了这个问题，我试过了，但失败了。这就是为什么我使用“getenv”来获取地址。@KUN：他们通过使用GDB打开一个核心转储文件来解决这个问题。这是一个不同的场景，不同之处很重要。