pub struct MemoryMap { /* private fields */ }Expand description
MemoryMap provides access to the system-level memory map describing how a BinaryView is loaded into memory.
§Architecture Note
This Rust MemoryMap struct is a proxy that accesses the BinaryView’s current MemoryMap state through
the FFI boundary. The proxy provides a simple mutable interface: when you call modification operations
(add_memory_region, remove_memory_region, etc.), the proxy automatically accesses the updated MemoryMap.
Internally, the core uses immutable copy-on-write data structures, but the proxy abstracts this away.
When you access a BinaryView’s MemoryMap, you always see the current state. For lock-free access during analysis, AnalysisContext provides memory layout query methods (is_valid_offset, is_offset_readable, get_start, get_length, etc.) that operate on an immutable snapshot of the MemoryMap cached when the analysis was initiated.
A MemoryMap can contain multiple, arbitrarily overlapping memory regions. When modified, address space segmentation is automatically managed. If multiple regions overlap, the most recently added region takes precedence by default.
Source§
Source
JSON string representation of the base MemoryMap, consisting of unresolved auto and user segments.
Source
Whether the memory map is activated for the associated view.
Returns true if this MemoryMap represents a parsed BinaryView with real segments
(ELF, PE, Mach-O, etc.). Returns false for Raw BinaryViews or views that failed
to parse segments.
This is determined by whether the BinaryView has a parent view - parsed views have a parent Raw view, while Raw views have no parent.
Use this to gate features that require parsed binary structure (sections, imports, relocations, etc.). For basic analysis queries (start, length, is_offset_readable, etc.), use the MemoryMap directly regardless of activation state - all BinaryViews have a usable MemoryMap.
Source
Adds the memory region using a DataBuffer.
This will add the contents of the DataBuffer to the database.
Source
Adds the memory region using a FileAccessor.
This does not add the region contents to the database, instead accesses to the contents
are done “remotely” to a FileAccessor.
NOTE: The FileAccessor MUST live as long as the region is available, currently there is no gurentee by
the type checker that the file accessor is tied to that of the memory region.
Source
Adds an unbacked memory region with a given length and fill byte.