Mac ASLR shift automagic isn't accurate enough

[ikelos]

A user pointed out to me that even using the latest mac.zip symbol pack, and though AOMF samples 1 and 4 returned appropriate results, samples 2 and 3 returned no results from pslist or tasks.

On further investigation the automagic is falling for a false kernel banner earlier in the image, so the shift is coming out at 0x600000, rather than the correct 0x2d200000. Seems the validity check we use isn't stable enough (ie, we've got images where the additional checks pass for something that isn't the right ASLR shift).

@atcuno Any chance you could investigate sometime please? Not sure if there's a better way of distinguishing false positives for the shift?

[ikelos]

Interestingly, sample-3 hits the WintelStacker which finds a DTB at 0x1ba000 before the MacIntelStacker has a chance to kick in... 5:S I'll look into ways to turn off different types of stacker based on the plugin type...

[ikelos]

I've spun that section up as #234, so no need to worry about that so much just yet...

[atcuno]

Hey @ikelos ,

I found a couple things while investigating this that I wanted to point out and discuss. I made a commit to a branch, with debugging statements included as I felt like that was the easiest way to discuss each item... Note that the pastes of log data is from sample 2 of the AOMF set.

The commit: https://github.com/volatilityfoundation/volatility3/commit/1d15834f9b7f00337c4a4437db16d6b67ed4b2f1

1) I had to modify virtual_to_physical_address to account for that some symbols come back masked and some don't. That is why you see the > check there. This was breaking calculations of where to find data to validate.

2) DTBs should always be page aligned. I added that check here: https://github.com/volatilityfoundation/volatility3/commit/1d15834f9b7f00337c4a4437db16d6b67ed4b2f1#diff-56f9d767c70152226911db6d200d21aaR89

3) Unfortunately, the code is still broke as, with the fixes from 1) and 2), the proper ASLR shift of 0x2d200000 is actually found correctly now by the "stack" method in mac.py, but this value is not saved and then later, find_aslr is ran again inside of symbol_finder. symbol_finder then finds the wrong shift value (0x600000) and sticks with it, leading the plugin crashing.

You can see this in the snipped log output here (you can re-generate the full log by -vvvvvv with this branch on mac-sample-2-bin):

DEBUG    volatility.framework.automagic.mac: json ffffff80007a7f70 | v2p 7a7f70 | offset 2d9a7f70 | tmp_aslr 2d200000
DEBUG    volatility.framework.automagic.mac: x version is b'Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root'
DEBUG    volatility.framework.automagic.mac: Mac ASLR shift value determined: 2d200000
DEBUG    volatility.framework.automagic.mac: POSSIBLE DTB: 0x2f430000
DEBUG    volatility.framework.automagic.mac: DTB was found at: 0x2f430000

So the correct shift is found there, but then later these print:

DEBUG    volatility.framework.automagic.symbol_finder: running find_aslr from symbol_finder
DEBUG    volatility.framework.automagic.mac: json ff80007a7f70 | v2p 7a7f70 | offset da7f70 | tmp_aslr 600000
DEBUG    volatility.framework.automagic.mac: x version is b'Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root'
DEBUG    volatility.framework.automagic.mac: Mac ASLR shift value determined: 600000
DEBUG    volatility.framework.automagic.symbol_finder: setting find_aslr from symbol_finder: 600000

I tried to set the symbol_shift value inside of stack() here, by adding a new line that set symbol_shift... but the code in symbol_finder still later ran and set the wrong value.

It seems best if stack() can set the ASLR value as:

1) It already has stronger checks, with the new DTB filtering

2) We wouldn't scan each sample twice for the ASLR value, instead only scan it once.

[ikelos]

Ok, I've got a better idea of what's going on.

We can cache the aslr value, but we end up stashing it in the Intel space (because the other one's already been constructed), and unfortunately find_aslr gets handed the physical layer, rather than the top level one. So I've moved the check earlier and since it's in the shared code, it's now technically also available for linux, but it's not stashed by linux yet. (There was already a check if the symbol table has cached it, but the symbol table doesn't exist at the time we figure out the ASLR the first time around.)

It's a shame we have to use the DTB to verify the ASLR value returned by find_aslr, but I guess it still works now we can cache.

I also tidied up some of the logging so that it's not so common (and chopped big chunks that felt like there were just for diagnosing this one problem) out. Lemme know if that works out for you (seems fine against mac-sample-2.bin for me now), and if so we can MR this and merge it in... 5:)

[ikelos]

So the place we stash it is in metadata (which is a means for layers to communicate upwards to things above them). Unfortunately, they're not supposed to be relied upon (they're not stored in the config, and systems should have their own ways of dealing with the data if it's not provided), but hopefully when the config gets saved, the symbol table will be saved, and that will store the right value for the kaslr assuming it was constructed properly. So it's just one of those gotchas, and I need to have a think over whether metadata needs passing in with the images or not. For now, I'm gonna say not, but I'll ask Nick next meeting...