标签: elf

将PE二进制文件转换为ELF二进制文件的最佳工具是什么？

以下是此问题的简要动机:

1. 假设我有一个简单的C程序.
2. 我使用gcc for linux编译它(这给了ELF),并使用'i586-mingw32msvc-gcc'用于Windows(这给出了一个PE二进制文件).
3. 我想分析这两个二进制文件的相似之处,使用Bitblaze的静态分析工具 - vine(http://bitblaze.cs.berkeley.edu/vine.html)
4. 现在藤蔓没有对PE二进制文件的良好支持,所以我想转换PE-> ELF,然后进行我的比较/分析.

由于所有分析都必须在Linux上运行,我更喜欢在Linux上运行的实用程序/工具.

谢谢

我在ELF共享库中有很多代码,只在库初始化期间使用它(它是从静态初始化程序调用的).如果我把这段代码放在它自己的部分(或者它可以放在.init部分中),我可以使用__attribute__((section(".mysection"))),有没有办法在库加载后强制将该部分分页？

这个问题是相关的,但结论是内核会在内存不足时分页出未使用的页面,所以没有必要明确地这样做.但是,我正在一个内存非常宝贵的嵌入式环境中工作,而来自磁盘(慢速USB闪存驱动器)的代码分页成本很高.因此,我宁愿显式刷新这段代码,我知道这些代码永远不会被再次使用,而不是内核可能决定刷新其他可能最终需要重新分页的代码.

我确定我记得读过有关系统调用的内容,要求内核进入或退出某些内存区域,虽然我无法在任何地方找到任何引用,所以也许我想象它.这样的事情存在吗？

假设二进制文件是PIC,我如何将其加载到内存中并执行入口点？我这样做是为了熟悉ELF所以execve不允许这样做.

解析动态重定位时符号查找的搜索顺序是什么？

解析共享库的符号时,加载器首先搜索"主可执行文件"(让主可执行文件覆盖定义......)或者什么？

我必须编写一个打印ELF文件的C程序.我无法弄清楚节头字符串表的位置.

假设我有一个文件,它给了我以下输出:

readelf -h

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)  
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          17636 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of …

是否可以将动态链接的elf二进制文件转换为静态链接的？

似乎glibc 2.14引入了新版本memcpy(修复bug 12518).然后,针对glibc 2.14+编译的程序将包含动态链接memcpy@GLIBC_2.14,这在旧版本的glibc中显然不可用.

但是,glibc 2.14+显然仍然包含旧memcpy@GLIBC_2.2.5符号以实现向后兼容.我希望能够以这样的方式编译一些程序,使它们与旧的glibc版本二进制兼容.如何在具有glibc 2.14+的系统上编译程序,以便它使用这个旧的符号版本？如果该过程必然是特定于编译器的,那么我正在使用GCC(但是知道如何在其他编译器上执行它也会很好).

(在一个侧面说明,我必须承认不知道一大堆有关版本的符号,比如如何产生,以及如何使用它们,或者他们是否是ELF特定的或应被认为是现代的ABI标准的一部分;我还没有找到任何关于它的文件.关于这个问题,有没有很好的信息来源？)

我在CentOS 7上使用Devtoolset-7并且已经构建了Boost 1.65.1 w/it.但是当我链接我的应用程序时,我有以下内容:

/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: /opt/rh/devtoolset-7/root/usr/lib64/libboost_unit_test_framework.a(compiler_log_formatter.o)(.text._ZN5boost9unit_test5utils11string_castINS0_13basic_cstringIKcEEEESsRKT_[_ZN5boost9unit_test5utils11string_castINS0_13basic_cstringIKcEEEESsRKT_]+0x3c): unresolvable R_X86_64_NONE relocation against symbol `_ZTVSt9basic_iosIcSt11char_traitsIcEE@@GLIBCXX_3.4'
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

搜索更多信息R_X86_64_NONE并没有给出任何有价值的结果:大多数类似的问题没有任何答案或精确解释这是什么以及如何解决它.

所以我的问题是:

• 这个错误究竟意味着什么？
• 是什么R_X86_64_NONE和为什么"没有任何重新定位"(根据bintils来源)ELF标题中存在的符号类型？

附录:

• 链接单元测试可执行文件时出错,链接到我的静态库和Boosts的静态库(单元测试框架)
• 所有静态库(Boost和我的一个)都内置了-fPIC选项

PS.我真的希望这个问题能够一次又一次地解决(已经打过几次,但这次更新到最新的binutils并没有帮助).(将对此问题的任何活动开始赏金)

我有 STM32F404 板，我正在尝试刷新它。我正在关注本教程。

在项目Makefile 中

$(PROJ_NAME).elf: $(SRCS)
    $(CC) $(CFLAGS) $^ -o $@ 
    $(OBJCOPY) -O ihex $(PROJ_NAME).elf $(PROJ_NAME).hex
    $(OBJCOPY) -O binary $(PROJ_NAME).elf $(PROJ_NAME).bin

burn: proj
    $(STLINK)/st-flash write $(PROJ_NAME).bin 0x8000000

bin 文件是使用生成的OBJCOPY，然后使用 Make 目标进行刷写burn

我的问题：

问题 1：OBJCOPY=arm-none-eabi-objcopy在这种情况下有什么作用。我打开了那个人，但我并没有完全理解，谁能简单解释一下？

问题 2：闪烁 bin 文件给出了预期的结果（LED 闪烁）但是闪烁 elf 文件时 LED 没有闪烁，$(STLINK)/st-flash write $(PROJ_NAME).elf 0x8000000为什么？

我遇到了一个问题，该问题已在一篇好文章“共享库符号冲突（在 Linux 上）”中详细阐述。问题是，当执行和.so定义了同名函数时，如果.so调用这个函数名，它会调用执行中的那个函数，而不是.so本身的这个函数。

我们来谈谈这篇文章中的案例。我了解DoLayer()中的函数在编译时layer.o具有外部函数依赖性。DoThing()layer.o

但是在编译时libconflict.so，外部函数依赖项不应该就地解析并用conflict.o/DoThing()静态地址替换吗？

为什么layer.o/DoLayer()仍然使用动态链接来查找DoThing()？这是设计好的行为吗？