Here you may find answers to various questions about the behavior of REVEN-Axion. If you think you hit a bug, please read the list of known issues for your version in the Change Log
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 setting 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.
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. For example, you will often see this error message in Windows crash handler code (during a BSOD)
If one of these errors prevents you from working, 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.
When REVEN does not find any information about a symbol, it has two options: it will either display something like my_binary_<logical_address>
(if there is no information about the beginning about the symbol) or create an unnamed symbol such as func_<rva>
.
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.
This is a known bug, probably related to the way Qt5 handles Apple keyboards. Unfortunately, we don't have a workaround for now except using the upper-row digit keys. If you see this problem on a non-Apple hardware, please contact the support.
We have seen configurations where shortcuts don't all work: some are caught by the Window Manager and never make it to the Axion app, some are caught before entering the Axion VM (if one is used). If you're not on Apple hardware (which, as seen above, can lead to another kind of issues), please try to make sure your Window Manager doesn't silently catch the shortcuts in question.
This is a known problem if your system's keyboard layout isn't US qwerty. A quick workaround for this issue is to edit your VNC program and surround the current value with calls to setxkbmap
: you will set the keyboard layout to us first, call the vnc program, then to restore it. This could be something like setxkbmap us; echo p | xtightvncviewer -autopass h::n; setxkbmap fr
This is a known bug. It is actually either RDRAND
or RDSEED
, which are not disassembled correctly. These instructions are declared as unavailable but programs can still make blind use of them, which will likely cause a desynchronisation.
Linux in particular is a known offender. You can still forbid it from using it:
nordrand
in the option field GRUB_CMDLINE_LINUX
of the file /etc/default/grub
sudo update-grub
to rebuild the grub configuration