292 lines
11 KiB
Markdown
292 lines
11 KiB
Markdown
# Notes
|
|
|
|
## http://nickdesaulniers.github.io/blog/2016/08/13/object-files-and-symbols/ (and it's follow up post)
|
|
|
|
These files are being used as an example:
|
|
|
|
```c
|
|
// main.c
|
|
// declare that these exist, but it's defined in hello.c
|
|
void hello();
|
|
void hello2();
|
|
int main() {
|
|
hello();
|
|
hello2();
|
|
return 0;
|
|
}
|
|
```
|
|
|
|
```c
|
|
// hello.c
|
|
#include <stdio.h>
|
|
void hello() {
|
|
puts("Hello World!");
|
|
}
|
|
```
|
|
|
|
```c
|
|
// hello2.c
|
|
#include <stdio.h>
|
|
void hello2() {
|
|
puts("Hello Again!");
|
|
}
|
|
```
|
|
|
|
* Object files (.o)
|
|
- `clang -c main.c hello.c hello2.c`
|
|
- Contain the actual compiled machine code, but the addresses used need to
|
|
be relocated when compiling the full binary.
|
|
- Contain symbol table, which relates addresses to variables and functions
|
|
defined in the object file.
|
|
- `nm` can be used to inspect symbol table. Includes "undefined" symbols,
|
|
which are symbols used by the object file but which aren't defined within
|
|
it (and which are presumably defined elsewhere).
|
|
```
|
|
▻ nm main.o
|
|
U hello
|
|
U hello2
|
|
0000000000000000 T main
|
|
|
|
▻ nm hello.o
|
|
0000000000000000 T hello
|
|
0000000000000000 r .L.str
|
|
U puts
|
|
|
|
▻ nm hello2.o
|
|
0000000000000000 T hello2
|
|
0000000000000000 r .L.str
|
|
U puts
|
|
```
|
|
- `readelf` can be also used to dump the contents of the object file's
|
|
symbol table on linux (`-s` displays symbol table):
|
|
```
|
|
▻ readelf -s main.o
|
|
Symbol table '.symtab' contains 6 entries:
|
|
Num: Value Size Type Bind Vis Ndx Name
|
|
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
|
|
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS main.c
|
|
2: 0000000000000000 0 SECTION LOCAL DEFAULT 2
|
|
3: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND hello
|
|
4: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND hello2
|
|
5: 0000000000000000 37 FUNC GLOBAL DEFAULT 2 main
|
|
|
|
▻ readelf -s hello.o
|
|
Symbol table '.symtab' contains 6 entries:
|
|
Num: Value Size Type Bind Vis Ndx Name
|
|
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
|
|
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS hello.c
|
|
2: 0000000000000000 13 OBJECT LOCAL DEFAULT 4 .L.str
|
|
3: 0000000000000000 0 SECTION LOCAL DEFAULT 2
|
|
4: 0000000000000000 29 FUNC GLOBAL DEFAULT 2 hello
|
|
5: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND puts
|
|
```
|
|
|
|
* Static library files (.a)
|
|
- `ar` utility creates uncompressed, static (those might be synonomous in
|
|
this context?) archives, with the `.a` extension.
|
|
- In the context of compiling code, `.a` files are archives of multiple
|
|
object files, with the symbol table preserved in a way where nm and ilk
|
|
can still understand it.
|
|
```
|
|
▻ ar r hello.a hello.o hello2.o
|
|
▻ nm hello.a
|
|
|
|
hello.o:
|
|
0000000000000000 T hello
|
|
0000000000000000 r .L.str
|
|
U puts
|
|
|
|
hello2.o:
|
|
0000000000000000 T hello2
|
|
0000000000000000 r .L.str
|
|
U puts
|
|
```
|
|
- This `.a` file can then be passed into clang as if it was an object file,
|
|
and the resulting binary would statically contain all symbols from the
|
|
archive that it needs:
|
|
```
|
|
▻ clang main.o hello.a
|
|
▻ ./a.out
|
|
Hello World!
|
|
Hello Again!
|
|
```
|
|
|
|
* Dynamic/shared library files (.so on Linux, .dylib on OSX, .dll on Windows)
|
|
- If multiple programs share the same library and are being statically
|
|
compiled then, when run, that library ends up in memory twice. Dynamic
|
|
linking allows the library to be dynamically linked in at runtime, to save
|
|
memory use.
|
|
- Can be compiled from either source or object files:
|
|
- `clang -shared hello.c hello2.c -o hello.so`
|
|
- `clang -shared hello.o hello2.o -o hello.so`
|
|
- Then used in final compilation normally: `clang main.o ./hello.so`
|
|
```
|
|
▻ clang main.o ./hello.so
|
|
▻ ldd a.out
|
|
linux-vdso.so.1 (0x00007ffd5665c000)
|
|
./hello.so (0x00007f7f9bbe8000)
|
|
libc.so.6 => /usr/lib/libc.so.6 (0x00007f7f9b830000)
|
|
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f7f9bfec000)
|
|
```
|
|
- `strace ./a.out` can be used to view all system calls a binary makes while
|
|
it runs, including opening and reading dynamic libaries, which will look
|
|
like:
|
|
```
|
|
openat(AT_FDCWD, "./hello.so", O_RDONLY|O_CLOEXEC) = 3
|
|
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\4\0\0\0\0\0\0"..., 832) = 832
|
|
fstat(3, {st_mode=S_IFREG|0755, st_size=7784, ...}) = 0
|
|
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f58fc93a000
|
|
```
|
|
- `LD_DEBUG` env variable can also be used for tracing information, as well
|
|
as dynamic library search path stuff.
|
|
- If hello.so were placed into `/usr/lib` or `/usr/local/lib` then
|
|
compilation could be done with just `clang hello.o -lhello`. `-L` can add
|
|
library search paths as well.
|
|
- `pkg-config` and its associated `.pc` files can be used by library authors
|
|
to specify flags required when compiling using that shared library (e.g.
|
|
to include necessary header files and whatnot).
|
|
- `LD_PRELOAD` can be used to pre-eminently link in a shared library which
|
|
will get searched first before symbols from the "real" shared libraries
|
|
are searched, allowing for code-replace and such.
|
|
|
|
## http://www.linuxjournal.com/article/1059
|
|
|
|
* ELF Header
|
|
- Contains (I think) information on sections, their sizes, and their offsets
|
|
|
|
* ELF File Sections
|
|
- After the header, ELF files composed of multiple sections
|
|
- Each section is composed of information of a similar type
|
|
- All sections are loaded into memory, presumably, but certain are loaded
|
|
into read-only pages (like .text, the executable code) and others are
|
|
loaded into read-write.
|
|
- It would seem that the read-only/read-write dichotemy is enforced by the
|
|
"memory manager", which is part of the cpu?
|
|
- Different sections:
|
|
- .text (ro): executable code
|
|
- .data (rw): variables the user has specified an initial value for
|
|
- .bss (rw): variables the user has not specified an initial value for,
|
|
separate from .data because there's no need to waste space in the
|
|
binary file with zeros.
|
|
- symbol table for debugging (and possibly dynamic linking?)
|
|
|
|
* Shared libraries
|
|
- so's are designed to be "position independent", meaning when the so is
|
|
loaded at binary runtime the place in memory that it is loaded into is not
|
|
actually important. The `-fPIC` compiler option used-to-be/is (?)
|
|
important in order to enable this. (PIC being "position independent code")
|
|
- Compiler reserves a register which points to the start of a "global offset
|
|
table", which is used to support global variables within shared libraries
|
|
using PIC. (I guess shared library global vars are shared across
|
|
processes?)
|
|
- Procedure Linkage Table is like the GOT but for functions, it's basically
|
|
a jump table within the library file. If the user wants to redefine one of
|
|
the shared library's functions, and have all other functions within the so
|
|
use that new one, then the PLT entry for that function is the only need
|
|
which gets changed.
|
|
|
|
* Compiling
|
|
- During compilation the compiler will keep track of symbols needing
|
|
"relocating", meaning they are external to the object file and will need
|
|
to be patched in during linking. Each relocated symbol is marked as such
|
|
in the symbol table (I think), along with the offset into .text where that
|
|
symbol was used, and where the linker needs to place the actual address.
|
|
|
|
## https://blog.oracle.com/ksplice/hello-from-a-libc-free-world-part-2
|
|
|
|
With the following file:
|
|
```c
|
|
// main.c
|
|
void alloc_boi() {
|
|
char *str = "Hello world";
|
|
}
|
|
|
|
void _start() {
|
|
alloc_boi();
|
|
asm("movl $1, %eax;" // what
|
|
"movl $0, %ebx;"
|
|
"int $0x80;");
|
|
}
|
|
```
|
|
|
|
* Compile the above with `clang -nostdlib main.c`, the result will have very
|
|
little in it, but it seems there's still some extra uneeded sections which
|
|
could be removed.
|
|
|
|
* `main.c` uses `_start` instead of `main` since that's the actual first
|
|
function called, but normally it gets filled with libc junk (like importing
|
|
environment variables and such).
|
|
|
|
* The exit call is needed to be explicitly defined otherwise the process won't
|
|
exit, instead execution will run past `.text` and segfault.
|
|
|
|
* The disassembly from above looks like this:
|
|
```
|
|
Disassembly of section .text:
|
|
|
|
0000000000000250 <alloc_boi>:
|
|
250: 48 8d 05 1d 00 00 00 lea 0x1d(%rip),%rax # 274 <_start+0x14>
|
|
257: 48 89 44 24 f8 mov %rax,-0x8(%rsp)
|
|
25c: c3 retq
|
|
25d: 0f 1f 00 nopl (%rax)
|
|
|
|
0000000000000260 <_start>:
|
|
260: 50 push %rax
|
|
261: e8 ea ff ff ff callq 250 <alloc_boi>
|
|
266: b8 01 00 00 00 mov $0x1,%eax
|
|
26b: bb 00 00 00 00 mov $0x0,%ebx
|
|
270: cd 80 int $0x80
|
|
272: 58 pop %rax
|
|
273: c3 retq
|
|
```
|
|
The `alloc_boi` section is the interesting one:
|
|
|
|
- `%rsp` is the stack pointer, `%rbp` is apparently general purpose but is
|
|
used in this context as the "frame pointer", meaning the start of the stack
|
|
frame. This is a small optimization which allows referencing memory from a
|
|
point which is constant during the function (the frame's start) rather than
|
|
a point which changes (the stack pointer's position). This optimization can
|
|
be negated by compiling with `-fomit-frame-pointer`
|
|
|
|
- It also contains `lea 0x1d(%rip),%rax` at the top of `alloc_boi`'s
|
|
disassembly. `lea` is "load effective address". Basically puts the
|
|
calculated pointer into `%rax`. The pointer being calculated is
|
|
`0x1d(%rip)`, which is the instruction pointer + 0x12. The instruction
|
|
pointer's value is always the next instruction to be run, and in this case
|
|
is `0x257`. Adding `0x1d` to that gives `0x274`, which is the first byte in
|
|
the `.rodata` section, the start of the `Hello World` string.
|
|
|
|
- The subsequent `mov %rax,-0x8(%rsp)` is moving the pointer (stored in
|
|
`%rax`) and putting it onto the stack.
|
|
|
|
## VLA
|
|
|
|
With the following file:
|
|
|
|
```c
|
|
// main.c
|
|
void do_the_thing(int n) {
|
|
int arr[n];
|
|
for (int i=0; i<n; i++) {
|
|
arr[i] = i;
|
|
}
|
|
asm("nop; nop; nop;");
|
|
}
|
|
|
|
|
|
void _start() {
|
|
do_the_thing(10);
|
|
asm("movl $1, %eax;"
|
|
"movl $0, %ebx;"
|
|
"int $0x80;");
|
|
}
|
|
```
|
|
|
|
And compiled into LLVM IR with the following:
|
|
|
|
```
|
|
clang -nostdlib -fno-stack-protector -fomit-frame-pointer -S -emit-llvm main.c
|
|
```
|
|
|
|
We can see how llvm handles VLA. It ain't pretty, that's for sure.
|