Pinpoint is a versatile pintool for finding bugs in x86-programs when a traditional debugger is useless, e.g., when the programs contain int3 instructions or other incompatible features.
Its features can be enabled on demand.
The analysis tool has been tested with Intel Pin 4.0.
We assume that there is a PIN_ROOT environment variable that points to Pin's base directory. This can be done per session with export PIN_ROOT=/path/to/pin.
The pintool can be compiled by running ./compile.sh.
An analysis can be started with ./analyze.sh <main binary> <output file>, e.g., ./analyze.sh /bin/ls test.out.
Configuration options for enabling features of the pintool are the following:
-o <path> Output file path (default: out)
-f <list> Functions to track (semicolon-separated, default: not specified)
-skip <n> Number of instructions to skip (default: 0)
-print_ins {0|1} Print executed instructions (default: 1)
-count_opcodes {0|1} Count executed opcodes (default: 0)
-print_memwrites {0|1} Print memory writes (default: 1)
-print_regwrites {0|1} Print register writes (default: 1)
-print_syscalls {0|1} Print system calls (default: 0)
-print_args {0|1} Print function argument registers (default: 0)
-indent {0|1|2} Indentation mode:
0 = none
1 = spaces
2 = tabs
(default: 1)
Further information can be found in the documentation of options.
For further information on how to debug implementations in settings where traditional debuggers fail, we refer to the talk "Debugging the Un-Debuggable: Advanced Debugging Techniques for Microarchitectural Security Tooling" (2nd Microarchitecture Security Conference (uASC '26)) and the talk's extended abstract.
For cases where the traces from the pintool are not giving all necessary information, or when the data volume is too high, we also provide a hack based on strace in the docs.
When building instrumentation-based mitigations against several side-channel leakages, either some original functionality must be preserved or the instrumented program should produce certain outputs or behavior. To test such conformance, the traces produced by pinpoint can be a good starting point. Further information can be found in the docs.
During the implementation of software-based side-channel mitigations, not only the conformance is part of the expected result: The instrumented program should also be free from leakages, i.e., no secret inputs should have an observable influence on the output (non-interference). Examples of how to assess the leakages of certain side-channel mitigations can be found in the docs.
Contributions are appreciated! Feel free to submit issues and pull requests.
The project is licensed under the MIT license. For further information refer to the LICENSE file.