elf

I've recently compiled a simple hello world C program under Debian Linux using gcc: gcc -mtune=native -march=native -m32 -s -Wunused -O2 -o hello hello.c The file size was 2980 bytes. I opened it in a hex editor and i saw the following lines: GCC: (Debian 4.4.5-8) 4.4.5 GCC: (Debian 4.4.5-10) 4.4.5 .shstrtab .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .text .fini .rodata .eh_frame .ctors .dtors .jcr .dynamic .got .got.plt data.data .bss .comment Are they really needed? No way to reduce executable size? That's in a

as we know .bss contains un-initialized variables. if in c code, programer initialize the variables before using them. then .bss is not necessary to be zero before executing C code. Am I right? Thanks In C code, any variable with static storage duration is defined to be initialized to 0 by the spec (Section 6.7.8 Initialization, paragraph 10): If an object that has static storage duration is not initialized explicitly, then: if it has pointer type, it is initialized to a null pointer; if it has arithmetic type, it is initialized to (positive or unsigned) zero; if it is an aggregate, every

I want to learn about elf files, but when I think of global variables, global static variables and scope static variables, I have some confusion. For example: int a = 2; int b; static int c = 4; static int d; void fun(){ static int e = 6; static int f; } int main(void){ fun(); } Who can tell which segment each variable belongs to? in my opinion, b , d and f belong to the .bss segment and a , c and e belong to the data segment, but I don't know the difference between global static variables and global variables in elf file. You can use objdump -t to view the symbol table: $ objdump -t foo |

What is the search order for symbol lookup when resolving dynamic relocations? When resolving symbols for a shared library does the loader first search in the 'main executable' (to let the main executable override definitions...) or what? Per my understanding, each executable object has its own "lookup scope": The main executable is usually the first object in the "global" lookup scope. This means that symbols defined in the main executable would override those in dependent shared libraries. Shared objects that are added using the LD_PRELOAD facility are added to the global lookup scope, right

写在前面 linux下的动态链接相关结构，重新回顾_dl_runtime_resolve的流程以及利用方法 动态链接相关结构 为了高效率的利用内存，多个进程可以共享代码段、程序模块化方便更新维护等，动态链接技术自然就出现了。不详细介绍位置无关代码和位置无关可执行程序这些基本知识，这里着重记录一下ELF实现运行时重定位为了提高效率做的各种工作和用到的结构。 动态链接的可执行文件装载过程和静态链接基本一样，OS读取可执行文件的头部信息，检查文件合法性后从Program Header中读取每一个Segment的虚拟地址、文件地址和属性，然后把他们映射到进程虚拟空间的相对位置。但是OS接下来不能把控制权交给可执行文件，因为动态链接中还有很多依赖于共享对象的无效地址，需要进一步处理。映射完成后，OS会启动一个动态链接器（Dynamic Linker)——linux下就是ld.so。这个动态链接器实际上也是一个共享对象，OS也会通过映射的方式把它载入进程的地址空间中。然后OS就会把控制权交给DL的入口地址，它会进行一系列初始化操作，根据当前环境参数对可执行文件进行动态链接工作。完成之后再把控制权转交给可执行文件。 pwn常见的so hell 动态链接器并非由系统配置或者环境参数决定，而是由ELF可执行文件自己决定！动态链接的ELF可执行文件中，有一个专门的段叫做.interp

Short of digging through GDB source, where can I find documentation about the format used to create core files? The ELF specification leaves the core file format open, so I guess this should be part of the GDB specifications! Sadly, I did not find any help in this regard from GNU's gdb documentation. Here's what I am trying to do: Map virtual addresses to function names in executable/libraries that comprised the running process. To do that, I would first like to figure out, from the core file, the map from virtual address space to the name of the executable file/libraries, and then dig into

If the same code is built at different times w/gcc, the resulting binary will have different contents. OK, I'm not wild about that, but that's what it is. However, I've recently run into a situation where the same code, built with the same version of gcc, is generating a binary with a different size than a prior build (by about 1900 bytes). Does anyone have any idea what may be causing either of these situations? Is this some kind of ELF issue? Are there any tools out there (other than ldd) that can be used to dump contents of binaries to see what exactly is different? Thanks in advance. I've

I have a binary that uses a bunch of .so files. bash-3.00$ file foo foo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.21, dynamically linked (uses shared libs), not stripped But if I run ldd on this file, its not able to pick up the .so files the binary is dependent on.' bash-3.00$ ldd foo not a dynamic executable bash-3.00$ readelf does show the list of shared libraries used by the binary.. bash-3.00$ readelf -d foo Dynamic segment at offset 0x17c810 contains 70 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libdl.so.2] Why is ldd not able to