标签: elf
为什么“H”/72/0x48 是可执行文件中第二个最常见的字节？
（如果本题得分为72分，请不要投票！）
我跑了这个：
cat /usr/bin/* |
perl -ne 'map {$a{$_}++} split//; END{print map { "$a{$_}\t$_\n" } keys %a}' |
grep --text . | sort -n | plotpipe --log y {1}
并得到这个：
（即使使用对数 y 轴，它看起来仍然是指数的！顶部和底部之间的距离超过 100 倍）
看一下数字：
:
31919597 ^H
32983719 ^B
33943030 ^O
39130281 \213
39893389 $
52237360 \211
53229196 ^A
76884442 \377
100776756 H
746405320 ^@
^@ (NUL) 是可执行文件中最常见的字节，这并不奇怪。\377 (255) 和 ^A (1) 对我来说也具有直观意义。
但是，是什么导致“H”（72）成为可执行文件中第二常见的字节——比 255 和 1 更常见呢？
背景
对于 Perl 脚本，我需要找到 Perl 脚本中最不常见的字节。意外的是，我没有只 grep 出 Perl 脚本，而是对所有二进制文件运行了该命令。我预计有几个字节会脱颖而出，例如 …
推荐指数
解决办法
查看次数
我们可以从 elf 二进制文件中获取编译器信息吗？
有没有机会知道在 Linux 下如何构建二进制文件？（和或其他 Unix）
编译器、版本、时间、标志等...
我查看readelf并找不到太多内容，但可能还有其他方法可以分析二进制代码/部分等...
你知道怎么提取吗？
推荐指数
解决办法
查看次数
为什么程序不以编译格式分发？
但他们给出的指令是
cd downloaded_program
./configure
make install
这将创建所需的 ELF，可能还有一些 .so 文件。
为什么不把它们放在一个 zip 文件中进行下载，就像 Windows 应用程序一样？有什么理由需要用户编译它们吗？
推荐指数
解决办法
查看次数
在 Linux 上运行的最古老的二进制文件？
在讨论 Linux 内核和 GUI ABI 的向后兼容性时，Alan Cox 指出“我的 3.6rc 内核仍将运行 1992 年构建的 Rogue 二进制文件。X 重新兼容比 Linux 更古老的应用程序。 ”
那么 Linux应用程序二进制接口的向后兼容程度如何？
什么是最古老的二进制可执行文件，实际上是在几年前编写和编译的，仍然可以在现代股票通用 Linux 发行版上运行？
我相信所有这些话都可以解释。我的主要观点是通过模拟器或专门的虚拟机或二进制翻译器运行它是不公平的，但一些这样的东西可能内置在一些现代发行版中，了解它是这里乐趣的一部分。
硬件架构、可执行文件格式、语言和主要库动态加载依赖项的变化也很有趣。
请注意，当规则放宽时，这里有一个更进一步的例子。2002年的网页运行的a.out现代的Red Hat Linux可执行会谈有关使用真的老的Linux预ELF的a.out格式的可执行文件后做事modprobe binfmt_aout ，并获得/lib/ld.so和libc.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 的，它应该是一个“真正的”二进制（非零长度），至少仍然以原始方式工作。
推荐指数
解决办法
查看次数
什么是精灵魔法？
我之前看过关于 ELF 魔法的讨论，最近是在这个安全堆栈交换问题中的评论。我之前已经看到它提到过，我在我自己的引导日志中也看到过它。但我不确定它是什么。
elf 上的手册页有点超出我的理解，因为我不使用 C 或更低级别的语言。
作为使用 Linux 作为日常操作系统的人，ELF 是什么？
推荐指数
解决办法
查看次数
在 /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”是什么意思？
推荐指数
解决办法
查看次数
为什么 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 支持吗？
推荐指数
解决办法
查看次数
确定特定进程是 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？
推荐指数
解决办法
查看次数
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一个链接器脚本，该链接器脚本隐藏了除 3 之外的所有符号，这些符号在其中定义libmagic.so并由它导出。这有效......或者至少libVersion()和LIB_VERSION值匹配（并且它报告版本2而不是1）。
-- 但是，当一些数据结构被序列化到磁盘时，我注意到一些损坏。在应用程序的目录中，如果我删除libsome1.so并在其指向的位置创建一个软链接libsome2.so，一切都按预期工作，并且不会发生相同的损坏。
我不禁想到这可能是由于运行时链接器对符号的解析存在一些冲突造成的。我已经尝试了很多东西，比如尝试链接libsome2.so以便所有符号都被别名化symbol@@VER_2（我仍然对此感到困惑，因为该命令nm -CD libsome2.so仍然将符号列为symbol和不列出symbol@@VER_2）......似乎没有任何效果！！！帮助！！！！！！
推荐指数
解决办法
查看次数
检测是否使用 gprof 检测构建了 ELF 二进制文件？
是否可以检查给定的程序是否是使用 GNU gprof 工具编译的，即“-pg”标志传递给编译器和链接器，而不运行它来检查它是否会生成gmon.out文件？
推荐指数
解决办法
查看次数
标签 统计
elf ×10
executable ×4
linux ×4
64bit ×1
compiler ×1
debugging ×1
file-format ×1
gcc ×1
history ×1
make ×1
proc ×1
profiling ×1
source ×1
terminology ×1
x86 ×1