-
Notifications
You must be signed in to change notification settings - Fork 492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
linux.pslist returns no results #413
Comments
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 |
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 ( |
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 |
Yes of course! |
I have the same problem, is there a further solution?
|
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 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//volatility3/symbols/deb.json Unknown 18 7463 141769 1217 - Linux version 4.19.0-14-arm64 ([email protected]) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.171-2 (2021-01-30) 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:
I can't tell whether the negative physical offset is important at this point or not? |
@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:
|
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 |
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 |
I already did the process with
|
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 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. -end of output- A translation layer requirement was not fulfilled. Please verify that: A symbol table requirement was not fulfilled. Please verify that: Unable to validate the plugin requirements: ['plugins.PsList.kernel.layer_name', 'plugins.PsList.kernel.symbol_table_name'] Any idea? |
If you run the Could you share the output when running the linux pslist with debug info. (e.g. -vvv before the plugin name) |
Hi @eve-mem ,this is the output of the isinfo command: file:///home/user/Desktop/volatility3/volatility3/symbols/windows/ntkrnlmp.pdb/BBCA518265E9D831935C4FC58E2542ED-1.json.xz True (cached) 16 1653 40028 293 b'ntkrnlmp.pdb|BBCA518265E9D831935C4FC58E2542ED|1' here the output of the banners command: 0x77600200 Linux version 5.15.0-83-generic (buildd@lcy02-amd64-027) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #92-Ubuntu SMP Mon Aug 14 09:30:42 UTC 2023 (Ubuntu 5.15.0-83.92-generic 5.15.116) and this is the ouput of the -vvv linux.pslist.PsList command (some strikethrough text.I think about some formatting characters.please,ignore it): DEBUG volatility3.framework: Failed to import module volatility3.plugins.windows.cachedump based on file: /home/user/Desktop/volatility3/volatility3/framework/plugins/windows/cachedump.py DEBUG volatility3.framework: Failed to import module volatility3.plugins.windows.hashdump based on file: /home/user/Desktop/volatility3/volatility3/framework/plugins/windows/hashdump.py DEBUG volatility3.framework: Failed to import module volatility3.plugins.windows.lsadump based on file: /home/user/Desktop/volatility3/volatility3/framework/plugins/windows/lsadump.py OFFSET (V) PID TID PPID COMM thanks for any tips |
Great thanks for that, It shows that you have the correct symbols, and vol is finding them in your sample and it's all working, almost as expected. This is the line where we see that it's been stacked correctly.
And here showing that your banner was found correctly.
Rereading your first message I see you say, lime raw format. I missed that at first. Unfortunately 'raw' from LiME means something else than what most people expect, it's the raw main memory but it doesn't preserve the correct layout of memory and that is why vol is failing. It's looking for where the init_task should be, but due to the "raw" format from LiME it's in the wrong place and therefore you get no results. The padded or lime formats should work flawlessly, but you will need to reacquire the memory. Essentially the LiME padded output is what most people would call a raw image. It's very unfortunate, I've raised an issue for LiME in the hopes that one day the option will be changed or at least come with a warning. 504ensicsLabs/LiME#111 |
talking about LiME,I think you made reference to the first post of this thread that is not mine ;) |
Ah yes. You've added a comment to an existing issue, rather than having your own. Sorry i got confused. I haven't got any experience with fmem personally so i can't say how it compares. At this point I'd probably need to see the sample myself to try and work out what's going on. |
thanks,meanwhile I'll try using LiME with padded or lime format |
Great, good luck. Given this is a three year old issue that's covered a few different people struggling with similar symptoms (no pslist) but different causes (format, making symbols, etc) it feels like this should be closed now. @ikelos do you agree? @gitter-sudo if you need to raise another similar issue, I'd personally suggest checking in the slack channel first - it's a good quick way to get some community support. Issues are fine too of course, but if you haven't seen the slack channel you might find it helpful. |
thanks @eve-mem ,I confirm that capturing RAM via LiME has allowed me to achieve the expected results |
Great news, be interesting to investigate what went wrong with fmem in slower time. |
I had the same issue. Using LiME format=padded now shows processes with |
This issue is stale because it has been open for 200 days with no activity. |
This issue was closed because it has been inactive for 60 days since being marked as stale. |
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
The text was updated successfully, but these errors were encountered: