Open typeryougishiki opened 3 months ago
Unfortunately it depends on the requirements of the plugin (whether it has a ModuleRequirement
or just a TranslationLayerRequirement
and a SymbolTableRequiement
and what plugin you used to generated the saved config. If it was the same plugin then the same config should have worked appropriately. Please could you attach the config file you used so we can check if there's anything unusual in there?
The config supplements volatility's automagic, so that if the additional information doesn't help, it'll fall back to doing the scans itself. As far as I was aware, this had all been working, but it's possible a recent change broke this or there's some other reason why it can't skip past the scan...
When I use linux.iomem to analyze 66.local.lime, the content of the generated config file is as follows:
{ "kernel.layer_name.class": "volatility3.framework.layers.intel.Intel32e", "kernel.layer_name.kernel_banner": "Linux version 3.10.0-1160.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020\n\u0000", "kernel.layer_name.kernel_virtual_offset": 763363328, "kernel.layer_name.memory_layer.base_layer.class": "volatility3.framework.layers.physical.FileLayer", "kernel.layer_name.memory_layer.base_layer.location": "file:///D:/66.local.lime", "kernel.layer_name.memory_layer.class": "volatility3.framework.layers.lime.LimeLayer", "kernel.layer_name.page_map_offset": 9663741952, "kernel.offset": 763363328, "kernel.symbol_table_name.class": "volatility3.framework.symbols.linux.LinuxKernelIntermedSymbols", "kernel.symbol_table_name.isf_url": "file:///C:/Users/typer/work/volatility3-2.5.2/volatility3/symbols/linux/kernel-3.10.0-1160.el7.x86_64.json", "kernel.symbol_table_name.symbol_mask": 281474976710655 }
@ikelos
@ikelos Are you still following this issue?
Sorry, I haven't had much time to devote to volatility recently, but I am still following it yes. That configuration is using the ModuleRequirement
so should be picking everything up and rebuilding it properly. I'll check the LinuxIntelStacker
to make sure it's trying to get the value from the config rather than scanning it all the time. It may take me a little while I'm afraid. Do feel free to keep prodding here if it takes me too long though....
When scanning a 24G windows lime memeory file,I can use --save-config option to create config file . The next time I scan this memory file, I can use the -c option set saved config to skip the Scanning memory_layer step.
But when scanning a 16G Linux lime memory file, I followed the same steps and could not skip the Scanning LimeLayer step.
Save config command:
python C:\Users\typer\work\volatility3-develop\vol.py -vvvv --save-config C:\Users\typer\temp\66.conf -f D:\66.raw linux.iomem
-c set config file command:
python C:\Users\typer\work\volatility3-develop\vol.py -vvvv -c C:\Users\typer\temp\66.conf -f D:\66.raw linux.iomem
output before start Scanning LimeLayer:
Is this the normal behavior of volatility3? Or did I do something wrong?