Is there any useful technique for finding the lines responsible for object collision?

[Ledin]

I've got static pointers for my XYZ values, but playing around with all of the addresses in the assembly that write to these or access these has not led to any success. Looking for 'compares' in the assembly instruction around those that write to the XYZ values and then modifying or NOPing those compares or the jump instructions after them has not lead to any success either.

How do you guys go about doing this? Out of all the released programs on this site I've found that include no collision type hacks, I cannot find a single guide on how to go about finding those addresses myself.

[Corthezz]

Actually an interesthing thread. I got most pointers and offsets by scanning for known patterns, looking through offset threads or using an idb.
In rare cases where nothing of the above helped I used CE to scan for actual numbers or states (hp, character dead or alive or whatever you are actually looking for).

But speaking of the thread creators question I am also curious how one found the addresses for collision without idb or other kind of "spoilers".
In many cases you can go with IDAs string search and reverse the LUA function until you hit the function you search but speaking about collision there is no starting point I could imagine.
What I mostly do in those cases is just start digging around an known pointer which stores an value which could be used by the function, try to make a bit sense of the code I find, and follow one idea after another until something seems to make sense but arent there better techniques which could be summerised in a step by step guide and then applied to any function you want to find or is reversing really all about guessing how the function you search could work?

[Master674]

Collision detection is usually divided in 2 parts:

Broad phase collision detection: (Optional)

1. Sort units + meshes into a grid / split bounding boxes.
2. Get relevant faces for narrow phase collision detection/resolution using bounding box tests.

Narrow phase collision detection:

1. Use your movement position delta vector and compute the barycentric coordinates with the current collision face.
2. Check if you're intersecting with this triangle (u, v, w >= 0) and perform collision resolution.
3. Calculate the surface normal.
4. Calculate the reflection vector.
5. Move along reflection vector (+ elasticity).
6. Reflect velocity.

WoW has a GetMovementFacets function somewhere, so you should look for it in the movement functions.
If you break one of those things you should get noclip if that is what you want.

You could even do something as simple as setting your bounding box to zero which would most likely cause it to fail to retrieve collision faces.

[Ledin]

I figure the offsets for these collision instructions must change with client updates, meaning they must be found again each time. There must be some method to the madness. I have IDA, but I am not sure how to go about using it for this purpose.

I found this thread, which shows snippets of the assembly instruction for the collision detection, but I haven't been researching this long enough to know if these change much with each game update.

http://www.ownedcore.com/forums/worl...ngine-wow.html (WoW Hacking For Beginners [Cheat Engine + WoW])

WoW has a GetMovementFacets function somewhere, so you should look for it in the movement functions.
If you break one of those things you should get noclip if that is what you want.

You could even do something as simple as setting your bounding box to zero which would most likely cause it to fail to retrieve collision faces.

But, how do I go about finding that function is the real question? Or at least the area around the function? I've already attempted to alter the compare and jump functions around the function that writes to one of my position variables.... I've gone both up and down maybe 100 jump/compare functions. Most of them crashing my client, freezing it, or doing nothing. The ones that I was able to get to have some effect in the game were usually those effecting my character animation.

[reliasn]

I used OHack's old source code to implement updated fly, climb, water walk and collision hacks. The offsets below are all for 32-bit WoW 6.1.2.19865.

For Fly hack, you need to mess with CMovement_C__IsFlyingOrSwimming = 0x366896, Script_JumpOrAscendStart = 0x382862 and apply a hook on CMovementShared__CalcDirection = 0x8FF0F0 or CMovement_CalcDirection = 0x8FEFA9. Beware: most of these offsets are currently scanned by Warden.

For Collision hack, it's all about messing with the collision flags passed to CMovement_C__IsColliding = 0x56351F. Since this function is also scanned by Warden, I decided to hook CMap__GetFacets = 0x563823 which calls CMovement_C__IsColliding iirc. And these are the collision flags:

enum CollisionFlags : unsigned int {
	CL_M2s = 0xF,
	CL_Terrain = 0x100,
	CL_IsNotPlayer = 0x2000,
	CL_WMOs = 0x200F0,
};

For climb hack, you need to patch CMovement_C__AttemptStepUp = 0x369A1F and CMovement_C__TraceSurface = 0x36A0EB.

For water hack, you can patch CMovement__SetMovementFlags = 0x366362.

As you can see, most functions are CMovement stuff. Curiously, most hacks released by l0l1dk on his open source OHack still work today - you just need to update the offsets every new patch, which shouldn't be a problem if you diff the binary properly.

Finally, always monitor Warden: most scanned offsets are a great hint at critical spots in the executable that could have a huge impact in the gameplay (these hacks, anti-afk, no zoom limit, etc).

By the way, if I was to reverse all these things by my own, I can't even imagine how long it would take me. It helps a lot when you have a nice IDB with most functions named :P

[JuJuBoSc]

Finally, always monitor Warden: most scanned offsets are a great hint at critical spots in the executable that could have a huge impact in the gameplay (these hacks, anti-afk, no zoom limit, etc).

I can't agree more with that, the Warden itself gave me exactly what I was looking for