I am currently writing a compiler (http://curly-lang.org if you’re curious), and have been encountering a strange bug when trying to run the generated ELF binaries on the latest Linux kernel. The same binaries run fine on older kernels (I’ve tried on several Ubuntu boxes, uname 4.4.0-1049-aws), but on my updated Arch box (uname 4.17.11-arch1), I can’t even open them under
Tag: elf
Relocations in generic ELF (EM: 183)
This used to work before. I don’t know what changed, the thing is I can’t run anymore. I’m cross-compiling for an aarch64 architecture with ARM cpu’s, using Ubuntu 16.04 x86-64. This is what I’m running to configure: ./configure –host=aarch64-linux-gnu –prefix=/data/data/papi/independent –exec-prefix=/data/data/papi/dependent –with-static-lib=yes –with-shared-lib=no –with-static-tools –with-arch=aarch64 –with-CPU=arm –with-ffsll –with-walltimer=cycle –with-tls=__thread –with-virtualtimer=clock_cputime_id –with-perf-events Logs from running configure: After running make: (…) file
How to create an ELF executable from process memory image
First of all, Engilish is not my native language. Please excuse if there are any mistakes. As stated above, I want to create an ELF executable from process memory image. Up until now, I successfully extracted an ELF Header, Program Headers and a list of Elf64_Dyn structures resides in Dynamic segment. I also restored GOT. However, I can’t figure out
How can I hook c function from ELF file, that uses library .so in Linux ?
I have executable ELF file, that uses library lib.so, and this ELF invokes function Func1 from lib.so I need to hook this function, so it will be replaced with my function, that does something else. How can I do this without changing this executable file ? Answer Take a look at LD_PRELOAD. That environment variable can be set to an
ELF label address
I have the following code in .s file: Its object file has the following: After linking, it becomes: How does the argument 0x0 to pushq at byte 20 of the object file gets converted to 0x400578 in the final executable? Which section of the object file contains this information? Answer You answered your own question: After linking…. Here is a
How do I find symbol offset in .so from runtime address
I need to be able to convert an instruction pointer (from a backtrace) into a file and line number after a program has terminated. During execution, I can store any additional information I will later require for this offline analysis, but the analysis does have to happen offline. Right now, I along with emitting the instruction pointers, I am emitting
ELF, Build-ID, is there a utility to recompute it?
I came across this useful feature in ELF binaries — Build ID. “It … is (normally) the SHA1 hash over all code sections in the ELF image.” One can read it with GNU utility: And I wonder if there is an easy way to recompute Build ID yourself? To check if it isn’t corrupted etc. Answer So, I’ve got an
Function of shared library is loaded at different physical addresses for different processes
I get physical addresses of function “printf” in libc.so in two programs, and two physical addresses are different. And I read two different physical address, the content are almost the same. This means function “printf” has two copies in memory? Details: My os is 32-bit linux. Physical address is calculated by read “/proc/self/pagemap”. Physical address reading is implemented with fmem
How does elf-loader knows the address of stderr and stdout
I am disassembling a very simple ELF program (Linux x86). With IDA PRO software I see stdout and stderr in .bss-section. And I haven’t found anything that sets the values of stdout or stderr. How does it work? Сan stdout and stderr be null? Answer So you mean stdout and stderr should always be at the same memory address in
How can gcc/clang assume a string constant’s address is 32-bit?
If I compile this program: for x86-64, the asm output uses movl $.LC0, %edi / call puts. (See full asm output / compile options on godbolt.) My question is: How can GCC know that the the string’s address can fit in a 32bit immediate operand? Why doesn’t it need to use movabs $.LC0, %rdi (i.e. a mov r64, imm64, not