Module interface

In a program, a module refers to an independent code unit used to implement specific functions or tasks. Modules can contain program components such as variables, functions, and classes, and can be referenced and reused by other programs or modules. The plugin provides various function support for module operations.

Module functions

GetModuleBaseAddress

Retrieves the base address (starting memory address) of a specified module (e.g., DLL, EXE) loaded into the target x86 process. The base address is the entry point of the module’s memory range in the process, and it is critical for tasks like locating functions within the module, scanning module-specific memory, or patching code/data in a known DLL/EXE. On success, it returns a dictionary with the module’s name, base address (in decimal and hex), and context notes; on failure, it returns false (common failure causes: module not loaded in the target process, invalid module name, or insufficient permissions to query loaded modules).

python

call interface function:
>>> module.GetModuleBaseAddress("kernelbase.dll")
Return value of interface function (JSON):
{
	'message': 'Module base address retrieved successfully',
	'module_name': 'kernelbase.dll',
	'base_address_value': 1971585024,
	'base_address_hex': '0x75840000',
	'note': "Module name is case-insensitive in most cases (e.g., 'KERNEL32.DLL' = 'kernel32.dll')",
	'platform': 'x86'
}

GetModuleProcAddress

Retrieves the memory address of an exported function from a specified module (e.g., DLL, EXE) loaded into the target x86 process. An "exported function" is a function explicitly made available for use by other modules (e.g., system APIs like IsValidCodePage in kernelbase.dll). This function is critical for dynamic function resolution—allowing you to locate and call functions in external modules, or analyze their memory addresses for debugging/reverse engineering. On success, it returns a dictionary with the module, function, and address details; on failure, it returns false (common failure causes: module not loaded, function not exported, invalid module/function name, or insufficient permissions).

python

call interface function:
>>> module.GetModuleProcAddress("kernelbase.dll","IsValidCodePage")
Return value of interface function (JSON):
{
	'message': 'Module function address retrieved successfully',
	'module_name': 'kernelbase.dll',
	'function_name': 'IsValidCodePage',
	'function_address_value': 1972848624,
	'function_address_hex': '0x759747F0',
	'note': 'Only works for exported functions (non-exported functions cannot be found)',
	'platform': 'x86'
}

GetBaseFromAddr

Retrieves the base address of the loaded module that contains a specified memory address in the target x86 process. Unlike mod.GetModuleBaseAddress (which uses a module name to find its base), mod.GetBaseFromAddr works in reverse: it takes an address that resides within a module (e.g., a function address, data address) and returns the module’s starting base address. This is critical for debugging and reverse engineering—for example, identifying which module a crash address belongs to, or resolving the base of a module when only a child address is known. On success, it returns a dictionary with the input address and corresponding module base; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or malformed hex format).

python

call interface function:
>>> module.GetBaseFromAddr("0x75840000")
Return value of interface function (JSON):
{
	'message': 'Module base address from memory address retrieved successfully',
	'input_address_value': 1971585024,
	'input_address_hex': '0x75840000',
	'module_base_address_value': 1971585024,
	'module_base_address_hex': '0x75840000',
	'note': 'The input address must belong to a loaded module (e.g., code/data segment of a DLL/EXE)',
	'platform': 'x86'
}

GetBaseFromName

Retrieves the base address (starting memory address) of a specified module (e.g., DLL, EXE) loaded into the target x86 process, using the module’s name as the lookup key. This function is a concise alternative to mod.GetModuleBaseAddress (with nearly identical functionality) and is critical for locating the entry point of a module when only its name is known—enabling tasks like function offset calculations, module-specific memory scans, or code patching. On success, it returns a dictionary with the module name and its base address; on failure, it returns false (common failure causes: module not loaded in the target process, invalid module name, or insufficient permissions to query the process’s module list).

python

call interface function:
>>> module.GetBaseFromName("kernelbase.dll")
Return value of interface function (JSON):
{
	'message': 'Module base address from name retrieved successfully',
	'module_name': 'kernelbase.dll',
	'base_address_value': 1971585024,
	'base_address_hex': '0x75840000',
	'platform': 'x86'
}

GetSizeFromAddress

Retrieves the total memory size of the loaded module that contains a specified memory address in the target x86 process. The "module size" refers to the total number of bytes the module occupies in the process’s address space (including all sections: code, data, resources, and metadata). This function is critical for memory range validation (e.g., checking if an address lies within a module) and module-specific operations (e.g., calculating the module’s end address). On success, it returns a dictionary with the input address and module size details; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or malformed hex format).

python

call interface function:
>>> module.GetSizeFromAddress("0x75840000")
Return value of interface function (JSON):
{
	'message': 'Module size from address retrieved successfully',
	'input_address_value': 1971585024,
	'input_address_hex': '0x75840000',
	'module_size_bytes': 2928640,
	'size_desc': 'Total size of the module in bytes (including all sections)',
	'platform': 'x86'
}

GetSizeFromName

Retrieves the total memory size of a specified loaded module (e.g., DLL, EXE) in the target x86 process, using the module’s name as the lookup key. The "module size" represents the total number of bytes the module occupies in the process’s address space, including all its sections (code, data, resources, metadata, and padding). This function is critical for analyzing memory usage, validating scan ranges, and ensuring modifications (e.g., patches) fit within the module’s bounds. On success, it returns a dictionary with the module name and size details; on failure, it returns false (common failure causes: module not loaded, invalid module name, or insufficient permissions to query the process’s module list).

python

call interface function:
>>> module.GetSizeFromName("kernelbase.dll")
Return value of interface function (JSON):
{
	'message': 'Module size from name retrieved successfully',
	'module_name': 'kernelbase.dll',
	'module_size_bytes': 2928640,
	'size_desc': 'Total size of the module in bytes (including all sections)',
	'note': 'Size may include padding or uninitialized data sections',
	'platform': 'x86'
}

GetOEPFromName

Retrieves the Original Entry Point (OEP) of a specified loaded module (e.g., DLL, EXE) in the target x86 process, using the module’s name as the lookup key. The OEP is the memory address where the module’s execution begins—for EXEs, this is the start of the main program logic; for DLLs, this is the entry point of DllMain (the function that runs when the DLL is loaded/unloaded). This function is critical for debugging, reverse engineering, and module initialization analysis. On success, it returns a dictionary with the module’s OEP and context; on failure, it returns false (common failure causes: module not loaded, invalid module name, corrupted module, or insufficient permissions).

python

call interface function:
>>> module.GetOEPFromName("kernelbase.dll")
Return value of interface function (JSON):
{
	'message': 'Module OEP from name retrieved successfully',
	'module_name': 'kernelbase.dll',
	'oep_address_value': 1972977792,
	'oep_address_hex': '0x75994080',
	'oep_desc': 'Original Entry Point - the address where execution starts in the module',
	'platform': 'x86'
}

GetOEPFromAddr

Retrieves the Original Entry Point (OEP) of the loaded module that contains a specified memory address in the target x86 process. The OEP is the address where the module’s execution begins (e.g., DllMain for DLLs or the main function for EXEs). This function works in reverse of mod.GetOEPFromName: instead of using a module name, it takes an address within the module to identify the module and return its OEP. It is critical for reverse engineering and debugging scenarios where you have a memory address (e.g., from a crash or breakpoint) but need to find the module’s entry point. On success, it returns a dictionary with the input address and OEP details; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or the module’s PE header is corrupted).

python

call interface function:
>>> module.GetOEPFromAddr("0x75994080")
Return value of interface function (JSON):
{
	'message': 'Module OEP from address retrieved successfully',
	'input_address_value': 1972977792,
	'input_address_hex': '0x75994080',
	'oep_address_value': 1972977792,
	'oep_address_hex': '0x75994080',
	'oep_desc': 'Original Entry Point - the address where execution starts in the module',
	'platform': 'x86'
}

GetPathFromName

Retrieves the full file system path of a specified loaded module (e.g., EXE, DLL) in the target x86 process, using the module’s name as the lookup key. The full path identifies where the module is stored on disk (e.g., "D:\test.exe"), which is critical for verifying the module’s origin (e.g., system vs. third-party), locating the file for analysis, or confirming the correct version is loaded. On success, it returns a dictionary with the module name and its full path; on failure, it returns false (common failure causes: module not loaded, invalid module name, or insufficient permissions to query the process’s module metadata).

python

call interface function:
>>> module.GetPathFromName("test.exe")
Return value of interface function (JSON):
{
	'message': 'Module path from name retrieved successfully',
	'module_name': 'test.exe',
	'module_full_path': 'D:\\test.exe',
	'path_desc': 'Full file system path of the loaded module',
	'platform': 'x86'
}

GetPathFromAddr

Retrieves the full file system path of the loaded module that contains a specified memory address in the target x86 process. This function works in reverse of mod.GetPathFromName: instead of using a module’s name to find its path, it uses an address within the module to identify the module and return its on-disk location. The full path is critical for validating a module’s origin (e.g., system vs. third-party), locating the module file for analysis, or investigating suspicious addresses (e.g., from crashes or debugging). On success, it returns a dictionary with the input address and module path details; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or insufficient permissions to access module metadata).

python

call interface function:
>>> module.GetPathFromAddr("0x75994080")
Return value of interface function (JSON):
{
	'message': 'Module path from address retrieved successfully',
	'input_address_value': 1972977792,
	'input_address_hex': '0x75994080',
	'module_full_path': 'C:\\Windows\\SysWOW64\\KernelBase.dll',
	'path_desc': 'Full file system path of the module containing the input address',
	'platform': 'x86'
}

GetNameFromAddr

Retrieves the name of the loaded module (including its file extension) that contains a specified memory address in the target x86 process. This function operates in reverse of name-based module queries (e.g., mod.GetBaseFromName): instead of using a module name to find its properties, it uses a memory address within the module to identify the module and return its name. It is critical for debugging, reverse engineering, and memory analysis—for example, determining which module a crash address belongs to or identifying the source of an unknown function address. On success, it returns a dictionary with the input address and module name; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or insufficient permissions to query the process’s module list).

python

call interface function:
>>> module.GetNameFromAddr("0x75994080")
Return value of interface function (JSON):
{
	'message': 'Module name from address retrieved successfully',
	'input_address_value': 1972977792,
	'input_address_hex': '0x75994080',
	'module_name': 'kernelbase.dll',
	'name_desc': 'Name of the module containing the input address (including extension)',
	'platform': 'x86'
}

GetMainModulePath

Retrieves the full file system path of the main module (primary executable) of the target/debugged x86 process. The "main module" is the core executable that launched the process (e.g., notepad.exe, test.exe), not a secondary DLL or library. Unlike other path-retrieval functions (e.g., mod.GetPathFromName, mod.GetPathFromAddr), this function requires no parameters—it automatically identifies and targets the main module, making it ideal for quickly accessing the primary executable’s on-disk location. On success, it returns a dictionary with the main module’s path and context; on failure, it returns false (common failure causes: target process is not running, main module metadata is corrupted, or insufficient permissions to access process info).

python

call interface function:
>>> module.GetMainModulePath()
Return value of interface function (JSON):
{
	'message': 'Main module path retrieved successfully',
	'main_module_full_path': 'D:\\test.exe',
	'path_desc': 'Full file system path of the debugged main executable',
	'note': 'Main module is the primary executable being debugged (e.g., C:\\Windows\\notepad.exe)',
	'platform': 'x86'
}

GetMainModuleSize

Retrieves the total memory size of the main module (primary executable) of the target/debugged x86 process. The "main module" is the core executable that launched the process (e.g., notepad.exe, test.exe), not secondary DLLs or libraries. Unlike size-retrieval functions that require a module name or address (e.g., mod.GetSizeFromName, mod.GetSizeFromAddr), this function requires no parameters—it automatically targets the main module, making it ideal for quickly analyzing the primary executable’s memory footprint. On success, it returns a dictionary with the main module’s size and context; on failure, it returns false (common failure causes: target process is not running, main module metadata is corrupted, or insufficient permissions to access process memory info).

python

call interface function:
>>> module.GetMainModuleSize()
Return value of interface function (JSON):
{
	'message': 'Main module size retrieved successfully',
	'main_module_size_bytes': 114688,
	'size_desc': 'Total size of the debugged main module (including all sections)',
	'note': 'Main module refers to the primary executable being debugged (e.g., notepad.exe)',
	'platform': 'x86'
}

GetMainModuleName

Retrieves the name of the main module (primary executable) of the target/debugged x86 process, including its file extension (e.g., ".exe"). The "main module" is the core executable that launched the process (e.g., test.exe, notepad.exe), not secondary DLLs or libraries. Unlike name-retrieval functions that require a module address or name (e.g., mod.GetNameFromAddr, mod.GetBaseFromName), this function requires no parameters—it automatically identifies the main module, making it ideal for quickly accessing the primary executable’s name in debugging or automation workflows. On success, it returns a dictionary with the main module’s name and context; on failure, it returns false (common failure causes: target process is not running, main module metadata is corrupted, or insufficient permissions to access process info).

python

call interface function:
>>> module.GetMainModuleName()
Return value of interface function (JSON):
{
	'message': 'Main module name retrieved successfully',
	'main_module_name': 'test.exe',
	'name_desc': 'Name of the debugged main module (including file extension)',
	'note': "e.g., 'notepad.exe' for the Notepad main executable",
	'platform': 'x86'
}

GetMainModuleEntry

Retrieves the Original Entry Point (OEP) of the main module (primary executable) of the target/debugged x86 process. The OEP is the memory address where the main module’s execution begins (e.g., the start of main or WinMain in an EXE). Unlike OEP-retrieval functions that require a module name or address (e.g., mod.GetOEPFromName, mod.GetOEPFromAddr), this function requires no parameters—it automatically targets the main module, making it ideal for quickly accessing the primary executable’s entry point in debugging or reverse engineering workflows. On success, it returns a dictionary with the OEP and context; on failure, it returns false (common failure causes: target process is not running, main module metadata is corrupted, or insufficient permissions to access process info).

python

call interface function:
>>> module.GetMainModuleEntry()
Return value of interface function (JSON):
{
	'message': 'Main module entry point (OEP) retrieved successfully',
	'main_module_entry_value': 5705843,
	'main_module_entry_hex': '0x00571073',
	'entry_desc': 'Original Entry Point (OEP) of the debugged main module - execution starts here',
	'platform': 'x86'
}

GetMainModuleBase

Retrieves the base address (starting memory address) of the main module (primary executable) of the target/debugged x86 process. The "main module" is the core executable that launched the process (e.g., test.exe, notepad.exe), not secondary DLLs or libraries. Unlike base address functions that require a module name or address (e.g., mod.GetBaseFromName, mod.GetBaseFromAddr), this function requires no parameters—it automatically targets the main module, making it ideal for quickly accessing the primary executable’s starting memory address in debugging, reverse engineering, or offset calculations. On success, it returns a dictionary with the base address and context; on failure, it returns false (common failure causes: target process is not running, main module metadata is corrupted, or insufficient permissions to access process memory info).

python

call interface function:
>>> module.GetMainModuleBase()
Return value of interface function (JSON):
{
	'message': 'Main module base address retrieved successfully',
	'main_module_base_value': 5636096,
	'main_module_base_hex': '0x00560000',
	'base_desc': 'Load base address of the debugged main module in memory',
	'platform': 'x86'
}

GetModuleAt

Retrieves the name of the loaded module associated with a specified memory address in the target x86 process, using the debugger-centric API DbgGetModuleAt under the hood. This function is similar to mod.GetNameFromAddr (both map an address to a module name) but differs in its underlying implementation—relying on debugger-specific logic that may yield slightly different results in edge cases (e.g., for modules with non-standard metadata). It is primarily used in debugging workflows to quickly identify the module containing a given address. On success, it returns a dictionary with the input address and module name; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or lack of debugger context).

python

call interface function:
>>> module.GetModuleAt("0x77D380F7")
Return value of interface function (JSON):
{
	'message': 'Module name at address retrieved successfully',
	'input_address_value': 2010349815,
	'input_address_hex': '0x77D380F7',
	'module_name': 'ntdll',
	'note': 'Relies on DbgGetModuleAt (may differ from NameFromAddr in edge cases)',
	'platform': 'x86'
}

GetWindowHandle

Retrieves the window handle (HWND) of the debugger’s own main window (not the debugged process’s windows) in the target x86 environment. A window handle (HWND) is a unique numerical identifier used by the Windows API to reference and manipulate windows (e.g., moving, showing, or closing them). Critical to note: this function returns the debugger’s window handle, not handles for the debugged process’s UI elements (e.g., the main window of notepad.exe being debugged). On success, it returns a dictionary with the handle and context; on failure, it returns false (common failure causes: debugger not initialized, no main window exists, or insufficient permissions to query window handles).

python

call interface function:
>>> module.GetWindowHandle()
Return value of interface function (JSON):
{
	'message': 'Debugger window handle retrieved successfully',
	'window_handle_value': 1508472,
	'window_handle_hex': '0x00170478',
	'handle_desc': "HWND of the debugger's main window (used for Windows API operations like ShowWindow)",
	'warning': "This is the debugger's own window handle, not related to the debugged process's modules",
	'platform': 'x86'
}

GetInfoFromAddr

Retrieves comprehensive metadata about the loaded module that contains a specified memory address in the target x86 process. Unlike single-purpose functions (e.g., mod.GetBaseFromAddr, mod.GetNameFromAddr) that return only one piece of module data, GetInfoFromAddr acts as a "one-stop shop"—it returns a full set of details (base address, size, name, path, section count) in a single call. This is critical for reverse engineering, debugging, and forensics, where quickly accessing all module properties from an address saves time. On success, it returns a dictionary with the input address and nested module info; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or module metadata is corrupted).

python

call interface function:
>>> module.GetInfoFromAddr("0x77D380F7")
Return value of interface function (JSON):
{
	'message': 'Module full info from address retrieved successfully',
	'input_address_value': 2010349815,
	'input_address_hex': '0x77D380F7',
	'module_info': {
		'base_address_value': 2009202688,
		'base_address_hex': '0x77C20000',
		'module_size_bytes': 1826816,
		'section_count': 8,
		'module_name': 'ntdll.dll',
		'module_full_path': 'C:\\Windows\\SysWOW64\\ntdll.dll'
	},
	'platform': 'x86'
}

GetInfoFromName

Retrieves comprehensive metadata about a specified loaded module (e.g., DLL, EXE) in the target x86 process, using the module’s name as the lookup key. This function acts as a "one-stop shop" for module details—unlike single-purpose functions (e.g., mod.GetBaseFromName, mod.GetSizeFromName), it returns a full set of properties (base address, size, section count, path) in a single call. A critical distinction from mod.GetInfoFromAddr (which uses an address) is that GetInfoFromName relies on the module’s name. Notably, the function includes a warning about potential consistency issues, requiring verification with other interfaces. On success, it returns a dictionary with the target module name and nested metadata; on failure, it returns false (common failure causes: module not loaded, invalid name, or corrupted metadata).

python

call interface function:
>>> module.GetInfoFromName("kernelbase.dll")
Return value of interface function (JSON):
{
	'message': 'Module full info from name retrieved successfully',
	'target_module_name': 'kernelbase.dll',
	'module_info': {
		'base_address_value': 1971585024,
		'base_address_hex': '0x75840000',
		'module_size_bytes': 2928640,
		'section_count': 6,
		'module_name': 'kernelbase.dll',
		'module_full_path': 'C:\\Windows\\SysWOW64\\KernelBase.dll'
	},
	'warning': "Original function marked 'has issues' - verify info consistency with other interfaces",
	'platform': 'x86'
}

GetAllModule

Retrieves a comprehensive list of all loaded modules in the target x86 process, along with detailed metadata for each module (e.g., base address, entry point, path, size). A "loaded module" includes the process’s main executable (e.g., test.exe) and all dependent DLLs (system DLLs like kernel32.dll, user DLLs like msvcr120d.dll). Unlike single-module functions (e.g., mod.GetInfoFromName), this function provides a holistic view of the process’s module dependencies, making it critical for debugging, reverse engineering, and forensics. On success, it returns a dictionary with a module count and a list of module details; on failure, it returns false (common failure causes: target process not running, insufficient permissions to query modules, or process termination during retrieval).

python

call interface function:
>>> module.GetAllModule()
Return value of interface function (JSON):
{
	'message': 'All loaded modules retrieved successfully',
	'total_module_count': 6,
	'note': 'Includes system DLLs (e.g., kernel32.dll) and user modules (e.g., notepad.exe)',
	'modules': [{
		'base_address_value': 5636096,
		'base_address_hex': '0x00560000',
		'entry_point_value': 5705843,
		'entry_point_hex': '0x00571073',
		'module_name': 'test.exe',
		'module_full_path': 'D:\\test.exe',
		'module_size_bytes': 114688
	},{
		'base_address_value': 2009202688,
		'base_address_hex': '0x77C20000',
		'entry_point_value': 0,
		'entry_point_hex': '0x00000000',
		'module_name': 'ntdll.dll',
		'module_full_path': 'C:\\Windows\\SysWOW64\\ntdll.dll',
		'module_size_bytes': 1826816
	}],
	'platform': 'x86'
}

Section functions

SectionCountFromName

Retrieves the number of PE sections in a specified loaded module (e.g., DLL, EXE) in the target x86 process, using the module’s name as the lookup key. PE sections are discrete, named blocks within a module’s structure (e.g., .text for executable code, .data for writable variables, .rdata for read-only data) that serve distinct purposes. This function is critical for reverse engineering and module analysis, as the number of sections provides insights into a module’s complexity, structure, and potential tampering (e.g., unexpected sections may indicate packing or malware). On success, it returns a dictionary with the module name and section count; on failure, it returns false (common failure causes: module not loaded, invalid name, or corrupted PE header).

python

call interface function:
>>> module.SectionCountFromName("kernelbase.dll")
Return value of interface function (JSON):
{
	'message': 'Module section count from name retrieved successfully',
	'module_name': 'kernelbase.dll',
	'section_count': 6,
	'count_desc': 'Number of PE sections in the module (e.g., .text, .data, .rdata)',
	'platform': 'x86'
}

GetMainModuleSectionCount

Retrieves the number of PE sections in the main module (primary executable) of the target/debugged x86 process. PE sections are discrete, named blocks within a module’s structure (e.g., .text for executable code, .data for writable variables) that serve distinct purposes. Unlike mod.SectionCountFromName (which requires a module name), this function exclusively targets the main module (the executable that launched the process) and requires no parameters. It is critical for analyzing the main executable’s structure, detecting tampering, or assessing complexity. On success, it returns a dictionary with the section count and context; on failure, it returns false (common failure causes: target process not running, main module metadata corrupted, or insufficient permissions).

python

call interface function:
>>> module.GetMainModuleSectionCount()
Return value of interface function (JSON):
{
	'message': 'Main module section count retrieved successfully',
	'main_module_section_count': 7,
	'count_desc': "Number of sections in the main module's PE file (e.g., .text, .data, .rdata)",
	'note': 'Main module refers to the debugged executable (e.g., notepad.exe)',
	'platform': 'x86'
}

SectionCountFromAddr

Retrieves the number of PE sections in the loaded module that contains a specified memory address in the target x86 process. PE sections are discrete, named blocks within a module (e.g., .text for executable code, .data for writable variables) that organize its code, data, and resources. This function works by first identifying the module containing the input address, then returning the count of its PE sections. It is critical for reverse engineering, debugging, and malware analysis—especially when you have a memory address but not the module’s name, and need to assess the module’s structure. On success, it returns a dictionary with the input address and section count; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or the module’s PE header is corrupted).

python

call interface function:
>>> module.SectionCountFromAddr("0x77D380F7")
Return value of interface function (JSON):
{
	'message': 'Module section count from address retrieved successfully',
	'input_address_value': 2010349815,
	'input_address_hex': '0x77D380F7',
	'section_count': 8,
	'count_desc': 'Number of PE sections in the module containing the input address',
	'platform': 'x86'
}

GetSectionFromAddr

Retrieves detailed metadata about a specific PE section in a loaded module, using two inputs: a memory address that identifies the module (e.g., the module’s base address) and a zero-based section index. PE sections are discrete blocks within a module (e.g., .text for executable code, .data for writable variables), and this function targets a single section to return its address, size, and name. It is critical for reverse engineering, debugging, and PE file analysis—where precise knowledge of section boundaries and purpose is essential. On success, it returns a dictionary with the module/section context and section-specific details; on failure, it returns false (common failure causes: invalid module address, out-of-range section index, or corrupted PE header).

python

call interface function:
>>> module.GetSectionFromAddr("0x75840000",0)
Return value of interface function (JSON):
{
	'message': 'Section info retrieved successfully',
	'module_address_value': 1971585024,
	'module_address_hex': '0x75840000',
	'section_index': 0,
	'section_info': {
		'section_address_value': 1971589120,
		'section_address_hex': '0x75841000',
		'section_size_bytes': 2582275,
		'section_name': '.text'
	},
	'note': 'Section index starts from 0 (0 = first section, e.g., .text)',
	'platform': 'x86'
}

GetSectionFromName

Retrieves detailed metadata about a specific PE section in a loaded module, using two inputs: the module’s name (e.g., "kernelbase.dll") and a zero-based section index. PE sections are discrete, purpose-built blocks within a module (e.g., .text for executable code, .data for writable variables), and this function targets a single section to return its memory address, size, and name. Unlike mod.GetSectionFromAddr (which uses a module address), GetSectionFromName relies on the module’s name—making it ideal when you know the module’s identity but not its memory address. It is critical for reverse engineering, debugging, and PE file analysis, where precise section boundaries and purpose drive analysis. On success, it returns a dictionary with module/section context and section-specific details; on failure, it returns false (common failure causes: invalid module name, out-of-range section index, module not loaded, or corrupted PE header).

python

call interface function:
>>> module.GetSectionFromName("kernelbase.dll",1)
Return value of interface function (JSON):
{
	'message': 'Section info from module name retrieved successfully',
	'module_name': 'kernelbase.dll',
	'section_index': 1,
	'section_info': {
		'section_address_value': 1974173696,
		'section_address_hex': '0x75AB8000',
		'section_size_bytes': 33680,
		'section_name': '.data'
	},
	'note': 'Section index starts from 0 (0 = first section, e.g., .text)',
	'platform': 'x86'
}

GetSectionListFromAddr

Retrieves a complete list of all PE sections in the loaded module that contains a specified memory address, along with detailed metadata for each section (e.g., start address, size, name). PE sections are discrete, purpose-built blocks within a module (e.g., .text for executable code, .data for writable variables), and this function provides a holistic view of the module’s section structure—unlike single-section functions (e.g., mod.GetSectionFromAddr) or count-only functions (e.g., mod.SectionCountFromAddr). It is critical for reverse engineering, PE file analysis, and debugging, where mapping all sections of a module is essential to understand its memory layout. On success, it returns a dictionary with the input address, section count, and a list of section details; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or the module’s PE header is corrupted).

python

call interface function:
>>> module.GetSectionListFromAddr("0x75AB8000")
Return value of interface function (JSON):
{
	'message': 'Module section list from address retrieved successfully',
	'input_address_value': 1974173696,
	'input_address_hex': '0x75AB8000',
	'section_count': 3,
	'sections': [{
		'section_address_value': 1971589120,
		'section_address_hex': '0x75841000',
		'section_name': '.text',
		'section_size_bytes': 2582275
	}, {
		'section_address_value': 1974173696,
		'section_address_hex': '0x75AB8000',
		'section_name': '.data',
		'section_size_bytes': 33680
	}, {
		'section_address_value': 1974243328,
		'section_address_hex': '0x75AC9000',
		'section_name': '.reloc',
		'section_size_bytes': 268792
	}],
	'platform': 'x86'
}

GetSectionListFromName

Retrieves a complete list of all PE sections in a specified loaded module (e.g., DLL, EXE) using the module’s name, along with detailed metadata for each section (e.g., start address, size, name). PE sections are discrete, purpose-built blocks within a module (e.g., .text for executable code, .data for writable variables), and this function provides a holistic view of the module’s section structure. Unlike mod.GetSectionListFromAddr (which uses a memory address to identify the module), GetSectionListFromName relies on the module’s name—making it ideal when you know the module’s identity but not its memory address. It is critical for reverse engineering, PE file analysis, and debugging, where mapping all sections of a module is essential to understand its memory layout. On success, it returns a dictionary with the module name, section count, and a list of section details; on failure, it returns false (common failure causes: invalid module name, module not loaded, or corrupted PE header).

python

call interface function:
>>> module.GetSectionListFromName("test.exe")
Return value of interface function (JSON):
{
	'message': 'Module section list from name retrieved successfully',
	'module_name': 'test.exe',
	'section_count': 3,
	'sections': [{
		'section_address_value': 5640192,
		'section_address_hex': '0x00561000',
		'section_name': '.textbss',
		'section_size_bytes': 65536
	}, {
		'section_address_value': 5705728,
		'section_address_hex': '0x00571000',
		'section_name': '.text',
		'section_size_bytes': 14579
	}, {
		'section_address_value': 5746688,
		'section_address_hex': '0x0057B000',
		'section_name': '.reloc',
		'section_size_bytes': 1266
	}],
	'platform': 'x86'
}

GetMainModuleInfoEx

Retrieves comprehensive extended metadata about the main module (primary executable) of the target/debugged x86 process. The "main module" is the core executable that launched the process (e.g., test.exe, notepad.exe), and this function consolidates critical details—base address, size, section count, name, and full path—into a single output. Unlike single-purpose main module functions (e.g., mod.GetMainModuleBase, mod.GetMainModuleSize), GetMainModuleInfoEx acts as an "all-in-one" tool for the main executable, streamlining workflows where holistic module data is needed. On success, it returns a dictionary with the main module’s extended info; on failure, it returns false (common failure causes: target process not running, main module metadata corrupted, or insufficient permissions).

python

call interface function:
>>> module.GetMainModuleInfoEx()
Return value of interface function (JSON):
{
	'message': 'Main module full info retrieved successfully',
	'main_module_info': {
		'base_address_value': 5636096,
		'base_address_hex': '0x00560000',
		'module_size_bytes': 114688,
		'section_count': 7,
		'module_name': 'test.exe',
		'module_full_path': 'D:\\test.exe'
	},
	'note': 'Main module refers to the primary executable being debugged',
	'platform': 'x86'
}

GetSection

Retrieves a complete list of all PE sections in the loaded module that contains a specified memory address, along with detailed metadata for each section (e.g., start address, size, name). This function is functionally equivalent to mod.GetSectionListFromAddr but uses a unified response format, making it consistent with other section-related functions. PE sections are discrete, purpose-built blocks within a module (e.g., .text for executable code, .data for writable variables), and GetSection provides a holistic view of the module’s section structure. It is critical for reverse engineering, PE file analysis, and debugging, where mapping all sections of a module is essential to understand its memory layout. On success, it returns a dictionary with the input address, section count, and a list of section details; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or the module’s PE header is corrupted).

python

call interface function:
>>> module.GetSection("0x77D380F1")
Return value of interface function (JSON):
{
	'message': 'Module section table from address retrieved successfully',
	'module_address_value': 2010349809,
	'module_address_hex': '0x77D380F1',
	'section_count': 2,
	'sections': [{
		'section_address_value': 2009206784,
		'section_address_hex': '0x77C21000',
		'section_name': '.text',
		'section_size_bytes': 1253957
	}, {
		'section_address_value': 2010464256,
		'section_address_hex': '0x77D54000',
		'section_name': 'RT',
		'section_size_bytes': 409
	}],
	'note': 'Function is functionally equivalent to GetSectionListFromAddr (unified response format)',
	'platform': 'x86'
}

Import/Export functions

GetImport

Retrieves a complete list of all PE sections in the loaded module that contains a specified memory address, along with detailed metadata for each section (e.g., start address, size, name). This function is functionally equivalent to mod.GetSectionListFromAddr but uses a unified response format, making it consistent with other section-related functions. PE sections are discrete, purpose-built blocks within a module (e.g., .text for executable code, .data for writable variables), and GetSection provides a holistic view of the module’s section structure. It is critical for reverse engineering, PE file analysis, and debugging, where mapping all sections of a module is essential to understand its memory layout. On success, it returns a dictionary with the input address, section count, and a list of section details; on failure, it returns false (common failure causes: input address is unallocated, not part of any loaded module, or the module’s PE header is corrupted).

python

call interface function:
>>> module.GetImport("test.exe")
Return value of interface function (JSON):
{
	'message': 'Import table of module retrieved successfully',
	'target_module_name': 'test.exe',
	'total_import_count': 3,
	'note': 'Imported functions are from other modules (e.g., user32.dll->MessageBoxA)',
	'import_functions': [{
		'function_name': '__dllonexit',
		'undecorated_function_name': '',
		'iat_va_value': 5738640,
		'iat_va_hex': '0x00579090',
		'iat_rva_value': 102544,
		'iat_rva_hex': '0x00019090',
		'function_ordinal': 4294967295
	}, {
		'function_name': '_onexit',
		'undecorated_function_name': '',
		'iat_va_value': 5738644,
		'iat_va_hex': '0x00579094',
		'iat_rva_value': 102548,
		'iat_rva_hex': '0x00019094',
		'function_ordinal': 4294967295
	}, {
		'function_name': '_invoke_watson',
		'undecorated_function_name': '',
		'iat_va_value': 5738648,
		'iat_va_hex': '0x00579098',
		'iat_rva_value': 102552,
		'iat_rva_hex': '0x00019098',
		'function_ordinal': 4294967295
	}],
	'platform': 'x86'
}

GetExport

Retrieves the export table of a specified loaded module (e.g., DLL, EXE) in the target x86 process. The export table lists functions that the module makes available for other modules to call (e.g., a DLL like kernelbase.dll exporting GetProcessId for use by notepad.exe). This is critical for understanding a module’s purpose (what functionality it provides), reverse engineering inter-module dependencies, or debugging function-call issues. On success, it returns a structured dictionary with the module’s export count and detailed metadata for each exported function; on failure, it returns false (common failure causes: module not loaded, invalid module name, or corrupted export table).

python

call interface function:
>>> module.GetExport("kernelbase.dll")
Return value of interface function (JSON):
{
	'message': 'Export table of module retrieved successfully',
	'target_module_name': 'kernelbase.dll',
	'total_export_count': 3,
	'note': 'Exported functions are callable by other modules (e.g., kernel32.dll->GetProcAddress)',
	'export_functions': [{
		'function_name': 'MsixIsSystemPackageByAppUserModelId',
		'forwarded_name': '',
		'undecorated_function_name': '',
		'is_forwarded': False,
		'function_va_value': 1973062160,
		'function_va_hex': '0x759A8A10',
		'function_rva_value': 1477136,
		'function_rva_hex': '0x00168A10',
		'function_ordinal': 1
	}, {
		'function_name': 'MsixIsSystemPackageByPackageFullName',
		'forwarded_name': '',
		'undecorated_function_name': '',
		'is_forwarded': False,
		'function_va_value': 1973194512,
		'function_va_hex': '0x759C8F10',
		'function_rva_value': 1609488,
		'function_rva_hex': '0x00188F10',
		'function_ordinal': 2
	}, {
		'function_name': 'PackageSidFromProductId',
		'forwarded_name': '',
		'undecorated_function_name': '',
		'is_forwarded': False,
		'function_va_value': 1973806400,
		'function_va_hex': '0x75A5E540',
		'function_rva_value': 2221376,
		'function_rva_hex': '0x0021E540',
		'function_ordinal': 3
	}],
	'platform': 'x86'
}

Module interface ​

Module functions ​

GetModuleBaseAddress ​

GetModuleProcAddress ​

GetBaseFromAddr ​

GetBaseFromName ​

GetSizeFromAddress ​

GetSizeFromName ​

GetOEPFromName ​

GetOEPFromAddr ​

GetPathFromName ​

GetPathFromAddr ​

GetNameFromAddr ​

GetMainModulePath ​

GetMainModuleSize ​

GetMainModuleName ​

GetMainModuleEntry ​

GetMainModuleBase ​

GetModuleAt ​

GetWindowHandle ​

GetInfoFromAddr ​

GetInfoFromName ​

GetAllModule ​

Section functions ​

SectionCountFromName ​

GetMainModuleSectionCount ​

SectionCountFromAddr ​

GetSectionFromAddr ​

GetSectionFromName ​

GetSectionListFromAddr ​

GetSectionListFromName ​

GetMainModuleInfoEx ​

GetSection ​

Import/Export functions ​

GetImport ​

GetExport ​

Module interface

Module functions

GetModuleBaseAddress

GetModuleProcAddress

GetBaseFromAddr

GetBaseFromName

GetSizeFromAddress

GetSizeFromName

GetOEPFromName

GetOEPFromAddr

GetPathFromName

GetPathFromAddr

GetNameFromAddr

GetMainModulePath

GetMainModuleSize

GetMainModuleName

GetMainModuleEntry

GetMainModuleBase

GetModuleAt

GetWindowHandle

GetInfoFromAddr

GetInfoFromName

GetAllModule

Section functions

SectionCountFromName

GetMainModuleSectionCount

SectionCountFromAddr

GetSectionFromAddr

GetSectionFromName

GetSectionListFromAddr

GetSectionListFromName

GetMainModuleInfoEx

GetSection

Import/Export functions

GetImport

GetExport