Incorrect Mac ASLR shift calculation?

[ilch1]

The following volatility command is failing to run:

$ python vol.py -vvvvvv -f <path-to-macos-10-11-15A282a-x64>data.lime mac.pslist.PsList

The relevant debug output is:

...
DEBUG    volatility.framework.automagic.mac: Mac ASLR shift value determined: 0
Level 7  volatility.framework.automagic.stacker: Exception during stacking: ('Ma
cDTBTempLayer1', 18446743523965197008, 'Page Fault at entry 0xdce7ab3470f9d408 i
n table page directory pointer')
Level 6  volatility.framework.automagic.stacker: Traceback (most recent call las
t):

  File "/Users/ilya/git/github.com/volatilityfoundation/volatility3/volatility/f
ramework/automagic/stacker.py", line 133, in stack
    new_layer = stacker.stack(new_context, current_layer_name, progress_callback
)

  File "/Users/ilya/git/github.com/volatilityfoundation/volatility3/volatility/f
ramework/automagic/mac.py", line 110, in stack
    idlepml4_str = layer.read(idlepml4_ptr, 4)

  File "/Users/ilya/git/github.com/volatilityfoundation/volatility3/volatility/f
ramework/interfaces/layers.py", line 377, in read
    for (offset, mapped_offset, mapped_length, layer) in self.mapping(offset, le
ngth, ignore_errors = pad):

  File "/Users/ilya/git/github.com/volatilityfoundation/volatility3/volatility/f
ramework/layers/intel.py", line 205, in mapping
    chunk_offset, page_size, layer_name = self._translate(offset)

  File "/Users/ilya/git/github.com/volatilityfoundation/volatility3/volatility/f
ramework/layers/intel.py", line 120, in _translate
    entry, position = self._translate_entry(offset)

  File "/Users/ilya/git/github.com/volatilityfoundation/volatility3/volatility/f
ramework/layers/intel.py", line 146, in _translate_entry
    "Page Fault at entry " + hex(entry) + " in table " + name)

volatility.framework.exceptions.PagedInvalidAddressException: ('MacDTBTempLayer1
', 18446743523965197008, 'Page Fault at entry 0xdce7ab3470f9d408 in table page d
irectory pointer')
...
Unsatisfied requirement plugins.PsList.primary: Memory layer for the kernel
Unsatisfied requirement plugins.PsList.darwin: Mac kernel symbols

A symbol table requirement was not fulfilled.  Please verify that:
        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

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 necessary symbols are present and identified by volatility
Unable to validate the plugin requirements: ['plugins.PsList.primary', 'plugins.PsList.darwin'

I'm pretty sure the ASLR value is not 0 as reported by this output.

I've added the version data to my symbol file and now the contents of the cache file is:

$ xxd ~/.cache/volatility3/mac_banners.cache
00000000: 8003 7d71 0043 6144 6172 7769 6e20 4b65  ..}q.CaDarwin Ke
00000010: 726e 656c 2056 6572 7369 6f6e 2031 352e  rnel Version 15.
00000020: 302e 303a 2057 6564 2041 7567 2032 3620  0.0: Wed Aug 26
00000030: 3136 3a35 373a 3332 2050 4454 2032 3031  16:57:32 PDT 201
00000040: 353b 2072 6f6f 743a 786e 752d 3332 3437  5; root:xnu-3247
00000050: 2e31 2e31 3036 7e31 2f52 454c 4541 5345  .1.106~1/RELEASE
00000060: 5f58 3836 5f36 3400 7101 5d71 0258 6a00  _X86_64.q.]q.Xj.
00000070: 0000 6669 6c65 3a2f 2f2f 5573 6572 732f  ..file:///Users/
00000080: 696c 7961 2f67 6974 2f67 6974 6875 622e  ilya/git/github.
00000090: 636f 6d2f 766f 6c61 7469 6c69 7479 666f  com/volatilityfo
000000a0: 756e 6461 7469 6f6e 2f76 6f6c 6174 696c  undation/volatil
000000b0: 6974 7933 2f76 6f6c 6174 696c 6974 792f  ity3/volatility/
000000c0: 7379 6d62 6f6c 732f 6d61 632f 6b65 726e  symbols/mac/kern
000000d0: 656c 2e64 5359 4d2e 6a73 6f6e 7103 6173  el.dSYM.jsonq.as
000000e0: 2e

[ikelos]

So the ASLR shift code currently lives here.

It seems to look up the location of the version symbol (ie, where it should live in virtual memory) and converts that to a physical address using stock heuristic, and then compares this to the actual physical address that the banner was found at, and then compares the major and minor values to see if they match. If any of that fails for any reason then the aslr_shift would stay as the default (0).

I'm not sure how best to debug this, so it sounds like one for @atcuno to handle I'm afraid... 5:S

[ilch1]

It looks like this was fixed at some point. When rerunning the command with the latest HEAD the output is as expected.