[Retail] Some Offsets 8.3.0.34963

[GlittPrizes]

At the beginning of the function, the mov rdx, [rbp+38h] loads the caller's return address. Then, the function checks the value of rdx is within some valid range and that the content of the memory prior to the return address is really containing a 5 byte CALL opcode like this:

 E8 ?? ?? ?? ??

Does this go for all functions that start like this? Can you call them higher in the chain (something above that calls it)?

Also, is it better to use the VMT for interacting compared FramescriptExecute commands or are they both suspect due to the lack of a hardware event?

[SailorMars]

Does this go for all functions that start like this? Can you call them higher in the chain (something above that calls it)?

Also, is it better to use the VMT for interacting compared FramescriptExecute commands or are they both suspect due to the lack of a hardware event?

The OBFUSCATED functions normally have this kind of check hidden. They require a lot of manual work to patch the obfuscation code in order de-compile them, thus reveal the checks. Probably that is why they hide the check there. For normal functions, it is easy to de-compile them and hence to spot the code doing the check.

Most of the check only check the immediate caller. So it is safe to call from higher up in the call chain - but i can't guarantee anything.

I've no experience with VMT and framescript_execute. Perhaps some experts can shed some light on this.

[doityourself]

It's always the same pattern for these checks. The ret address/call checks are not obfuscated at all so you can just pattern search these. Also if ida fails to analyze 'obfuscated' functions it's pretty easy to just fix the wrongly analyzed jumps to be able to decompile the funcs.

[xalcon]

didn't check the others, but the healthMax is wrong, should be 0x1590, health is 0x1588/0x1378

Since I've not seen anyone mention the reason for the 2 Health Values, this is what I've found out:
The function CGUnit_C::GetDisplayedHealth @ 0xD63500 uses both values, depending on a configuration value which is stored at [[wow.exe + 0x2A6A948] + 0x5C]. I assume 0x2A6A948 is the offset to the CVar stuff, but the 5C offset is infact a CVar called "predictedHealth". If that CVar is 0, the client will use the health value stored at Unit+0x1588, otherwise it will use Unit+0x1378. The default setting for "predictedHealth" is 1.
CVar predictedHealth - Wowpedia - Your wiki guide to the World of Warcraft