index.md (2480B)
1 +++ 2 title = 'Dynamic Binary Instrumentation & Intel Pin' 3 +++ 4 5 # Dynamic Binary Instrumentation & Intel Pin 6 Full system emulation is powerful (full system visibility) but invasive (full system runs emulated). 7 8 Dynamic binary instrumentation (DBI) gives you binary-level visibility, and is efficient and self-contained. 9 10 Instrumentation: technique injecting code into binary to collect runtime info 11 - executes as part of normal instruction stream 12 - doesn't modify semantics of program 13 14 Instrumentation is good 15 - optimisation/profiling: instruction profiling, basic block count 16 - bug detection/exploit generation: find references to uninitialized addresses, inspect arguments at particular function call, inspect function pointers and return addresses, record & replay 17 - architectural research: processor and cache simulation, trace collection 18 19 Two classes 20 - static: instrument before runtime (source code, IR, binary) 21 - dynamic: at runtime (just in time, e.g. Pin, Valgrind, QEMU) 22 - no need to recompile or relink, discover code at runtime, handles generated code, attaches to running processes 23 - but: higher performance overhead, needs framework which malware can detect 24 25 Why binary instrumentation: 26 - libraries are a pain for source/IR instrumentation (e.g. proprietary) 27 - easily handles multilingual programs 28 - with malware you rarely get source code 29 30 ## Intel Pin ([website](http://pintool.intel.com/)) 31 DBI framework, can insert arbitrary code in arbitrary places in executable. 32 33 Can examine any type of instruction, track function calls including library and syscalls, track application threads, etc. 34 35  36 37 Instrumentation vs analysis: 38 - instrumentation routines: define where instrumentation inserted, invoked when instruction being JITted 39 - analysis routines: define what to do when instrumentation activated, invoked every time instruction is executed 40 41 Using it: 42 1. `export PIN_HOME=/path/to/pin/directory && make` 43 2. `pin -t /path/to/pin/code.so -- /path/to/binary` 44 45 Reducing Pin overhead: 46 - shift computation from analysis routines to instrumentation routines when possible 47 - instrument at largest granularity whenever possible (e.g. one call per basic block or trace) 48 - reduce number of arguments to analysis routines 49 - inline functions where possible (do `pin --log-inline` and look in pin.log) 50 51 Debugging Pin: 52 1. Run Pin with `-appdebug` 53 2. Start GDB and run `target remote :<number given by pin>` 54 3. Use GDB normally