标签: elf

这是我偶尔遇到的情况:

对于不使用虚拟寻址的嵌入式系统,我有一个可执行文件,它是用C或C++代码编译的,包含调试信息.它通常在COFF或ELF/DWARF(我得到那两个混合)格式.

在运行时,在PC上,我想确定给定名称的变量的地址.(例如"foo.bar [7] .baz")这允许我在嵌入式系统上读/写变量的值(给定一个超出本问题范围的调试协议).显然,任何基于堆栈或基于堆的变量都没有,因为它们没有静态地址.

我之前在C++中已经完成了这项工作,用于解析TI编译器为其2800系列DSP编写的COFF文件,这有点痛苦.我想知道是否有一个Java库已经做了这种事情,因为我面对着一个或两个其他处理器的可执行文件.

更新:(11/18/2009)一个有希望的线索!

有没有人使用Eclipse CDT ELF解析器？

(见http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.cdt.doc.isv/reference/api/org/eclipse/cdt/core/model/IBinary.html一的javadoc pgs)

TI的Code Composer 4(基于Eclipse)似乎使用了这个,所以似乎我可以弄清楚文档的位置,也许我可以用它来解决我的问题.

我想用一个.interp段编译一个共享库。

#include <stdio.h>

int foo(int argc, char** argv) {

    printf("Hello, world!\n");
    return 0;

}

我正在使用以下命令。

gcc -c -o test.o test.c
ld --dynamic-linker=blah -shared -o test.so test.o

我最终没有INTERP段，就好像我从未通过过该--dynamic-linker=blah选项一样。用检查readelf -l test.so。生成可执行文件时，链接器会正确处理该选项，并将INTERP段放在程序头中。如何使它也适用于共享库？

我有一个静态ELF二进制文件,它从zip文件中读取数据.为了简化分发,我想将zipfile附加到二进制文件,如下所示:

$ cat mydata.zip >> mybinary

我知道这样做不会损害mybinary,但我不知道如何访问mydata.zip的内容.可能吗？如果是这样,怎么样？

在过去,我使用了附加数据然后附加数据长度的技巧,因此我所要做的就是打开二进制文件,读取流的最后一个int,回退那个长度然后开始解压缩,但是由于各种原因在这里不起作用(例如,我不能保证当需要zipfile时文件仍然在光盘上).

如果解决方案适用于OS X和MinGW,那么全面超级双倍加分.

我有一个广泛使用模板的源文件。在该文件中，我还具有不同模板的显式实例化…很多。该文件被编译为静态库的一部分。我在多个平台上为多个体系结构编译了该库：Win x86，Linux x86和Linux ARM。对于Linux版本，我使用不同的编译器，因此生成的文件（在ELF文件本身的上下文中讨论）是不同的：对于GCC，生成的目标文件大小为8.4MB，并具有超过40000个ELF节；对于ARM编译器（armcc），结果文件的大小为12.7MB，并具有超过90000个ELF节（！）；在两种情况下，我都有调试信息。

发生的情况是，在链接时，ARM链接器试图将静态库中的巨大目标文件链接起来而死掉了。经过一番调查，看来它无法处理其中包含超过65536个ELF部分的目标文件（尽管我仍然必须从编译器供应商处获得确认，否则我将完全或完全错误地做某件事）。我发现的解决方案是将文件拆分为多个较小的文件（它的结构以及允许的内容）。

问题：还有其他替代解决方案吗？在链接阶段之前，编译器是否有可能在目标文件中（在模板的上下文中）生成额外的代码？

为了研究如何在linux中加载和运行目标文件,我制作了最简单的c代码,文件名simple.c.

int main(){}

接下来,我制作目标文件并将目标文件保存为文本文件.

$gcc ./simple.c 
$objdump -xD ./a.out > simple.text

从许多互联网文章中,我可以发现gcc动态加载启动函数,如_start,_init,__ libc_start_main @ plt等.所以我开始阅读我的汇编代码,由http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html提供帮助.

这是汇编代码的一部分.

080482e0 <__libc_start_main@plt>:
 80482e0:       ff 25 10 a0 04 08       jmp    *0x804a010
 80482e6:       68 08 00 00 00          push   $0x8
 80482eb:       e9 d0 ff ff ff          jmp    80482c0 <_init+0x2c>

Disassembly of section .text:

080482f0 <_start>:
 80482f0:       31 ed                   xor    %ebp,%ebp
 80482f2:       5e                      pop    %esi
 80482f3:       89 e1                   mov    %esp,%ecx
 80482f5:       83 e4 f0                and    $0xfffffff0,%esp
 80482f8:       50                      push   %eax
 80482f9:       54                      push   %esp …

链接目标文件以生成ELF文件，并确定其虚拟地址。例如，.text的虚拟地址为0x8048000。当ELF文件要映射到虚拟空间时，另一个ELF已经映射到该地址。操作系统应该做什么？为什么在将ELF的虚拟地址映射到虚拟空间之前就可以确定它的原因。

我在linux上有一些关于ELF可执行文件的奇怪问题.

这是我的系统(uname -a):

Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02) x86_64 GNU/Linux

我有以下程序(test.asm),我使用NASM组装它:

; program just exits with code 0 using linux INT 80H

SECTION .data
SECTION .text
GLOBAL _start

_start:
    MOV EAX, 1
    XOR EBX, EBX
    INT 0x80

我创建三个不同的可执行文件:

nasm -f elf32 -o test32-i386.o test.asm
ld -m elf_i386 -o test32-i386 test32-i386.o

nasm -f elfx32 -o test32-x86_64.o test.asm
ld -m elf32_x86_64 -o test32-x86_64 test32-x86_64.o

nasm -f elf64 -o test64-x86_64.o test.asm
ld -m elf_x86_64 -o test64-x86_64 test64-x86_64.o

这是file …

GCC似乎在进行优化，将合并了相同后缀的字符串文字组合在一起。

例如，一个包含两个字符串文字"foo bar"并"bar"可以最终ELF形式结束的C程序（1）将字符串表更改为具有单个字符串文字，"foo bar"以及（2）将该程序更改为将任何指针"bar"都转换为现在指向的4字符入弦"foo bar"。请注意，从仅向前读取C程序的角度来看，第二个文字仍然看起来像"bar"。

虽然我认为这是一种压缩字符串集合而不增加ELF文件格式复杂性的聪明方案，但是出于深奥的原因，这也给我带来了麻烦（在后期处理ELF文件并对其进行各种分析时）。如何关闭GCC的此功能？

所以我参考这篇论文：

二进制搅拌：旧版x86二进制代码的自随机指令地址

https://www.utdallas.edu/~hamlen/wartell12ccs.pdf

代码与数据交织：由于性能原因，现代编译器在PE和ELF二进制文件的代码段中积极插入静态数据。在编译的二进制文件中，通常没有办法将数据字节与代码区分开。不经意地将数据与代码随机化会破坏二进制文件，从而给指令级随机化器带来困难。可行的解决方案必须以某种方式保留数据，同时随机化所有可访问的代码。

但我有一些问题：

1. 如何提高程序速度？我只能想象这只会使cpu的执行更加复杂吗？

2. CPU如何区分代码和数据？因为据我所知，除非有跳转类型的指令，否则cpu将以线性方式依次执行每个指令，那么cpu怎么知道代码中的哪些指令是代码，哪些指令是数据？

3. 考虑到代码部分是可执行的，并且CPU可能会错误地将恶意数据作为代码执行，这对安全性是否非常不利？（也许攻击者将程序重定向到该指令？）

我将kexec压缩为一个二进制文件，并将其编写为x86_64 ELF。运行正常。

由于它是64位二进制文​​件，因此我知道处理器必须处于64位长模式。这需要使用分页，所以我知道必须打开分页。

我的问题是，这些页表的状态是什么？是否有某些区域（例如我加载的二进制文件）可以保证进行身份映射？是否所有可用的RAM标识都已映射？由于启用了分页，因此页面在哪里？

执行完kexec'之后，我想对整个地址空间进行身份映射。为此，我需要在我知道物理地址的地址处构建一些页表结构，然后将该结构的地址写入CR3。

如果我知道加载到内存中的小精灵二进制文件是身份映射的，则可以在其中静态构建页表，然后进行无缝切换。如果kexec之后没有标识映射的页面，则需要关闭分页，退出long模式，然后进行设置，然后重新进入long 64位模式。

谢谢！