tonka4ok wrote: ↑Sun Jan 02, 2022 11:52 pm
Just wondering one thing, you mentioned exception breakpoints, how are they actually useful in the current scenario? Aren't they triggered upon an exception occurrence? Or am I wrong?
When you debug some on-screen value (read/write, hardware or software breakpoint -- most people use VEH) you usually end-up with a series of instructions accessing (reading/writing from/to) your address. Then you see something like this: "cmp byte ptr [rcx+750],1". Instantly you will say "well, rcx is base, so let me see what's there". In modern games, this is a
structure that has a certain layout.
The first element you will often find at "rcx" (meaning offset 0 of rcx structure; and by "rcx" I mean the ADDRESS shown in RCX register) is the
member-functions or
virtual functions table pointer. Simplified, there's an address at offset 0x00 that points to a table of addresses. These are addresses to functions that can be executed in the context of your "rcx" address. Why are these useful? Because if you inspect the executable code of these functions, you might find OTHER offsets of interest within our "rcx" structure.
Since most games are not shipped with debug symbols, you won't know what the layout of that structure is. Namely, what's the structure called and what are the elements called and at which offset within your structure. Sure, CE can help identify them by RTTI when possible, but it doesn't happen for a lot of games. Please be advised that we're not talking
Unity Engine here, as for that Engine CE operates differently (using mono, which gives out a shit ton of information).
To find out which offsets are being used by the game on THOUGHT-OF events, you would want to use exception breakpoints. How does this work? Well, your address is part of allocated memory. If you check Memory View > View > Memory Regions you will see which region (or PAGE) your "rcx" address is a part of. Exception breakpoints would be set over a defined range in that "rcx" of yours, ergo in that page. When the game Engine code attempts to access (read/write) an address and the data in it in YOUR RANGE, it will trigger an exception. That exception will then report the "culprit" (which piece of executable code tried to use that location) in the debug window. And you get a big ass list of said instructions.
Case in point: I see my health is 100 on screen. Scan for it, find it, debug it. Get hit and I see this: "sub [rcx+250],1". Every time I get hit, 1 point is subtracted from [rcx+250]. "rcx" becomes our address. Say our RCX is 0x25F800420 (an address). What we do then is go to it in Memory View, bottom part (hex dump) and Ctrl+G > 25F800420. Then press Ctrl+Enter so you see the offsets on the left-hand side. After this, make a selection by dragging the mouse from +00000000 till an offset of your choice: +00000310. Then right-click OVER THE BYTES and pick Data Breakpoint > Exception Breakpoint.
It will look kinda like this (ignore the ?? in the picture, for you there will be valid data there):
What that will do is to set a watch-dog over the range you've selected and every time the game Engine executable code tries to access (read/write) a byte/word/dword/qword/etc. in that red range, the said executable code will show up in the debug window. Just like normal debugging. So why is this good? Cuz you will get to see which offset in your "rcx" structure is being used and what for.
DO NOT USE
F5 BREAKPOINTS WHILE EXCEPTION BREAKPOINTS ARE ACTIVE. You won't be able to step through executable code. If you forgot you've switched to exception breakpoints, just Ctrl+B in Memory View, delete all breakpoints in that list (also right-click and "Show shadow breakpoints"), then right-click in hex dump and change Data Breakpoint to Hardware Breakpoint.
Long story short: your structure is part of a page. Imagine a sheet of paper with text on it. At the middle of the page there is a paragraph. That paragraph is your structure. You want to find out what accesses each of the letters in that ENTIRE paragraph. That's how exception breakpoints work.
Lastly, be advised that when you use exception breakpoints over ranges, there will be executable code that will CONSTANTLY read certain offsets. And that will make the game lag. If you don't freak out instantly "omg, my game froze" and have patience, you will see that the screen refreshes, even if after 20-30s and by 1 frame. Just have patience. Then, to find as much as possible (what's used), I recommend DOING A LOT OF ACTIONS in-game while the exception breakpoint is active. For example, if I debug my Weapon structure, I usually fire the weapon, hide/show weapon (if action is doable), reload, change weapons, throw weapon on ground, pick it back up, etc. All the actions you can think of. Then when you get back to CE you will have a big ass list of instructions in the debug window
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Past that it's your job to inspect them all (I usually copy-paste them to Notepad++ to inspect later on; what if the game crashes?).
Cheers,
Sun