Adds a user breakpoint. This fails when called from a breakpoint-handler (such as On_BP_0()). pdwId will be filled with the ID of the breakpoint if the function is successful. The ID of the breakpoint is required to remove the breakpoint later. This parameter can be NULL. lpbpBreakpoint->iType can be SPBT_EXECUTE, SPBT_READ, or SPBT_WRITE. lpbpBreakpoint->iProlog, lpbpBreakpoint->iCallback, and lpbpBreakpoint->iEpilog can be one of:
SYS_FUNCS_DO_NOTHING, SYS_FUNCS_BEEP, SYS_FUNCS_BREAK, SYS_FUNCS_SETCF, SYS_FUNCS_SETPF, SYS_FUNCS_SETAF, SYS_FUNCS_SETZF, SYS_FUNCS_SETSF, SYS_FUNCS_SETOF, SYS_FUNCS_SCRIPT_FUNC, or SYS_FUNCS_CUR_PROC_SCRIPT_FUNC. lpbpBreakpoint->dwNewParms[0] is the parameter for the iProlog function, lpbpBreakpoint->dwNewParms[1] is the parameter for the iCallback function, and lpbpBreakpoint->dwNewParms[2] is the parameter for the iEpilog function. lpbpBreakpoint->pcName points to the optional name for the breakpoint. This can be NULL. lpbpBreakpoint->bHardware determines whether the new breakpoint should be hardware or software. Only 4 hardware breakpoints can be set. Any number of software breakpoints can be set but each modifies the RAM of the target process. lpbpBreakpoint->bSet determines whether the breakpoint is active or not. lpbpBreakpoint->aAddress indicates the address of the breakpoint. If another breakpoint is already on the supplied address, AddBreakpoint fails. lpbpBreakpoint->dwRange indicates the total number of addresses to cover. This is valid only for software read/write breakpoints. This indicates that X number of addresses from aAddress can cause breaks when read/written. lpbpBreakpoint->bUseCondition indicates whether the condition is used. lpbpBreakpoint->pcCondition points to a string representing the condition for the breakpoint. This can be NULL.
BOOL AttachDebugger()
Attaches the Debugger to the current process. Returns TRUE if the attach was successful or if the Debugger was already attached. This must not be called from a breakpoint handler.
Opens an executable file for debugging. This must not be called while opening or closing a process or from a breakpoint handler.
VOID DetachDebugger()
Detaches the Debugger from the current process. This must only be called from a hotkey.
VOID EnterSingleStep()
Enters the Debugger into single-stepping mode. The Debugger will wait for human input before continuing. This must be called from within a breakpoint handler.
Searches the target process’ module list for a module beginning at the specified address and, if found, fills the supplied MODULEENTRY32 structure with its data. pme32Return can be NULL. This function uses a binary search and is extremely fast, but not always up-to-date unless the Debugger is active.
Searches the target process’ module list for a module matching the specified name and, if found, fills the supplied MODULEENTRY32 structure with its data. pme32Return can be NULL. This function uses a binary search and is extremely fast, but not always up-to-date unless the Debugger is active.
Searches the target process’ module list for a module covering the specified address and, if found, fills the supplied MODULEENTRY32 structure with its data. pme32Return can be NULL. This function uses a binary search and is extremely fast, but not always up-to-date unless the Debugger is active.
Returns the address of the specified function within the target process. If there is no target process or the module or function does not exist, the return value is MHS_NULL. The module name is case-insensitive.
Injects the specified DLL into the target process. If bAutoUninject is TRUE the DLL will be uninjected when Memory Hacking Software detaches from the target process.
BOOL IsDebugging()
Returns TRUE if the Debugger is currently active.
BOOL IsStepping()
Returns TRUE if the Debugger is in single-stepping mode.
BOOL RemoveBreakpoint(
DWORD dwId)
Removes a breakpoint by its ID. This fails when called from within a breakpoint handler.
VOID StepOnce()
Causes the Debugger to single-step one instruction if it is in single-stepping mode. The breakpoint handler that was originally used to put the thread into single-stepping mode is not triggered as a result of this call, however if single-stepping results in a breakpoint being hit, that breakpoint’s handlers will be called. This should not be called from a breakpoint handler.
VOID StepOver()
Causes the Debugger to step over a function CALL if it is in single-stepping mode. If the next instruction is not a CALL, this behaves the same as StepOnce. The breakpoint handler that was originally used to put the thread into single-stepping mode is not triggered as a result of this call, however if stepping over results in a breakpoint being hit, that breakpoint’s handlers will be called. This should not be called from a breakpoint handler.
VOID StopStepping()
Causes the Debugger to leave single-stepping mode, if already in it.
