How to read the extended debug info?

[FrechetDerivative]

Occasionally a game may be shipped with an associated program database (.pdb) file that Cheat Engine can parse. Opening up the Memory View, Cheat Engine will parse the symbols, and then load in the extended debug information.
How to make sense of the additional information obtained after the extended debug info has been loaded?

Take the game Expeditions: Rome as an example.
Here is a screen shot where a function has already been annotated with additional debug info parsed by Cheat Engine.

What is it trying to say to me? Does that mean, when I call the function, I should have an pointer to a URomeCheatManger object stored in RCX and at [RSP+40] location?

[LeFiXER]

Your image isn't loading.

[FrechetDerivative]

Thank you for letting me know @LeFiXER!
If you right click on the word "Image", then open it in another tab, the image will show. I don't know why the forum doesn't load it...

For completeness, I will type out the additional debug info generated here:

URomeCheatManager this (RCX)
URomeCheatManager this (RSP+40)
TArray<UItemDefinition *, TSizedDefaultAllocator<32> > AllItems (RSP+20)
UInventory PartyIventory
UItemDefinition <begin> $L0
UItemDefinition <end> $L0
UItemDefinition Item
UItem SchematicItem

[LeFiXER]

This is setting up the stack with those parameters. I'm not sure if the parameters are pushed onto the stack in reverse order or if it is sequential but the registers will hold the pointers/data for those parameters.

[FrechetDerivative]

This is setting up the stack with those parameters.

I am not sure about this...

Ghidra says this function only accepts 1 argument, which is a URomeCheatManger object named `this`. I can see how it should be stored at the RCX register given the x64 calling convention. So maybe the first line of the extended debug info is telling me about this.

The rest doesn't appear to be function arguments left on the stack required for this function. In addition to violating the calling convention, the first few lines of that function are:

mov [rsp+08],rbx
mov [rsp+10],rbp
mov [rsp+18],rsi
mov [rsp+20],rdi

And at the end of the function, prior to return, those values are them moved from stack into respective registers.

If they were arguments, then they are immediately overwritten.


I guess I am just very confused by writing my own script call this function. I thought I have passed the right argument to the right register prior to calling the function, but the game crashes immediately. Perhaps, since this function is not used by the game itself, it may contain bugs that caused the crash? In other words, I called the function properly, but the code itself had errors that crashed, at no fault of my own.

[SunBeam]

Learn how Unreal Engine works. Your game came shipped with that pdb out of accident or be it cuz the developers wanted.

What you need to understand is you need to learn how to code your own test program in C++ (use Visual Studio for that) and compile it with debug symbols. Then see how those symbols match what you see in the debugger. I recommend using x64dbg, as CE is a bit cumbersome for a debugger.

Once you really get the idea behind a pdb and can obtain relevant reverse engineering information out of it (hack your own program using a debugger and the pdb symbols), then you will begin to understand how it applies in other software/games. There's no shortcut to understanding everything in record time, so it's all a matter of how much you understand and taking it slowly, phased. Not rushed cuz you want some cheat done.

[S1N74X]

This is setting up the stack with those parameters.

I called the function properly, but the code itself had errors that crashed, at no fault of my own.

Iam not sure what your Script does, but did you save the Flags with pushf and restored them with popf ?
Gamecrashes are sometimes a hint that flags were not properly set.

[SunBeam]

Iam not sure what your Script does, but did you save the Flags with pushf and restored them with popf ?
Gamecrashes are sometimes a hint that flags were not properly set.

I've been seeing this quite a few times with some people, as some sort of rule. If you intend to use pushf/popf as a personal practice, then please don't promote it or suggest it as some attempt to fix crashes.

Saving and restoring flags matters only when you know for certain the next instruction after your code cave is going to be an instruction that uses the flags (so you'd need to restore their original states). Like a JE or JNE. Other than that, it makes no sense to save/restore them. But hey, if you are stubborn, don't care for others' opinions and act like "I know better" so you won't change your mentality when addressed, then that's that. Lastly, using this where not required is also an indication of poor ASM knowledge on the user end.

Here's an example.

Code: Select all

addr:
mov rax,[rcx+2B0]
test rax,rax
je L1

So you want to hook the 2 lines above, but not the JE:

Code: Select all

cave:
mov rax,[rcx+2B0] // original
test rax,rax // original
mov rcx,[rax+200]
test rcx,rcx // at this point you've changed the original zero flag (ZF)
jmp back

addr:
jmp cave
je L1
back:

So with the above implementation (which is a very poor implementation) you're changing the ZF inside the cave. Based on rcx's value (null or not), ZF will be 0 or 1. Because of "test rcx,rcx". So when the "jmp back" occurs (which doesn't affect any flags), the "je L1" can jump or not to L1. When, if not hooked, it would jump to L1 only if rax is 0 as tested by "test rax,rax". So yes, that's where you'd need to use what you said..

Code: Select all

cave:
mov rax,[rcx+2B0] // original
test rax,rax // original
pushf <--
mov rcx,[rax+200]
test rcx,rcx // at this point you've changed the original zero flag (ZF)
popf <--
jmp back

addr:
jmp cave
je L1
back:

But then, again, in the implementation above, there's no point in doing that "test rcx,rcx" anymore if I restore the original flags, is there? Like I said, poor implementation to exemplify.

Bottom line: is your code-cave changing flags? is the next instruction at "back:" checking flags? Evaluate these questions, then decide if you actually need pushf/popf instead of "I put them here just to be safe". Cuz "just to be safe" to the knowledgeable eye means you don't know WHY you're using them like that or have read/watched some tutorial where another "knowledgeable" person like you instructed you to do so, cuz it's "good", "will not cause errors" and "it's 2 lines of code anyway, so not time consuming to ALWAYS put them there". So you adopt that and boom, before you know it, it becomes a personal rule driven by just the fact that if you use those, chances of crashing are reduced to some imaginary minimum.

[S1N74X]

Iam not sure what your Script does, but did you save the Flags with pushf and restored them with popf ?
Gamecrashes are sometimes a hint that flags were not properly set.

I've been seeing this quite a few times with some people, as some sort of rule. If you intend to use pushf/popf as a personal practice, then please don't promote it or suggest it as some attempt to fix crashes.

Saving and restoring flags matters only when you know for certain the next instruction after your code cave is going to be an instruction that uses the flags (so you'd need to restore their original states). Like a JE or JNE. Other than that, it makes no sense to save/restore them. But hey, if you are stubborn, don't care for others' opinions and act like "I know better" so you won't change your mentality when addressed, then that's that. Lastly, using this where not required is also an indication of poor ASM knowledge on the user end.

I just wanted to help and it was only a suggestion. If that is a reason for you "top notch Hacker" to offend others so go on.
Or get yourself a girlfriend and cool down.

[SunBeam]

Or get yourself a girlfriend and cool down.

That's the kind of statement people that are aged < 25 would say. Good luck with your self-sufficiency, you'll see how long this feeling good about yourself, based on your current knowledge level, lasts. You'll see, in time, how many others will point out your logic/knowledge gaps/flaws and try to correct/address them.. yet you will continue to feel offended and act like you did, bitching me/they feel superior to you or some random shit. This is my cue to leave you on your way, cuz I sure as shit won't spend anymore time with ungrateful pricks treating my attempt to readjust your coding habits/principles as jokes. Tried to lend you a hand, but you only see the "how he addressed me" part; which is telling me how tiny your perception views are, what matters the most for you and what not, out of someone's reply. Easily offended GenZ/people of 2022. Am out...