volatility3
volatility3 copied to clipboard
linux.pslist returns no results
Volatily 3 is not able to find plugins I made a memory dump with Lime in raw format, and i wanted to process it with Volatility3. I have installed all dependencies even the optional dependencies.
Context
Volatility Version: Volatility 3 Framework 2.0.0 Beta
Operating System: Debian Testign
Python Version: 3.9.1
Kernel Version: 5.9.0.5-amd64
Command: python3 vol.py -vvvv -s symbols/ --file /linux.mem linux.bash.Bash
To Reproduce
1- Run a python3 setup.py install
2- Generate JSON file with dwarf2json linux --elf /usr/lib/debug/boot/vmlinux-5.9.0.5-amd64 > output.json
Expected behavior Volatility3 shoud find the plugins
Command output
https://pastebin.com/vdW3s7Ar
So this has nothing to with the plugins. It clearly says that it can't determine the information it needs to load the layer (and therefore can't find the symbols it might need). When using dwarf2json you should also use the System.map, because the debugging kernel may not contain all the necessary symbols. You can then also check that the symbols you've created (output.json) live in the volatility/symbols/linux directory, and show up in the output of the isfinfo plugin (this can take a long time to run if you have lots of symbol files). Once it's in there, you should see which banner it's looking for, and you can then run the banners plugin against your image and see if any of the banners it finds match the ones in the ISF file. Please report back the results of these steps, and if you're still experiencing difficulty after that... 5:)
Hi, tanks a lot for your fast answer, i uncompressed the linux.zip file, and commpresed the folder linux with output.json in order to generate another linux.zip file. Also, i have installed jsonschema beacuse it's another dependency.
Here you are the logs: https://pastebin.com/681Jv8yW
Ok, it looks like the symbol file is loaded correctly. Now you have to check your memory image to make sure that the banner (Linux version 5.9.0-5-amd64 ([email protected]) (gcc-10 (Debian 10.2.1-1) 10.2.1 20201207, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.15-1 (2020-12-17)) appears exactly within the memory image, otherwise volatility won't decide to use it. I'd recommend trying the banners plugin to see if volatility can find anything similar within the image. Please remember, it must match exactly for volatility to make use of it...
Hi again, i have tried to run the banner plugin, but i am too confused, i will generate another memory dump with Lime using the current Kernel, here you are the logs. https://pastebin.com/ZqJePSPD
Well, the output from banners matches the output.json file you made, so it should be finding that within the memory image? I'm not sure how to debug this further without a copy of the memory image?
Okey, can I send you an email with the memory dump throug gdrive or wetransfer?
Hiya, you can share it via gdrive with [email protected] and I'll pick it up. I can let you know once I've got it...
Thanks I can confirm I've got it. I'll try to find some time to look at it in the next couple of week...
Hiya, I've managed to take a look into this, but I'm having difficulty tracking down the packages needed for this kernel. I found one with a matching kernel, but it was built with a different compiler for backports. Ever jiggering the banner constant_data didn't allow it to output any data (which is likely due to a system.map that doesn't match the system we're analyzing. Would you be able to provide the JSON file you said that you generated from the original linux-kernel-dbg package please?
Yes of course!
I have the same problem, is there a further solution?
python3 vol.py -vvvv -s volatility3/framework/symbols/linux/ isfinfo

python3 vol.py -vvvv -f cyq.vmem banners

python3 vol.py -vvvv -f cyq.vmem linux.bash.Bash

python3 vol.py -vvvv -c /pentest/volatility3/volatility3/framework/symbols/linux/Ubuntu1804.json -f cyq.vmem linux.bash.Bash

python3 vol.py -vvvv -s volatility3/framework/symbols/linux/ -f cyq.vmem linux.bash.Bash

Thanks for the additional information @No-Github. It looks as though despite the banner and the isfinfo both being in place, volatility isn't finding the isf's banner in the memory image. It's not clear why that is, but it should report whenever it finds a banner it knows about, so that's the area to target.
In your third screenshot the -c command is used for a save configuration, but you also suggested that isfinfo already found the JSON file, so there shouldn't be a need to provide it again (and if you did, you'd use -s to specify an additional symbols directory, rather than a -c to specify plugin configuration options.
Lastly whilst the screenshots are compact, they're also squashed up and so can be difficult to read. At the moment, it looks like the banners output and the isfinfo output match exactly, but even a slight difference may mean that we get the results we're seeing.
I'll try and get on this at some point, but I haven't found the time yet I'm afraid...
Just as an update to this, we've now got an image whose banner gets detected, but pslist doesn't provide any output and doesn't indicate that the profile is bad in any way, so that's what we're gonna look into next... 5:)
@ikelos I think I'm having a similar issue.
Output from banners on memory dump: Linux version 4.19.0-14-amd64 ([email protected]) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.171-2 (2021-01-30)
Output from isfInfo: file:///home/
Not sure its exactly what @No-Github is experiencing but just thought I'd share. I was able to build a functioning profile in Vol2 for this memory dump. If that matters I'm not sure.
I think someone else on the community slack has run into this issue. Here's the lines that look relevant from the output:
# python3 vol.py -vvvv -f /tmp/dump.mem linux.bash.Bash
Volatility 3 Framework 1.0.1
INFO volatility3.framework.automagic: Detected a linux category plugin
INFO volatility3.framework.automagic: Running automagic: ConstructionMagic
...
Level 8 volatility3.framework.automagic.stacker: Attempting to stack using LinuxIntelStacker
DEBUG volatility3.framework.automagic.linux: Identified banner: b'Linux version 3.10.0-957.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Thu Oct 4 20:48:51 UTC 2018\n\x00'
...
DEBUG volatility3.framework.symbols: Unresolved reference: LintelStacker1!...
DEBUG volatility3.framework.automagic.linux: Linux ASLR shift values determined: physical 71000000 virtual 22c00000
DEBUG volatility3.framework.automagic.linux: DTB was found at: 0x72c10000
Level 8 volatility3.framework.automagic.stacker: Stacked IntelLayer using LinuxIntelStacker
...
DEBUG volatility3.framework.automagic.stacker: Stacked layers: ['IntelLayer', 'LimeLayer', 'FileLayer']
INFO volatility3.framework.automagic: Running automagic: LinuxSymbolFinder
Level 9 volatility3.framework.configuration.requirements: Symbol table requirement not yet fulfilled: plugins.Bash.vmlinux
DEBUG volatility3.framework.automagic.symbol_finder: Identified banner: b'Linux version 3.10.0-957.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Thu Oct 4 20:48:51 UTC 2018\n\x00'
DEBUG volatility3.framework.automagic.symbol_finder: Using symbol library: file:///tmp/volatility3/volatility3/symbols/linux/3.10.0-957.el7.x86_64.json.xz
DEBUG volatility3.framework.symbols: Unresolved reference: vmlinux1!...
DEBUG volatility3.framework.automagic.linux: Linux ASLR shift values determined: physical -fffe4f000000 virtual 22c00000
I can't tell whether the negative physical offset is important at this point or not?
@atcuno @ikelos Hi, any news?
@atcuno Have you had any time to investigate this?
@ikelos do you have a sample still that exhibits this behaviour?
Yep, I've got the sample we were originally sent.
Just want to add to this, that I am having the same problem as above. I have a symbol.json which shows the exact same banner as the isfinfo command.
Do you guys have an ETA on a fix?
I'm afraid not @oxnan, we don't know for certain what's causing the problem. I'd imagine that the ISF files aren't accurate for some reason. The one sample we had I wasn't able to find a suitable debug kernel for it, so it's still not clear if it's just a mismatch or something deeper...
I was looking at it a lot as well, but i have been unable to find the root cause :/
Hopefully you find the solution soon
My problem might be unrelated tho, as I am getting the following errors in my logs:
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel.layer_name
Level 9 volatility3.framework.configuration.requirements: TypeError - Layer is not the required Architecture: QemuSuspendLayer
Level 9 volatility3.framework.configuration.requirements: TypeError - Layer is not the required Architecture: FileLayer
DEBUG volatility3.framework.automagic.stacker: Stacked layers: ['QemuSuspendLayer', 'FileLayer']
INFO volatility3.framework.automagic: Running automagic: LinuxSymbolFinder
Level 9 volatility3.framework.configuration.requirements: Symbol table requirement not yet fulfilled: plugins.Bash.kernel.symbol_table_name
@oxnan it looks as though your version isn't able to find an appropriate ISF JSON file for the image you're running against. That is a different issue, and I'd recommend reading through here or searching here to find a solution.
Already made 2 custom ISF jsons using dwarf2json, both one with the system.map and one without. Both are in a folder that is loaded in with the -s parameter. Both using the debug kernel. They are showing up in the isfinfo command, but not being run against it. I thought it might be because of the qemu format, but seem like it should be supported
It should, and I'm surprised they haven't worked. I don't think the Qemu layer is relevant, but you can always eliminate it from the equation using the layerwriter. Also, you should only put one or the other of the ISF files in the directory, otherwise the automagic always chooses the first one it comes across (which may not work as well). You could trying adding more -v flags (up tro 7) to see if it gives you any more information about the situation?
I already did the process with layerwriter.LayerWriter but it is the first time I have used it so not sure what it was supposed to do. I extracted the Primary layer so I am primarily working on that. I only have one of the ISF files in the symbols folder, and with -v{7} it gives me the following output:
$ vol3 -f primary.raw -s symbols/ -vvvvvvv --offline linux.bash.Bash
[2612273] WARNING: file already exists but should not: /tmp/_MEIAYVhlQ/Crypto/Cipher/_AES.cpython-38-x86_64-linux-gnu.so
[2612273] WARNING: file already exists but should not: /tmp/_MEIAYVhlQ/Crypto/Cipher/_ARC4.cpython-38-x86_64-linux-gnu.so
[2612273] WARNING: file already exists but should not: /tmp/_MEIAYVhlQ/Crypto/Cipher/_DES.cpython-38-x86_64-linux-gnu.so
[2612273] WARNING: file already exists but should not: /tmp/_MEIAYVhlQ/Crypto/Hash/_SHA256.cpython-38-x86_64-linux-gnu.so
Volatility 3 Framework 2.0.0: Patched as of 20220105
INFO volatility3.cli: Volatility plugins path: ['/usr/bin/plugins', '/usr/share/Volatility3/plugins', '/tmp/_MEIAYVhlQ/volatility3/plugins', '/tmp/_MEIAYVhlQ/volatility3/framework/plugins']
INFO volatility3.cli: Volatility symbols path: ['/temp/symbols', '/usr/bin/symbols', '/usr/share/Volatility3/symbols', '/tmp/_MEIAYVhlQ/volatility3/symbols', '/tmp/_MEIAYVhlQ/volatility3/framework/symbols']
Level 6 volatility3.framework: Importing from the following paths: /usr/bin/plugins, /usr/share/Volatility3/plugins, /tmp/_MEIAYVhlQ/volatility3/plugins, /tmp/_MEIAYVhlQ/volatility3/framework/plugins
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/automagic
INFO volatility3.framework.automagic: Detected a linux category plugin
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
INFO volatility3.framework.automagic: Running automagic: ConstructionMagic
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
Level 9 volatility3.framework.automagic.construct_layers: Failed on requirement: plugins.Bash.kernel
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel.layer_name
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
Level 9 volatility3.framework.automagic.construct_layers: Failed on requirement: plugins.Bash.kernel.layer_name
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel.layer_name
Level 9 volatility3.framework.automagic.construct_layers: Failed on requirement: plugins.Bash.kernel
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
Level 9 volatility3.framework.configuration.requirements: Symbol table requirement not yet fulfilled: plugins.Bash.kernel.symbol_table_name
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
Level 9 volatility3.framework.automagic.construct_layers: Failed on requirement: plugins.Bash.kernel.symbol_table_name
Level 9 volatility3.framework.configuration.requirements: Symbol table requirement not yet fulfilled: plugins.Bash.kernel.symbol_table_name
Level 9 volatility3.framework.automagic.construct_layers: Failed on requirement: plugins.Bash.kernel
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel
Level 9 volatility3.framework.automagic.construct_layers: Failed on requirement: plugins.Bash
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
Level 6 volatility3.framework.automagic.construct_layers: Construction Exception occurred: Unexpected config value found: None
INFO volatility3.framework.automagic: Running automagic: LinuxBannerCache
Level 6 volatility3.framework.symbols.intermed: Searching for symbols in /temp/symbols, /usr/bin/symbols, /usr/share/Volatility3/symbols, /tmp/_MEIAYVhlQ/volatility3/symbols, /tmp/_MEIAYVhlQ/volatility3/framework/symbols
INFO volatility3.framework.automagic.symbol_cache: Building linux caches...
Level 7 volatility3.framework.layers.resources: Available URL handlers: HTTPErrorProcessor, HTTPDefaultErrorHandler, HTTPRedirectHandler, ProxyHandler, HTTPBasicAuthHandler, ProxyBasicAuthHandler, HTTPDigestAuthHandler, ProxyDigestAuthHandler, AbstractHTTPHandler, HTTPHandler, HTTPSHandler, HTTPCookieProcessor, UnknownHandler, FileHandler, FTPHandler, CacheFTPHandler, DataHandler, VolatilityHandler, JarHandler, OfflineHandler
INFO volatility3.framework.automagic: Running automagic: LayerStacker
Level 6 volatility3.framework: Importing from the following paths: /tmp/_MEIAYVhlQ/volatility3/framework/layers
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel
Level 8 volatility3.framework.automagic.stacker: Attempting to stack using LimeStacker
Level 8 volatility3.framework.automagic.stacker: Attempting to stack using Elf64Stacker
Level 6 volatility3.framework.layers.elf: Exception: Bad magic 0xf000ff53 at file offset 0x0
Level 8 volatility3.framework.automagic.stacker: Attempting to stack using QemuStacker
Level 8 volatility3.framework.automagic.stacker: Attempting to stack using AVMLStacker
Level 8 volatility3.framework.automagic.stacker: Attempting to stack using WindowsCrashDumpStacker
Level 8 volatility3.framework.automagic.stacker: Attempting to stack using VmwareStacker
Level 8 volatility3.framework.automagic.stacker: Attempting to stack using LinuxIntelStacker
INFO volatility3.framework.automagic.linux: No Linux banners found - if this is a linux plugin, please check your symbol files location
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel.layer_name
Level 9 volatility3.framework.configuration.requirements: TypeError - Layer is not the required Architecture: FileLayer
DEBUG volatility3.framework.automagic.stacker: Stacked layers: ['FileLayer']
INFO volatility3.framework.automagic: Running automagic: LinuxSymbolFinder
Level 9 volatility3.framework.configuration.requirements: Symbol table requirement not yet fulfilled: plugins.Bash.kernel.symbol_table_name
INFO volatility3.framework.automagic: Running automagic: KernelModule
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel.layer_name
Level 9 volatility3.framework.configuration.requirements: IndexError - No configuration provided: plugins.Bash.kernel
Unsatisfied requirement plugins.Bash.kernel: Linux kernel
Unable to validate the plugin requirements: ['plugins.Bash.kernel']
Hmmmm, just one thing to check (and this will hopefully be going away soon, depending on #630) but the linux ISF files must be under symbols/linux and similarly mac ones must be under symbols/mac. That's a requirement that we hope to remove with #630, but it's a sizable change so it needs a bit more testing.
If that still fails, then we'd need to debug what's going on which either means diving into the code and adding print statements, or being happy to share the image and JSON file you've created with us, so we can look into it. Let me know if the directory thing works first, and then if not we can go from there. Also happy for you to spin up your own ticket if you'd like so we don't swamp Rafael's issue. 5:)
Hi.
I used dwarf to create json symbols file related to the Linux kernel of the host from which I captured RAM via fmem module.
Then I put the json file in the volatility symbols folder and tried to use linux.pslist.PsList plugin.Output below:
Volatility 3 Framework 2.5.0
Progress: 100.00 Stacking attempts finished
OFFSET (V) PID TID PPID COMM
-end of output-
It looks no process were found
I'm pretty sure symbols file is correct because I tested the same scenario with a wrong json symbols file and I received this output:
Volatility 3 Framework 2.5.0
Progress: 100.00 Stacking attempts finished
Unsatisfied requirement plugins.PsList.kernel.layer_name:
Unsatisfied requirement plugins.PsList.kernel.symbol_table_name:
A translation layer requirement was not fulfilled. Please verify that: A file was provided to create this layer (by -f, --single-location or by config) The file exists and is readable The file is a valid memory image and was acquired cleanly
A symbol table requirement was not fulfilled. Please verify that: The associated translation layer requirement was fulfilled You have the correct symbol file for the requirement The symbol file is under the correct directory or zip file The symbol file is named appropriately or contains the correct banner
Unable to validate the plugin requirements: ['plugins.PsList.kernel.layer_name', 'plugins.PsList.kernel.symbol_table_name'] -end of output-
Any idea?
If you run the isfinfo plugin, and the banners plugin. Do the banners match exactly? Vol what's them to be exactly the same and won't attempt to use them otherwise.
Could you share the output when running the linux pslist with debug info. (e.g. -vvv before the plugin name)