We now use mapping to skip unmapped pages when scanning. This
should be slightly quicker and likely more accurate. We also now
don't chunk over the size requested by the scanner. We don't quite
handle overlaps correctly yet (we overlap, but don't prevent
duplicates if the pattern is entirely within the overlap segment).
This uses the exceptions to indicate how much can be skipped in the
virtual intel translation layer. This means large holes in the memory
can be skipped more quickly. It also eliminates the is_valid/mapping
loop.
Layers now accept metadata dictionaries (and chain/stack them on top of
those from lower layers). Metadata can only be set at construction
time, and the metadata dictionary is readonly. The hope is this will
make enumerating metadata keys across the codebase simpler.
The current metadata items that layers hold is:
architecture (Unknown | Intel32 | Intel64)
os (Unknown | Windows | Linux)
pae (bool)
page_map_offset (int)
This patchset may develop further to help enumerate all of these
(through a registration/reporting system).
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.
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.
Refactored the location of the progress_callback so that the UI can
specify it and ensure it is used by the automagics process as well as
the plugins themselves.
The progress_callback function has also had an optional description parameter
added, so that it can differentiated in case two scans happen
simultaneously.
This change is quite signficant, and requires that TranslationLayers
get all additional parameters that they need through their requirements.
These are now automatically enumerated and populated on object
construction based on the requirements, so should not require lots of
repetitive filling out of fields.
It does come with the downside that TranslationLayers can only be
contructed with a context (and appropiate config), but TLs in particular
always require a context (to contain the base layer) and blank configs
can be constructed relatively easily (convenience functions can be added
if necessary).
This allows configuration trees to be built up, and their configs
spliced into an existing config (as if it were being loaded from a
file).
Not all ConstructableRequirements use this method, since SymbolTables
(for example) do not have access to the context or config_path in order
to get to any parameters stored in the context's config. They therefore
are still passed their requirement values as __init__ parameters
instead.
This also adds support for manually constructed configurables to
populate the config tree in the current context.
I'm still toying around with this though, I need to figure out
what to do with optional values and think the whole thing through
to make sure it's worthwhile.
Mike Auty