SetFacing with memory writes

[MaiN]

Seems like we have an StdCall with 1 param as returnValue? Looking at RETN 4.
so..

        [UnmanagedFunctionPointer(CallingConvention.StdCall)]
        private unsafe delegate int SetFacing(float floatPtr);

Not sure about the float floatPtr. But ive tried almost everything as argument, pointer to the float value.. etc etc Everything crashes wow. :/

I really suck at ASM.. sigh..

It looks like it's a thiscall, and it's definitely not a float pointer.
[UnmanagedFunctionPointer(CallingConvention.ThisCall)]
private delegate int SetFacing(IntPtr baseAddress, float radian);

  *(_DWORD *)(_ESI + 0x44) &= 0xFFFFFFCFu;

If I'm correct, that removes a flag (probably from the movement flags stuff). ESI is ECX, which should be the local player base address.

I'm not great with float operations, but it seems like it pushes two floats on the float stack, last one being your facing. The first one is popped off close to the first jump. If the first jump is taken it looks like something wrong has happened.

test    ah, 5           ; Logical Compare
jnp     short loc_949C89 ; Jump if Not Parity (PF=0)

loc_949C89:             
fstp    st               ; Store Real and Pop

As you can see, your facing is stored but then popped off - it looks like it's not used anymore after that.
If it reaches the good way

test    dword ptr [esi+44h], 1000h ; Logical Compare
fstp    dword ptr [esi+20h] ; Store Real and Pop
jnz     short loc_949C8B ; Jump if Not Zero (ZF=0)

First it does an AND on what I believe is the movement flags (?) at playerbase + 0x44 with the flag 0x1000 (looks like this decompiled v4 = (*(_DWORD *)(this + 0x44) & 0x1000) == 0) - it then sets playerbase + 0x20 to the facing value.
If the flag was zero, it goes the bad way, if it wasn't it goes the good way.
Basicly the good way calls 0x9480E0 which might be some kind of player nudge

[xzidez]

It was those playerbase stuffs I was trying to avoid in the first place :/.. Nevertheless Thanks a lot

edit:
still doesnt work. Im completley sure that I have the right playerbase, this crashes are driving me insane :/

        [UnmanagedFunctionPointer(CallingConvention.ThisCall)]
        private delegate int SetFacing(IntPtr playerBaseAddr, float floatRdr);

            IntPtr cConnection = Marshal.ReadIntPtr(new IntPtr(0x12705B0));
            IntPtr curMgr = Marshal.ReadIntPtr(cConnection, 0x2d94);
            IntPtr curObj = Marshal.ReadIntPtr(curMgr, 0xac);
            Int64 PlayerGuid = Marshal.ReadInt64(curMgr, 0xC0);
            while (curObj != IntPtr.Zero)
            {
                if (Marshal.ReadInt64(curObj, 0x30) == PlayerGuid)
                {
                    break;
                }
                curObj = Marshal.ReadIntPtr(curObj, 0x3c);
            }
            SetFacingHandler(curObj, rad);

I really feel like an idiot. Even with help I cant manage to get things working

Edit again: Once again thanks for the in-depths explanation. Lets see if I can understand something of this..

[amadmonk]

Sorry to rez an old thread, but did you ever resolve this?

The problem I'm having is that the this pointer I'm using is clearly wrong. I am using the active player pointer (or so I assumed). I obtain it by obtaining the local player guid from the object manager, and then calling GetObjectByGuid on that guid. The player base address is working for VMT calls and other stuff, so it's not an utterly ignorant failure on my part

However, the same base address is NOT working for SetFacing; in fact, while most of the time it just does nothing, sometimes it crashes WoW. I debugged it, and when I set facing in the game via mouselook, ecx is NOT the same as my player base address, so I'm clearly using the wrong this pointer.

I tried some other possibilities for this, such as CInputControl, but no dice. Nothing I could find matched the ecx that the game was using.

I'm poking at the code in IDA now, but if anyone else has unraveled this, I'd appreciate a tip. I'm sick of using SetFlags for motion (my bot weaves like a drunkard when the framerate blips). I saw a reference to using an "unreconstructed" player object in my searches. Anyone know what that means?

EDIT: I found the this pointer at playerbase + 0xd8. Searching forums to figure out what this means... I don't like blind offsets

[lanman92]

That's a pointer to the player descriptor fields I think.

[amadmonk]

WTF... I thought that the descriptors were just an array... If that's true, they're apparently an object that is the base of the "set facing" object.

Odd. Anyway, I tested it, and using *(playerobject+0xd as ecx to the SetFacing function works perfectly to instantly set facing.

Yeah, my bot's movement is now perfect; turns are instant and 100% precise, and require no emulated keyboard input or CTM. It does "look bottish" (since it turns instantly), but I think that as long as I don't flip 180 degrees in a tight loop, it shouldn't be too noticeable (people will chalk it up to lag, etc.)

I've analyzed the call path for SetFacing, and it never sends packets, so in theory this shouldn't lead to detection.

EDIT: Hmm, requires a call to SetMovementFlags before and after to nudge the client into acknowledging the move. Small price to pay.

[fish2k]

Dunno if your searching for an in-process solution but I think so.

I'm using this to call SetFacing (without any other calls) and it works quite well:

DWORD localPlayerAddress = playerbase;
__asm("push %2;"
	"mov %%ecx, %1;"
	"mov %%esi, %1;"
	"call %0;"
	: /* no output */
	: "r" (Addresses::adrSetFacing), "r" ((void*)(localPlayerAddress + Addresses::offsMovementStruct)), "r" (angle)
	: "ecx", "esi"
);

[EmilyStrange]

@amadmonk: What you see on your game client and what others see on their game client are, I am sure you know, two different things.

I run multiple clients side-by-side and using the in-game CTM or even doing a mouse-jump-turn ala PvP combat, looks instantaneous on most other game clients.

I have found that what makes a bot look "bottish" is more subtle than "instant turning." The biggest giveaway of course is just watching a bot grind on four or five mobs, there is no randomness in the sequence, there is very little "down time," there is absolutely no "dancing around," there is no "pausing for thought."

Gotta min-max the downtime/XP to be as efficient as possible. It is the efficiency that is the biggest tip-off.

Instantaneous turning due to SetFacing or CTM? Yeah, not so much.

[nitrogrlie]

WTF... I thought that the descriptors were just an array... If that's true, they're apparently an object that is the base of the "set facing" object.

I wouldn't call it a "set facing" object but rather a WoW Position Object.

[flo8464]

WTF... I thought that the descriptors were just an array... If that's true, they're apparently an object that is the base of the "set facing" object.

Well, its obvious they can't be an array.
When was the last time you saw an array with mixed datatypes (8byte-GUIDs, 4byte integers/floats, 1byte bools) ?

[amadmonk]

I assumed it was an array of e.g. ulongs that was being cast as-needed. Obviously if 0xd8 is the descriptor base, it isn't "just" an array.

@EmilyStrange: yeah, I know about the subjective nature of (WoW) reality I hadn't measured it, but assumed that insta-turning would still look bottish since even with lag, you'd just "snap" from one facing to the other without traversing the points in between (albeit after a 500ms or so round-trip delay). However, I'd wager that most people would assume it was mouse-turn or just a lag effect, so I'm not too worried about it. I'll have to actually look at the turns from another box to see what it looks like.

My bot is already insanely more efficient at playing than I am. The main I'm playing is a Demonology lock and he can easily solo 10+ equal level mobs. When playing manually, I'm hard pressed to manage more than 4-5 at a time. So yeah, the giveaway wouldn't be how bad he plays, but rather how WELL he plays. Still, I keep him mostly in instances where there's nobody else to see him

I just need to figure up my configuration code (so I can swap out "boss mode" and "grinding mode" configs on the fly), and I'm ready to roll. Can't wait till I can roll my new pybot in a group of 5 running heroics. Just gotta put a few finishing touches on my healadin routines...

[rootguy]

From what i can tell from my searches here on the forums it's a pointer to the InputControl class, not the descriptor storrage array.
I will look at it more in depth when i get back from work cause it is intriging but with the information i have at hand now everything indicates that the descriptor array is actually an array of unsigned longs cleverly used to contain any data type needed.

I have been using a setfacing routine that takes the localplayer as this pointer but requires a patch to work:

int SetFacing(WOWObject* me, float facing) {
	
	unsigned long a = *(unsigned long*)(WOWOffset::GetPointer()->GetAddress("SetFacingPatch")) + 0x30;
	*(unsigned long*)a = 1;
	UpdateLastHardwareAction();
	
	int (__attribute__((stdcall)) *pSetFacing)(float) = (int (__attribute__((stdcall)) *)(float))WOWOffset::GetPointer()->GetAddress("SetFacing");
	
	__asm__ __volatile__(
			"movl %0, %%ecx\n\t"
			:
			: "g" (me)
	);
	
	return pSetFacing(facing);
}

[Flowerew]

@amadmonk: I just read this thread on SetFacing and about the structure behind [playerbase + 0xd8]. I just recently started to RE that structure myself and posted my findings here:
http://www.mmowned.com/forums/wow-me...ml#post1748145

I thought it may be helpful to you. Best regards.

[lanman92]

That's right. I don't know where I got descriptors from that, but it is the movement fields. My mistake.

[EmilyStrange]

My bot is already insanely more efficient at playing than I am.

@amadmonk: I wouldn't go so far as the too say my bot is a better player than me, but it's definitely smarter. No... Wait! I meant that the other way round.

I've concentrated most of my efforts of development in to creating a multiboxing assistant. I like playing the game, but I also like "soloing" dungeons and other difficult, group-only, content by myself. I like to explore, and most regular groups I get in to have already done the content, so I don't get to look down every blind alley of a dungeon, or "kill the boring boss that never has very interesting loot." With three to ten characters all controlled by me, some days, it feels like I am playing Dungeon Siege rather than World of Warcraft.

Right now I am trying my best at emulating some of the work that Apoc has done on pre-determined navigation meshes using the world data. The pathing system I use for the non-human controlled player characters leaves much to be desired, especially in "dangerous areas" such as crossing narrow bridges. Also, pre-processed data would take a huge load off of the CPU which is already under stress by WoW.

[Apoc]

@amadmonk: I wouldn't go so far as the too say my bot is a better player than me, but it's definitely smarter. No... Wait! I meant that the other way round.

I've concentrated most of my efforts of development in to creating a multiboxing assistant. I like playing the game, but I also like "soloing" dungeons and other difficult, group-only, content by myself. I like to explore, and most regular groups I get in to have already done the content, so I don't get to look down every blind alley of a dungeon, or "kill the boring boss that never has very interesting loot." With three to ten characters all controlled by me, some days, it feels like I am playing Dungeon Siege rather than World of Warcraft.

Right now I am trying my best at emulating some of the work that Apoc has done on pre-determined navigation meshes using the world data. The pathing system I use for the non-human controlled player characters leaves much to be desired, especially in "dangerous areas" such as crossing narrow bridges. Also, pre-processed data would take a huge load off of the CPU which is already under stress by WoW.

If I were you; I'd use some remoting; and follow-the-leader pathing.

Have your 'leader' bot set waypoints for the followers to walk as you move through the dungeon. That removes any worrying about whether they may fall off a ledge or somehting.

Yes; waypoint navs are still useful. Even with a nav mesh.