在C语言中，如何在运行时访问解释器路径地址？

Question

通过使用objdump命令，我发现内存中的地址0x02a8contains start路径 ，并且由于C标准，此路径以 0x00byte结尾。

所以我试着写一个简单的C程序来打印这一行（我使用了丹尼斯·尤里切夫（Denis Yurichev）的“RE初学者”一书中的一个示例 - 第24页）：

#include <stdio.h>

int main(){
    printf(0x02a8);
    return 0;
}

但是我很失望得到了一个分段错误，而不是预期的< code >/lib 64/LD-Linux-x86-64 . so . 2 输出。

我觉得使用这样一个“快速”调用printf而没有说明符或至少没有指针转换很奇怪，所以我尝试使代码更自然：

#include <stdio.h>

int main(){
    char *p = (char*)0x02a8;
    printf(p);
    printf("\n");
    return 0;
}

运行这个之后，我仍然得到一个分割错误。

我不认为这是因为记忆区域有限，因为在书中，第一次尝试都很顺利。我不确定，也许还有一些书中没有提到的东西。

因此，需要一些明确的解释，说明为什么每次我尝试运行程序时，分段错误都会不断发生。

我使用的是最新的完全升级的Kali Linux版本。

Answer 1

我想这是因为你使用printf的方式：你没有按照设计的方式使用格式参数。

当您想使用printf函数读取数据时，它需要的第一个参数是一个字符串，该字符串将格式化显示的工作方式int printf（char*fmt，…）"the…表示您要根据格式化字符串参数显示的数据

因此，如果要将字符串//格式打印为文本

  printf("%s\n", pointer_to_beginning_of_string);

//如果这不起作用，可能是因为您正在尝试读取不应该访问的内存。

尝试使用您的编译器添加额外的标志“-Werror-Wext-Wall-steantic”并请向我们显示错误。

Answer 2

它不再像那样工作了。您可能使用的64位Linux可执行文件是独立于位置的，它们被加载到内存中的任意地址。在这种情况下，ELF文件不包含任何固定的基址。

虽然您可以按照马尔科·博内利的指示创建一个位置相关的可执行文件，但这并不是现代64位linuxen上任意可执行文件的工作方式，因此更值得学习使用位置无关的文件来实现这一点，但这有点棘手。

这对我打印ELF起到了作用，即小精灵头魔法和解释器字符串。这是肮脏的，因为它可能只适用于一个小的可执行文件。

#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>

int main(){
    // convert main to uintptr_t
    uintptr_t main_addr = (uintptr_t)main;

    // clear bottom 12 bits so that it points to the beginning of page
    main_addr &= ~0xFFFLLU;

    // subtract one page so that we're in the elf headers...
    main_addr -= 0x1000;

    // elf magic
    puts((char *)main_addr);

    // interpreter string, offset from hexdump!
    puts((char *)main_addr + 0x318);
}

在内存中查找ELF可执行文件的开头还有另一个技巧：所谓的辅助向量和getauxval：

< code>getauxval()函数从辅助向量中检索值，这是一种机制，内核的ELF二进制加载程序在执行程序时使用这种机制将某些信息传递给用户空间。

ELF程序头在内存中的位置是

#include <sys/auxv.h>
char *program_headers = (char*)getauxval(AT_PHDR);

实际的ELF头是64字节长，程序头从64字节开始，因此如果从中减去64，您将再次得到一个指向神奇字符串的指针，因此我们的代码可以简化为

#include <stdio.h>
#include <inttypes.h>
#include <sys/auxv.h>


int main(){
    char *elf_header = (char *)getauxval(AT_PHDR) - 0x40;
    puts(elf_header + 0x318); // or whatever the offset was in your executable
}

最后，一个可执行文件，仅从ELF标头中计算出解释器位置，前提是您有一个来自维基百科的64位ELF魔术数字......

#include <stdio.h>
#include <inttypes.h>
#include <sys/auxv.h>


int main() {
    // get pointer to the first program header
    char *ph = (char *)getauxval(AT_PHDR);

    // elf header at this position
    char *elfh = ph - 0x40;

    // segment type 0x3 is the interpreter;
    // program header item length 0x38 in 64-bit executables
    while (*(uint32_t *)ph != 3) ph += 0x38;

    // the offset is 64 bits at 0x8 from the beginning of the 
    // executable
    uint64_t offset = *(uint64_t *)(ph + 0x8);

    // print the interpreter path...
    puts(elfh + offset);
}

Answer 3

令人失望的是，你的《初学者的教育》一书没有首先进入基础知识，还吐出了这些废话。尽管如此，你所做的显然是错误的，让我解释一下为什么。

通常在Linux上，GCC生成独立于位置的ELF可执行文件。这样做是出于安全目的。当程序运行时，操作系统能够把它放在内存的任何地方(任何地址)，程序就会正常工作。这种技术被称为地址空间布局随机化，是操作系统的一个特性，现在默认启用。

通常，ELF程序会有一个“基地址”，并且会准确地加载到该地址才能工作。但是，在位置无关的ELF的情况下，“基地址”设置为0x0，操作系统和解释器决定在运行时将程序放在哪里。

当在独立于位置的可执行文件上使用< code>objdump时，您看到的每个地址都不是真实的地址，而是从程序基址的偏移量(只有在运行时才知道)。因此，在运行时不可能知道这样一个字符串(或任何其他变量)的位置。

如果你想让上面的工作，你将不得不编译一个不独立于位置的ELF。你可以这样做:

gcc -no-pie -fno-pie prog.c -o prog