Reading position xyz and character data, seeking to learn more

[CaptainCode]

Hello guys, I'm new here. I've made fishing bots and pixel bots in the past, but recently I started looking at memory reading.

I'm using C++ with ReadProcessMemory -- I started by trying to find my character's position and health.

Here is what I've done so far; all feedback welcome:
1. Look at current max health, call it H1, scan entire process memory (Using VirtualQueryEx and ReadProcessMemory ), look for any 32-bit regions that match this value.
2. Change health (by swapping out gear) to H2, and then scan all locations that used to be H1, see where it has become H2. This gave me addresses for current health and max health.
3. Look at character position using UnitPosition call ingame, try to find, near the location found in #2 , a consecutive pair of floats that are close enough to this value.

I successfully managed to do this, and I can see live coordinates & health in my separate program.

(What I found interesting is that the address doesn't seem to change when I log out and change character! This seems odd to me, I'd imagine when you log out the memory associated with the character is freed and then logging in would reallocate, probably in a totally random part of memory. It doesn't seem to be the case, however.)

Here are my questions:
1. The memory addresses I find seem to be absolute values, but looking around the forum, people seem to specify constant "offset" values for where certain variables are. Is there a trick I'm missing here?
2. I have to restart the search process (search, change gear, search again..) every time the game restarts.. is there a better way to find these values?
3. I'm basically operating blind, accessing raw memory and tweaking it, looking for patterns, etc. Looking around, it seems people have more in-depth information about the data structures, objects, etc. in the memory. Is there something missing from my toolkit?

Any other feedback welcome.

[oiramario]

You can get all the Magic Secrets in this forum by searching.

[CaptainCode]

You can get all the Magic Secrets in this forum by searching.

Search for what ? I didn't ask for magic secrets, just wanted to know if there was another way to do things other than what I did.

[oiramario]

I think you prefer this to search
GitHub - MicahRCM/Happy-Pixels: Learn how to develop a WoW Bot

[CaptainCode]

I think you prefer this to search
GitHub - MicahRCM/Happy-Pixels: Learn how to develop a WoW Bot

Thank you for the link, but it is clearly (and intentionally) off-topic.

[xalcon]

What answer do you expect? All of these things have been answered in the past, you are asking basic questions about how object oriented language work on memory level.

(What I found interesting is that the address doesn't seem to change when I log out and change character! This seems odd to me, I'd imagine when you log out the memory associated with the character is freed and then logging in would reallocate, probably in a totally random part of memory. It doesn't seem to be the case, however.)

This expected behavior. Just because memory gets freed, doesn't mean it gets zeroed/reset. If you would've dabbled in basic c programming, you would know that you need to zero memory before using something since it can contain garbage from earlier allocations or even the default 0xCC interrupt. It's totally expected to still see the old HP values when changing characters, the allocator just didn't reuse that memory yet.

1. The memory addresses I find seem to be absolute values, but looking around the forum, people seem to specify constant "offset" values for where certain variables are. Is there a trick I'm missing here?

Basic memory stuff. WoW is designed with an object oriented language and they utilize member variables to store stuff. If you find an offset, you will need the object instance (base address) and then add the offset to that address to get to the value in question.

2. I have to restart the search process (search, change gear, search again..) every time the game restarts.. is there a better way to find these values?

Of course there is a better way, just find out how wow stores things. A lot of stuff is accessible through one or more static variables. Ingame objects for example are stored in the object manager in a linked list. Just find the address of the object manager (either by static analysis or via pattern scanning or whatever other technique there is) and iterate the list. There are dozens of threads that talk about iterating through the object manager, out of process as well as in process.

3. I'm basically operating blind, accessing raw memory and tweaking it, looking for patterns, etc. Looking around, it seems people have more in-depth information about the data structures, objects, etc. in the memory. Is there something missing from my toolkit?

Sounds like you are missing a disassembler. Most people here use IDA, I've tried Ghidra in the past but never managed to get it working with the shadowlands client (If anyone has more info on how to get ghidra working with wow, let me know). IDA 7 Free is enough to get going, no need to shell out thousands of dollars for the hex rays decompiler.

Generally, I feel like you are missing the absolute basics. Start with a simpler project. Here are some things I've done (not in order)

• Read a book (or ten) on reverse engineering. Heck, there are a million guides on youtube
• Create your own C++ Application with Classes that prints out member variables in a loop, then hack it.
• Read through older posts in this forum
• Learn x86/x86_64 ASM
• hack a simple game

[CaptainCode]

Thank you xalcon for your in-depth response.

This expected behavior. Just because memory gets freed, doesn't mean it gets zeroed/reset. If you would've dabbled in basic c programming, you would know that you need to zero memory before using something since it can contain garbage from earlier allocations or even the default 0xCC interrupt. It's totally expected to still see the old HP values when changing characters, the allocator just didn't reuse that memory yet.

No, I'm saying something different. I'm saying that even when you log into a new character, the player data is in the exact same memory location. This is not expected behavior at all, if the memory is freed and reallocated it would be a very happy coincidence if newly allocated memory is in the exact same place.

Basic memory stuff. WoW is designed with an object oriented language and they utilize member variables to store stuff. If you find an offset, you will need the object instance (base address) and then add the offset to that address to get to the value in question.
Of course there is a better way, just find out how wow stores things. A lot of stuff is accessible through one or more static variables. Ingame objects for example are stored in the object manager in a linked list. Just find the address of the object manager (either by static analysis or via pattern scanning or whatever other technique there is) and iterate the list. There are dozens of threads that talk about iterating through the object manager, out of process as well as in process.

Thanks, yes, I've spent a few hours reading and I'm working on how to access the object manager from static memory.

Sounds like you are missing a disassembler. Most people here use IDA, I've tried Ghidra in the past but never managed to get it working with the shadowlands client (If anyone has more info on how to get ghidra working with wow, let me know). IDA 7 Free is enough to get going, no need to shell out thousands of dollars for the hex rays decompiler.

Am I understanding correctly, that the purpose of disassembling is to reverse engineer basic functions, so that by seeing how the code operates on memory, we deduce the memory locations and what is in the memory?

Are you just attaching a disassembler to the wow.exe file?

[karnkore]

You need to correctly dump wow to open it in ida, you cant just attach a dissasembler as they use anti-debug stuff. Your best bet is to use someone elses posted offsets and write patterns/ida scripts for them so you can find them yourself when a patch happens. WoW is not a noob friendly game to hack dude, they have all sorts of defense like crc checks and checks for open handles. I started as a newb on WoW 1.12.1 private server and wrote a waypoint bot, you can have it fully external using only reads and you get to learn juicy stuff like how the object manager works and how to rotate a character based on heading.

[xalcon]

No, I'm saying something different. I'm saying that even when you log into a new character, the player data is in the exact same memory location. This is not expected behavior at all, if the memory is freed and reallocated it would be a very happy coincidence if newly allocated memory is in the exact same place.

I don't have a full understanding of how wow handles allocation and deallocation of objects but this sounds like they use an allocator specific to objects in the object manager. An Object pool would probably show similar behavior. But that doesn't really matter, you shouldn't rely on objects staying in the same location in memory across relogs.

Am I understanding correctly, that the purpose of disassembling is to reverse engineer basic functions, so that by seeing how the code operates on memory, we deduce the memory locations and what is in the memory?

Are you just attaching a disassembler to the wow.exe file?

It's not just basic functions, even complex stuff. A lot of us still use older versions of the games binaries that were linked with debug information enabled, which gives a lot of insight into the inner workings.
But like karnkore said, you will need to dump the wow process since we can't just attach a debugger to wow without deafeating their debugging protection.

[CaptainCode]

You need to correctly dump wow to open it in ida, you cant just attach a dissasembler as they use anti-debug stuff. Your best bet is to use someone elses posted offsets and write patterns/ida scripts for them so you can find them yourself when a patch happens. WoW is not a noob friendly game to hack dude, they have all sorts of defense like crc checks and checks for open handles. I started as a newb on WoW 1.12.1 private server and wrote a waypoint bot, you can have it fully external using only reads and you get to learn juicy stuff like how the object manager works and how to rotate a character based on heading.

Thanks for your response. Is my understanding correct that wow packs the code inside wow.exe, and at runtime decodes the real game code into memory, which is what we have to read somehow?

I don't plan on writing memory so the crc checks don't bother me, I am happy to just send mouse and keystrokes -- my fishing bot has been running 20 hours a day for the last month without issues.

Regarding open handles, I'm guessing that you mean the process handle used by ReadProcessMemory? There is no way around this, is there?

[scimmy]

Thanks for your response. Is my understanding correct that wow packs the code inside wow.exe, and at runtime decodes the real game code into memory, which is what we have to read somehow?

I don't plan on writing memory so the crc checks don't bother me, I am happy to just send mouse and keystrokes -- my fishing bot has been running 20 hours a day for the last month without issues.

Regarding open handles, I'm guessing that you mean the process handle used by ReadProcessMemory? There is no way around this, is there?

Packing an executable is basically just running some type of algorithm through the code or data sections of the PE file. It also generally changes the entrypoint of the executable to some type of decompression/decryption routine so the "real" code and data can be mapped into memory properly.

I'm not sure if they look for open handles. Does NtQuerySystemInformation have a class that provides this info from usermode? I was under the impression that you'd have to iterate the handle table from the kernel structures to find out which processes have open handles to other processes. Regardless, there are ways to use readprocessmemory without having to open a handle such as hijacking an already opened handle from system processes such as svchost or lsass. Or you can go down the kernel driver route and implement your own readprocessmemory without using the windows API.

[Hazzbazzy]

Packing an executable is basically just running some type of algorithm through the code or data sections of the PE file. It also generally changes the entrypoint of the executable to some type of decompression/decryption routine so the "real" code and data can be mapped into memory properly.

I'm not sure if they look for open handles. Does NtQuerySystemInformation have a class that provides this info from usermode? I was under the impression that you'd have to iterate the handle table from the kernel structures to find out which processes have open handles to other processes. Regardless, there are ways to use readprocessmemory without having to open a handle such as hijacking an already opened handle from system processes such as svchost or lsass. Or you can go down the kernel driver route and implement your own readprocessmemory without using the windows API.

To answer part of your question, yes there is a clas that allows for handle enumeration through user mode. If you're interested, do a search for SYSTEM_HANDLE_INFORMATION.

[xalcon]

Regarding open handles, I'm guessing that you mean the process handle used by ReadProcessMemory? There is no way around this, is there?

Ofc there are ways around those open handles. Having an open handle to a process in general isn't going to be a problem. A lot of legitimate applications have open handles to other processes, heck even injection of libraries is a legitimate use case. Discord for example injects a library into game processes in order to render its overlay. But if you want to be really stealthy about it, you will need to move to a kernel driver which is a completly different can of worms.

everything can be circumvented as long as you are the owner of the hardware running the software. It's just a matter of how complex its going to be - and if it is worth it circumventing the measures put in place.

[moisteroyster]

I’m currently on a mission to find the same answers.