ReadProcessMemory and thread-safety in general

[flo8464]

Hi.
Why is ReadProcessMemory safe against race-conditions etc?
I see all out-of-process bots working properly. But internally ReadProcessMemory does nothing more than dereferencing the process handle and call something like memcpy.
I really don't get it.

Second, if you would write an injected bot for a game NOT using the TLS, do you think it is safe enough to just run the whole bot in your own thread instead of hijacking the mainthread? I doubt it, but I would appreciate an answer to this.

Greetings,
Flo

-----------
Third sidequestion...anyone here seriously reversing Runes of Magic? Please drop me a message, I got a few questions regarding the ObjectContainer, thanks

[kynox]

Hi.
Why is ReadProcessMemory safe against race-conditions etc?
I see all out-of-process bots working properly. But internally ReadProcessMemory does nothing more than dereferencing the process handle and call something like memcpy.
I really don't get it.

Second, if you would write an injected bot for a game NOT using the TLS, do you think it is safe enough to just run the whole bot in your own thread instead of hijacking the mainthread? I doubt it, but I would appreciate an answer to this.

Greetings,
Flo

-----------
Third sidequestion...anyone here seriously reversing Runes of Magic? Please drop me a message, I got a few questions regarding the ObjectContainer, thanks

Regarding your second question, no. When two threads try and call/read/whatever something at the same time, it's the same effect as having two fat kids try and get the same piece of cake.

In a real world example, take lua_dostring. You try call it while theres already a lua function being executed by the game, the lua VM isn't ready to handle this and subsequently shits itself.

The bonus of executing in EndScene is that a) It's an easy callback to execute logic in as its end of the scene (duh), meaning all game updates have already been processed and b) The added bonus of being able to execute code on their thread.

[Cypher]

Hi.
Why is ReadProcessMemory safe against race-conditions etc?
I see all out-of-process bots working properly. But internally ReadProcessMemory does nothing more than dereferencing the process handle and call something like memcpy.
I really don't get it.
[SNIP]

Its not.

You're misunderstanding the difference between a race condition and an exception of some sort (caused by said race condition).

ReadProcessMemory uses SEH internally to make sure that your application won't crash if you try to read from an invalid address. If you simply do the same you will be fine.

Example:

// Must compile with 'C++ with SEH' exceptions
int ReadSomeInt()
{
try
{
int* pMyInt = reinterpret_cast<int*>(0xDEADBEEF);
return *pMyInt;
}
catch(...)
{
// Something went wrong
return 0;
}
}

The race condition and invalid memory access is still there, we're simply 'masking' it. It does NOTHING to solve the underlying problem.

Regarding your second question, no. When two threads try and call/read/whatever something at the same time, it's the same effect as having two fat kids try and get the same piece of cake.

In a real world example, take lua_dostring. You try call it while theres already a lua function being executed by the game, the lua VM isn't ready to handle this and subsequently shits itself.

The bonus of executing in EndScene is that a) It's an easy callback to execute logic in as its end of the scene (duh), meaning all game updates have already been processed and b) The added bonus of being able to execute code on their thread.

I just wanted to clarify the thread-safety discussion.

Whether or not a function or object is thread-safe depends on the function or object itself.

If the function is totally contained and doesn't use any static resources, then you can call it with as many concurrent threads as you want.

Example:

int ThreadSafeExample(int Blah)
{
return Blah + 5;
}

However, if the function DOES operate on global data, it is no longer thread safe.

Example:

int NonThreadSafeExample(int Blah)
{
retun Blah + SomeGlobal.SomeNumber;
}

Now, in the above example, a race condition exists where SomeNumber could change after we retrieve its value but before its returned to the caller. Whether this matters or not depends entirely on the circumstance (I'm giving fairly contrived examples for simplicities sake).

However, you can obviously see how in more complex situations it would quickly become an issue.

For example a list structure. If I'm enumerating a list while at the same time another thread is removing an entry from said list, I may dereference an invalid pointer whilst the change is taking place.

P.S. I love your fat kid analogy.

[suicidity]

@ #3 - I am, what do you need to know? PM me the question if you want.

[flo8464]

Thanks for those perfect answers, covered everything.

@suicidity: PM'ed you.