[WoW][3.2.2] Info Dump Thread

[halloman]

Originally Posted by arthanos2

For everybody always asking for Playerbase, here you go, in autoit for you.

Func getplayerbase()

$gclientconnection = _MemoryRead(0x12705B0, $HPROCESS, "dword")
$scurmgr = _MemoryRead($gclientconnection + 0x2d94, $HPROCESS, "dword")
$curobj = _MemoryRead($scurmgr + 0xac, $HPROCESS, "int")
$nextobj = $curobj
Dim $GUID
Dim $pbase

While ($curobj <> 0 And BitAND($curobj, 1) = 0)

$nextobj = _MemoryRead($curobj + 0x3c, $HPROCESS, "int")
$GUID = _MemoryRead(($curobj + 0x30), $HPROCESS, "uint64")
$playerguid = _MemoryRead($scurmgr + 0xC0, $HPROCESS, "uint64")

If $GUID == $playerguid Then
$pbase = $curobj
EndIf

If $nextobj = $curobj Then
ExitLoop
Else
$curobj = $nextobj
EndIf

WEnd
Return $pbase
EndFunc ;==>getplayerbase

to get pbase:

$lololplayerbase = getplayerbase()

Don't be to lazy to rep me, enjoy.

thx try it later that day when im back home

[Nesox]

Static LocalPlayer pointer = [[[0x12D4EA8] + 0x34] + 0x24]

Here's the correct offsets for dumping buffs ..

enum UnitBaseGetUnitAura
{
AURA_COUNT_1 = 0x0DD8, //CGUnit_C__GetUnitAura(int index) 3.2.a 0x0DC8
AURA_COUNT_2 = 0x0F4C, //CGUnit_C__GetAura(int index) 3.2.a 0xF3C
AURA_TABLE_1 = 0xC58, //CGUnit_C__GetUnitAura(int index) 3.2.a 0xC48
AURA_TABLE_2 = 0xC60, //CGUnit_C__GetUnitAura(int index) 3.2.a 0xC50
AURA_SIZE = 0x18, //Size of the Aura Struct, 6 * 4 bytes
AURA_SPELL_ID = 0x8 //Offset in the struct for the Id, "Second Integer"
} ;

[Ohsnap]

Thanks for the information. Highly appreciated.

[Nuegenx]

I am currently working on a idc file for my patchday that will work for WoW i am off by 10 on the total but it would allow all opcodes to be updated from the exe with in a couple minutes it posted on my site for the developers. on [Only registered and activated users can see links. ] this is a Bot creation site and developers are welcome to come and help work up the basis.

[ReversingForFun]

Originally Posted by Nesox

Here's the correct offsets for dumping buffs ..

enum UnitBaseGetUnitAura
{
AURA_COUNT_1 = 0x0DD8, //CGUnit_C__GetUnitAura(int index) 3.2.a 0x0DC8
AURA_COUNT_2 = 0x0F4C, //CGUnit_C__GetAura(int index) 3.2.a 0xF3C
AURA_TABLE_1 = 0xC58, //CGUnit_C__GetUnitAura(int index) 3.2.a 0xC48
AURA_TABLE_2 = 0xC60, //CGUnit_C__GetUnitAura(int index) 3.2.a 0xC50
AURA_SIZE = 0x18, //Size of the Aura Struct, 6 * 4 bytes
AURA_SPELL_ID = 0x8 //Offset in the struct for the Id, "Second Integer"
} ;

Thank you very much.
I was wondering if you would mind copying the memory address of the CGUnit_C__GetAura function? i am still unable to find it and it really starts to drive my nuts.
Thank you very much in advance.

[naa]

.text:0055D370 CGUnit_C__GetAura proc near

[guizmows]

little contrib :

cache player name ptr : 0x12542D8 //Tested
cache pet name : 0x12544F8 
cache item text : 0x1254608

[Tanaris4]

Originally Posted by Apoc

    public enum VFTableIndex
    {
        GetBagPtr = 10,
        GetPosition = 10,
        GetFacing = 12,
        GetScale = 14,
        Interact = 41,
        GetName = 51,

        // PLAYER ONLY
        GetAFKText = 63,
        GetDNDText = 64,
        GetGMText = 65,
    }

Noob question mb, virtual func table? What are these used for? (the stubs created for injection?)

[Robske]

Originally Posted by Tanaris4

Noob question mb, virtual func table? What are these used for? (the stubs created for injection?)

http://en.wikipedia.org/wiki/Virtual_method_table

:/

[Tanaris4]

0x0113F2B0,//Battle Ground Status

Can you state more about the values of this?

[MaiN]

Originally Posted by Tanaris4

Can you state more about the values of this?

Try this:
[Only registered and activated users can see links. ]
They're probably indexed like shown there.

EDIT:

  switch ( dword_113F2B0[14 * v4] )
  {
    case 0:
      v6 = "none";
      break;
    case 1:
      v6 = "queued";
      break;
    case 2:
      v6 = "confirm";
      break;
    case 3:
      v6 = "active";
      break;
    default:
      v6 = "error";
      break;
  }

v4 is the battleground index (starting at 0).

[mnbvc]

i could use a static for local player rage and player targets hp. is there any? or do i need to use the objectmanager?

[aGor2k]

Thanks a lot!

Btw, does someone have the offset for the object type? Like if it's a player, npc, creature etc

[lanman92]

Should still be at 0x14. Those kind of offsets don't change much usually.

[wraithZX]

<rant>

I know this probably isn't the place to be complaining, but seriously, why are people continually asking for offsets, patch after patch?

There seems to be a natural cycle in this forum - a few people that consistently contribute to this forum, patch after patch, as well as a bunch of newer people who wander in each patch, ask stuff for a few patch drops, decide it's all too hard and head out.

Do half you people even attempt to understand the reasons why these things do or don't change?

The forum rules state that a certain level of knowledge is required to be able to participate in the discussions here - surely by extrapolation and a little research you'd be able to find out where/how/why offsets change? Sections 4 and 6 of the forum rules come to mind. Hell, section 2 explicitly prohibits asking for offsets.

It took me a grand total of 15 minutes after patching to find and post the ~15 offsets I needed, as well as generate and post my (non-)updated descriptors. I don't proclaim to know much about reverse engineering, far from it. But I've bought the required tools and done the legwork to understand the amount of knowledge needed to get what I need without external intervention. Everyone's aim as far as RE'ing WoW should be the same. Become self-sufficient, and you'll end up contributing more than you think. Not to mention that doing the research has actually helped dissecting crashdumps in my desk job. (Thankyou GD/MMOwned! )

Don't get me wrong, I'm all for sharing offsets - what I'd like to see in the forum is more questions about how to find them yourself, not just what the actual values are. Those sorts of questions do a lot more for the community as a whole, in the sense that they end up spreading knowledge, compared to threads continually asking for stuff that changes patch after patch.

I don't know, talking out my arse here, but maybe we can change something so we filter the stupid stuff and end up having more visible discussions of the juicier stuff. Maybe a change of structure or something can be sorted out so that the newer people find stuff easier, thus asking a lower number of stupid questions?

</rant>

With any luck, this post falls outside section 7 Hmmm, reminds me of Ghost in the Shell. Might watch that tonight.