Establish a breakpoint address

[live2play]

What is the easiest/best way to establish a good breakpoint for a particular part of a game that you want to hack?

[dcx2]

In the future, this kind of question probably belongs in this forum instead.

Find an interesting value in memory and use read/write breakpoints.

Sometimes it's hard to find "interesting values" because the game doesn't always tell you the value you're interested in.  In such a case, look for values near interesting values.  If it tells you magic points but not hit points, search for magic points and the hit points are probably located close by in memory.

For a real life example, hawkeye made this code for Tales of Symphonia that changes the color of the cracks in the screen when you start a fight.  With it, you could make the cracks any color you want.  The important bit was that he found the address of the colors.  Why is this important?

Normal encounters have grey cracks, but if you surprise the enemy the cracks are green instead.  "Interesting value" - type of encounter I will have.  "Value near interesting value" - color of the screen cracks during encounters.

I set a write breakpoint on the color of the screen cracks and found the code that was making the cracks green.  From here, I was able to trace back and find the code that determines what type of encounter (you surprise enemy, enemy surprises you, none), and then I could write a code for "always surprise attack enemies".

[live2play]

Thanks.  That's exactly the problem.  Trying to find the address itself.  In the example you gave, the address for the color of the cracks was found.  However, I'm sure that he wasn't able to search for "gray" or "green" in WiiRD to find that.  In the case of hit points or helth points, that's easy as you can search for the numeric value.  Let's say you wanted to find the address for an explosion timer that's not displayed on the screen.  So, for instance, you throw a bomb and it takes ~4 seconds before it explodes.  How would you go about finding the address for the timer in that case?

[dcx2]

You could watch your own health while you blow yourself up with a grenade.

There are other ways to find timers.  They take some finesse to find.  You can't use the "Next" button because it sometimes skips two frames.

Set an execute breakpoint on 800018A8.  This is the entrance to the code handler and always breaks once per frame.

Throw your grenade.  Then set the breakpoint to pause the game.  Search memory for an unknown value.  Go back to Breakpoint and hit Set Breakpoint *twice* - for some reason the first breakpoint after a search is fake.  Then go back to code search and look for values that are different by 1.  Note that this will catch values different by +1 *AND* -1 so you can find up or down counters.

Repeat this process a few times (double-breakpoint, codesearch for different by 1).  You'll probably only have a few results after four or five tries.

I believe the game runs at 30 FPS, so for a timer of 4 seconds, you're looking for values less than 120.  Add a little extra just to be safe, and you can be pretty sure that any values greater than 200 are probably not what you're looking for.

It's *probably* a 16-bit counter, so I would search 16-bit values first, but unfortunately, 200 can be an 8-bit unsigned value, so if you can't find it with a 16-bit search then try 8-bit.

[live2play]

Great information!  Very well stated!  So, when you say,

I believe the game runs at 30 FPS, so for a timer of 4 seconds, you're looking for values less than 120.  Add a little extra just to be safe, and you can be pretty sure that any values greater than 200 are probably not what you're looking for.

, you mean the actual value at the memory addresses that are left after the 4 or so double-breakpoint/search cycles, right?  So, I wouldn't expect to see a zero at those addresses given that the timer starts at 4 and counts down to 0?

[dcx2]

The timer doesn't start at 4.  The timer counts "frames".  There are not 4 frames between you throwing the grenade and its explosion.  It's closer to 120 frames.  That's why I said anything over 200 probably won't be your timer and can be safely ignored.

If you find the timer there's an easy way to make sure.  Watch in Memory Viewer after you throw a grenade with Auto-Update.  You should see the value counting down rapidly, with an explosion when it reaches 0.

[live2play]

Excellent!  Thanks again!

[live2play]

Once the breakpoint hits and I've performed my search, do I then select Run from the breakpoint screen or Next?

[wiiztec]

You do the search to find the value to set a breakpoint on not the other way around

[dcx2]

Timers are easy to find because they change by 1 every frame.  The problem is reliably going 1 frame at a time.

You can't use "Run" because then the game runs and the counter starts counting down by more than 1 before you can search.

You can't use "Next" because sometimes it skips two frames.  It's unreliable in the long run.  It's difficult to explain exactly why, if you don't believe me press next yourself and you'll see it skip two frames eventually.

Once upon a time, Link made an excellent point.  The code handler is executed once per frame.  If you Set Execute Breakpoint on the entrance of the code handler (800018A8) you will hit each frame exactly once, at the same point in the code. 

This is why we are doing the breakpoint first.  It is the only reliable way to move exactly one frame at a time with WiiRDGUI.

Instead of Breakpoint, think of it as a really complicated Pause/Next button (hopefully Gecko dotNET will incorporate a more reliable Next Frame).  Each time we stop the game, we want to see exactly one frame go forward *.  Your timer will be 1 less (or 1 more, in rare instances).   Now you can search for "different by 1".

But what is the value to start with?  We don't know.  Your rough guess gives us an upper limit, though.  4 seconds is 120 frames, but a really high estimate won't hurt us so I rounded up to 200.  You could even start with an unknown search, not specifying any value at all.

So, recap...

1) Execute Breakpoint on Code Handler to pause the game
2) Search for values less than rough guess (200 in this case)
3) Execute Breakpoint on Code Handler to step one frame
4) Search for values different from the last value by 1
5) If you have too many values, repeat steps 3-4

* - Okay, so WiiRDGUI has this weird bug where, if you were paused in a breakpoint (like 1), and you do a code search (like 2), then the next time you hit Set Breakpont (like 3) you won't actually see the game go forward by one frame.  If you hit a breakpoint, then code search, the very next breakpoint after the code search is fake.  You won't see any frame movement.  You need to hit Set Breakpoint again, then the frame will go by, then you can do another search for different by 1.

Oh, by the way.  Don't hit Set Breakpoint too fast.  Don't switch tabs too quickly after hitting breakpoints, either.

...Okay, this is kinda complicated.  Maybe I should do a video tutorial or something...

[live2play]

Thanks for the clarification.  I do appreciate it.  So, I don't want to have the breakpoint set until after I perform the action (e.g. throw the bomb), right?  Also, you said,

I believe the game runs at 30 FPS

.  However, each time I press Set Breakpoint, I only go forward one frame, right?  If this is the case, then when you said,

I believe the game runs at 30 FPS, so for a timer of 4 seconds, you're looking for values less than 120

, it would seem that the timer would have only moved as much as one frame's worth which at 30FPS, that would be 1/30th of a second.  If this is true, the timer wouldn't have gone even a second's worth for each Set Breakpoint, right?

[live2play]

One more question....  Do I throw the bomb just prior to the following steps?  If so, I'm guessing that I have to perform step 1 below just before I believe that the timer has started, right?

1) Execute Breakpoint on Code Handler to pause the game
2) Search for values less than rough guess (200 in this case)
3) Execute Breakpoint on Code Handler to step one frame
4) Search for values different from the last value by 1
5) If you have too many values, repeat steps 3-4

[live2play]

I think I understand now.  Is my thinking correct in assuming that I would search for less than 200 as when the game is normally running (30 FPS), a timer of 4 seconds would have to be a value of 120 so that when 4*30FPS passed, the timer would expire?  Also, would I search for a 200 decimal or C8?

[dcx2]

Yes, you're starting to get it.   ;D  30 Frames/Second * 4 Seconds = 120 Frames, and choosing 200 = 0xC8 gives us lots of breathing room in case you estimate the time wrong.

You could also start with an unknown search.  Starting with less than 200 gets rid of a lot of results though.

Finally, we want to be as precise as possible when doing this, and we want the timer to already have started.  So, throw your grenade just prior to 1.  Make sure it has left your hand before you pause the game, or you might pause before the timer starts.

[live2play]

I understand all of it except for the searching for different by 00000001.  If the number is, for example, 120, it would be 90 after 30 frames, right.  If so, what would it be after one frame?