tenet: Trace Explorer for Reverse Engineers
Tenet – A Trace Explorer for Reverse Engineers
Tenet is an IDA Pro plugin for exploring execution traces. The goal of this plugin is to provide more natural, human controls for navigating execution traces against a given binary. The basis of this work stems from the desire to research new or innovative methods to examine and distill complex execution patterns in software.
For more context about this project, please read the blogpost about its initial release.
Q: How do I record an execution trace using Tenet?
- A: Tenet is a trace reader, not a trace recorder. You will have to use dynamic binary instrumentation frameworks (or other related technologies) to generate a compatible execution trace. Please refer to the tracing readme for more information on existing tracers, or how to implement your own.
Q: What trace architectures does Tenet support loading?
- A: Only x86 and AMD64, but the codebase is almost entirely architecture agnostic.
Q: How big of a trace file can Tenet load / navigate?
- A: Tenet’s trace reader is pure python, it was written as an MVP. There is no guarantee that traces which exceed 10 million instructions will be reasonable to navigate until a native backend replaces it.
Q: I loaded an execution trace, now there is a ‘.tt’ file. What is it?
- A: When Tenet loads a given text trace, it will parse, index, and compress the trace into a more performant format. On subsequent loads, Tenet will attempt to load the ‘.tt’ file which should load in a fraction of the time that it would take to load the original text trace.
Q: The plugin crashed/threw an error / is showing bad trace information, what should I do?
- A: If you encounter an issue or inaccuracy that can be reproduced, please file an issue against this repository and upload a sample trace + executable.
Q: Memory in my trace is changing, but there are no writes to the region. Is this a bug!?
- A: Your log file may not have captured all memory writes. For example, usermode DBI generally do not get a memory callback for external writes to process memory. This is most common when reading from a file, or from socket — it is the kernel that writes memory into your designated usermode buffer, making the event invisible to traditional instrumentation.
- Microsoft TTD generally exhibits the same behavior, it’s tricky to solve without modeling syscalls.
Q: Will this be ported to Binary Ninja / Ghidra / …?
- A: Possibly, but not anytime soon (unless there is a significant incentive). As a research-oriented project, the driving motivation is on developing novel strategies to organize and explore program execution — not porting them.
Q: My organization would like to support this project, how can we help?
- A: Without funding, the time I can devote to this project is limited. If your organization is excited by the ideas put forth here and capable of providing capital to sponsor dedicated R&D, please contact us.
Copyright (c) 2021 Markus Gaasedelen