Closed lprat closed 3 years ago
From looking at the output, it looks like the top option on the list:
Memory smear during acquisition (try re-acquiring if possible)
It's returned what look to be a number of valid results, and then points off to somewhere that isn't mapped, and volatility couldn't then read further entries in the list. This is expected behaviour when volatility encounters an address that isn't readable (in the develop branch we've moved the python code telling us where the problem is, so that it's only exposed with at least on -v
flag).
If this memory used to work in volatility3, or you've acquired memory multiple times and always get the same result, then please feel free to reopen this issue, but it's unlikely we'll be able to change the outcome I'm afraid. 5:(
(The commands that you mentioned didn't work require the yara-python package to be installed)
The vadtree issue looks more like a separate issue, please could you file a separate issue to discuss it? Otherwise it keeps information about both bugs around even when only one might be necessary.
From looking at the output, it looks like the top option on the list:
Memory smear during acquisition (try re-acquiring if possible)
It's returned what look to be a number of valid results, and then points off to somewhere that isn't mapped, and volatility couldn't then read further entries in the list. This is expected behaviour when volatility encounters an address that isn't readable (in the develop branch we've moved the python code telling us where the problem is, so that it's only exposed with at least on
-v
flag).If this memory used to work in volatility3, or you've acquired memory multiple times and always get the same result, then please feel free to reopen this issue, but it's unlikely we'll be able to change the outcome I'm afraid. 5:(
(The commands that you mentioned didn't work require the yara-python package to be installed)
Is it possible to do "try" on "volatility3/volatility3/framework/renderers/init.py", line 211 to avoid to stop analyze on error (just pass the address isn't readable) ?
We made a conscious decision to very clearly indicate when an error has occurred so that users are aware something has gone wrong (otherwise, as with volatility 2 which simply consumed errors without feedback) it's impossible to tell the difference between one that ran fine and one that didn't return complete results.
We have added the fail_on_errors
options to TreeRenderers, so that other user interfaces can decide whether to continue accumulating results or not:
Within the official CLI we've made the decision that results after a known issue are likely questionable and as a forensics tool we need to make certain the user is aware of this. We may in the future alter how this operates, but for now this seemed the best way of ensuring that anyone using the results of the tool knew that an issue had occurred.
Describe the bug
Context Volatility Version: git current master (today) Operating System: Docker Debian 10 Python Version: Python 3.7.3 Suspected Operating System: Win 2012 R2 Command: windows.pslist (bug on some command: vadinfo, malfind, VadYaraScan)
temporary solution Is it possible to do "try" on "volatility3/volatility3/framework/renderers/init.py", line 211 to avoid to stop analyze on error, in wait to fix the real problem?