diff options
Diffstat (limited to 'src/development')
| -rw-r--r-- | src/development/README.md | 1 | ||||
| -rw-r--r-- | src/development/c++.md | 12 | ||||
| -rw-r--r-- | src/development/c++filt.md | 12 | ||||
| -rw-r--r-- | src/development/gcc.md | 58 | ||||
| -rw-r--r-- | src/development/glibc.md | 47 | ||||
| -rw-r--r-- | src/development/ld.so.md | 130 |
6 files changed, 260 insertions, 0 deletions
diff --git a/src/development/README.md b/src/development/README.md new file mode 100644 index 0000000..459110d --- /dev/null +++ b/src/development/README.md @@ -0,0 +1 @@ +# Development diff --git a/src/development/c++.md b/src/development/c++.md new file mode 100644 index 0000000..d9fbbda --- /dev/null +++ b/src/development/c++.md @@ -0,0 +1,12 @@ +# c++ + +## Type deduction + +Force compile error to see what `auto` is deduced to. +```cpp +auto foo = bar(); + +// force compile error +typename decltype(foo)::_; +``` + diff --git a/src/development/c++filt.md b/src/development/c++filt.md new file mode 100644 index 0000000..2592ba9 --- /dev/null +++ b/src/development/c++filt.md @@ -0,0 +1,12 @@ +# c++filt(1) + +## Demangle symbol +```markdown + c++-filt <symbol_str> +``` + +## Demangle stream +For example dynamic symbol table: +```markdown + readelf -W --dyn-syms <elf> | c++filt +``` diff --git a/src/development/gcc.md b/src/development/gcc.md new file mode 100644 index 0000000..1381242 --- /dev/null +++ b/src/development/gcc.md @@ -0,0 +1,58 @@ +# gcc(1) + +## CLI + +### Preprocessing +While debugging can be helpful to just pre-process files. + +```bash +gcc -E [-dM] ... +``` +- `-E` run only preprocessor +- `-dM` list only `#define` statements + +## [Builtins][builtins] + +### `__builtin_expect(expr, cond)` +Give the compiler a hint which branch is hot, so it can lay out the code +accordingly to reduce number of jump instructions. +See on [compiler explorer](https://godbolt.org/z/MbTHAP). + +```bash +echo " +extern void foo(); +extern void bar(); +void run0(int x) { + if (__builtin_expect(x,0)) { foo(); } + else { bar(); } +} +void run1(int x) { + if (__builtin_expect(x,1)) { foo(); } + else { bar(); } +} +" | gcc -O2 -S -masm=intel -o /dev/stdout -xc - +``` + +Will generate something similar to the following. +- `run0`: `bar` is on the path without branch +- `run1`: `foo` is on the path without branch +```c +run0: + test edi, edi + jne .L4 + xor eax, eax + jmp bar +.L4: + xor eax, eax + jmp foo +run1: + test edi, edi + je .L6 + xor eax, eax + jmp foo +.L6: + xor eax, eax + jmp bar +``` + +[builtins]: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html diff --git a/src/development/glibc.md b/src/development/glibc.md new file mode 100644 index 0000000..2b2ab34 --- /dev/null +++ b/src/development/glibc.md @@ -0,0 +1,47 @@ +# glibc + +## malloc tracer [`mtrace(3)`][mtrace] +Trace memory allocation and de-allocation to detect memory leaks. +Need to call `mtrace(3)` to install the tracing hooks. + +If we can't modify the binary to call `mtrace` we can create a small shared +library and pre-load it. +```c +// libmtrace.c +#include <mcheck.h> +__attribute__((constructor)) static void init_mtrace() { mtrace(); } +``` + +Compile as: +```bash +gcc -shared -fPIC -o libmtrace.so libmtrace.c +``` + +To generate the trace file run: +```bash +export MALLOC_TRACE=<file> +LD_PRELOAD=./libmtrace.so <binary> +``` +**Note**: If `MALLOC_TRACE` is not set `mtrace` won't install tracing hooks. + +To get the results of the trace file: +```bash +mtrace <binary> $MALLOC_TRACE +``` + +## malloc check [`mallopt(3)`][mallopt] +Configure action when glibc detects memory error. + +```bash +export MALLOC_CHECK_=<N> +``` + +Useful values: +```markdown +1 print detailed error & continue +3 print detailed error + stack trace + memory mappings & abort +7 print simple error message + stack trace + memory mappings & abort +``` + +[mtrace]: http://man7.org/linux/man-pages/man3/mtrace.3.html +[mallopt]: http://man7.org/linux/man-pages/man3/mallopt.3.html diff --git a/src/development/ld.so.md b/src/development/ld.so.md new file mode 100644 index 0000000..311d1be --- /dev/null +++ b/src/development/ld.so.md @@ -0,0 +1,130 @@ +# ld.so(8) + +## Environment Variables +```console + LD_PRELOAD=<l_so> colon separated list of libso's to be pre loaded + LD_DEBUG=<opts> comma separated list of debug options + =help list available options + =libs show library search path + =files processing of input files + =symbols show search path for symbol lookup + =bindings show against which definition a symbol is bound +``` + +## LD_PRELOAD: Initialization Order and Link Map +Libraries specified in `LD_PRELOAD` are loaded from `left-to-right` but +initialized from `right-to-left`. + +```markdown + > ldd ./main + >> libc.so.6 => /usr/lib/libc.so.6 + + > LD_PRELOAD=liba.so:libb.so ./main + --> + preloaded in this order + <-- + initialized in this order +``` + +The preload order determines: +- the order libraries are inserted into the `link map` +- the initialization order for libraries + +For the example listed above the resulting `link map` will look like the +following: + +```makrdown + +------+ +------+ +------+ +------+ + | main | -> | liba | -> | libb | -> | libc | + +------+ +------+ +------+ +------+ +``` + +This can be seen when running with `LD_DEBUG=files`: + +```makrdown + > LD_DEBUG=files LD_PRELOAD=liba.so:libb.so ./main + # load order (-> determines link map) + >> file=liba.so [0]; generating link map + >> file=libb.so [0]; generating link map + >> file=libc.so.6 [0]; generating link map + + # init order + >> calling init: /usr/lib/libc.so.6 + >> calling init: <path>/libb.so + >> calling init: <path>/liba.so + >> initialize program: ./main +``` + +To verify the `link map` order we let `ld.so` resolve the `memcpy(3)` libc +symbol (used in _main_) dynamically, while enabling `LD_DEBUG=symbols,bindings` +to see the resolving in action. + +```makrdown + > LD_DEBUG=symbols,bindings LD_PRELOAD=liba.so:libb.so ./main + >> symbol=memcpy; lookup in file=./main [0] + >> symbol=memcpy; lookup in file=<path>/liba.so [0] + >> symbol=memcpy; lookup in file=<path>/libb.so [0] + >> symbol=memcpy; lookup in file=/usr/lib/libc.so.6 [0] + >> binding file ./main [0] to /usr/lib/libc.so.6 [0]: normal symbol `memcpy' [GLIBC_2.14] +``` + +## Dynamic Linking (x86_64) +Dynamic linking basically works via one indirect jump. It uses a combination of +function trampolines (`.plt` section) and a function pointer table (`.got.plt` +section). +On the first call the trampoline sets up some metadata and then jumps to the +`ld.so` runtime resolve function, which in turn patches the table with the +correct function pointer. +```makrdown + .plt ....... procedure linkage table, contains function trampolines, usually + located in code segment (rx permission) + .got.plt ... global offset table for .plt, holds the function pointer table +``` + +Using `radare2` we can analyze this in more detail: + +```makrdown + [0x00401040]> pd 4 @ section..got.plt + ;-- section..got.plt: + ;-- .got.plt: ; [22] -rw- section size 32 named .got.plt + ;-- _GLOBAL_OFFSET_TABLE_: + [0] 0x00404000 .qword 0x0000000000403e10 ; section..dynamic + [1] 0x00404008 .qword 0x0000000000000000 + ; CODE XREF from section..plt @ +0x6 + [2] 0x00404010 .qword 0x0000000000000000 + ;-- reloc.puts: + ; CODE XREF from sym.imp.puts @ 0x401030 + [3] 0x00404018 .qword 0x0000000000401036 ; RELOC 64 puts + + [0x00401040]> pd 6 @ section..plt + ;-- section..plt: + ;-- .plt: ; [12] -r-x section size 32 named .plt + ┌─> 0x00401020 ff35e22f0000 push qword [0x00404008] + ╎ 0x00401026 ff25e42f0000 jmp qword [0x00404010] + ╎ 0x0040102c 0f1f4000 nop dword [rax] + ┌ 6: int sym.imp.puts (const char *s); + └ ╎ 0x00401030 ff25e22f0000 jmp qword [reloc.puts] + ╎ 0x00401036 6800000000 push 0 + └─< 0x0040103b e9e0ffffff jmp sym..plt +``` + +- At address `0x00401030` in the `.plt` section we see the indirect jump for + `puts` using the function pointer in `_GLOBAL_OFFSET_TABLE_[3] (GOT)`. +- `GOT[3]` initially points to instruction after the `puts` trampoline + `0x00401036`. +- This pushes the relocation index `0` and then jumps to the first trampoline + `0x00401020`. +- The first trampoline jumps to `GOT[2]` which will be filled at program + startup by the `ld.so` with its resolve function. +- The `ld.so` resolve function fixes the relocation referenced by the + relocation index pushed by the `puts` trampoline. +- The relocation entry at index `0` tells the resolve function which symbol to + search for and where to put the function pointer: + ```makrdown + > readelf -r <main> + >> Relocation section '.rela.plt' at offset 0x4b8 contains 1 entry: + >> Offset Info Type Sym. Value Sym. Name + Addend + >> 000000404018 000200000007 R_X86_64_JUMP_SLO 0000000000000000 puts@GLIBC_2.2.5 + 0 + ``` + As we can see the offset from relocation at index `0` points to `GOT[3]`. + |