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.
Implementations§
source§impl MemoryMap
impl MemoryMap
pub fn new(view: Ref<BinaryView>) -> Self
sourcepub fn base_description(&self) -> String
pub fn base_description(&self) -> String
JSON string representation of the base MemoryMap, consisting of unresolved auto and user segments.
sourcepub fn description(&self) -> String
pub fn description(&self) -> String
JSON string representation of the MemoryMap.
pub fn set_logical_enabled(&mut self, enabled: bool)
sourcepub fn is_activated(&self) -> bool
pub fn is_activated(&self) -> bool
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.
pub fn add_binary_memory_region( &mut self, name: &str, start: u64, view: &BinaryView, segment_flags: Option<SegmentFlags>, ) -> bool
sourcepub fn add_data_memory_region(
&mut self,
name: &str,
start: u64,
data: &DataBuffer,
segment_flags: Option<SegmentFlags>,
) -> bool
pub fn add_data_memory_region( &mut self, name: &str, start: u64, data: &DataBuffer, segment_flags: Option<SegmentFlags>, ) -> bool
Adds the memory region using a DataBuffer.
This will add the contents of the DataBuffer to the database.
sourcepub fn add_remote_memory_region<A: Accessor>(
&mut self,
name: &str,
start: u64,
accessor: &mut FileAccessor<A>,
segment_flags: Option<SegmentFlags>,
) -> bool
pub fn add_remote_memory_region<A: Accessor>( &mut self, name: &str, start: u64, accessor: &mut FileAccessor<A>, segment_flags: Option<SegmentFlags>, ) -> bool
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.
sourcepub fn add_unbacked_memory_region(
&mut self,
name: &str,
start: u64,
length: u64,
segment_flags: Option<SegmentFlags>,
fill: Option<u8>,
) -> bool
pub fn add_unbacked_memory_region( &mut self, name: &str, start: u64, length: u64, segment_flags: Option<SegmentFlags>, fill: Option<u8>, ) -> bool
Adds an unbacked memory region with a given length and fill byte.