Table of Contents
REVEN-Axion's goal is to allow its users to fully inspect a machine in a read-only fashion, down to the CPU level, at any point in time, regardless of any physical or logical limitation of the architecture, in a way that does not alter the machine's state or its execution flow.
Doing so on a live system the way a debugger would is not possible: the user's actions would have a significant impact on the machine's execution, even in user-land.
Therefore, we've developed the REVEN technology, and the Axion tool on top of it to fulfil that goal.
What REVEN does
REVEN-Axion first requires its user to record a scenario: the user will spawn a virtual machine of his choice and create a situation relevant to his interests which he will record: this is the scenario. The latter cannot be too long for the moment (a few seconds), but can contain various interactions: keyboard, network, pci accesses will all be recorded.
REVEN-Axion can then play this scenario back at its own pace. This phase is the execution, for which the user can select inspectors that will aggregate data about what is happening. This process can take a few hours up to a few days, depending on the length of the scenario, because REVEN is actually replaying the scenario on its own symbolic CPU.
Then, once this execution is complete, the user can access the resulting execution trace along with the aggregated data and start working: the entire trace consists of each and every instruction that has been executed by the virtual machine during the scenario, along with the state of the CPU registers and the virtual machine's RAM at every instruction.
What you can do with Axion
Once you have configured a set of virtual machines you want to use, we provide the means to create the scenarios: Axion can automatically upload and launch the binary you want on a selected VM; if your test case is more complicated than simply starting a binary, Axion can give you more precise handles on where and how to start recording the scenario.
We provide a dedicated GUI which will enable the user to work on the execution trace by hand, along with various tools: search, data tainting, memory history, etc.
We also provide a Python API that enables the user to automate his tasks. Almost anything that is accessible through the GUI is also available through this API.
Current limitations
REVEN is a complicated technology and is always in development. As such, it still has limitations which we are working on:
First, the user must carefully plan its scenarios and reduce its cases to the most interesting parts only, because a scenario can only be a few seconds long at most. The symbolic execution is quite complex, so executions could take tens of hours and generate hundreds of gygabytes of data if the scenario is too long. Note that given the level of detail which is provided, a few seconds is often more than enough.
Second, the symbolic CPU's output must very precisely match that of the real CPU. If that were not the case, the execution would diverge from the original scenario, rendering the trace meaningless. When such a divergence occurs, the execution gracefully stops and let the user work on what has already been processed.