Using AddBreakpoint()... having trouble.

Ask for Help on Using the Language With Memory Hacking Software

Moderators: g3nuin3, SpeedWing, WhiteHat, mezzo

Using AddBreakpoint()... having trouble.

Postby CodeMaster.Rapture » Thu Mar 05, 2009 11:26 am

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?
CodeMaster.Rapture
Hackleberry Fin
 
Posts: 20
Joined: Sun Mar 16, 2008 2:15 pm

Postby CodeMaster.Rapture » Sun Mar 08, 2009 7:54 am

Good talk, thanx.
CodeMaster.Rapture
Hackleberry Fin
 
Posts: 20
Joined: Sun Mar 16, 2008 2:15 pm

Postby minorutono » Sun Mar 08, 2009 9:39 am

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.
User avatar
minorutono
i R t3h nUB!!111
 
Posts: 944
Joined: Thu Apr 17, 2008 10:10 am
Location: 2845 Vista Verde Way Cameron Park CA 95682

Postby L. Spiro » Mon Mar 09, 2009 6:19 am

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
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3122
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby CodeMaster.Rapture » Tue Mar 10, 2009 4:05 am

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
CodeMaster.Rapture
Hackleberry Fin
 
Posts: 20
Joined: Sun Mar 16, 2008 2:15 pm

Postby L. Spiro » Tue Mar 10, 2009 9:51 am

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
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3122
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby CodeMaster.Rapture » Tue Mar 10, 2009 11:26 am

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?
CodeMaster.Rapture
Hackleberry Fin
 
Posts: 20
Joined: Sun Mar 16, 2008 2:15 pm

Postby CodeMaster.Rapture » Wed Mar 11, 2009 5:54 am

I was wrong, closing the helper window didn't fix it.

Also, I still can't add my breakpoints via script :/
CodeMaster.Rapture
Hackleberry Fin
 
Posts: 20
Joined: Sun Mar 16, 2008 2:15 pm

Postby L. Spiro » Thu Mar 12, 2009 8:44 am

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
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3122
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby L. Spiro » Mon Mar 23, 2009 2:28 pm

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
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3122
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan


Return to Help

Who is online

Users browsing this forum: No registered users and 1 guest

cron