[WoW] [6.2.2.20490] Release Info Dump Thread

[reliasn]

@reliason - how does one go about loading that pattern file "https://dl.dropboxusercontent.com/u/230498559/EWT/finalPattern.json"
in IDA? I have hunted everywhere online but cant seen to find how its loaded.

Nah, it won't work in IDA :P It's just a pattern scheme I created that works with my own tool (Easy WoW Toolbox). It's useful for me if I want to find simple stuff quickly without depending on diffing with BinDiff. With it, I basically get all the offsets that I need every new patch in less than 5 seconds.

In any case, it contains some useful info if you're learning about diffing and are really interested about where stuff is found. Btw, I've updated the first post with a link to my Windows 32-bit IDA database.

[WiNiFiX]

@Reliasn,
Ah ok thanks, btw, anyone wanting to know how to find these offsets the "hard" way see below, I explained it from a noob perspective in IDA (like me).




Anyone know how I can go about finding (in IDA / Cheat engine)
EntityList = DA69A0
FirstEntity = 0C
NextEntity = 3C
and
ClntObjMgrObjectPtr

[lolp1]

...

No offense, but you really need to quit getting so far ahead of yourself. You're trying to run before you can crawl. A google search "json pattern scanning c# game hacking" in 10 seconds told me that it was not some thing you load in IDA.

I really thought the pattern file reliasn posted was neat and very useful for me though, coming from learning about development in another game I tried the past few months to Wow, it gave me a huge head start in "lazy pointers" for wow. So , since there is so much good help given out here for no cost I'll try and give back a little to for others who might read this and are as confused as I was about patterns day one seeing them.

To put it simply, you can serialize objects from certain files such as xml and json, so what some people do is store their pattern scanning data(google about that) in one of those files, then when they want in their tool/bot/hack/what ever, they serialize the object and pattern scan every item in it and store the results so their pointers are up-to date hassle free.

This is how I personally do it:

http://pastebin.com/km7GRHZu

[WiNiFiX]

@lolp1, fyi, comments that start with no offense are offensive :P

@Reliasn, I have figured out most of your logic for pattern finding and got it working to a degree, please could you give me simple explanations on
ref, size, index, function, rebase & displ

I will post the source once I have it completed for others to use.

[lolp1]

:confused:

[reliasn]

@Reliasn, I have figured out most of your logic for pattern finding and got it working to a degree, please could you give me simple explanations on
ref, size, index, function, rebase & displ

• ref - the name of another function in the file
• size - if the offset has a length of 4 bytes, 2 bytes, 1 byte, etc
• rebase - if you need to rebase the found offset (static pointers need to be rebased while some offsets with immediate values do not)
• displ - displacement - the "offset" that must be added to "ref"'s value in order to find the desired offset. In other words, you don't use patterns, but the pattern of another found offset and then add a displacement to it
• function - 0 or 1 - used to calculate functions referenced in CALL/JMP instructions since they are referenced as relative. Therefore, you grab the offset from ref, add the displacement, find the 4 bytes that represent the relative jmp or call and then do some math to get where the real function is.
• index - used on VTables - it basically grabs the VTable offset and adds index * 4 to it, because that's how the VTable is represented in .rdata: a sequence with all the functions it refers, every 4 bytes. Since VTables are usually in .rdata and you're reading from the .exe, you will need to fix the found value with an offset that makes the physical address become the virtual address.

I won't copy/paste the whole source here because it's a mess but hit me up on Skype if you need more info. For now, I can share the snippet below. Keep in mind that I use RapidJSON to parse JSON files in C++.

int fixText = wowTextSection->VirtualAddress - wowTextSection->PointerToRawData; // 0xC00
int fixRData = wowRDataSection->VirtualAddress - wowRDataSection->PointerToRawData - fixText;
...
// While you iterate the pattern file, check if the offset has a "ref". 
// If it does, check if you already processed the referred function.
// If not, then find the offset normally with its pattern. 
// Btw, I used a std::map to store the already processed offsets.
...
... 
// After you find the offset, whether from the pattern or from the "ref" field

if(type){ // type = 1, offset was found with a pattern
	offset += fixText;
} else { // type = 0, offset found with "ref"
	if(a.HasMember("displ")){
		offset += a["displ"].GetInt();
	}
	if(a.HasMember("index")){
		offset += a["index"].GetInt() * 4;
		if(offset > wowTextSection->Misc.VirtualSize){ // offset is in RDATA
			offset -= fixRData;	// match RDATA pointer to raw data and virtual address
		}
	}
	offset = *(DWORD*)((DWORD)wowFile.c_str() + offset);
	if(a.HasMember("add")){
		offset += a["add"].GetInt();
	}
	if(a.HasMember("rebase") && a["rebase"].GetInt() || a.HasMember("index")){
		offset -= 0x400000;
	}
	if(a.HasMember("size")){
		int shift = 4 - a["size"].GetInt();
		if(shift){ 
			offset <<= shift*8;
			offset >>= shift*8;
		}
	}
	if(a.HasMember("function")){
		offset = offsets[a["ref"].GetString()].offset + a["displ"].GetInt() + 4 + offset;
	}
}

[WiNiFiX]

@reliasn

If you would prefer to chat over Skype I PM'd you

I think your code there is missing some logic, because if I follow the current logic (on build number for example, I get).
S13__Init = 0x3AD664 - This is correct according to posted offsets above, This is the "ref" of build number used in below sample calculation
1. offset = 0x0 + 0x39 [ because a.HasMember("displ") ]
2. offset = 0x39 + 0x3AD664
3. offset = 0x3AD69D - 0x400000 [ because a.HasMember("rebase") ]
Result = FFFAD69D, this is very far from 0xA22818

Am I missing something in the understanding here?

[Jadd]

Speaking of union structs, I tend to like using them.. is there anything wrong with using a struct like this compared to the one you posted I don't know about, or is it just preference?

Almost entirely preference. Marshaling sequential and explicitly defined structs are practically identical in speed.

[WiNiFiX]

Hey, any one got tips on how to find the memory address of Action Bar address and Key bindings for those bars?

[Jadd]

Hey, any one got tips on how to find the memory address of Action Bar address and Key bindings for those bars?

Exactly the same as you would get any other address that has been provided for previous patches. And I hope I never have to refer you to this post again because the answer is the same every time. Updating offsets is so easy.

1. Search for "key binding" or something similar in this forum. Within the first couple of posts I found that LazyBot makes use of distinctly named offsets:
- ActionBarFirstSlot
- NumKeyBindings

2. Search again for these exact names. The newer posts should appear first, so I can see that the latest addresses we have available for these offsets are from 6.2.0.20182 ([WoW] [6.2.0 20182] Release Info Dump Thread)
- ActionBarFirstSlot = 0xF11ED0
- NumKeyBindings = 0xEFFCA0

3. Open 6.2.0.20182 in IDA, go to the first address. You can name it if you want. [1]

4. Look at how you can find it in reverse, so that you can work from the starting point in future patches. I checked the first xref (sub_7DB7B5+6). [2]

5. Straight away I can see that this is referenced from a Lua function (Script_GetActionInfo+2F). You can almost always find these in the info dump threads. There's a script available to automatically name them for you, too, but I'm not going to go searching for it for you.

6. The reference makes less sense in a line of assembly, so decompile the function (push F5) and with a guess I would say it's some function to check if an action key is bound to a spell. We now know where and why it's referenced and this will make it easy to reverse in future patches. [3]

7. Back to the latest patch, we now have a starting point to update the offset. Head to Script_GetActionInfo again and we can see the new referencing function's address. [4]

8. Can you see ActionBarFirstSlot? [5]

[WiNiFiX]

Thanks, I think I get it, (all i needed was the hint to search for "GetActionInfo", I was looking for "Key" ,"IO" or "Input", etc...), I wanted to look at prior versions of the EXE but could not find the builds I had offsets for like 20182 and 19678

Its either F1EBFC or F1EBF8 (they only 4 bits apart so should be easy to find the right one)

[Jadd]

It should be pretty apparent if you look at it side by side. [1] [2]

[lolp1]

...useful info.....

Blizzhackers ? View topic - How To Update a Pointer using logic is also a good quick read. Updating offsets for WoW at least with all of it's prior resources of other peoples work being so open / free and easy to find should be no issue with some googling.

EDIT: And just to be useful, look at the info like this:

 data:00F1EBF8                               ; int dword_F1EBF8[]
.data:00F1EBF8 ?? ?? ?? ??                   dword_F1EBF8    dd ?                    ; DATA XREF: sub_3E074D+6r
.data:00F1EBF8                                                                       ; sub_3E0778+6r ...
.data:00F1EBFC                               ; int dword_F1EBFC[]
.data:00F1EBFC ?? ?? ?? ??                   dword_F1EBFC    dd ?                    ; DATA XREF: sub_3E074D+Dr
.data:00F1EBFC                                                                       ; sub_3E0778+Dr ...

EDIT: Better example of using those values, just tested myself. Just checked how lazy bot did it. Does not handle bonus bars.

         //  0xF1EBF8 // First action bar slot.
         //  0xF1EBFC // Bonus action bar.
     
        public struct WowActionBarSlot
        {
            public int Id;
            public int Bar;
            public int Slot;
        }

        private const int MaxSlots = 60;
        [SuppressMessage("ReSharper", "SuggestVarOrType_Elsewhere")]
        public static List<WowActionBarSlot> DumpActionBarSlots()
        {
            var actionBarSlots = new List<WowActionBarSlot>();
            var currentActionBar = 1;
            var currentBarSlot = 1;

            // Read all possible slots.
            int[] allActionBarSlots = Wow.Memory.Read<int>(Wow.Exe[WoWData.FirstActionBarSlot], MaxSlots);
            // Loop through results.
            foreach (var slot in allActionBarSlots)
            {
                // Each bar is always 12 slots max, if > 12 we're on a new bar at the first index.
                if (currentBarSlot > 12)
                {
                    currentActionBar++;
                    currentBarSlot = 1;
                }
                // If 0 the slot on the bar contains nothing. Should match skill id's on wow head otherwise. 
                // For example, if it's 585 it would be smite on that bar. http://www.wowhead.com/spell=585/smite
                var actionId = slot; 
                if (actionId != 0)
                {
                    actionBarSlots.Add(new WowActionBarSlot { Id = actionId, Bar = currentActionBar, Slot = currentBarSlot });
                }
                currentBarSlot++;
            }
            return actionBarSlots;
        }

[dragonbane24]

This thread has split off into interesting topics. Not complaining at all, just stating the obvious.

Anyway, I've been converting my Lazybot to 64 bit code and updating the LazyLib etc. I originally thought I was going to make it usable for both 32-bit and 64-bit with just a recompile, but I've had to tweak too many of the routines and such to bother trying to go back and make them all work properly. I'm sure it is do-able, but just not worth my time. So I'm posting my current offsets here. Not 100% guaranteed to work, but so far most of the basic functions seem to be up and running.

Maybe this will help someone out there who is thinking of doing the same.

/*
This file is part of LazyBot - Copyright (C) 2011 Arutha

    LazyBot is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    LazyBot is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with LazyBot.  If not, see <http://www.gnu.org/licenses/>.
*/

#region
using System;
using System.Reflection;
#endregion


#if true

namespace LazyLib.Wow
{
    [Obfuscation(Feature = "renaming", ApplyToMembers = true)]
    public class PublicPointers
    {
        #region Globals enum
        public enum Globals
        {
            PlayerName = 0x17EF7E0, 
        }
        #endregion

        #region InGame enum
        public enum InGame
        {
            InGame = 0x16A2F5E, 
            InstanceSize = 0x16A3064,
        }
        #endregion
    }

    internal class Pointers
    {

        #region Nested type: ObjectManager
        internal enum ObjectManager
        {
            //CurrentManager = Memory.Read<uint>(Memory.ReadRelative<uint>((uint) Pointers.ObjectManager.CurMgrPointer)
            //    + (uint) Pointers.ObjectManager.CurMgrOffset);
            //LocalGUID = Memory.Read<UInt64>(CurrentManager + (uint) Pointers.ObjectManager.LocalGUID);
            CurMgrPointer = 0x17EF770, 
            CurMgrOffset = 0x648,           
            NextObject = 0x68,              
            FirstObject = 0x18,             
            LocalGUID = 0x1D8,               
        }
        #endregion

        #region Nested type: BMAH
        internal enum BMAH
        {
            ItemCount = 0x1757Cc8,   // + CDA8
            ItemStart = ItemCount + 0x08,   
        }
        #endregion

        #region Nested type: Globals
        internal enum Globals
        {
            RedMessage = 0x16A2370, 
            MouseOverGUID = 0x16A3598, 
            LootWindow = 0x1716a24, 
            ChatboxIsOpen = 0x14557f0, 
            CursorType = 0x166878c, 
            IsBobbing = 0x1E0,                      
            ArchFacing = 0x490,                          
            ArchFacingOffset2 = 0x258,        
        }
        #endregion
      
        
#region ActionBar enum
        public enum ActionBar 
        {
            ActionBarFirstSlot = 0x1715030, 
            ActionBarBonus = ActionBarFirstSlot + 0x240, 
        }
#endregion

#region ClickToMove enum
        public enum ClickToMove
        {
            Offset = 0x60,
            Pointer = 0x16A3148, // + 0xCD00
        }
#endregion

#region AutoLoot enum
        public enum AutoLoot
        {
            Offset = 0x60,
            Pointer = 0x16A3188, // + 0xCD00
        }
#endregion

#region CgUnitCGetCreatureRank enum
        public enum CgUnitCGetCreatureRank
        {
            Offset1 = 0x16F0,                
            Offset2 = 0x38,                 
        }
#endregion

#region CgUnitCGetCreatureType enum
        public enum CgUnitCGetCreatureType
        {
            Offset1 = 0x16F0,                
            Offset2 = 0x30,                 
        }
#endregion

#region CgWorldFrameGetActiveCamera enum  
        public enum CgWorldFrameGetActiveCamera 
        {
            //return Memory.Read<uint>(Memory.ReadRelative<uint>((uint)Pointers.CgWorldFrameGetActiveCamera.CameraPointer) 
            // + (uint)Pointers.CgWorldFrameGetActiveCamera.CameraOffset);

            CameraX = 0x10,                      
            CameraY = 0x14,                  
            CameraZ = 0x18,                 
            CameraMatrix = 0x1C,
            CameraPointer = 0x16A3A10, 
            CameraOffset = 0x7768,                  
        }
#endregion


#region Nested type: AutoAttack
        internal enum AutoAttack 
        {
            //AutoAttackFlag = 0xEE8,       //Old Method
            //AutoAttackMask = 0xEEC,       //Old Method
            //Address seems to show the GUID of the Auto Attack target
            AutoAttackGUID = 0x1AE0,         
            //Shows 0x06 when not wanding, 0x0C or 0x0E when wanding.
            //Wanding = 0xEF8,                
        }   
#endregion

#region Nested type: CastingInfo
        internal enum CastingInfo
        {
            IsCasting = 0x1B98,              
            ChanneledCasting = 0x1BB8,       
        }
#endregion

#region Nested type: Chat
        internal enum Chat : uint  
        {
            //TODO : Go fix chat arrays and memory usage there.
            //Thx for struct info Torpedoes
            ChatStart = 0x16A52F0, 
            ChatPosition = 0x16FF84C,
            OffsetToNextMsg = 0x17F0,
            MsgSenderGuid	= 0x00,         
            MsgSenderName	= 0x034,        
            MsgFullMessage = 0x0065,        
            MsgOnlyMessage = 0x0C1D,        
            MsgChannelNum = 0x17D8,         
            MsgTimeStamp = 0x17E4,          
        }
#endregion

#region Nested type: RealId
        internal enum ReadId : uint
        {
            DatabasePointer = 0x17010C0, // + 0xCD30
            NumItems = DatabasePointer + 0x08,
            ItemSize = 0x33C,
        }
#endregion


#region BlueChat
        internal enum Messages
        {
            //This is incorrect.  I never use it, so haven't updated it.
            //Seems to be used in updating skills?
            //Same as red message?
            EventMessage = 0x16A2370, // + 0xCD00
        }
#endregion

 //Moved to Power3
//#region Nested type: ComboPoints
//        internal enum ComboPoints 
//        {
//            ComboPoints = 0xD91411,     // 5.4.8 (18414) (0x4F0 diff)
//        }
//#endregion

#region Nested type: Runes
        //Thx evil2
        internal enum Runes
        {
            RuneTypes = 0x171D0d8, // + 0xCD48  //Appears to be unused.
            RunesOffset = 0x171D13C, // + 0xCD48
            //Offset is usually RuneTypes + 0x64
        }
#endregion

#region Nested type: Container
        internal enum Container
        {
            //Provided by Charles.
            //Untested
            EquippedBagGUID = 0x171D0d8, //This is not correct - It's somewhere in the area likely though.
        }
#endregion


#region Nested type: KeyBinding
        internal enum KeyBinding
        {
            NumKeyBindings = 0x17017F0, 
            First = 0xC8,                   
            Next = 0xB8,                    
            Key = 0x30,                     
            Command = 0x58,                 
        }
#endregion


 #region Nested type: Macros
        internal enum MacroManager
        {
            MacroCount = 0x13E8410, // + 0xCD48
            MacroTable = 0x13E8420, // + 0xCD48
            MacroIdOffset = 0x30,
            SpecificMacroIdOffset = 0x38,
            MacroNameOffset = 0x44,
        }
#endregion


#region Nested type: Reaction
        //Thx for struct info JuJuBoSc
        internal enum Reaction 
        {
            FactionDBCStruct = 0x14BF900, // + 0xBE18
            FactionDBRows = FactionDBCStruct + 0x08,        
            FactionMaxIndex = FactionDBCStruct + 0x0C,      
            FactionMinIndex = FactionDBCStruct + 0x10,      
            //Naming string is at Memory.ReadUtf8(Memory.Read<uint>((uint)Pointers.Reaction.FactionDBNaming), 64);
            FactionDBNaming = FactionDBCStruct + 0x18,      
            FactionDBData = FactionDBCStruct + 0x20,        
            FactionDBFirstRow = FactionDBCStruct + 0x28,    
            FactionDBRowSize = FactionDBCStruct + 0x54,     
            HostileOffset1 = 0x14,                          
            HostileOffset2 = 0x0C,                          
            FriendlyOffset1 = 0x10,                         
            FriendlyOffset2 = 0x0C,                         
        }
#endregion


/*
 * //Now using the one from the descriptors offset.
#region Nested type: ShapeshiftForm
        internal enum ShapeshiftForm 
        {
            BaseAddressOffset1 = 0xE4,       // 5.4.8 (18414)
            BaseAddressOffset2 = 0x1E3,      // 5.4.8 (18414)
        }
#endregion
*/

#region Nested type: SpellCooldown
        internal enum SpellCooldown : uint 
        {
            CooldPown = 0x14DE1B0, // + 0xC8A0
        }
#endregion

#region Nested type: Swimming
        internal enum Swimming  
        {
            Pointer = 0x230,    
            Offset = 0x58,      
            Mask = 0x100000,    
        }
#endregion

#region IsFlying enum
        public enum IsFlying
        {
            Pointer = 0x230,    
            Offset = 0x58,      
            Mask = 0x1000000    
        }
#endregion

#region Nested type: UnitSpeed
        internal enum UnitSpeed
        {
            Pointer1 = 0x230,   
            Pointer2 = 0xA0,    
        }
#endregion


#region Nested type: UnitAuras
        internal enum UnitAuras : uint 
        {
            AuraCount1 = 0x2390,        
            AuraCount2 = 0x1D10,        
            AuraTable1 = 0x1D14,        
            AuraTable2 = 0x1D18,        
            AuraSize = 0x68,            
            AuraSpellId = 0x50,         
            AuraStack = 0x59,           
            TimeLeft = 0x60,            
            OwnerGUID = 0x40,           
        }
#endregion

#region Nested type: UnitName
        internal enum UnitName : uint
        {
            ObjectName1 = 0x498,                
            ObjectName2 = 0xD8,                 
            PlayerNameGUIDOffset = 0x020,       
            PlayerNameStringOffset = 0x031,
            PlayerNameCachePointer = 0x14C3FD8, // + 0xC850
            UnitName1 = 0x16F0, // 0xC04,                  
            UnitName2 = 0xA0,                   
        }
#endregion

#region Nested type: WowObject
        internal enum WowObject 
        {
            X = 0x1548,                                   
            Y = X + 0x4,                                
            Z = X + 0x8,                                
            RotationOffset = X + 0x10,                  
            GameObjectX = 0x0248,                       
            GameObjectY = GameObjectX + 0x4,            
            GameObjectZ = GameObjectX + 0x8,            
            GameObjectRotation = GameObjectX + 0x10,    
        }
#endregion

#region Nested type: Zone
        internal enum Zone : uint
        {
            ZoneText = 0x16A2F70,
            ZoneID = 0x16A2FE0, 
        }
#endregion


#region Nested type: UiFrame
        internal enum UiFrame 
        {
            //var @base = Memory.ReadRelative<uint>((uint)Pointers.UiFrame.FrameBase);
            //var currentFrame = Memory.Read<uint>(@base + (uint)Pointers.UiFrame.FirstFrame);

            ScrWidth = 0x1355088, 
            ScrHeight = 0x135508C,
            FrameBase = 0x14479d0,
            CurrentFrameOffset = 0x160, 

            FirstFrame = 0x23E8,
            NextFrame = 0x23D8, 
            RegionsFirst = 0x220,
            RegionsNext = 0x210, 
            Visible = 0xC0, 
            Visible1 = 0x1A,                
            Visible2 = 1,                   
            LabelText = 0x1A0, 
            Name = 0x30, 

            ButtonEnabledPointer = 0x1F4,   //Assumed Good
            ButtonEnabledMask = 0xF,        //Assumed Good
            ButtonChecked = 0x230,          //Assumed Good
            EditBoxText = 0x210,            //Assumed Good
            FrameBottom = 0xC4, 
            FrameLeft = 0xC8, 
            FrameTop = 0xCC, 
            FrameRight = 0xD0, 
        }

#endregion
    }
}

#endif

[lolp1]

...

Thanks for the ui frame stuff.


Side note, there is no reason I can think of to bother with porting any existing large code bases to x64. You gain practically nothing. You're not safer from detection, you're not more compatible, you're not gaining worth while performance, you're not getting access to any libs written for x64 wow, etc. If writing a brand new code base, it perhaps might be worth it just because why not?