Originally Posted by
enteleky
Ok I think I have found the objMgr... This snippet of ASM code comes from the GetObjectFromGUID()
│__text:000A7B4D mov ebp, esp
│__text:000A7B4F push edi
│__text:000A7B50 push esi
│__text:000A7B51 push ebx
│__text:000A7B52 sub esp, 4Ch
│__text:000A7B55 mov esi, [ebp+arg_0]
│__text:000A7B58 mov edi, [ebp+arg_4]
│__text:000A7B5B mov eax, ds:dword_121D5AC
│__text:000A7B60 mov [ebp+var_38], eax
│__text:000A7B63 test eax, eax
│__text:000A7B65 jz loc_A7C33
│__text:000A7B6B mov ecx, [eax+0C4h]
│__text:000A7B71 mov ebx, [eax+0C8h]
│__text:000A7B77 mov eax, ebx <---- I think this is the line in which the objMgr offset is put into eax.
│__text:000A7B79 or eax, ecx
│__text:000A7B7B jnz loc_A7C45
│__text:000A7B81 mov ebx, edi
│__text:000A7B83 or ebx, esi
│__text:000A7B85 jz loc_A7C33
Is the object manager at 0x0121d5ac+c8h?
The problem is when ever I set IDAs debugger to break on this line WoW spinlocks and IDA doesn't show its broken yet... Could anyone help me?
Only had a old mac client to use as reference (I don't have 3.0.3), but it looks like in that above snippet that dword_121D5AC is probably a pointer to the object manager.
Comparing equivalent code from the Mac client and a Windows PTR client from around the same time (checking to see if s_curMgr->m_movement is NULL or not):
Code:
mov ecx, ds:dword_121944C
mov [ebp+var_94], ecx
mov eax, [ecx+0E0h]
test eax, eax
jz short loc_B0164
mov [esp+0C8h+var_B4], 1
mov [esp+0C8h+var_B8], 0
mov [esp+0C8h+var_BC], offset aS_curmgrM_move ; "s_curMgr->m_movement == __null"
mov [esp+0C8h+var_C0], 6B4h
mov [esp+0C8h+var_C4], offset aVolumesF2Us_83 ; "/Volumes/F2/usrbuild/xb/build/WoW_9056p"...
mov [esp+0C8h+var_C8], 85100000h
call wow_assert_fail
Code:
mov eax, TlsIndex
mov ecx, large fs:2Ch
push esi
mov esi, [ecx+eax*4]
cmp dword ptr [esi+8], 0
jz short loc_47C036
call sub_47B070
mov edx, [esi+8]
cmp dword ptr [edx+0E4h], 0
jz short loc_47C00A
push 1 ; uExitCode
push 0 ; int
push offset aS_curmgrM_move ; "s_curMgr->m_movement == 0"
push 6B4h ; ExitCode
push offset a_Objectmgrclie ; ".\\ObjectMgrClient.cpp"
push 85100000h ; dwMessageId
call wow_assert_fail
The windows client gets it from the TLS, the mac client gets it from a global variable (uninitialized global variables are stored in the bss section by gcc). The mac client is checking for 0xE0, and the windows client is checking for 0xE4; might be some sort of padding that's being added.
I would poke around the structure and find the pointer to the first object (my bet is that it is 4 off from the windows client).