GetSpellCharges reversing

[NitroGlycerine]

Hi all,

I am trying to learn some reversing with IDA. I was looking at the function GetSpellCharges. The function takes one input parameter (spellID|a1 in script), but inside the function this spellID doesn't seem to be used. Is this a problem with IDA decompiling or am I just not understanding it? I hope someone could enlighten me! Thanks in advance!

signed int __cdecl Script_GetSpellCharges(int a1)
{
  signed int result; // eax@5
  unsigned int v2; // [sp+10h] [bp-14h]@4
  unsigned int v3; // [sp+14h] [bp-10h]@4
  int v4; // [sp+18h] [bp-Ch]@4
  int v5; // [sp+1Ch] [bp-8h]@1
  int v6; // [sp+20h] [bp-4h]@1

  v6 = 0;
  LOBYTE(v5) = 0;
  if ( !sub_8F7B58(0, 1) )
    goto LABEL_9;
  if ( (unsigned __int8)sub_8F5F0F(v6, 1) )
    LOBYTE(v5) = 1;
  v5 = sub_77DEA1(v6, v5, &v4, &v3, &v2);
  if ( v4 > 0 )
  {
    lua_pushnumber(a1, (double)v5);
    lua_pushnumber(a1, (double)v4);
    lua_pushnumber(a1, (double)v3 * 0.001);
    lua_pushnumber(a1, (double)v2 * 0.001);
    result = 4;
  }
  else
  {
LABEL_9:
    result = 0;
  }
  return result;
}

[namreeb]

Well firstly you probably have the prototypes for those first two function calls wrong. Try double-clicking them and IDA will look at the function more closely and update the prototypes as it chooses. (I am referring to 'sub_8F7B58' and 'sub_77DEA1'). The parameter passed to 'Script_GetSpellCharges' is neither the spell id nor the spell name, but a pointer to the current Lua state. The Lua stack is contained within the state.

My guess is that one of those will read the parameter from the Lua stack, which can be either a spell id or a spell name according to this: API GetSpellCharges - Wowpedia - Your wiki guide to the World of Warcraft (tinyurl necessary because ownedcore.com seems to think that the domain name counts as profanity and filters it out ).

It looks like 'sub_77DEA1' is the function that actually looks up the charge information for the spell. This part is where the results are added back to the Lua stack:

  if ( v4 > 0 )
  {
    lua_pushnumber(a1, (double)v5);
    lua_pushnumber(a1, (double)v4);
    lua_pushnumber(a1, (double)v3 * 0.001);
    lua_pushnumber(a1, (double)v2 * 0.001);
    result = 4;
  }
  else
  {
LABEL_9:
    result = 0;
  }

Notice that it pushes four numbers to the stack, which is consistent with the return values as described in the link above. You can therefore assume the following mapping of your variable names to the API descriptions:

v5 ==> currentCharges
v4 ==> maxCharges
v3 ==> cooldownStart
v2 ==> cooldownDuration

The * .001 is likely to convert what the game stores internally in milliseconds into seconds for Lua.

[NitroGlycerine]

Well firstly you probably have the prototypes for those first two function calls wrong.
The parameter passed to 'Script_GetSpellCharges' is neither the spell id nor the spell name, but a pointer to the current Lua state. The Lua stack is contained within the state.

That will probably explain it. I naively assumed that the variable a1 just contained the spell ID.
I'll look closer into those functions. Thank you for your help! Much appreciated.

[NitroGlycerine]

Indeed as you suggested, the function was not completely correctly shown. The parameter a1 is actually used in 8F7B58:

signed int __cdecl Script_GetSpellCharges(int a1)
{
  signed int result; // eax@5
  unsigned int v2; // [sp+10h] [bp-14h]@4
  unsigned int v3; // [sp+14h] [bp-10h]@4
  int v4; // [sp+18h] [bp-Ch]@4
  int v5; // [sp+1Ch] [bp-8h]@1
  int v6; // [sp+20h] [bp-4h]@1

  v6 = 0;
  LOBYTE(v5) = 0;
  if ( !sub_8F7B58(a1, (int)&v6, 0, 1) )
    goto LABEL_9;
...

I was looking deeper into some of the subfunctions and came across the following function:

int __thiscall sub_77A366(int this, int a2, int a3)
{
  int v3; // eax@1
  int v4; // edi@1
  int v5; // esi@1
  int v6; // eax@11

  v3 = *(_DWORD *)(this + 32);
  ...
}

How would I go to evaluate v3? "this" is a pointer to the function, does it point to the address 77A366 (not rebased) or is there more to it?

[namreeb]

We have no way of knowing the value of 'this' in that context. But what that line is doing is reading the value pointed to by the pointer located at this + 32.