C 流程的哪些部分'；虚拟地址空间是否可覆盖？

例如，假设缓冲区不是沿堆栈的相反方向增长，而是沿相同方向增长。如果我有一个包含字符串“Hello world”的字符缓冲区，它不是放在最低地址，而是放在最高地址，依此类推

---

如果复制到缓冲区的输入字符串溢出，则无法覆盖函数的返回地址，但肯定会覆盖其他内容。我的问题是——如果输入字符串足够长，哪些内容可以被覆盖？堆和堆栈之间是否存在可以覆盖的库函数？堆变量可以被覆盖吗？我假设数据和bss部分中的变量可以被覆盖，但文本段是否受写保护？

您的问题的答案完全取决于所使用的操作系统以及硬件体系结构。操作系统以某种方式布置逻辑内存，体系结构有时也会为特定目的保留（非常低的）内存

需要了解的一点是，传统进程可以访问其整个逻辑内存空间，但通常很少使用这种容量。您所描述的最可能的影响是，您将尝试访问一些未分配的内存，并且您将得到一个segfault作为响应，使您的程序崩溃

也就是说，您肯定可以修改这些其他内存段，但这样做时会发生什么取决于它们的读/写权限。例如，你在学校学到的典型记忆布局是：

Low memory to high memory:
.text - program code
.data - initialized static variables
.bss  - uninitialized static variables
.heap - grows up
memory map segments - dynamic libraries
.stack - grows down

默认情况下，.text段标记为只读/可执行，因此，如果尝试写入.text内存位置，将出现段错误。可以将.text更改为可写，但这通常是一个糟糕的想法

默认情况下，.data、.bss、.heap和.stack段都是可读/写的，因此您可以覆盖这些段而不会出现任何程序错误

内存映射段也都有自己的权限处理。其中一些段是可写的，而大多数段是不可写的（因此写入这些段会产生错误）

最后一点需要注意的是，大多数现代操作系统都会随机化这些部分的位置，从而使黑客更难操作。这可能会在不同的线束段之间引入间隙（如果您试图访问这些线束段，将再次导致SEGFULTS）

在Linux上，您可以使用命令

pmap

打印进程内存映射。以下是该程序在vim实例上的输出：

10636:   vim hello.text
0000000000400000   2112K r-x-- vim
000000000080f000      4K r---- vim
0000000000810000     88K rw--- vim
0000000000826000     56K rw---   [ anon ]
0000000000851000   2228K rw---   [ anon ]
00007f7df24c6000   8212K r--s- passwd
00007f7df2ccb000     32K r-x-- libnss_sss.so.2
00007f7df2cd3000   2044K ----- libnss_sss.so.2
00007f7df2ed2000      4K r---- libnss_sss.so.2
00007f7df2ed3000      4K rw--- libnss_sss.so.2
00007f7df2ed4000     48K r-x-- libnss_files-2.17.so
00007f7df2ee0000   2044K ----- libnss_files-2.17.so
00007f7df30df000      4K r---- libnss_files-2.17.so
00007f7df30e0000      4K rw--- libnss_files-2.17.so
00007f7df30e1000     24K rw---   [ anon ]
00007f7df30e7000 103580K r---- locale-archive
00007f7df960e000      8K r-x-- libfreebl3.so
00007f7df9610000   2044K ----- libfreebl3.so
00007f7df980f000      4K r---- libfreebl3.so
00007f7df9810000      4K rw--- libfreebl3.so
00007f7df9811000      8K r-x-- libutil-2.17.so
00007f7df9813000   2044K ----- libutil-2.17.so
00007f7df9a12000      4K r---- libutil-2.17.so
00007f7df9a13000      4K rw--- libutil-2.17.so
00007f7df9a14000     32K r-x-- libcrypt-2.17.so
00007f7df9a1c000   2044K ----- libcrypt-2.17.so
00007f7df9c1b000      4K r---- libcrypt-2.17.so
00007f7df9c1c000      4K rw--- libcrypt-2.17.so
00007f7df9c1d000    184K rw---   [ anon ]
00007f7df9c4b000     88K r-x-- libnsl-2.17.so
00007f7df9c61000   2044K ----- libnsl-2.17.so
00007f7df9e60000      4K r---- libnsl-2.17.so
00007f7df9e61000      4K rw--- libnsl-2.17.so
00007f7df9e62000      8K rw---   [ anon ]
00007f7df9e64000     88K r-x-- libresolv-2.17.so
00007f7df9e7a000   2048K ----- libresolv-2.17.so
00007f7dfa07a000      4K r---- libresolv-2.17.so
00007f7dfa07b000      4K rw--- libresolv-2.17.so
00007f7dfa07c000      8K rw---   [ anon ]
00007f7dfa07e000    152K r-x-- libncurses.so.5.9
00007f7dfa0a4000   2044K ----- libncurses.so.5.9
00007f7dfa2a3000      4K r---- libncurses.so.5.9
00007f7dfa2a4000      4K rw--- libncurses.so.5.9
00007f7dfa2a5000     16K r-x-- libattr.so.1.1.0
00007f7dfa2a9000   2044K ----- libattr.so.1.1.0
00007f7dfa4a8000      4K r---- libattr.so.1.1.0
00007f7dfa4a9000      4K rw--- libattr.so.1.1.0
00007f7dfa4aa000    144K r-x-- liblzma.so.5.0.99
00007f7dfa4ce000   2044K ----- liblzma.so.5.0.99
00007f7dfa6cd000      4K r---- liblzma.so.5.0.99
00007f7dfa6ce000      4K rw--- liblzma.so.5.0.99
00007f7dfa6cf000    384K r-x-- libpcre.so.1.2.0
00007f7dfa72f000   2044K ----- libpcre.so.1.2.0
00007f7dfa92e000      4K r---- libpcre.so.1.2.0
00007f7dfa92f000      4K rw--- libpcre.so.1.2.0
00007f7dfa930000   1756K r-x-- libc-2.17.so
00007f7dfaae7000   2048K ----- libc-2.17.so
00007f7dface7000     16K r---- libc-2.17.so
00007f7dfaceb000      8K rw--- libc-2.17.so
00007f7dfaced000     20K rw---   [ anon ]
00007f7dfacf2000     88K r-x-- libpthread-2.17.so
00007f7dfad08000   2048K ----- libpthread-2.17.so
00007f7dfaf08000      4K r---- libpthread-2.17.so
00007f7dfaf09000      4K rw--- libpthread-2.17.so
00007f7dfaf0a000     16K rw---   [ anon ]
00007f7dfaf0e000   1548K r-x-- libperl.so
00007f7dfb091000   2044K ----- libperl.so
00007f7dfb290000     16K r---- libperl.so
00007f7dfb294000     24K rw--- libperl.so
00007f7dfb29a000      4K rw---   [ anon ]
00007f7dfb29b000     12K r-x-- libdl-2.17.so
00007f7dfb29e000   2044K ----- libdl-2.17.so
00007f7dfb49d000      4K r---- libdl-2.17.so
00007f7dfb49e000      4K rw--- libdl-2.17.so
00007f7dfb49f000     20K r-x-- libgpm.so.2.1.0
00007f7dfb4a4000   2048K ----- libgpm.so.2.1.0
00007f7dfb6a4000      4K r---- libgpm.so.2.1.0
00007f7dfb6a5000      4K rw--- libgpm.so.2.1.0
00007f7dfb6a6000     28K r-x-- libacl.so.1.1.0
00007f7dfb6ad000   2048K ----- libacl.so.1.1.0
00007f7dfb8ad000      4K r---- libacl.so.1.1.0
00007f7dfb8ae000      4K rw--- libacl.so.1.1.0
00007f7dfb8af000    148K r-x-- libtinfo.so.5.9
00007f7dfb8d4000   2048K ----- libtinfo.so.5.9
00007f7dfbad4000     16K r---- libtinfo.so.5.9
00007f7dfbad8000      4K rw--- libtinfo.so.5.9
00007f7dfbad9000    132K r-x-- libselinux.so.1
00007f7dfbafa000   2048K ----- libselinux.so.1
00007f7dfbcfa000      4K r---- libselinux.so.1
00007f7dfbcfb000      4K rw--- libselinux.so.1
00007f7dfbcfc000      8K rw---   [ anon ]
00007f7dfbcfe000   1028K r-x-- libm-2.17.so
00007f7dfbdff000   2044K ----- libm-2.17.so
00007f7dfbffe000      4K r---- libm-2.17.so
00007f7dfbfff000      4K rw--- libm-2.17.so
00007f7dfc000000    132K r-x-- ld-2.17.so
00007f7dfc1f8000     40K rw---   [ anon ]
00007f7dfc220000      4K rw---   [ anon ]
00007f7dfc221000      4K r---- ld-2.17.so
00007f7dfc222000      4K rw--- ld-2.17.so
00007f7dfc223000      4K rw---   [ anon ]
00007ffcb46e7000    132K rw---   [ stack ]
00007ffcb475f000      8K r-x--   [ anon ]
ffffffffff600000      4K r-x--   [ anon ]
 total           163772K

---

从0x851000开始的段实际上是堆的开始（pmap会告诉您使用更详细的报告模式，但更详细的模式并不合适）。

内存中进程的布局因系统而异。这个答案涵盖了x86_64处理器下的Linux

有一篇很好的文章演示了Linux进程的内存布局

如果缓冲区是一个局部变量，那么它将与其他局部变量一起位于堆栈上。如果缓冲区溢出，首先可能遇到的是同一函数中的其他局部变量

当您到达堆栈的末尾时，在下一个使用的内存段之前有一个随机大小的偏移量。如果继续写入该地址空间，将触发segfault（因为该地址空间未映射到任何物理RAM）

假设您在不崩溃的情况下跳过了随机偏移量，并继续覆盖，那么它可能遇到的下一个问题就是内存映射段。此段包含文件映射，包括用于将动态共享库映射到地址空间的映射，以及匿名映射。动态库将是只读的，但是如果流程中有任何RW映射，您可能会覆盖其中的数据

在这个段之后是另一个随机偏移量，在您到达堆之前。同样，如果试图写入随机偏移量的地址空间，则会触发崩溃

堆下面是另一个随机偏移量，后面是BSS、数据，最后是文本段。BSS和数据中的静态变量可能被覆盖。文本段不应是可写的

---

您可以使用该命令检查进程的内存映射。

我认为您的问题反映了对操作系统中工作方式的根本误解。像“缓冲区”和“堆栈”之类的东西往往不由操作系统定义

操作系统将内存划分为内核区域和用户区域（有些系统具有附加的受保护区域）

用户区域的布局通常由链接器定义。链接器创建可执行文件，指示加载程序如何设置地址空间。不同的链接器具有不同的控制级别。通常，默认链接器设置将程序的各个部分按如下方式分组：

-读取/执行

-读/不执行

-读/写/初始化

-读/写/要求零

在某些链接器中，可以使用这些属性创建多个程序节

你问：

如果我有一个包含字符串“Hello world”的字符缓冲区，那么它不是放在最低地址，而是放在最高地址，依此类推

在范诺依曼机器中，内存独立于其用途。同一内存块可以同时解释为字符串、浮点、整数或指令。你可以把你的信按你想要的任何顺序排列，但大多数软件库不会按相反的顺序识别它们。如果您自己的库可以处理向后存储的字符串，那么您就可以退出了

“我的问题是——如果输入字符串足够长，哪些内容可以被覆盖？”

它可能是任何东西

“b中是否存在库函数