Questions tagged «elf»

ELF代表可执行和可链接格式,这是包含机器代码的文件的文件格式。


2
在Linux上运行最早的二进制文件?
在关于Linux内核和GUI ABI的向后兼容性的讨论中,Alan Cox指出:“ 我的3.6rc内核仍将运行1992年构建的Rogue二进制文件。X向后兼容比Linux早得多的应用程序。 ” 那么Linux 应用程序二进制接口到底向后兼容吗? 什么是几年前实际编写和编译的最旧的二进制可执行文件,仍然可以在现代的通用Linux发行版上运行? 我确定所有这些词都可以解释。我的主要观点是,通过仿真器或专用虚拟机或二进制转换器运行它是不公平的,但是某些此类内容可能已内置在一些现代发行版中,在这里进行学习是有趣的一部分。 还需要关注硬件体系结构,可执行文件格式,语言和主要库动态加载依存关系的变化。 请注意,放宽规则后,这里有一个更进一步的示例。2002年的网页在现代Red Hat Linux上运行a.out可执行文件讨论了在完成 并获得之后使用非常老的Linux之前的ELF a.out格式的可执行文件,这 再次引起了这个问题的兴趣,但它说明了这类事情进一步挖掘时可能会涉及到。modprobe binfmt_aout/lib/ld.solibc.so.4 为您的BSD粉丝提供更新,很高兴看到iBCS2支持旧的Xenix应用程序(例如1990年的zork / dungeon-2.5.6)和SCO OpenServer 5.0.x应用程序以及最近的NetBSD 4.0.1(来自2008年):iBCS2和NetBSD | 虚拟化的乐趣。但是同一件事在NetBSD 5.0.x中似乎坏了。 更新2:一年后,即使获得了此问题的“播音员”徽章,我仍在寻找答案。而且要澄清的是,由于这是关于API的,因此它应该是“真实的”二进制文件(长度不为零),至少仍然大部分以原始方式工作。


2
什么是ELF Magic?
我之前看过有关ELF魔术的讨论,最近一次是关于此安全堆栈交换问题的评论。我之前已经看过它,并且在我自己的启动日志中也看到了它。但是我不确定它是什么。 elf上的手册页让我有些头疼,因为我不使用C或较低级别的语言。 作为使用Linux作为日常操作系统的人,ELF是什么?
26 elf 

1
在/ bin / file的输出中引用可执行文件时,“ LSB”是什么意思?
我在Linux 的命令输出中找到了术语“ LSB可执行文件”或“ LSB共享对象”file。例如: $ file /bin/ls /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=4637713da6cd9aa30d1528471c930f88a39045ff, stripped 在这种情况下,“ LSB”是什么意思?

1
为什么file命令说ELF二进制文件适用于Linux 2.6.9?
每当我在ELF二进制文件上运行文件时,都会得到以下输出: [jonescb@localhost ~]$ file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped 我只是想知道Linux 2.6.9中有什么变化,使得该二进制文件无法在2.6.8上运行?Linux 2.0中是否未添加ELF支持?
18 linux  executable  elf 

2
确定特定进程是32位还是64位
给定2.6.x或更高版本的Linux内核以及既可以运行ELF32也可以运行ELF64二进制文件的现有用户区(即,过去如何知道我的CPU在Linux下支持64位操作系统?)如何确定给定进程(通过PID)是在32位还是64位模式下运行? 天真的解决方案是运行: file -L /proc/pid/exe | grep -o 'ELF ..-bit [LM]SB' 但是,这些信息是否在/proc不依赖的情况下直接公开了libmagic?
14 linux  64bit  proc  elf 

1
Linux,GNU GCC,ld,版本脚本和ELF二进制格式-如何工作?
我试图了解有关Linux中库版本控制的更多信息,以及如何使它们全部正常工作。这里是上下文: -我有两个版本的动态库,它们公开了相同的一组接口,例如libsome1.so和libsome2.so。 -应用程序链接到libsome1.so。 -此应用程序用于libdl.so动态加载另一个模块,例如libmagic.so。 -现在libmagic.so链接libsome2.so。显然,在不使用链接程序脚本隐藏其中的符号的情况下libmagic.so,在运行时,所有对接口的调用libsome2.so都解析为libsome1.so。可以通过libVersion()对照宏的值检查返回的值来确认LIB_VERSION。 -所以我接下来尝试编译并链接libmagic.so一个链接描述文件,该脚本隐藏除其中定义libmagic.so和导出的3个符号以外的所有符号。这行得通...或至少libVersion()和LIB_VERSION值匹配(并且报告版本2不是1)。 -但是,当某些数据结构序列化到磁盘时,我注意到了一些损坏。在应用程序目录中,如果我删除libsome1.so并在其指向的位置创建一个软链接libsome2.so,则一切都会按预期工作,并且不会发生相同的损坏。 我忍不住认为这可能是由于运行时链接程序的符号解析中的某些冲突引起的。我尝试了很多事情,例如尝试链接,libsome2.so以便所有符号都被链接到symbol@@VER_2(我仍然感到困惑,因为该命令nm -CD libsome2.so仍将符号列为symboland而不是symbol@@VER_2)……似乎没有任何作用!!!救命!!!!!!

1
什么时候可以在可执行二进制文件中编辑字符串?
我有一个可执行的二进制文件;让我们称之为a.out。我可以看到二进制文件包含字符串 $ strings a.out ... /usr/share/foo .... 我需要将字符串更改/usr/share/foo为/usr/share/bar。我可以将字符串替换为sed吗? sed -i 's@/usr/share/foo@/usr/share/bar@' a.out 这看起来很安全。当字符串长度不同时,这也可以工作吗?


1
为什么readelf将“ System V”显示为我的操作系统而不是Linux?
我用gcc编译了一个小型C程序(两行代码),以尝试了解ELF文件格式。readelf -h在目标文件上做一个,我在标题中: OS/ABI: UNIX - System V 我正在使用Fedora,所以为什么不使用Linux? 编辑:我编译 int main(){ int x = 0; x++; } 与gcc -o main.o -c main.c。我的gcc版本是 gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
10 linux  elf 

1
ELF可执行文件的哪些部分被加载到内存中,在哪里?
我已经知道的: ELF可执行文件包含许多节,显然.text和.data节已加载到内存中,因为这些是程序的主要部分。但是要使程序正常工作,它需要更多信息,尤其是在动态链接时。 我感兴趣的是.plt,.got,.dynamic,.dynsym,.dynstr等部分。ELF中负责将功能链接到地址的部分。 到目前为止,据我所知,诸如.symtab和.strtab之类的内容不会加载(或不保留)在内存中。但是链接器是否使用.dynsym和.dynstr?他们留在记忆中吗?我可以从程序代码访问它们吗? 可执行文件的任何部分都驻留在内核内存中吗? 我对此的兴趣主要是法医,但是有关此主题的任何信息都将有所帮助。我所阅读的有关这些表和动态链接的资源比较高级,它们仅说明工作原理,而与内存中的内容无关。 让我知道我的问题是否有任何不清楚之处。

1
为什么`strip`不从ELF可执行文件中删除节标题?
最小的ELF可执行文件仅需要ELF标头和至少一个程序标头才能起作用。但是,当我在一个简短的可执行文件上运行strip时,它决定不扔掉节头表或节字符串节,尽管它们对程序执行没有任何作用(据我所知),但仍保留它们。 有没有理由不将它们删除?是否有另一个实用程序可以删除可执行文件运行所不需要的所有内容?我尝试手动编辑要删除的节标题的代码跟踪可执行文件,它看起来可以正常工作,并且要小得多。
9 executable  elf  strip 

1
bash如何执行ELF文件?
当我在Linux Box上时,我使用bash作为外壳。现在,我想知道bash如何处理ELF文件的执行,也就是说,当我键入./program且program是ELF文件时。我grep了bash-4.3.tar.gz,似乎没有某种魔术数字解析器可以确定文件是否为ELF,也没有找到exec()syscall。 整个进程如何运作?bash如何将ELF的执行传递给OS?
8 bash  kernel  executable  exec  elf 
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.