Closed ikelos closed 5 years ago
This is a bit tricky. MacOSs puts debug information into a separate file that does not contain the TEXT
sections. Populating the version
bytes would thus require dwarf2json
to be provided 2 inputs for mac:
kernel
kernel.dSYM
This would be different from the ELF case, where only the equivalent of 2) from above would need to be provided.
So this seems improved (it pulls out the banner when it processes the kernel.debug dSYM file), but it seems to be fixed length because we get a list of sometimes truncated, sometimes too long values:
b'Darwin Kernel Version 17.7.0: Fri Nov 2 20:43:16 PDT 2018; root:xnu-4570.71.17~1/RELEASE_X86_64\x00'
b'Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64\x00\x11'
b'Darwin Kernel Version 18.2.0: Fri Oct 5 19:41:49 PDT 2018; root:xnu-4903.221.2~2/RELEASE_X86_64\x00'
b'Darwin Kernel Version 18.2.0: Mon Nov 12 20:24:46 PST 2018; root:xnu-4903.231.4~2/RELEASE_X86_64\x00'
b'Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64\x00'
b'Darwin Kernel Version 16.4.0: Thu Dec 22 22:52:37 PST 2016; root:xnu_debug-3789.41.3~3/DEBUG_X86_'
Good catch. The kernel version string length varies across macOS kernels. Unfortunately, the symbol length is not available so we have to resort to scanning for NULL.
Looks like this is resolved (save for 10.9, but I've opened a separate issue for that). Thanks! 5:)
I dunno if this repo has been kept up-to-date, but it appears not to properly support creating the necessary
constant_data
field for theversion
symbol when operating on mac dwarf files, in order to allow volatility to appropriately detect the mac tables. This relates to volatility3 issue #61.