Attempt at reversing GetUnitType

[namreeb]

In 3.1.2 (and maybe versions before it), an object's type does not appear to be where it used to be [[objBase + 0x8] + 0x8]. Some have posted that the offset for object type is now 0x2, or [[objBase + 0x8] + 0x2]. I have found neither of these to be accurate.

To attempt to solve my problem, I thought I would try to reverse 'GetUnitType' which in 3.1.2 is at 0x005A55C0.

ASM code:

005A55C0   80B9 F0090000 00 CMP BYTE PTR DS:[ECX+9F0],0
005A55C7   74 04            JE SHORT WoW.005A55CD
005A55C9   33C0             XOR EAX,EAX
005A55CB   EB 0D            JMP SHORT WoW.005A55DA
005A55CD   8B81 D0000000    MOV EAX,DWORD PTR DS:[ECX+D0]
005A55D3   0FB680 D3010000  MOVZX EAX,BYTE PTR DS:[EAX+1D3]
005A55DA   8B15 8083A300    MOV EDX,DWORD PTR DS:[A38380]
005A55E0   3BC2             CMP EAX,EDX
005A55E2   7C 1E            JL SHORT WoW.005A5602
005A55E4   3B05 7C83A300    CMP EAX,DWORD PTR DS:[A3837C]
005A55EA   7F 16            JG SHORT WoW.005A5602
005A55EC   2BC2             SUB EAX,EDX
005A55EE   8B15 9083A300    MOV EDX,DWORD PTR DS:[A38390]
005A55F4   8B0482           MOV EAX,DWORD PTR DS:[EDX+EAX*4]
005A55F7   85C0             TEST EAX,EAX
005A55F9   74 07            JE SHORT WoW.005A5602
005A55FB   8B40 10          MOV EAX,DWORD PTR DS:[EAX+10]
005A55FE   85C0             TEST EAX,EAX
005A5600   7F 42            JG SHORT WoW.005A5644
005A5602   8B81 68090000    MOV EAX,DWORD PTR DS:[ECX+968]
005A5608   85C0             TEST EAX,EAX
005A560A   74 04            JE SHORT WoW.005A5610
005A560C   8B40 10          MOV EAX,DWORD PTR DS:[EAX+10]
005A560F   C3               RETN
005A5610   8B81 D0000000    MOV EAX,DWORD PTR DS:[ECX+D0]
005A5616   0FB640 40        MOVZX EAX,BYTE PTR DS:[EAX+40]
005A561A   8B0D F86EA300    MOV ECX,DWORD PTR DS:[A36EF8]
005A5620   3BC1             CMP EAX,ECX
005A5622   7C 1E            JL SHORT WoW.005A5642
005A5624   3B05 F46EA300    CMP EAX,DWORD PTR DS:[A36EF4]
005A562A   7F 16            JG SHORT WoW.005A5642
005A562C   2BC1             SUB EAX,ECX
005A562E   8B0D 086FA300    MOV ECX,DWORD PTR DS:[A36F08]
005A5634   8B0481           MOV EAX,DWORD PTR DS:[ECX+EAX*4]
005A5637   85C0             TEST EAX,EAX
005A5639   74 07            JE SHORT WoW.005A5642
005A563B   8B40 24          MOV EAX,DWORD PTR DS:[EAX+24]
005A563E   85C0             TEST EAX,EAX
005A5640   7F 02            JG SHORT WoW.005A5644
005A5642   33C0             XOR EAX,EAX
005A5644   C3               RETN

To try and understand this better, I re-wrote it as I read through it in psuedo-code. This is what I came up with:

if ([ecx+0x9F0] == NULL)
{
	eax = [ecx + 0xD0]
	eax = [eax + 0x1D3]
}
else
	eax = 0

edx = [0xA38380]

if (eax < edx || eax > [0x00A3837C])
{

	eax = eax - edx

	edx = [0xA38390]
	eax = [edx + eax*4]
}

eax = [ecx + 0x968]

eax = [ecx+0xD0]
eax = [eax+0x40]
ecx = [0xA36EF8]
if (eax < ecx || eax > [0xA36EF4)
	return 0

eax = eax - ecx
ecx = [0xA36F08]
eax = [ecx + eax*4]
return 0

I have to confess that this has created more questions and provided no real answers for me. In particular, it seems like the function always returns 0! I know this can't be true, but of the two RETNs, this is the one which seems to return an actual value:

005A5608   85C0             TEST EAX,EAX
005A560A   74 04            JE SHORT WoW.005A5610
005A560C   8B40 10          MOV EAX,DWORD PTR DS:[EAX+10]
005A560F   C3               RETN

Obviously eax always equals eax, so this jump to 0x005A5610 will always be performed. Moreover, there is no jump to 0x005A560C in this function. To me that means this code will never be executed. The second RETN is here:

005A563E   85C0             TEST EAX,EAX
005A5640   7F 02            JG SHORT WoW.005A5644
005A5642   33C0             XOR EAX,EAX
005A5644   C3               RETN

Again, obviously, eax > eax is always false, so, eax will be zero'd. While in this case there is one other place where we can jump to 0x005A5644, it also follows an always-false eax > eax statement at 0x005A55FE. So while this code will be executed, eax will always equal 0 when it does.

Can someone please tell me what I'm doing wrong? And though my reason for doing this is ultimately just to get an object's type (player, npc, corpse, etc.), after putting this effort in I'm more interested in learning what my mistake is so that I can be more self-sufficient with these sorts of efforts.

[adaephon]

I'm just getting into the reversing stuff myself, so I can't offer too much help, but after having a glance through that code and from what I've read I'd say that possibly you need to work out what calling convention is being used (cdecl, thiscall etc) and how the stack is treated with that call. It could well be a function that returns nothing, but stores a modified value in register? Not too sure

[jjaa]

TEST EAX, EAX
Is testing non-zero. It only sets the Z-Flag, when EAX is 0.

If (eax)
{
    __asm { MOV EAX,DWORD PTR DS:[EAX+10] } 
}
else
{
  __asm
  {
      MOV EAX,DWORD PTR DS:[ECX+D0]
      MOVZX EAX,BYTE PTR DS:[EAX+40]
      MOV ECX,DWORD PTR DS:[A36EF8]
      ....
   }
 }

[fish2k]

Without any clue if it's correct:

005A55C0   80B9 F0090000 00 CMP BYTE PTR DS:[ECX+9F0],0
005A55C7   74 04            JE SHORT WoW.005A55CD
if([ECX+9F0] != 0)
{
005A55C9   33C0             XOR EAX,EAX
    EAX = 0
005A55CB   EB 0D            JMP SHORT WoW.005A55DA
}
else
{
005A55CD   8B81 D0000000    MOV EAX,DWORD PTR DS:[ECX+D0]
    EAX = [ECX+D0]
005A55D3   0FB680 D3010000  MOVZX EAX,BYTE PTR DS:[EAX+1D3]
    EAX = [EAX+1D3] 
}
005A55DA   8B15 8083A300    MOV EDX,DWORD PTR DS:[A38380]
EDX = [A38380]
005A55E0   3BC2             CMP EAX,EDX
005A55E2   7C 1E            JL SHORT WoW.005A5602
if(EDX >= EAX)
{
005A55E4   3B05 7C83A300    CMP EAX,DWORD PTR DS:[A3837C]
005A55EA   7F 16            JG SHORT WoW.005A5602
    if([A3837C] <= EAX)
    {
005A55EC   2BC2             SUB EAX,EDX
        EAX = EAX - EDX
005A55EE   8B15 9083A300    MOV EDX,DWORD PTR DS:[A38390]
        EDX = [A38390]
005A55F4   8B0482           MOV EAX,DWORD PTR DS:[EDX+EAX*4]
        EAX = [EDX+EAX*4]
005A55F7   85C0             TEST EAX,EAX
005A55F9   74 07            JE SHORT WoW.005A5602
        if(EAX != NULL)
        {
005A55FB   8B40 10          MOV EAX,DWORD PTR DS:[EAX+10]
            EAX = [EAX+10]
005A55FE   85C0             TEST EAX,EAX
005A5600   7F 42            JG SHORT WoW.005A5644
            if(EAX == NULL)
            {
                return
            }
        }
        else
        {
005A5602   8B81 68090000    MOV EAX,DWORD PTR DS:[ECX+968]
            EAX = [ECX+968]
005A5608   85C0             TEST EAX,EAX
005A560A   74 04            JE SHORT WoW.005A5610
            if(EAX != NULL)
            {
005A560C   8B40 10          MOV EAX,DWORD PTR DS:[EAX+10]
                EAX = [EAX+10]
005A560F   C3               RETN
                return
            }
            else
            {
005A5610   8B81 D0000000    MOV EAX,DWORD PTR DS:[ECX+D0]
                EAX = [ECX+D0]
005A5616   0FB640 40        MOVZX EAX,BYTE PTR DS:[EAX+40]
                EAX = [EAX+40]
005A561A   8B0D F86EA300    MOV ECX,DWORD PTR DS:[A36EF8]
                ECX = [A36EF8]
005A5620   3BC1             CMP EAX,ECX
005A5622   7C 1E            JL SHORT WoW.005A5642
                if(ECX >= EAX)
                {
005A5624   3B05 F46EA300    CMP EAX,DWORD PTR DS:[A36EF4]
005A562A   7F 16            JG SHORT WoW.005A5642
                    if(DWORD PTR DS:[A36EF4] <= EAX)
                    {
005A562C   2BC1             SUB EAX,ECX
                        EAX = EAX - ECX
005A562E   8B0D 086FA300    MOV ECX,DWORD PTR DS:[A36F08]
                        ECX = [A36F08]
005A5634   8B0481           MOV EAX,DWORD PTR DS:[ECX+EAX*4]
                        EAX = [ECX+EAX*4]
005A5637   85C0             TEST EAX,EAX
005A5639   74 07            JE SHORT WoW.005A5642
                        if(EAX != NULL)
                        {
005A563B   8B40 24          MOV EAX,DWORD PTR DS:[EAX+24]
                            EAX = [EAX+24]
005A563E   85C0             TEST EAX,EAX
005A5640   7F 02            JG SHORT WoW.005A5644
                            if(EAX == NULL)
                            {
005A5642   33C0             XOR EAX,EAX
                                EAX = 0
                            }
                        
                        }
                    }
                }
            }
        }
    }
}
005A5644   C3               RETN
return

Would lead to:

if([ECX+9F0] != 0)
{
    EAX = 0
}
else
{
    EAX = [ECX+D0]
    EAX = [EAX+1D3] 
}
EDX = [A38380]
if(EDX >= EAX)
{
    if([A3837C] <= EAX)
    {
        EAX = EAX - EDX
        EDX = [A38390]
        EAX = [EDX+EAX*4]
        if(EAX != NULL)
        {
            EAX = [EAX+10]
            if(EAX == NULL)
            {
                return
            }
        }
        else
        {
            EAX = [ECX+968]
            if(EAX != NULL)
            {
                EAX = [EAX+10]
                return
            }
            else
            {
                EAX = [ECX+D0]
                EAX = [EAX+40]
                ECX = [A36EF8]
                if((ECX >= EAX) && (DWORD PTR DS:[A36EF4] <= EAX))
                {

                    EAX = EAX - ECX
                    ECX = [A36F08]
                    EAX = [ECX+EAX*4]
                    if(EAX != NULL)
                    {
                        EAX = [EAX+24]
                        if(EAX == NULL)
                        {
                            EAX = 0
                        }
                    
                    }
                }
            }
        }
    }
}
return

I'm also an assembler beginner so be mercy :S

[namreeb]

Thanks to the input above, I have revised my psuedo-code.

if ([ecx+0x9F0] == NULL)
{
	eax = [ecx + 0xD0]
	eax = [eax + 0x1D3]
}
else
	eax = 0

edx = [0xA38380]

if (eax >= edx && eax <= [0x00A3837C])
{

	eax = eax - edx

	edx = [0xA38390]
	eax = [edx + eax*4]

	if (eax)
	{
		eax = [eax+0x10]

		if (eax > 0)
			return eax
	}
		
}

eax = [ecx + 0x968]

if (eax)
{
	eax = [eax + 0x10]
	return eax
}

eax = [ecx+0xD0]
eax = [eax+0x40]
ecx = [0xA36EF8]
if (eax < ecx || eax > [0xA36EF4)
	return 0

eax = eax - ecx
ecx = [0xA36F08]
eax = [ecx + eax*4]

if (eax)
{
	eax = [eax+0x24]
	if (eax > 0)
		return eax
}

return 0

Edit: I should point out that this is seriously over-kill. It is enough to see that the only registered uninitialized (iow, the inputs) is ecx. So to call the built-in function one can do something as simple as:

	DWORD GetUnitType = gpWoWX->GetFindPattern()->GetAddress( "GetUnitType" );
	unsigned long UnitType;
	_asm
	{
		mov ecx, lTargetObj
		call GetUnitType
		mov UnitType, eax
	}

Where lTargetObj is a pointer to the object. The values returned are as follows:

enum eUnitTypes
{
	UT_UNKNOWN = 0,
	UT_CRITTER,
	UT_DRAGONKIN,
	UT_DEMON,
	UT_ELEMENTAL,
	UT_GIANT,
	UT_UNDEAD,
	UT_HUMANOID,
	UT_BEAST,
	UT_MECHANIC,
	UT_NOT_SPECIFIED,
	UT_TOTEM
};

Credits of course go to Bobbysing for the WoWX framework preventing those of us who use it from reinventing about 1000 wheels.

Edit2: *sigh* after all of this I completely forgot that my original goal was to find OBJECT type (unit, corpse, gameobject, etc.), not unit type. /wrists

[amadmonk]

The TEST EAX,EAX thing is a common pitfall for a new reverser. The reason is that this is an unintuitive way to check if a register is zero -- unintuitive, but very common. You'll note that CMP EAX,0 actually takes more bytes to encode than TEST EAX,EAX, so many compilers optimize this test to the TEST form. It's similar to XOR EAX,EAX -- this is just a "shortcut" for MOV EAX,0, but it's more compact (and very common, as your code sample shows).

Sometimes it gets even weirder; if you have a non-aliased (don't ask) value that's, say, 4, in EAX and you want to compare EAX with 4 you can't just do TEST EAX,EAX, right?

Wrong... you could actually do something like

SUB EAX,4
TEST EAX,EAX

or even

SHR EAX,2
TEST EAX,EAX

Protip: note that switch-case code is sometimes compiled in the first format, where numeric values are arranged in-order, so that the optimized ASM can just subtract a certain amount (the delta between two switch values) for each switch block and then look at the EFL and do a JA/JB (or JAE/JBE,JL/JG, JLE, JGE -- many ways to achieve the same goal, remember) to decide whether to look at the next case block or continue processing this one. So, instead of CMP EAX, [FirstValue] ... CMP EAX, [NextValue] ... etc., you see CMP EAX, [FirstValue] ... JAE case2 ... SUB EAX, case2_3delta ... JAE case3 ... etc. Basically, the compiler treats the case values as a search space and does a form of divide-and-conquer on it. Of course, sometimes it's just CMP EAX, [FirstValue] ... CMP EAX, [SecondValue]. Depends on the compiler, the code, and other factors. Simple, eh?

Depending upon the rest of the code in the function, this may be more efficient. The best thing to do is to get or bookmark a copy of the Intel x86 instruction guide so you can look at how the individual opcodes work (and esp. how they affect the EFL register). Then "reverse" a bunch of samples of your own C/C++ and see what the compiler turns it into; there are usually a bunch of different ways to compile the same source code, and every compiler does it differently -- in fact, every version of every compiler has its own idiosyncracies. Just benchmarking the differences caused by PIC vs. non-PIC code in gcc vs. Visual Studio gave us serious grief when I was on the VS team, since it's comparing apples to oranges (but the end user still sees one as "faster").

Some things -- like calling conventions -- are relatively static, but as Cypher reminded me in another thread, even cconvs aren't 100% fixed, since the compiler can decide to break the convention if it knows that the function isn't going to be called anywhere else.

Reversing is fun and profitable (in terms of knowledge gained). There is no faster way to understand the hardware you're using...

[Cypher]

Intel's C++ Compiler is ftw. Check out this loop:

.text:10055A90 loc_10055A90:                           ; CODE XREF: sub_100543B0+1208j
.text:10055A90                                         ; sub_100543B0+1723j
.text:10055A90                                         ; DATA XREF: ...
.text:10055A90                 sub     ecx, 20h
.text:10055A93                 movdqa  xmm3, xmmword ptr [esi+10h]
.text:10055A98                 movdqa  xmm0, xmmword ptr [esi+20h]
.text:10055A9D                 add     esi, 20h
.text:10055AA0                 psrldq  xmm1, 0Fh
.text:10055AA5                 movdqa  xmm2, xmm3
.text:10055AA9                 pslldq  xmm3, 1
.text:10055AAE                 por     xmm3, xmm1
.text:10055AB2                 psrldq  xmm2, 0Fh
.text:10055AB7                 movdqa  xmm1, xmm0
.text:10055ABB                 pslldq  xmm0, 1
.text:10055AC0                 por     xmm0, xmm2
.text:10055AC4                 movdqa  xmmword ptr [edx], xmm3
.text:10055AC8                 movdqa  xmmword ptr [edx+10h], xmm0
.text:10055ACD                 add     edx, 20h
.text:10055AD0                 cmp     ecx, 20h
.text:10055AD3                 jge     short loc_10055A90

This function is pretty win too:

.text:100563B0 sub_100563B0    proc near               ; CODE XREF: sub_10056490+Aj
.text:100563B0
.text:100563B0 var_210         = dword ptr -210h
.text:100563B0 var_1F4         = dword ptr -1F4h
.text:100563B0 var_10          = dword ptr -10h
.text:100563B0 arg_0           = dword ptr  8
.text:100563B0
.text:100563B0                 push    ebp
.text:100563B1                 mov     ebp, esp
.text:100563B3                 and     esp, 0FFFFFFF0h
.text:100563B6                 push    edi
.text:100563B7                 push    esi
.text:100563B8                 push    ebx
.text:100563B9                 sub     esp, 204h
.text:100563BF                 mov     edi, [ebp+arg_0]
.text:100563C2                 mov     esi, edi
.text:100563C4                 and     esi, 2
.text:100563C7                 mov     ebx, edi
.text:100563C9                 and     ebx, 4
.text:100563CC                 test    esi, esi
.text:100563CE                 jnz     short loc_100563D4
.text:100563D0                 test    ebx, ebx
.text:100563D2                 jz      short loc_10056402
.text:100563D4
.text:100563D4 loc_100563D4:                           ; CODE XREF: sub_100563B0+1Ej
.text:100563D4                 lea     eax, [esp+210h+var_210]
.text:100563D7                 push    200h            ; Size
.text:100563DC                 push    0               ; Val
.text:100563DE                 push    eax             ; Dst
.text:100563DF                 call    _memset
.text:100563E4                 add     esp, 0Ch
.text:100563E7                 fxsave  [esp+210h+var_210]
.text:100563EB                 mov     edx, [esp+210h+var_1F4]
.text:100563EF                 xor     ecx, ecx
.text:100563F1                 mov     eax, edx
.text:100563F3                 and     eax, 40h
.text:100563F6                 cmovz   esi, ecx
.text:100563F9                 and     edx, 20000h
.text:100563FF                 cmovz   ebx, ecx
.text:10056402
.text:10056402 loc_10056402:                           ; CODE XREF: sub_100563B0+22j
.text:10056402                 test    edi, 1
.text:10056408                 jnz     short loc_10056463
.text:1005640A
.text:1005640A loc_1005640A:                           ; CODE XREF: sub_100563B0+D6j
.text:1005640A                 test    esi, esi
.text:1005640C                 jz      short loc_1005642F
.text:1005640E                 stmxcsr [esp+210h+var_10]
.text:10056416                 mov     eax, [esp+210h+var_10]
.text:1005641D                 or      eax, 40h
.text:10056420                 mov     [esp+210h+var_10], eax
.text:10056427                 ldmxcsr [esp+210h+var_10]
.text:1005642F
.text:1005642F loc_1005642F:                           ; CODE XREF: sub_100563B0+5Cj
.text:1005642F                 test    ebx, ebx
.text:10056431                 jz      short loc_10056456
.text:10056433                 stmxcsr [esp+210h+var_10]
.text:1005643B                 mov     eax, [esp+210h+var_10]
.text:10056442                 or      eax, 20000h
.text:10056447                 mov     [esp+210h+var_10], eax
.text:1005644E                 ldmxcsr [esp+210h+var_10]
.text:10056456
.text:10056456 loc_10056456:                           ; CODE XREF: sub_100563B0+81j
.text:10056456                 add     esp, 204h
.text:1005645C                 pop     ebx
.text:1005645D                 pop     esi
.text:1005645E                 pop     edi
.text:1005645F                 mov     esp, ebp
.text:10056461                 pop     ebp
.text:10056462                 retn
.text:10056463 ; ---------------------------------------------------------------------------
.text:10056463
.text:10056463 loc_10056463:                           ; CODE XREF: sub_100563B0+58j
.text:10056463                 stmxcsr [esp+210h+var_10]
.text:1005646B                 mov     eax, [esp+210h+var_10]
.text:10056472                 or      eax, 8000h
.text:10056477                 mov     [esp+210h+var_10], eax
.text:1005647E                 ldmxcsr [esp+210h+var_10]
.text:10056486                 jmp     short loc_1005640A
.text:10056486 sub_100563B0    endp

Just be grateful WoW isn't compiled with ICC.

[namreeb]

Actually, in a way that would be nice. Because then I'd quit messing with this stuff and "go outside" haha.

Edit: Incidentally, can you explain why sometimes when I attach to WoW.exe with Olly all of the threads stay suspended?

[amadmonk]

F*** me, but I hate XMM asm.

We're doing huge bit-shifts to extract a byte at a time from 16 byte blocks. We're... doing a bytewise merge of some kind on the first and second 16 byte blocks of 32 byte blocks of memory, sequentially? What's this from, anyway?

Why, Intel, why?

[Cypher]

Actually, in a way that would be nice. Because then I'd quit messing with this stuff and "go outside" haha.

Edit: Incidentally, can you explain why sometimes when I attach to WoW.exe with Olly all of the threads stay suspended?

Because you touch yourself at night.

F*** me, but I hate XMM asm.

We're doing huge bit-shifts to extract a byte at a time from 16 byte blocks. We're... doing a bytewise merge of some kind on the first and second 16 byte blocks of 32 byte blocks of memory, sequentially? What's this from, anyway?

Why, Intel, why?

It's from my generic API logging module.

[amadmonk]

It's from my generic API logging module.

NOT at all what I would have guessed, unless you're doing something really odd here.

[namreeb]

Because you touch yourself at night.

Anyone else?:cussing:

[Cypher]

NOT at all what I would have guessed, unless you're doing something really odd here.

It's Intel, and I'm making heavy use of the STL, Boost, etc. Its probably some obscure library function that it's decided to optimize the shit out of.

[amadmonk]

It's Intel, and I'm making heavy use of the STL, Boost, etc. Its probably some obscure library function that it's decided to optimize the shit out of.

Oh that makes more sense. I could see that being part of a std::map or something.

I wonder how much of a perf enhancement Intel thinks they get from using those XMM registers; it's probably significant per-call, but still unless it's pogo'd or in a tight loop or something I doubt it accounts for much in the big picture.

[Cypher]

Oh that makes more sense. I could see that being part of a std::map or something.

I wonder how much of a perf enhancement Intel thinks they get from using those XMM registers; it's probably significant per-call, but still unless it's pogo'd or in a tight loop or something I doubt it accounts for much in the big picture.

I think the idea of the Intel compile is to squeeze every last possible drop from the CPU. I guess for large and complex systems it all ends up making a difference in the end.