I have executed the command "readelf -h test" ("test" is my binary program) on linux, and got following text:
ELF header:
Magic: 7f 45 4c 46 ....
Data: 2's complement, little endian
...
**Flags: 0x1007, noreorder, pic, cpic, o32, mips1**
...
Could you please let me know each meanings of flags of the above text in detail?
I have googled it, but could not find answers. Any comments would be appreciated.
ELF header flags are architecture-specific. For MIPS they are defined in SYSTEM V APPLICATION BINARY INTERFACE
EF_MIPS_NOREORDER 0x00000001
EF_MIPS_PIC 0x00000002
EF_MIPS_CPIC 0x00000004
EF_MIPS_ARCH 0xf0000000
Related
On Ubuntu 20.10 x86_64
my sample code:
#include <stdio.h>
#include <stdlib.h>
int main() {
printf("helloworld\n");
return 0;
}
Build:
gcc -o test test.c
Show entry point address:
readelf -h ./test
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x1060
Start of program headers: 64 (bytes into file)
Start of section headers: 14824 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 13
Size of section headers: 64 (bytes)
Number of section headers: 31
Section header string table index: 30
Why does entry point address start at 0x1060 ? not 0x40000 ?
The binary is relocatable, and the segments have been packed against each other. The .text segment starts at 0x1050 in the file, and the entry point is relative to its location in the file, not the location it will ultimately be loaded.
For a non-relocatable file try readelf -h /usr/lib/klibc/bin/sh. This file is simpler in a number of ways, including not using an interpreter but actually being loaded as-is by the kernel.
We're not in x86 anymore. Relocatable binaries are the default for everything now, not just shared libraries. It's no longer a great pain to do relocatable stuff, and in a certain way it's cheaper than non-relocatable now because we have to emit the vector table anyway because the processor doesn't have 64 bit displacement.
As Nate Eldredge points out, compiling with -no-pie yields a non-relocatable binary, and I have verified the expected start address appears.
Here is a very simple assembly program, just return 12 after executed.
$ cat a.asm
global _start
section .text
_start: mov rax, 60 ; system call for exit
mov rdi, 12 ; exit code 12
syscall
It can be built and executed correctly:
$ nasm -f elf64 a.asm && ld a.o && ./a.out || echo $?
12
But the size of a.out is big, it is more than 4k:
$ wc -c a.out
4664 a.out
I try to understand it by reading elf content:
$ readelf -l a.out
Elf file type is EXEC (Executable file)
Entry point 0x401000
There are 2 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x00000000000000b0 0x00000000000000b0 R 0x1000
LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000
0x000000000000000c 0x000000000000000c R E 0x1000
Section to Segment mapping:
Segment Sections...
00
01 .text
it is strange, segment 00 is aligned by 0x1000, I think it means such segment at least will occupy 4096 bytes.
My question is what is this segment 00?
(nasm version 2.14.02, ld version 2.34, os is Ubuntu 20.04.1)
Since it starts at file offset zero, it is probably a "padding" segment introduced to make the loading of the ELF more efficient.
The .text segment will, in fact, be already aligned in the file as it should be in memory.
You can force ld not to align sections both in memory and in the file with -n. You can also strip the symbols with -s.
This will reduce the size to about 352 bytes.
Now the ELF contains:
The ELF header (Needed)
The program header table (Needed)
The code (Needed)
The string table (Possibly unneeded)
The section table (Possibly unneeded)
The string table can be removed, but apparently strips can't do that.
I've removed the .shstrtab section data and all the section headers manually to shrink the size down to 144 bytes.
Consider that 64 bytes come from the ELF header, 60 from the single program header and 12 from your code; for a total of 136 bytes.
The extra 8 bytes are padding, 4 bytes at the end of the code section (easy to remove), and one at the end of the program header (which requires a bit of patching).
I am trying to find a call function in a binary file, so I tried this:
Compile my code (in C),
Use the command: mips-mti-linux-gnu-objdump -d myapp.elf> objdump.txt
My function in objdump.txt file: 9d003350: 42000828 myfunction 0x1
Now, I want to identify this function in myapp.bin when reading this from memory. But, I get this: 28080042.
I tried to use the command: xxd -ps myapp.bin> xxd.txt
Just can find: 28080042.
Is it possible to do that?
That's an endianness conflict. objdump and xxd are giving you the same bytes, they're just using different endianness.
Actual bytes in order:
28 08 00 42
Big endian value:
28 08 00 42
Little endian value:
42 00 08 28
xxd -p will print out the individual bytes in the file in the order in which they exist.
objdump is disassembling it, it knows that the bytes belong in groups of 4, and it's interpreting them as little-endian.
xxd can print in little-endian order, using the -e flag (with a default grouping of 4 bytes, use the -g flag to change the number of bytes per group). However, this is incompatible with the -p flag, because the -p flag ignores any grouping.
objdump can be made to print in big-endian order, using the -EB flag, however, this will affect what instructions it reports.
I'm trying to run dfhack in a debugger. I'm running 64-bit Ubuntu Trusty, but Dwarf Fortress does not have a 64-bit build so I'm running 32-bit Dwarf Fortress. I have installed gdb via apt-get install gdb:i386.
Here's what happens when I start dfhack with gdb:
ben#australium:~/df_linux$ xvfb-run -a ./dfhack --gdb
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./libs/Dwarf_Fortress...(no debugging symbols found)...done.
(gdb) start
Temporary breakpoint 1 at 0x804bdec
Starting program: /home/ben/df_linux/libs/Dwarf_Fortress
ERROR: ld.so: object './hack/libdfhack.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, 0xf7598b53 in main ()
from /home/ben/df_linux/libs/libgraphics.so
(gdb)
Here's what happens when I run it without gdb:
ben#australium:~/df_linux$ xvfb-run -a ./dfhack
Xlib: extension "RANDR" missing on display ":99".
Loading bindings from data/init/interface.txt
New window size: 1280x720
Font size: 10x12
Resizing grid to 128x60
Resizing font to 10x12
Resetting textures
DFHack is ready. Have a nice day!
Type in '?' or 'help' for general help, 'ls' to see all commands.
[DFHack]#
The executable, the preloaded library, and gdb are all 32-bit:
ben#australium:~/df_linux$ readelf -h /home/ben/df_linux/libs/Dwarf_Fortress
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: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x804c980
Start of program headers: 52 (bytes into file)
Start of section headers: 18192664 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 28
Section header string table index: 27
ben#australium:~/df_linux$ readelf -h /home/ben/df_linux/hack/libdfhack.so
ELF Header:
Magic: 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - GNU
ABI Version: 0
Type: DYN (Shared object file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x1b7e40
Start of program headers: 52 (bytes into file)
Start of section headers: 43686636 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 7
Size of section headers: 40 (bytes)
Number of section headers: 37
Section header string table index: 34
ben#australium:~/df_linux$ readelf -h /usr/bin/gdb
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: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x808cb95
Start of program headers: 52 (bytes into file)
Start of section headers: 5089368 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 9
Size of section headers: 40 (bytes)
Number of section headers: 28
Section header string table index: 27
ERROR: ld.so: object './hack/libdfhack.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
This error comes from GDB starting your (64-bit) shell, which in turn execs your (32-bit) dfhack program.
You should only care about preloading into the target program. The fact that libdfhack.so was not preloaded into your shell is of no consequence, and you should simply ignore it.
I have a .a file from which I want to get architecture information. Running file myFile.a results in file.a: current ar archive. How can I get more information on what architecture the file contains?
You can also skip the ar command and use readelf, via something like:
readelf -h <archive>.a | grep 'Class\|File\|Machine'
[00:32:15] /usr/lib $ readelf -h libxslt.a | grep 'Class\|File\|Machine'
File: libxslt.a(attrvt.o)
Class: ELF32
Machine: Intel 80386
File: libxslt.a(xslt.o)
Class: ELF32
Machine: Intel 80386
... #Trimmed this, it goes on a bit
File: libxslt.a(transform.o)
Class: ELF32
Machine: Intel 80386
File: libxslt.a(security.o)
Class: ELF32
Machine: Intel 80386
[00:32:24] /usr/lib $
In case it's relevant, here's the other information that you can get from readelf -h. I just trimmed the above with grep, obviously:
File: libxslt.a(security.o)
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: 2548 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 16
Section header string table index: 13
That output is for one of the object files in libxslt.a, but it gives the same information for each file.
Use
lipo -info libExample.a
It will Who the architecture it build for. Other functions like otool or file doesn't give the exact answer and sometimes it to verbose to get the correct information.
objdump is another option:
objdump -a file.a|grep 'file format'
http://linux.die.net/man/1/ar
extract the object files from the archive and inspect them with file(1), nm(1), etc.
I would suggest using objdump instead of lipo. objdump provides detailed information than lipo.