Open Lowengrube opened 2 years ago
So it did identify the correct banner, but we then immediately try to use a structure that wasn't present:
volatility3.framework.automagic.mac: Identified banner: b'Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64\x00'
INFO volatility3.schemas: Dependency for validation unavailable: jsonschema
DEBUG volatility3.schemas: All validations will report success, even with malformed input
Level 7 volatility3.framework.automagic.stacker: Exception during stacking: Symbol type not in MacintelStacker1 SymbolTable: vm_map_object
Level 6 volatility3.framework.automagic.stacker: Traceback (most recent call last):
File "/Users/test/volatility3/volatility3/framework/automagic/stacker.py", line 171, in stack_layer
new_layer = stacker.stack(context, initial_layer, progress_callback)
File "/Users/test/volatility3/volatility3/framework/automagic/mac.py", line 61, in stack
table = mac.MacKernelIntermedSymbols(context = context,
File "/Users/test/volatility3/volatility3/framework/symbols/mac/__init__.py", line 21, in __init__
self.set_type_class('vm_map_object', extensions.vm_map_object)
File "/Users/test/volatility3/volatility3/framework/symbols/intermed.py", line 54, in _delegate_function
return getattr(self._delegate, name)(*args, **kwargs)
File "/Users/test/volatility3/volatility3/framework/symbols/intermed.py", line 362, in set_type_class
raise ValueError(f"Symbol type not in {self.name} SymbolTable: {name}")
ValueError: Symbol type not in MacintelStacker1 SymbolTable: vm_map_object
It's not clear if this structure's name has changed, or it was removed (or possibly if the symbol table was generated incorrectly, but it doesn't look like it). We'll need to do some investigation to figure out what the problem is. The vm_map_object
type is one that we override with a custom handler, and it appears the custom handler isn't finding the original definition in the JSON. I've asked @atcuno to see whether the vm_map_object
structure was renamed or removed from recent mac kernels...
This issue is stale because it has been open for 200 days with no activity.
Ping @atcuno, before this times out in a couple months, could you please check about the vm_map_object
in the mac symbol tables?
This issue is stale because it has been open for 200 days with no activity.
@atcuno The stale ticket just got added, which means it's been a couple of months since I asked. Have you had a chance to check out what's going on with the symbol tables and the vm_map_object
symbol?
This structure was removed from the kernel, as well as many related vm_map
ones.
The old/new versions are here :
Here is an article brieflly talking about it :
I was planning to update the framework, but It's gonna need more time and analysis to fix it. It mostly impacts mac.malfind
.
@Abyss-W4tcher thanks for the analysis! Perhaps @atcuno or @gcmoreira can help out now we know what it is?
Hi, I will propose a patch in a PR soon, it's only in my fork right now.
I inform any dev here, to avoid potentially duplicating the same work 😃
This issue is stale because it has been open for 200 days with no activity.
Definitely not stale, just tricky to fix... 5:S Sorry I've been so slow on it, I'm finding it hard to get dedicated time to fix big issues like this. It is still on my list though.
Hi, this should have been fixed in the two macOS PRs that were released a few months ago. However due to the current calendar I completely understand the lack of time to allocate on this subject 👍.
Yeah, I thought I was producing a MacSymbolTable that was a facade for the two different mac tables and gave you the right table (with the right shift) based on which symbol you asked for? Did we still need that, I don't remember how we left it sadly... 5:S
When you are ready, just comment on any of the PRs and I will provide you with a quick resume.
But basically, this issue is related to malfind (fixed by the "plugins" PR) and the "double module" aspect you mentioned relates to the automagic update PR supporting a new self-contained MACHO kernel in macOS.
Ok thanks, as I say it hasn't slipped off my list but it needs me to find some time to sit and concentrate on it. Thanks for your understanding, it's really appreciated!
Hey there, so currently i'm facing problem in using Volatility 3 to analyse the ram dump file from MacOS Monterey 12.6 build 21G115, I had successfully created the symbol table for that OS version:
./dwarf2json mac --macho /Library/Developer/KDKs/KDK_12.6_21G115.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/DWARF/kernel --macho-symbols /Library/Developer/KDKs/KDK_12.6_21G115.kdk/System/Library/Kernels/kernel > 12.6.json
After that I copied 12.6.json to /path_to_volatility3/symbols/mac/ directory.
ISFinfo shows:
python3 ./volatility3/vol.py isfinfo
file:///Users/test/volatility3/volatility3/symbols/mac/allmacho.json Unknown 19 0 64681 392 b'Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64\x00'
Banners of image show:
python3 ./volatility3/vol.py -f raw_dump_only_osxpmem.dump banners
It looks like ok, but any operations with image (mac.bash/mac.lsof/mac.pstree and etc.) don't work:
python3 ./volatility3/vol.py -vvvvvv -f raw_dump_only_osxpmem.dump mac.bash