[3.1.2] Some Changes...Few Static updates...

[amadmonk]

Wouldn't they detect speedhacks serverside (based on motion prediction)?

I don't know anything about WoW's motion code, but that's what I would do.

[BoogieManTM]

Wouldn't they detect speedhacks serverside (based on motion prediction)?

I don't know anything about WoW's motion code, but that's what I would do.

that's A LOT of checks for a server to be doing all the time. I would hope they at least have something in there, but i doubt they have anything all the time. Just too many packets to be checking all of them, especially when there are so many legit speed modifiers you have to factor in as well.

[namreeb]

Curious if I'm doing this right. Can anyone confirm that the new address for Lua_Register is 0x00499990?

[SKU]

Curious if I'm doing this right. Can anyone confirm that the new address for Lua_Register is 0x00499990?

Yup, correct.

[RoKFenris]

that's A LOT of checks for a server to be doing all the time. I would hope they at least have something in there, but i doubt they have anything all the time. Just too many packets to be checking all of them, especially when there are so many legit speed modifiers you have to factor in as well.

It shouldn't be that hard (they just have to be cautious to not use the ban hammer on people hit by legitimate lag spikes), and they just updated the hardware on a whole bunch of servers - maybe one side effect of that update was to have enough spare computing power to enable extra server-side checks.

[Robske]

that's A LOT of checks for a server to be doing all the time. I would hope they at least have something in there, but i doubt they have anything all the time. Just too many packets to be checking all of them, especially when there are so many legit speed modifiers you have to factor in as well.

Truth, I've tried out several private servers with "anti-speedhack code" but as a result, mages DC on blink.

[SKU]

It shouldn't be that hard (they just have to be cautious to not use the ban hammer on people hit by legitimate lag spikes), and they just updated the hardware on a whole bunch of servers - maybe one side effect of that update was to have enough spare computing power to enable extra server-side checks.

Wintergrasp.

[garkeinplan]

0x012CBCD4 LastHardwareAction
0x0046C5E0 InputEvent

override LastHardwareAction with InputEvent for AntiAFK.

0x00A45D2C Login_State ( 0x16 for Login Screen, 0x4 for Charselect, 0x5 for Auth failed more not checked. On entering World its 0x16 too )

0x012A75C0 Game_State ( returns an String with "login" for Login Screen and "charselect" for Charselect Screen. On entering World its "charselect" too )

[numinis]

0x012CBCD4 LastHardwareAction
0x0046C5E0 InputEvent

override LastHardwareAction with InputEvent for AntiAFK.

0x00A45D2C Login_State ( 0x16 for Login Screen, 0x4 for Charselect, 0x5 for Auth failed more not checked. On entering World its 0x16 too )

0x012A75C0 Game_State ( returns an String with "login" for Login Screen and "charselect" for Charselect Screen. On entering World its "charselect" too )

thx mate this helped me a lot

[Nesox]

0x012CBCD4 LastHardwareAction
0x012A75C0 Game_State ( returns an String with "login" for Login Screen and "charselect" for Charselect Screen. On entering World its "charselect" too )

0x012A75C0 that's the last gluescreen used

[namreeb]

Yup, correct.

Great! That's encouraging. Another question: has the structure of the client cache db changed? I've repeated my rather primitive attempt to locate 'RegisterBase_ClientDB' only to wind up outside of the .text section of memory, and into a section that is pretty much all zerod.

[ramey]

Great! That's encouraging. Another question: has the structure of the client cache db changed? I've repeated my rather primitive attempt to locate 'RegisterBase_ClientDB' only to wind up outside of the .text section of memory, and into a section that is pretty much all zerod.

Yes, as far as I know it has changed.

[Nesox]

CategoryBC - WoW.Dev Wiki

[namreeb]

sCurMgr = [[1139F80h] + 2C34h]
pDevice = [[0x13C290] + 0x38A8]

DXEndScene   = [[[[0x113C290] + 0x38A8]] + 42 * 4]
DXBeginScene = [[[[0x113C290] + 0x38A8]] + 41 * 4]

CastSpellByID:0x004C4E90
ClickToMove:0x005AFA80
g_ClientConnection:0x01139F80
g_ClientConnection_offset:0x00002C34
GetSpellIdByName:0x006FF3D0
GetTimeStamp:0x0046E580
InputControl_ClassPointer:0x0113F8E4
InputControl_SetFlags:0x00691A10
Lua_ToInteger:0x0091AC7C
Lua_DoString:0x0049AB60
Lua_ProtectionCheck:0x006E4500
SetFacing:0x005AFA10
UpdateModel:0x005C1C30

Ill add some more later

Excellent! +rep for you!

[namreeb]

PlayerBase was given in this thread as:

PlayerBase   :    0x010BD5F4

And the offsets for position were given as:

I just tested on a trial account. I am getting banned for modifying one or more of the following playerbase offset addresses:


X=0x798
Y=0x79C
Z=0x7A0
Movestate=0x7CC

Question 1: Is the value at the offset for Z supposed to be the actual float value, or a pointer to it?

Question 2: I tried to answer this myself by writing my function for both cases and comparing to the value I get from the VMT function. Neither works! What am I doing wrong here?

In the case of the offset containing the actual float value, my code is:

		WOWPOS pos;
		float z;

		_asm
		{
			mov eax, dword ptr ds:[0x010BD5F4 + 0x7A0]
			mov z, eax
		}

		GetCurMgr()->GetLocalPlayer()->GetPosition(pos);
		DBGLOG("z from class: " << std::dec << pos.Z);
		DBGLOG("z from mem  : " << std::dec << z);

Case #2, the offset containing a pointer to the Z value:

		WOWPOS pos;
		float *z;

		_asm
		{
			mov eax, dword ptr ds:[0x010BD5F4 + 0x7A0]
			mov z, eax
		}

		GetCurMgr()->GetLocalPlayer()->GetPosition(pos);
		DBGLOG("z from class: " << std::dec << pos.Z);
		DBGLOG("z from mem  : " << std::dec << *z);

Yet both give me bogus values. Have I made a mistake somewhere, or are these values possibly incorrect?