search

volatilityfoundation / volatility3

Volatility 3.0 development
http://volatilityfoundation.org/
Other
2.61k stars 447 forks source link

Does Volatility support the Encase EX file format? #560

Open KevinK24 opened 3 years ago

KevinK24 commented 3 years ago

Hello, I'm sorry if this isn't the appropriate place - I couldn't find anywhere else that seemed appropriate. Two use questions

  1. I've placed my symbols table under symbols\linux\symbols.json - (generated by dwarf2json) - but I'm unable to find any documentation on the proper naming convention. Is it just .json? .json.xz? ntsomethingsomething.json?
  2. Are Encase EX files supported? I'm trying to support my internal DF team but getting errors of
    • Warning volatility3.framework.plugins: automagic exception occured: +lzma.LZMAError: Input format not supported by decoder
    • Unsatisfied Requirement plugins.PsList.primary: Memory layer for the kernel
    • Unsatisfied Requirement plugins.PsList.vmlinux: Linux kernel symbols Thank you
ikelos commented 3 years ago

Hiya @KevinK24

If the file isn't compressed, .json will work, if it's xz compressed, then it needs to be .json.xz. For linux files, the file name isn't important, but windows the JSON files have a specific name. There is some documentation about the naming conventions at https://volatility3.readthedocs.io/en/latest/symbol-tables.html#how-volatility-finds-symbol-tables

You can check whether volatility has correctly identified the JSON file, by locating it with the output of isfinfo. If you can't find the file in there, then it hasn't been detected. That will also tell you the banner that it's found, and that banner must match exactly with the image you're expecting it to be used on. If the banner isn't present then the JSON file wasn't generated correctly, and if it is but doesn't match the kernel of the image, then it also won't work (you can check if it did find it by using -vvv when running vol.py. If it doesn't say that it matched a banner (and tell you the banner) then the two didn't match.

As to the Encase file format, I'm afraid we don't have a handler for that file format. it sounds as though it's got a header that looks like an LZ compression, and so the mime-type attempts to decompress it, but even if it has decompressed, we wouldn't be able to read the data inside it appropriately.

Since I've answered the first question, I'm going to retitle the issue as an enhancement request for Encase EX support. We'll leave this open so we don't forget that someone wants it (and so that others can potentially work on it). I'm afraid I don't know where encase support fits into our priorities, but without samples it's going to be less likely to get done soon I'm afraid...

KevinK24 commented 3 years ago

Hey no worries at all. I really (super) appreciate the great answer.

iMHLv2 commented 3 years ago

@KevinK24 Most acquisition tools that output proprietary formats can either optionally be asked to output raw instead, or they support converting from their custom format to raw after the capture. In that case, you could just work that extra step into your pipeline and analyze the raw sample with Volatility. You might also recommend Surge to your DF team, which outputs in a format natively supported by Volatility, so that will save a lot of time and headache right off the bat.