I did not see this post until just now.
I assume it is because of bots—when I have to waste my time deleting their posts, the forum doesn’t show me all the other messages I didn’t see.
I wouldn’t be able to tell exactly what it is unless you post a link to allow me to do more reading on it.
What I see offhand:
The first 8 characters are an address, of course.
Next you have ZF, PF, or EIP.
ZF and PF are flags in the EFLAGS register of a thread context.
ZF is bit 6 and PF is bit 2 (zero-based indices).
These are used for conditional checking.
For example, if ZF is 1, it means the last comparison operation was with a value equal to 0. If PF is 1, the last comparison operation had even parity.
How these could be used to help them hack is not necessarily clear, except that it can replace a condition-jump injection.
CMP sets these bits in the EFLAGS register, after which JNE, JNZ, etc. use them to determine if a jump should be taken.
If the debugger sets a hardware breakpoint and changes these flags when hit, it can force the condition to be met every time, causing the jump to always be taken, and without modifying RAM.
EIP (extended instruction pointer) is the instruction pointer—it indicates the actual location where instructions are being executed on a thread.
PF and ZF are followed by block values. It is unclear what these would do, since PF and ZF can only be 0 or 1.
EIP is followed by an address.
This is most likely the address where EIP is to be set after the first address is hit.
By doing this, it can yet again emulate a JMP without actually modifying RAM.
As for whether or not it can be done in my software, yes.
Differently, but the result is the same.
In my software, to perform these operations, you would set hardware breakpoints on the addresses they give you, then set the callback function to a script function.
Write a script that will be called when that breakpoint is hit.
The script function will be given a CONTEXT pointer that you can modify.
Modify the EFLAGS or EIP as you wish.
In the end, you would achieve the same thing they are doing, which is to force JNZ, JNE, etc., commands to be taken without modifying RAM.
The reason to avoid modifying RAM is to avoid being detected.
A breakpoint function in my software looks like this:
- Code: Select all
VOID On_BP_1( LPVOID lpvAddress, LPPROC_INFO_MHS lpProcInfo ) {
// Set ZF.
lpProcInfo->pcContext |= (1 << 6);
// Unset ZF.
lpProcInfo->pcContext &= ~(1 << 6);
// Set PF.
lpProcInfo->pcContext |= (1 << 2);
// Unset PF.
lpProcInfo->pcContext &= ~(1 << 2);
// Tell MHS that you modified the context and it will set the thread
// context for you. This helps you save time in the script to make
// everything faster.
lpProcInfo->bSetContext = TRUE;
}
Add that to the scripts, then select the “
Script Function” function for the
Callback Function and set the
Parm to 1 (the breakpoint will call On_BP_
1 because of this).
Modify my code as necessary of course.
You wouldn’t want to set AND unset the flags.
L. Spiro
