Here you may find answers to various questions about the behavior of REVEN-Axion.
An execution produces a lot of data, most of which is written on disk. When you ask for the execution to pause, REVEN must flush its buffer first: that may take up to 30 seconds depending on the trace and on your disk bandwidth.
You can find comprehensive information about the server configuration file in the setup page. The client configuration files are located in ~/.config/tetrane/
.
The server log files are (assuming the default configuration):
/home/reven/reven_data/<project>/output/reven.log
/var/log/reven_launcher.log
The client outputs its logs on the stderr file, so you can find them in your common X session errors log file, usually located at ~/.xsession-errors
. You can also start the Axion client directly in a console, and see its logs printed there.
Yes you can! See the init script option where you can specify the load init script. You can copy this script somewhere, edit it to your liking, and configure Axion to load it at startup.
They actually are sorted chronologically, as expected. But their names include the parent run's sequence number where this run has started; in the case of nested runs, you could have something like this:
Execution run #3186 PageFault #21 Nested PageFault #5445 Another PageFault ...
Displaying this indentation would be impractical, so it may look as if runs are unsorted. We intend to rework on how we display this information in the future.
The case of lsl
is special: this instruction is partially implemented but still triggers a warning.
There are a few other CPU instructions that REVEN does not handle yet. Those instructions are ignored but raise warnings, and depending on the program this may cause a out of sync error later.
If you have this error with an other instruction than lsl
, please contact the support team. We will certainly implement it in a future revision.
Sometimes symbols are deduced from the pdb-like files, which also contains information about the arguments. In this case, you will see the arguments and their content in the trace view.
Although when symbols are o deduced from the binary, REVEN doens't have enough information to help you further.
The LEA instruction does not dereference the given pointer. In fact if the address was to be completely invalid, the instruction would still work.
Let's take the following example:
lea eax, [ebp+edx*4+0x7]
Selecting the second operand will select ebp. This is an arbitrary decision here. This LEA is a shortcut for something like:
mov eax, edx shl eax, 2 add eax, ebp add eax, 0x7
If we were selecting the pointer instead of the register that gives the pointer, a use of the "previous" or "next" feature would lead to the previous or next use of the pointer, which is not necessarily related to this context. Maybe the pointer in question will never be accessed in the whole program. In this case, the shown LEA would just be a more compact way to compute a value.
It is a known bug, sorry about that. It happens when REVEN reaches code which hasn't been explicitely called, and knows neither the binary name nor the symbol name.
When REVEN does not recognize a symbol, it generates an anonymous name for further reference in this form.
If you think you should have more symbols, perhaps you should check the configured pdb_path contains the files you need (you can generate them).
The tainter widget gives limited information when it is waiting for an anwser from the server. This may be confusing, especially if other projects are being executed on the same server, slowing it down a lot. We are working on that.
If you have a problem, you should always first check that:
REVEN's execution is heavily dependent on the server's specifications. Using various unix tools on the server (htop
, iotop
, etc.) you can look for the bottleneck:
See also scenario tips for tips on how to make your scenario smaller, if possible.
First of all, make sure the VM you produced your scenario with does not have Virtual Box's Guest Additions enabled. These implement custom emulated hardware that we do not support for now, and are bound to desync quickly. If your VM has them enabled, you will have to deinstall them, restart the VM and re-record your scenario from scratch.
If not, then REVEN's CPU has diverged from the reference execution recorded in the scenario, and stopped because it can no longer produce relevant results. This is current limitation of REVEN, and will certainly happen from time to time, especially if you let REVEN work for more than a few days.
You still have a chance at producing a usable output. The point where the desync happened is not necessarily where the problem appeared, so you should always try taking the following mitigations steps:
You have hit a bug. Make sure you follow the basic checks. If it's not enough and if you know how to reproduce this behavior, please contact the support team to let us know. The bug may have appeared on the client's side or on the server's side:
killall -9 axion
) first, and then reconnect to your project. If this works, no work has been lost.Your project is frozen, you have hit a bug. Make sure you follow the basic checks. If it's not enough and if you know how to reproduce this behavior, please contact the support team to let us know.
For the moment you have no other choice but to manually kill the frozen process:
ps aux | grep reven
, list the reven processes and note the pid corresponding to your project's port.If it's not yet enough, you have to restart the REVEN daemon, but understand that this will force close all opened projects on the server. Make sure you take the appropriate steps before going this far.
There is a whole page dedicated to scenario creation, with a specific troubleshooting section.
This is a server configuration problem. If you recently created a new user, make sure its directory and all its children are owned by the reven
user.