Difference between object list ptr and object list manager?

[Tanaris4]

I noticed in the enumerator thread here: http://www.mmowned.com/forums/wow-me...g-objects.html EmilyStrange references an object list manager, this was the first time I had noticed this, as I assumed those who simply read memory for objects had to find the object list pointer, then jump all over the place to find the complete list (using the 4 other object pointers per list).

But when I saw this post I realized how much more efficient the search could be. Can anyone clarify what the object list manager is? And how to find it? (either through IDA or via memory scanning, I don't use injection).

Thanks :-)


And my post in the other thread just for reference that I deleted:

When you guys are saying ObjectManagerPtr, is that basically a pointer to the START of the object list? (so 0x1?

i.e. Address 0x2DB0EC00 happens to be the start of the object list in memory:


Edit: I'm currently doing this to find the object list pointer:

- (UInt32)findObjectList: (MemoryAccess*)memory {
    if(memory){
		UInt32 objectListPtr = 0, objectListAddr = 0;
		if([memory loadDataForObject: self atAddress: [offsetController offset:@"OBJECT_LIST_LL_PTR"] Buffer: (Byte*)&objectListPtr BufLength: sizeof(objectListPtr)] && objectListPtr) {
			if([memory loadDataForObject: self atAddress: objectListPtr + 0x1C Buffer: (Byte*)&objectListAddr BufLength: sizeof(objectListAddr)] && objectListAddr) {
				return objectListAddr;
			}
		}
	}
	return 0;
}

Not sure that well help, but basically that return value (objectListAddr) points to the mentioned list above.

[Robske]

I noticed in the enumerator thread here: http://www.mmowned.com/forums/wow-me...g-objects.html EmilyStrange references an object list manager, this was the first time I had noticed this, as I assumed those who simply read memory for objects had to find the object list pointer, then jump all over the place to find the complete list (using the 4 other object pointers per list).

But when I saw this post I realized how much more efficient the search could be. Can anyone clarify what the object list manager is? And how to find it? (either through IDA or via memory scanning, I don't use injection).

Thanks :-)


And my post in the other thread just for reference that I deleted:

Wow, that sure is confusing The "object list manager" that you refer to used in the enumerator is the same old objectmanager that's advertised all over this forum. It's not all that hard to follow, I got tossed off by the 0x70, which is just a neat trick to avoid excess code in order not to skip the first object. (as 0xC3 is added to that in the next step, which results in 0xAC)

[Tanaris4]

How do you find the object list manager? I had thought people were finding the object list the same way I was, then jumping all over the place + only grabbing the unique objects (or they used injection for the easiest route)

[Robske]

How do you find the object list manager? I had thought people were finding the object list the same way I was, then jumping all over the place + only grabbing the unique objects (or they used injection for the easiest route)

Gawd I just can't decipher what you are saying
ObjectManager: [[ClientConnection]+ObjMgrOffset]
And the first object at [ObjectManager+0xAC]

3.2.2 10505: [[0x12705B0]+0x2d94]

[Tanaris4]

Thanks, I'll fire up IDA Pro and look at the windows version, then try to find it on mac.

[Tanaris4]

Any thoughts on how to actually "search" to TLSIndex in IDA Pro, or some clarity on what it is? Haven't been able to find it in the OS X binary

[EmilyStrange]

From reading your post it seems that there is confusion over the nomenclature with regard to the game client object manager and the in-game object list.

OBJECT MANAGER
Dredging up some ancient memory, I recall that the "object manager" is a standard C++ class within the game client that keeps a local cache and tracks all of the game objects that the local player character may interact with, such as other player characters, NPCs, Monsters, Treasure Chests, Spell Effects, Signs, etc. The "object manager" is partially responsible for determining which objects are held in the cache and which are removed, based on a number of support classes.

As game objects move out of range of the player character's local view horizon they are retired from the cache and new game objects are placed into the cache as the player character encounters them. Note that a player view horizon has nothing to do with what you can physically view with the camera from your character's point of view, instead referring to an invisible bounding circle -- a conceptual horizon -- around the local player character that denotes how far the player can see, and possibly interact with, game objects.

Interesting side-note: The vertical position of a player is not taken in to consideration when determining what game objects are "visible", the local view horizon is a circle and not a sphere. A legacy decision that goes back to the "2D" heritage of the game world, i.e. free-roaming flight was never part of the original game engine design and was grounded very much in the EverQuest mould of players being locked to the ground for the most part.

Cache is a bit of a misnomer as it is not strictly a cache in the truest sense, instead being a partial local view of the remote game server's view of the game world within a geographically bounded area, i.e. the local player's view horizon.

Most of the time you do not need to worry about any other functions within the object manager and instead just pull the list of game objects.

OBJECT LIST
The "object list" is just a standard linked list that the object manager keeps a reference to.

I have not had the opportunity to spelunk through the Mac game client but as it is cross-compiled from the same base source tree as the Windows client, with appropriate Mac OS X specific code where applicable, the method of retrieving and walking the "object list" should be nearly the same. I am sure some Mac OS X developer can point you in the right direction.

As Robske pointed out, on the Windows game client, the Object Manager is retrieved by double de-referencing through the Client Connection class, and then de-referencing with an offset 0xAC to obtain a pointer to the first game object in the list.

Please let me know if this helps or if further clarification is required.

[Tanaris4]

Yea I understand the difference thanks :-)

Tough part is going to be finding the client connection manager w/in the OS X client, then building a byte signature for future updates.

Thanks again! +rep

[EmilyStrange]

Okay, sorry for belabouring the point, I just wanted to make sure we were discussing the same subject.

I would mention that there was a post on these forums within the past three weeks that dealt with finding the client connection and the game object list on Mac OS X but I see you have already been active in that thread.

Sorry I cannot be more help with regard to debugging the Mac OS X client.

[Tanaris4]

I don't think that was on finding the client connection, that was on the object list ptr. (so the huge list w/the 0x18 crap in it).

I would LOVE to find the client connection so I could just use the object list mgr. The problem is I can't find it using IDA, I've tried searching for immediate values (0x2d94), then I've created byte signatures to find the offsets and scanning memory but this has failed as well. Any ideas?

Binary here:http://dump.ifeedr.com/WoWBinaries/W...t%203.2.2a.zip

Edit: Found it :-) Will post more soon, used these threads + byte signatures:
http://www.mmowned.com/forums/wow-me...onnection.html
http://www.mmowned.com/forums/wow-me...ject-list.html

[flo8464]

Any thoughts on how to actually "search" to TLSIndex in IDA Pro, or some clarity on what it is? Haven't been able to find it in the OS X binary

Thread-local storage - Wikipedia, the free encyclopedia

Not sure how far different Macs implementation of a thread storage is, try to look it up.

Just a piece of code to explain how Windows-WoW accesses the object manager:

.text:00476580 mov ecx, large fs:2Ch // fs points to TEB, 0x2C is the offset to the storage-pointer
.text:00476587 mov eax, TlsIndex // Index of the storage is loaded
.text:0047658C mov edx, [ecx+eax*4]
.text:0047658F mov ecx, [edx+8]

The whole thing is highly platform-dependend, on x64 it would look totally different.

[Reconsider]

Gawd I just can't decipher what you are saying
ObjectManager: [[ClientConnection]+ObjMgrOffset]
And the first object at [ObjectManager+0xAC]

3.2.2 10505: [[0x12705B0]+0x2d94]

I think what he was asking is how did you actually find the ClientConnection and ObjectManager from the beginning, before you knew what they looked like at all..

[lanman92]

I would search for ObjMgr or something along those lines and find the xrefs. The objmgr should be referenced somewhere along there(Duhhhh).

[Tanaris4]

yea you say Duhhh, but you guys are all speaking of windows, which yes I can do. That doesn't exist on mac.

Good thing is I found it from the referenced post (i had the old binaries), then I made a byte signature and found the new offsets in 3.2.2 for mac :-)

It's: [[0x15F95E8] + 0x2D98]

[Tanaris4]

For some reason this logic doesn't work for me, i'm not getting anything that looks like the first object if i read [[0x15F95E8] + 0x2D98] than add AC + jump to that location.



Any ideas as to why?