Page 1 of 1

Using AddBreakpoint()... having trouble.

PostPosted: Thu Mar 05, 2009 11:26 am
by CodeMaster.Rapture
So I've got this little script:

Code: Select all
VOID On_Open_FOO_EXE( HANDLE hHandle, DWORD dwProcess )
{
   PrintF("Foo opened!");
   if (!AttachDebugger())
   {
      PrintF("Failed to attach debugger!");
      //return;
   }
   
   SCRIPT_ADD_BP bp1 = {0};
   bp1.pcName = "Breakpoint 1";
   bp1.aAddress = 0x1234567;
   bp1.iType = SPBT_EXECUTE;
   bp1.bHardware = true;
   bp1.iProlog = SYS_FUNCS_SCRIPT_FUNC;
   bp1.dwNewParms[0] = 1;
   bp1.bSet = true;
   if (AddBreakpoint(&bp1, NULL))
      PrintF("BP 1  set!");

   SCRIPT_ADD_BP bp2 = {0};
   bp2.pcName = "Breakpoint 2";
   bp2.aAddress = 0x1234560;
   bp2.iType = SPBT_EXECUTE;
   bp2.bHardware = true;
   bp2.iProlog = SYS_FUNCS_SCRIPT_FUNC;
   bp2.dwNewParms[0] = 1;
   bp2.bSet = true;
   if (AddBreakpoint(&bp2, NULL))
      PrintF("BP 2 set!");
   
    return;
}

void On_BP_1(LPVOID lpvAddress, LPPROC_INFO_MHS lpProcInfo)
{
   lpProcInfo->pcContext->Eax = 0x40;
   lpProcInfo->bSetContext = true;
}

void On_BP_2(LPVOID lpvAddress, LPPROC_INFO_MHS lpProcInfo)
{
   lpProcInfo->pcContext->Eax = 0x40;
   lpProcInfo->bSetContext = true;
}


For some reason, this either:
a.) crashes my game or
b.) BP 2 will not be set to hardware, even tho it is set correctly above.

What am I doing wrong?

PostPosted: Sun Mar 08, 2009 7:54 am
by CodeMaster.Rapture
Good talk, thanx.

PostPosted: Sun Mar 08, 2009 9:39 am
by minorutono
CodeMaster.Rapture wrote:Good talk, thanx.


Just wait for L.Spiro to answer. He has a life too >..< give him time..

I'd help but I'm to noob to know LSS yet.

PostPosted: Mon Mar 09, 2009 6:19 am
by L. Spiro
It crashes your game because your addresses are invalid.
Setting valid breakpoints is your responsibility.

As for why it will not go into hardware mode, it most likely means you already have the maximum number of allowed hardware breakpoints.


L. Spiro

PostPosted: Tue Mar 10, 2009 4:05 am
by CodeMaster.Rapture
Actually, my breakpoints are valid. I've set them manually multiple times. Moreover, I have ensured I do not have any hardware breakpoints set before the script is run. On top of that, I have a few wierd bugs with this version:

1.) Using Vista Ultimate x32 SP1, the debugger takes anywhere from 30 seconds to 15 minutes to attach to a process (I've tried many, including calc and notepad). I've tried toying with the many options to no avail.

2.) When I go to an address (CTRL+G in disassembler), it will go to that address but will not allow me to set NOPs or assemble. It goes through the motions but nothing happens at that address.

3.) Auto-Inject will fail to alloc memory for a code cave.

As for the topic at hand, I was wondering if the script treats the game's memory space as literal to that module (i.e. game.exe+0x41000 is 0x81000, the address I want to BP). I've been trying to use FindModuleByName(), but it will not allow me to use pme32Return.modBaseAddress + 0xSomeNumbersHere due to array/struct compatibility.

What did I miss in the helpfile? Please excuse my ignorance.

-CMR

PostPosted: Tue Mar 10, 2009 9:51 am
by L. Spiro
Which version are you using?
If it is the latest I can make a quick check to ensure that the structure in the script matches the internal one for setting breakpoints. That would be the only explanation I can imagine at this time.

Try closing the Helper window before attaching the Debugger. The part of the Debugger that takes the longest to do is updating the module lists in the Import/Export sections. Closing the Helper window allow you to check to see if that is the problem or not. Windows Vista uses an unreasonable amount of modules in every process, including small ones, so it takes significantly longer to parse each module and fill the TreeBox with their informations.

If you can not modify code for any reason, use File/Properties and set the chunks of interest to full access, or at least to something writable.

Normally the only way an allocation can fail is if the game has protections to prevent it.


L. Spiro

PostPosted: Tue Mar 10, 2009 11:26 am
by CodeMaster.Rapture
L. Spiro wrote:Which version are you using?
If it is the latest I can make a quick check to ensure that the structure in the script matches the internal one for setting breakpoints. That would be the only explanation I can imagine at this time.


I'm using 5.6.0 Pro. How do I go about checking the structure? I would assume scripting something similar to BaseAddress = FindBaseAddressOfModule("game.exe"); would work, but alas, no such function exists.

L. Spiro wrote:Try closing the Helper window before attaching the Debugger. The part of the Debugger that takes the longest to do is updating the module lists in the Import/Export sections. Closing the Helper window allow you to check to see if that is the problem or not. Windows Vista uses an unreasonable amount of modules in every process, including small ones, so it takes significantly longer to parse each module and fill the TreeBox with their informations.


Wow. That fixed that issue! I was assuming it was a module population issue, never thought to close the helper window! Thanx! I wonder what can be done to fix/speed up that issue.

L. Spiro wrote:If you can not modify code for any reason, use File/Properties and set the chunks of interest to full access, or at least to something writable.

Normally the only way an allocation can fail is if the game has protections to prevent it.


These two issues seem related. I did try changing the chunk which did nothing. The issue seems to sort itself out if I goto multiple addresses first and the back to what I want to modify or if I keep trying to NOP said address, it will finally allow it after 7-8 tries (sometimes). As in, where it goes to and highlights isn't allowed to be modified. Maybe something isn't being set to allowed/true?

PostPosted: Wed Mar 11, 2009 5:54 am
by CodeMaster.Rapture
I was wrong, closing the helper window didn't fix it.

Also, I still can't add my breakpoints via script :/

PostPosted: Thu Mar 12, 2009 8:44 am
by L. Spiro
You can not look into the structure issue; only I can do that.

I will look into the other issues as well and possibly release a new version.


L. Spiro

PostPosted: Mon Mar 23, 2009 2:28 pm
by L. Spiro
I could not find the reason for breakpoint failure via scripts. It all works the same exact way as in the MHS core.

Give a detailed description of the problem and when it works and when it does not.


L. Spiro