GetObjectByGUID return always NULL

[goderion]

Hello.

I try to use the function GetObjectByGUID.

If i use the address, that Cypher post in his last big amazing post about the addresses, WoW crashes.

This was in the post:
[07:14:50]: 0x0046D220 -> CObjectMgr__GetObjectByGUID

If i obtain the address via FindPattern (thanks to the great WoWXBase), i get 0x0046D3C0.

If i use this address, i get everytime NULL.
Here a part of my log:

GUID_High GUID_Low - *pObject - Result of GetObjectByGUID
0x1A0694E1 0xF130000C - 0x1278B1F8 - 0x00000000
0x1A0694F1 0xF130000C - 0x1277CE10 - 0x00000000
0x1A06955F 0xF130000C - 0x1276EA28 - 0x00000000
0x1A06956F 0xF130000C - 0x12764468 - 0x00000000
0x1A06957D 0xF130000C - 0x12765920 - 0x00000000
0x1A0695DE 0xF130000C - 0x1278C6B0 - 0x00000000
0x1A0696C8 0xF130000C - 0x12771398 - 0x00000000
0x1A067BED 0xF130000C - 0x1276D570 - 0x00000000
0x40001E90 0xF1300017 - 0x12766DD8 - 0x00000000
0x1A06839C 0xF130000C - 0x12762FB0 - 0x00000000
0x1A0684E4 0xF130000C - 0x127751C0 - 0x00000000
0x1A06851D 0xF130000C - 0x12772850 - 0x00000000

The pObject is the pointer, who is used for the enumeration. (FirstObject->NextObject->NextObject->ect.)

I use the function like this:
typedef IObject* (__cdecl *Func_GetObjectByGUID)(UINT64 Guid, UINT32 Filter);

Func_GetObjectByGUID m_fpGetObjectByGUID = Addr; ' 0x0046D3C0

IObject* pObject = m_fpGetObjectByGUID(Object.GUID, -1);

I dont get it... i was also searching the forums for an actuall address of GetObjectByGUID or similar problems, but cant find anything.

What i am doing wrong?

[kynox]

GetObjectByGUID references s_curMgr via the Thread Local Storage. If you want to use GetObjectByGUID, you have two options.

1) Call it from WoW's main thread.
2) Set the value of your TLS variable, index 0 to the s_curMgr pointer.

[goderion]

@Kynox:
Thanks for the hints.

I guess i can only call a function in the main thread of WoW, if i hook some or a specific function of that thread.

So i decided to test the second solution.

i first tried this, but after i think about it, it was the false way. ^^

BYTE *ThreadLocalStorage = (BYTE*)0x0046FD15;
BYTE *m_pObjectManager = (BYTE*)0x11B3EE48;
m_Proc_GetObjectByGUID = (Func_GetObjectByGUID)(0x0046D3C0);

Process->ReadProcessMemory(ThreadLocalStorage, &Backup, 4);
Process->WriteProcessMemory(ThreadLocalStorage, m_pObjectManager, 4);
pObject = m_Proc_GetObjectByGUID(Object.GUID, -1);
Process->WriteProcessMemory(ThreadLocalStorage, &Backup, 4):

then i tried this:

pBackup = TlsGetValue(0);
TlsSetValue(0, m_pObjectManager);
pObject = m_Proc_GetObjectByGUID(Object.GUID, -1);
TlsSetValue(0, pBackup);

Both tries fails, GetObjectByGUID returns always NULL.

I dont understand it. In the WoWXBase, it looks so easy.
He just call the function without any TLS-Changes, or i have missed the section, while i was study this great piece of code.

Is there somewhere another example code available, who shows the use of GetObjectByGUID?

[hypnodok]

Take a look at this post.

[typedef]

Umm you have to make a token to access WoWs program, and I dont even see that you have the program attached. And you dont need ASM. Maby instead of ruining the games you should make them? The funny thing is the warden sees alls the memory reading as soon as a outside programs creates a token for permission to read. The warden goes horray another *******! Although blizz is gay and doesnt do anything

[goderion]

@hypnodok:
YEAH! Many thanks, this looks really interesting. ^^ i will check it out.

@typedef
A Token to access wow? You mean the ProcessToken to enable DebugPriviliges?
To clear this.... DebugPriviliges are enabled and the dll is loaded into the process of wow.

[Shynd]

Don't pay attention to typedef. He's worse than a troll in that, with him, it's not an act.

[goderion]

@Shynd:
Hehe... guess you are right. Your writings in your blog are really interesting and well written, thanks for the nice share. ^^

@hypnodok:
I say it again: YEAH! your great hint helped me a lot, i am now able to use GetObjectByGUID. The function Object->Interact works now too... yeah! I wanted only to use GetObjectByGUID to look, if the return value differs of the pointer, who is used through the enumeration of the objects, couse Object->Interact failed.

I made a stress test for the functions, and since im using Object->Interact, sometimes WoW crashes. I used the function more then 50 times per second on all Units that are nearer as 10 yard. This works well for some minutes, but then it crash.
Have i missed some important information?

Short description how i work with WoW:
DLL-Inject (RemoteThread->LoadLibrary)
DLL-Main (CreateThread) // the main thread
Main-Thread (Create the classes like CWoW)

Main-Thread-Loop
CWoW->BeginUpdate (main thread of WoW suspend, read all needed data)

here i do the stuff, like Interact.

CWoW->EndUpdate (main thread of WoW resume)

after that, there comes some other stuff, but nothing who need to read or interact with WoW.

Mmmh... where is the bug?

Maybe the function of Interact conflicts with the current paused function in the main thread, and then it crash at the resume.

I could hook a specific function of WoW, to ensure, that there are no functions executed at the time, when i suspend the main thread.

Mmmmmh.... ^^

[Shynd]

I'm pretty sure you don't want to be Interacting with a million things a second regardless of whether that crashes WoW or not. It's not something you'll ever need to do, so why get all hot and bothered if it causes problems?

[kynox]

The funny thing is the warden sees alls the memory reading as soon as a outside programs creates a token for permission to read. The warden goes horray another *******! Although blizz is gay and doesnt do anything

Stop ****ing posting. You don't know anything and your false accusations show how stupid you actually are.

@goderion:

The reason in WoWX you can call the functions is because they're all coming from a DirectX EndScene hook. WoW's main thread is responsible for calling DirectX.

[goderion]

@Kynox:
Thats a great piece of information!

Im currently trying to hook Direct3DCreate9, but its useless, couse WoW already called the function. Is there a way to force WoW to recreate Direct3D9? It seems, that WoWXBasic must be started, before WoW starts, or i missed some part of code.

I would like to hook Direct3D, without restarting WoW everytime, when i want to test some functions. I looked through the net, but all code i found, who hook Direct3D, starts with the hook of Direct3DCreate9.

Another question to CInputControl::SetFlag. My FindPattern tell me this address:
Func_CInputControl_SetFlag = 0x001548F0. Can someone confirm that or tell me the correct address?
I only ask, couse this address is so much different like the address, who Cypher posted: [07:14:50]: 0x005544A0 -> CInputControl__SetFlags.

The use of the addresses 0x001548F0 or 0x005544A0 crashes WoW.

EDIT: Im so stupid: forgot to add the base to my SetFlag function, now it is 0x005548F0. I check now if this will work.

[Cypher]

@Kynox:
Thats a great piece of information!

Im currently trying to hook Direct3DCreate9, but its useless, couse WoW already called the function. Is there a way to force WoW to recreate Direct3D9? It seems, that WoWXBasic must be started, before WoW starts, or i missed some part of code.

I would like to hook Direct3D, without restarting WoW everytime, when i want to test some functions. I looked through the net, but all code i found, who hook Direct3D, starts with the hook of Direct3DCreate9.

Another question to CInputControl::SetFlag. My FindPattern tell me this address:
Func_CInputControl_SetFlag = 0x001548F0. Can someone confirm that or tell me the correct address?
I only ask, couse this address is so much different like the address, who Cypher posted: [07:14:50]: 0x005544A0 -> CInputControl__SetFlags.

The use of the addresses 0x001548F0 or 0x005544A0 crashes WoW.

EDIT: Im so stupid: forgot to add the base to my SetFlag function, now it is 0x005548F0. I check now if this will work.

With your D3D stuff, if you inject your DLL into WoW at launch by starting WoW with the SUSPENDED flag set, injecting, then resuming the primary thread, you can get yourself in before any initialization is done.

Also, I belive (lolkynox) that you can call Direct3DCreate9 and it will return the old pointer for you. Thats how Fraps etc are able to attach after the fact.

[kynox]

I just hook EndScene via a Virtual Function hook by obtaining the already created IDirect3DDevice9 pointer stored in the CGxDevice3d class.

[Neffarian]

0x0046D3C0 -> GetObjectByGUID

[kynox]

0x0046D3C0 -> GetObjectByGUID

Uh? Thanks for that offset that has totally not been posted by the OP..