t_memory

One of the most important structures, describes memory block in the debugged application. Memory blocks are listed in the sorted data of table memory. Plugins should not attempt to modify memory descriptions directly.

 typedef struct t_memory {              // Descriptor of memory block
  ulong          base;                 // Base address of memory block
  ulong          size;                 // Size of memory block
  ulong          type;                 // Service information, TY_xxx+MEM_xxx
  int            special;              // Extension of type, one of MSP_xxx
  ulong          owner;                // Address of owner of the memory
  ulong          initaccess;           // Initial read/write access
  ulong          access;               // Actual status and read/write access
  ulong          threadid;             // Block belongs to this thread or 0
  wchar_t        sectname[SHORTNAME];  // Null-terminated section name
  uchar          *copy;                // Copy used in CPU window or NULL
  uchar          *decode;              // Decoding information or NULL
} t_memory;


Members:

base
Base address of memory block. Most blocks are page-aligned (a Win32 page consists of 409610 = 0x1000 bytes), but in some rare cases OllyDbg may create unaligned blocks. Note that ZwAllocateVirtualMemory() allows to allocate memory at address 0 (by passing some small base address which will be rounded down). Routines that check whether memory is available or not should not assume that base==0 means no memory
size
Size of memory block, bytes. Usually a multiple of the page size, but in some rare cases OllyDbg may create blocks of any size
type
Attributes of memory block, a set of flags TY_xxx combined with the following memory-specific flags:
MEM_CODE - contains image of code section
MEM_DATA - contains image of data section
MEM_SFX - contains self-extractor
MEM_IMPDATA - contains import data
MEM_EXPDATA - contains export data
MEM_RSRC - contains resources
MEM_RELOC - ontains relocation data
MEM_STACK - contains stack of thread with identifier threadid
MEM_STKGUARD - guarding page of the stack (used as a trap when stack grows)
MEM_THREAD - contains data block of thread with identifier threadid
MEM_HEADER - contains DOS/COFF header
MEM_DEFHEAP - contains default heap
MEM_HEAP - contains non-default heap
MEM_NATIVE - contains JIT-compiled native code
MEM_SECTION - section of the executable file (and sectname is usually defined, too)
MEM_GUARDED - guarded memory block (used internally by debugging engine)
MEM_TEMPGUARD - temporarily guarded block (used internally by debugging engine)
Additional information is available in the member special. Note that if some flag is set, then OllyDbg guarantees its correctness, but its absence generally does not mean that feature is not present
special
Additional attribute of memory block, one of the following constants:
MSP_NONE - no special attribute
MSP_PEB - contains Process Environment Block
MSP_SHDATA - contains KUSER_SHARED_DATA
MSP_PROCPAR - contains Process Parameters
MSP_ENV - contains Environment
owner
Address of the owning memory block, as reported by VirtualQueryEx() in AllocationBase. Consult Windows API for details
initaccess
A set of flags PAGE_xxx, defined in Windows API, specifies access protection given when memory block was initially allocated
access
A set of flags PAGE_xxx, defined in Windows API, specifies current state of memory block. To fill access, OllyDbg combines State, Protect and Type members of the structure MEMORY_BASIC_INFORMATION returned by VirtualQueryEx()
threadid
Identifier of the thread owning this memory block, or 0 if there is no associated thread or thread is not known to OllyDbg
sectname
Null-terminated name of the section in the executable file from which this memory block was mapped. If several sections were merged together by the OllyDbg, sectname lists names of all participating sections serapated by comma
copy
Pointer to the global backup of the memory block or NULL. If backup is present, its size is the same as the size of memory block. Note that dump windows may have their own, unrelated backups
decode
Decoding information created by the Analyser or NULL. If analysis is present, its size is the same as the size of memory block. Each byte of the analysis data is the combination of flags DEC_xxx. Preferrable way to get analysis data is to call Finddecode()


See also:
Sorted data, tables, Analyser, Listmemory(), Findmemory(), Finddecode(), Ensurememorybackup()