This effectively means that the FileTranslationLayer will reuse the
cached file even with multiple opens, but rerunning python, or starting
a new context (with a new FileTranslationLayer but on the same URL) will
cause a redownload whether necessary or not. This ensures that running
volatility as an engine (inside a long lived python session) will not
prevent a file being checked again later.
Other caching mechanisms (such as last-modified) should be used to
determine if the cached file is still valid.
Note this may cause issues if plugins run concurrently.
It's longer to type, but people shouldn't be typing it directly.
They should be pulling the value from the config and using that, which
can default to 'nt' if necessary.
We determine address_masks using log/ln2, which cannot accept 0.
Therefore we don't support address spaces with a maximum_address of 0.
This can affect registry hives, so we've added a check in registry hives
to prevent creating layers with invalid maximum_addresses.
We use the jar scheme because that's actually registered with the right
bodies, even if the syntax is a bit weird. The contents is still
processed by the ResourceAccessor meaning it can be compressed with any
of the supported compression methods.
Since the stacker and Linux automagic will always be different objects
(even if they're the same class), and we don't want to add OS specific
code to the stacker, this is the simplest way of allowing the Linux
symbol automagic to get information from the dtb finding stacker.
Really need to figure out how to deal with _HBIN and _HCELL for
systems that don't have those structures. The format seems extremely
unlikely to change, but better not to hard code anything if avoidable.
They weren't consistent and they show just remind me how slowly
I've been getting vol 3 written! 5:S
There's git commits to track all of that stuff if we need it.
Mike Auty