Retail 10.1.0.49365. Where did they shift UnitOrigin and UnitAngle?

[Kovrizha]

There is no problem with everything else. Nothing unusual.
But what the heck is happened with UnitOrigin and UnitAngle?
I cant locate them anymore.

CameraStruct = 0x3BED8F8
CameraOffset = 0x3930
CharacterSelection = 0x37DAFD0
CorpseOrigin = 0x3C5A8A4
IsTexting = 0x3BDE2EC-0x8
LoadingScreen = 0x3E19698
MerchantFrameGuid = 0x398E4E8+0x2A8
MouseGuid = 0x3E196A0
ObjectList = 0x3CE3D60
ObjectFirst = 0x120
ObjectNext = 0x18
ObjectCount = 0x10
PlayerGuid = 0x38FC728
ZoneId = 0x3E199DC
MapId = 0x3789818
Logon = 0x3C5BFF8

Guid = 0x8
Type = 0x0
Id = 0x88
DynamicFlags = 0x8C
StackCount = 0x190
Durability = 0x19C
MaxDurability = 0x1A0
Slots = 0x460
NumSlots = 0x458
DisplayId = 0x190
TypeId = 0x201
ObjectOrigin = 0xB8
UnitOrigin = ???
UnitAngle = ???
MountDisplayID = 0x1F8
Casting = 0x363
StandState = 0x1958
Target = 0x1890
Health = 0x18D8
MaxHealth = 0x18E0
Level = 0x18E8
Race = 0x18CC
Flags = 0x1910
VisFlags = 0x195A
ShapeshiftForm = 0x199B
Spec = 0x1ECC
QuestFirst = 0x1FA0
Money = 0x4FF0
Bags = 0x6768
BackpackSlots = 0x67B8

[scizzydo]

0xA8 appears to be a pointer to the movement struct which contained all that before at 0xB0. So rather the old obj->origin->x out would be obj->ptr->origin->x (At least what I found, but I only dumped 10.1.0.49190). You can see this in the GetUnitSpeed function, it reads 0xA8 after getting the object pointer, then passing it to the function which gets the run speed:

sub_141BF2620   proc near
    mov     rax, [rcx+8]
    movss   xmm0, dword ptr [rax+1B0h]
    retn
sub_141BF2620   endp

EDIT:
Loading latest 10.1 in IDA now, but loaded my tool and printed my player pointer to look at it in Reclass.NET, and the movement struct is at 0xB0 still, and my facing still at 0x30. I noticed that the speeds are shifted down to represent what was shown above. Your other offsets you have though don't match what I see. Waiting for IDA to finish up and reflect on all I use.

EDIT 2:
Looking at the binary for the latest PTR, your offsets are off by 0x10, movement is still at 0xB0 which has your yaw/position/speeds, type is at 0x10 (0x0 is your object vtables, 0x8 is the pointer to the display struct where you can get stuff like scale), GUID is at 0x18, Dynamic Flags at 0x9C (see UnitIsTapDenied), etc. Not sure how you got all of those, unless it was the EnumVisibleObjects where you see there is 2x, one that passes the object pointer into the callback, and one that passes the object GUID into the callback (-0x28 and 0x10 accordingly)

[Kovrizha]

Not sure how you got all of those, unless it was the EnumVisibleObjects where you see there is 2x, one that passes the object pointer into the callback, and one that passes the object GUID into the callback (-0x28 and 0x10 accordingly)

Scizzydo, it seems, you are right. For years I used EnumVisibleObjects to traverse trough objest list:

//simplified version
vCurMgr = MemoryReadInt(BinAddress + ObjectList, 8);
vFirstObject = MemoryReadInt(vCurMgr + ObjectFirst, 8);
vObjectCount = MemoryReadInt(vCurMgr + ObjectCount, 8);
vAddress = vFirstObject;
vObject = vAddress - ObjectNext;
for (i = 0; i < vObjectCount; i++)
{
	vType = MemoryReadInt(vObject + 0x0, 2);
	vGuid = MemoryRead(vObject + 0x8, 16);
	vObjectZYX = MemoryRead(vObject + 0xB8, 12);
	//...
	vAddress = MemoryReadInt(vAddress, 8);
	vObject = vAddress - ObjectNext;
}

But now they cleaned movement data from that.
Are your ObjectFirst/ObjectNext the same?

ObjectFirst = 0x120
ObjectNext = 0x18
ObjectCount = 0x10

[scizzydo]

This is what I do:

if (pCurMgr && in_game && pCurMgr->ObjectCount) {
    auto pCurrent = pCurMgr->pFirst;
    while (true) {
        if (!pCurrent)
            break;
        auto pObj = reinterpret_cast<WoWObject*>(reinterpret_cast<uintptr_t>(pCurrent) - 0x28);
        // Doing stuff here
        pCurrent = pCurrent->pNext;
        if (pCurrent == pCurMgr->pFirst)
            break;
        }
    }
}

struct CurMgr {
	uint64_t ArraySize;				//0x0000
	uintptr_t* ArrayBase;			//0x0008
	uint64_t ObjectCount;			//0x0010
	char pad_0018[8];				//0x0018
	uint64_t ArraySize2;			//0x0020
	void* Array2Base;				//0x0028
	uint64_t ObjectsToFree;			//0x0030
	uint64_t pad_0038[29];			//0x0038
	CurMgrEntry* pFirst;			//0x0120
	char pad_0128[24];				//0x0128
	WoWGUID SomethingGUID;			//0x0140
	WoWGUID ActivePlayerGUID;		//0x0150
	uint32_t MapID;					//0x0160
	char pad_0164[12];				//0x0164
	void* pMovementGlobals;			//0x0170
};

I haven't confirmed the movement globals with 10.1 though, and honestly that struct is mostly from way older code, just updated for the count, first, activeplayer and mapid. The CurMgrEntry ptr is also at 0x28 of the WoWObject struct. Movement is still a pointer at 0xB0 from the base, and yaw is at 0x30 of that (where it was before 10.1)

[gdfsxwy]

10.1 MovementFlags : *(DWORD64*)(obj + 0xA8+0x0+0x108
10.1 X,Y,Z: *(DWORD64*)(obj + 0xA8+0x0+0x20
10.1 UnitName: 0x128,0xF8

10.1 ObjName:?
Where are they?
Please help me or tell me the method.
thank!

[Mr.Sergey]

10.1 ObjName:?
Where are they?
Please help me or tell me the method.
thank!

ReadUtf8String(ReadInt64(ReadInt64(ObjectBase + 0x108) + 0xE0)) - for gameobject
ReadUtf8String(ReadInt64(ReadInt64(ObjectBase + 0x128) + 0xF8)) - for unit

[gdfsxwy]

You're right.

My incorrect gameobject X, Y, Z caused me to not find the Name.

It seems to change to * (DWORD64 *) (obj+0xE0)+0xB0

[Watermi]

anyone knows CGPlayer_C__ClickToMove ？
signature can't find 48 83 EC ? 48 83 B9 ? ? ? ? ? 7E 62 4C 8B 81 ? ? ?

[Tirthankara]

- 10.0.0.46549
Here's a new pattern

48 89 5C 24 ?? 57 48 83 EC 40 33 DB 48 39 99 ?? ?? ?? ?? 7E 6B

reinterpret_cast<bool(__fastcall*)(uintptr_t*, Vector3*)>(m_base + Data.OfsMoveToVector3)(t, &Data.VStartX);
where
uintptr_t* t = GtPlayerPtr(); // GET_UNIT_FROM_NAME  //  new pattern  - E8 ?? ?? ?? ?? 48 85 C0 74 63 44 8B 80 ?? ?? ?? ?? 48

if I'm not mistaken. But it only triggers once, and that's it. They must have changed something in the function - I haven't looked into it yet, I don't have time

[scizzydo]

ClickToMove is behind a ret check now (or at least the CGPlayer_C::ClickToMove always was, and the one that calls it (MoveToVector3 or w/e) used to not be, but is now also

[Tirthankara]

I see why there was an error when I called - thank you

[Watermi]

ClickToMove is behind a ret check now (or at least the CGPlayer_C::ClickToMove always was, and the one that calls it (MoveToVector3 or w/e) used to not be, but is now also

how to actually spoof the op codes and return address. I could probably work out the expected parameters but i'm still relatively new to reversing / game hacking and i still a bit beyond my skill level. Thank you bro

[sendeos23]

* nothing to see here *

[sendeos23]

how to actually spoof the op codes and return address. I could probably work out the expected parameters but i'm still relatively new to reversing / game hacking and i still a bit beyond my skill level. Thank you bro

google "x64-return-address-spoofing-source-explanation" - but in all seriousness you will need to bring your assembly / reverse knowledge up to a level to understand what is actually being done if you want to have any chance on getting this working - impossible to "spoon" this one

[helloworld1024]

Your offsets seems to be off by 0x10
By the way can you tell me the sigs of
CorpseOrigin = 0x3C5A8A4
LoadingScreen = 0x3E19698