[Help] PlayerAdress

[Zombie911]

I have similar problem!

EnableDebugPrivileges not guilty. If anything it's not, then the result of reading the memory was filled to zero.

I think this happens because another threads who write memory at a time when you read it.
ReadProcessMemmory returns FALSE if an error occurred while reading from memory.

ReadProcessMemory(handle2, (LPCVOID)base, &base, sizeof(buffer), &rw);

In this case: if the value of your variable "rw" is less than or not equal to the number of bytes a fourth argument, "sizeof (buffer)" then the value of the third argument is not right.

A good test of what you read, it seems to this

DWORD rw = 0;
BOOL ret = ReadProcessMemory(handle2, (LPCVOID)base, &base, sizeof(buffer), &rw);
if( ret == FALSE || rw != sizeof(buffer) )
{
    //Read FAILED
}

[unbekannt1]

Thanks for your help. I just tested it with :

bool ret = ReadProcessMemory(handle, (LPCVOID)adresse, &puffer, sizeof(puffer), &rw2);
	if( ret == FALSE || rw2 != sizeof(puffer) )
	{
		std::cout<< "Reading Error";
	}

The first two times i started my program everythink worked fine, but the third time i got "Reading Error". So it is exactly that what Zombie911 said.

But how can i fix it?

[apollo0510]

Hi unbekannt1,

the source of all your problems is, that you assume to find static data.

First, it is not static at all. Especially when the client starts up, or when you are zoning, reloading the UI etc.

Second, you are observing the data from a totally asynchronious point of view. We are living in a preemtive-multiprocessor-world now, so you can not rely on the data and pointers that you have just read from another processes memory. All you can do is hope that the data is correct, and you must always expect pointers that do not fit together.

Thats why Cypher said, your code is awful. You do not even check one of your intermeditate values. In fact, you should check each value that you read from the process memory if it makes sense. For example it is possible to verify pointers if they point to a valid memory region in the other process.
If not - just skip all further calculations and try again a little while later.

Your problem is the typical punishment for accessing data "out of process".

Please think about your problem : While you are reading the data, it may change at the very same time. You can never know if it is valid or not.

Apollo

[unbekannt1]

But i thought the playerbase is static?

[apollo0510]

But i thought the playerbase is static?

Ouch.

Would you please have a look at your own code ? You are not using the static playerbase, but the Worldframe + 2 adress hops method.

How can you seriously expect those pointers to be static ?
Only the first one (pointing to the worldframe pointer) is static.

Apollo

[unbekannt1]

Sry i am very new^^

Only the first one (pointing to the worldframe pointer) is static.

That was what i mean with static. I mean if i can successfully read the world frame pointer and using my code everythink should be fine or?

So when i am right i dont understand why sometimes i cant read the worldframe pointer?

[apollo0510]

At this point I raise the question , if you know what you are doing at all.

But let me explain:

The guys who program WoW use C++ to do their work.
So they define a class called CWorldframe, and they have one static pointer to the one and only worldframe object. That pointer is NULL when the program starts, and is initialized, when the player enters the world:

CWorldframe * pWorldframe=NULL;

void PlayerEntersWorld()
{
pWorldframe=new CWorldframe();
}

void PlayerLeavesWorld()
{
delete pWorldframe;
pWorldframe=NULL;
}

If your external program is scanning the content of the pWorldframe pointer, you will see NULL for a while, and then it gets a value, when the player enters the world. And it may become NULL again, if the player logs out and goes back to the character selection screen.

Now the CWorldframe object has a member variable that points to another structure. This pointer is initialized shortly after the worldframe is created. And that structure again has a member variable that points to your player object.

So in order to get your player address, you are following a chain of pointers that is initialized at one point, and which is invalidated at another time.

As you run your external app out of process, you can not know, when the pointer chain becomes valid, and when it becomes invalid again.

If that did't help, you should stop coding.

Apollo

[unbekannt1]

Ok thank you so far i got it, but what i really cant understand is, the pWorldframe pointer is static. I am standing with my char somewhere in the world. No loading screen or something similar. Why the hell I sometimes can not read it? This is the only problem in my program that i sometimes cant read the pointer of pWorldframe which will break the chain.

[apollo0510]

Ok. Another thing:

I assume, your program runs in a loop.

It is ok to search the window handle for the wow applicatiohn once.
It is ok to adjust debug provileges once.
It is ok to open the wow process once.

But INSIDE the loop, you must never memorize pointers to anything.
Do not assume, that the pointer to the playerbase remains static.

For EVERY loop of your program, calculate the playerbase again.
If you detect abnormal pointers (NULL or outside the limits for the WoW process, or ill aligned), stop further computing, and continue with the next loop. As a first precaution, you should always check the result of ReadProcessMemory, therefore checking if you really read the exact amount bytes you wanted to read.

It is also a good idea, to simply check inside the loop. if your window handle is still a valid window handle. If not -> quit your program.

Apollo

[unbekannt1]

Ok for testing i put some code for memory reading in a loop :

unsigned adresse = 0x010B65F4;
unsigned int puffer;

	bool ret = ReadProcessMemory(handle, (LPCVOID)adresse, &puffer, sizeof(puffer), &rw2);
	while ( ret == FALSE || rw2 != sizeof(puffer) )
	{
bool ret = ReadProcessMemory(handle, (LPCVOID)adresse, &puffer, sizeof(puffer), &rw2);
		std::cout<< "Reading Error";
	}

When i start the program either it works at the first reading process or it reads...reads... and reads.

So i think there must be a problem with he hwnd,Process Id or handle?

[opulent]

Message removed.

[apollo0510]

Ok for testing i put some code for memory reading in a loop :

unsigned adresse = 0x010B65F4;
unsigned int puffer;

	bool ret = ReadProcessMemory(handle, (LPCVOID)adresse, &puffer, sizeof(puffer), &rw2);
	while ( ret == FALSE || rw2 != sizeof(puffer) )
	{
bool ret = ReadProcessMemory(handle, (LPCVOID)adresse, &puffer, sizeof(puffer), &rw2);
		std::cout<< "Reading Error";
	}

When i start the program either it works at the first reading process or it reads...reads... and reads.

So i think there must be a problem with he hwnd,Process Id or handle?

ouch again.

Please please, never define a variable that shadows the existence of another. That is very very bad programming style. And thanks god, some compilers would simply refuse to compile your code example ...

... and please, just write your loop like this:

main()
{
FindWindow
OpenProcess
GetDebugAccess
while(WindowHandleIsValid)
{
ReadProcessMemory(...)
if(EverthingSeemsToBeOk)
{
DoSomethingWithTheData
}
WaitSomeTime();
}
}



Apollo

[unbekannt1]

unsigned adresse = 0x010B65F4;
unsigned int puffer;

	bool ret = ReadProcessMemory(handle, (LPCVOID)adresse, &puffer, sizeof(puffer), &rw2);
	while ( ret == FALSE || rw2 != sizeof(puffer) )
	{
ReadProcessMemory(handle, (LPCVOID)adresse, &puffer, sizeof(puffer), &rw2);
		std::cout<< "Reading Error";
	}

I used this code and not the wrong one above. I think this code is ok for testing.

I now found out that the problem is that the Window Handle is sometimes invalid(meas that it has a wrong value).

Is that a normal problem or is it because i have so ****ed up code?

[amadmonk]

unbekannt1, your code is messy, but no more so than the average novice programmer's. The only way you'll learn and grow as a programmer is to make mistakes, so keep plugging away.

Your core problem here is what's known as a "race condition." In this situation, you have two unsynchronized bits of code that "race" to do something. One may be writing a data value, one may be reading it. The problem is, without synchronization you simply cannot know which one will get to the finish line first. This is why race conditions are so maddening; they're not "always good" or "always bad" -- they just break... sometimes... and it's not always clear what the trigger is.

Your out-of-process memory reading is racing Blizzard's code to read a value that WoW wants to write. This isn't entirely the fault of your code; all out-of-process scanners will have this issue, to a greater or lesser degree. Even reading statics isn't 100% failsafe, since there's no guarantee that what the static points to won't change mid-read.

In this particular race condition, the more hops you use, the more risk you run, so it's probably a better idea to use the static playerbase if possible. Even this won't completely insulate you, but it will help.

Try to validate EVERYTHING. This is good programming form, and it will also reduce your risk of races a bit (because of the programming model you're using, you can't get to zero risk, but you can reduce the risk greatly). So, validate window handles. Check return values from ReadProcessMemory, and make sure the "bytes read" equals the bytes expected to be read, make sure pointers are aligned correctly. If anything returns a wrong or "weird" value, best to just assume you have no data for that read loop cycle.

Also, if you have multiple pointers in a block of memory, consider reading the entire block in one read, rather than multiple small reads. To reduce the risk of races, you want your read loop to be as fast as possible, and in this style of code, the ReadProcessMemory is by far (factors of ten) the slowest operation.

Finally, to echo what the others have been saying, make sure you're calling all of your API's correctly -- disposing of handles correctly, checking return values, and so on. Not only is it good programming style -- it may well save you from weird, hard-to-explain errors later -- but it will help you shave off just a tiny bit more percentage points chance off your likelihood of races (since races will likely show up in inconsistencies in the API's return values and so on). Read the free online MSDN docs for each API you use to understand how the API is supposed to be called and what its return values are.

Take heart; this is not a trivial task. In fact, full synchronization out-of-process (with no injected code and no communication between the target program and the scanner) with zero potential races is, by definition, impossible. All you can do is stack the deck and try to improve your odds.

[unbekannt1]

amadmonk thank you for your detailed answer, but what is with Glider. Glider didnt inject code it was just a memory reader, too. There i never had this problem that i had to start the program many times until it gets the right hwnd.