Patterns for LocalPlayer

Trying to pattern scan the new local player but cant get any to work. Here are the values I am getting:

This is what I am doing

Code:

	uintptr_t LocalPlayer0 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\xA3\x00\x00\x00\x00\xC7\x05\x00\x00\x00\x00\x00\x00\x00\x00\xE8\x00\x00\x00\x00\x59\xC3\x6A\x00", "x????xx????????x????xxxx");
	uintptr_t LocalPlayer1 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\x8B\x80\x00\x00\x00\x00\x40\xC3", "xx????xx");
	uintptr_t LocalPlayer2 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\xFC\xE8\x00\x00\x00\x00\x8B\x3D", "xx????xx") + 0x8;

	uintptr_t Client = (uintptr_t)GetModuleHandle(L"client.dll");

	AllocConsole();
	freopen("CONOUT$", "w", stdout);

	std::cout << std::hex << "LocalPlayer0: " << LocalPlayer0 - Client << "\n";
	std::cout << std::hex << "LocalPlayer1: " << LocalPlayer1 - Client << "\n";
	std::cout << std::hex << "LocalPlayer2: " << LocalPlayer2 - Client << "\n";

None of these appear to be correct

should be the correct one
ZacZero made post about this check it out it may help you
http://www.mpgh.net/forum/showthread.php?t=1197536

Code:

"\xA3\x00\x00\x00\x00\xC7\x05\x00\x00\x00\x00\x00\x00\x00\x00\xE8\x00\x00\x00\x00\x59\xC3\x6A\x00" ), "x????xx????????x????xxxx"

Originally Posted by fwsefwsgrgwhergr

should be the correct one
ZacZero made post about this check it out it may help you
http://www.mpgh.net/forum/showthread.php?t=1197536

Code:

"\xA3\x00\x00\x00\x00\xC7\x05\x00\x00\x00\x00\x00\x00\x00\x00\xE8\x00\x00\x00\x00\x59\xC3\x6A\x00" ), "x????xx????????x????xxxx"

You didn't mention about offsets in [C0DE] they are important

I posted this ages ago and it still works:

Code:

LocalPlayer ( - client.dll if you want to get the offset ): 0x4F47190
1. FC E8 ? ? ? ? 8B 3D ) + 8 ]
2. FC E8 ?? ?? ?? ?? 8B 3D ) + 8 ]
3. 0xFC, 0xE8, 0x00, 0x00, 0x00, 0x00, 0x8B, 0x3D ) + 8 ]
4. \xFC\xE8\x00\x00\x00\x00\x8B\x3D ) + 8 ] : xx????xx

Code:

	uintptr_t LocalPlayer0 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\xA3\x00\x00\x00\x00\xC7\x05\x00\x00\x00\x00\x00\x00\x00\x00\xE8\x00\x00\x00\x00\x59\xC3\x6A\x00", "x????xx????????x????xxxx");
	uintptr_t LocalPlayer1 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\x8B\x80\x00\x00\x00\x00\x40\xC3", "xx????xx");
	uintptr_t LocalPlayer2 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\xFC\xE8\x00\x00\x00\x00\x8B\x3D", "xx????xx") + 0x8;

	uintptr_t Client = (uintptr_t)GetModuleHandle(L"client.dll");

	AllocConsole();
	freopen("CONOUT$", "w", stdout);

	std::cout << std::hex << "LocalPlayer0: " << LocalPlayer0 - Client << "\n";
	std::cout << std::hex << "LocalPlayer1: " << LocalPlayer1 - Client << "\n";
	std::cout << std::hex << "LocalPlayer2: " << LocalPlayer2 - Client << "\n";

I don't think there is a good reason to use uintptr_t when you want to store a pointer. However, you should use freopen_s(), freopen() is deprecated:

Code:

FILE *fileout; // file pointer
freopen_s(&fileout, "CONOUT$", "w", stdout);

Originally Posted by javalover

Code:

	uintptr_t LocalPlayer0 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\xA3\x00\x00\x00\x00\xC7\x05\x00\x00\x00\x00\x00\x00\x00\x00\xE8\x00\x00\x00\x00\x59\xC3\x6A\x00", "x????xx????????x????xxxx");
	uintptr_t LocalPlayer1 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\x8B\x80\x00\x00\x00\x00\x40\xC3", "xx????xx");
	uintptr_t LocalPlayer2 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\xFC\xE8\x00\x00\x00\x00\x8B\x3D", "xx????xx") + 0x8;

	uintptr_t Client = (uintptr_t)GetModuleHandle(L"client.dll");

	AllocConsole();
	freopen("CONOUT$", "w", stdout);

	std::cout << std::hex << "LocalPlayer0: " << LocalPlayer0 - Client << "\n";
	std::cout << std::hex << "LocalPlayer1: " << LocalPlayer1 - Client << "\n";
	std::cout << std::hex << "LocalPlayer2: " << LocalPlayer2 - Client << "\n";

I don't think there is a good reason to use uintptr_t when you want to store a pointer. However, you should use freopen_s(), freopen() is deprecated:

Code:

FILE *fileout; // file pointer
freopen_s(&fileout, "CONOUT$", "w", stdout);

uintptr_t is the type to choose when your cant use a pointer to a class (for instance if you have none).

You also missed dereferences. You are storing pointers to pointers to the local player. You would want to dereference once and get a reference to the pointer pointing to the local player.

You are currently subtracting client dll from the address of the pattern. The pointer is inside of the instructions and you would want to extract it out of it.

Originally Posted by SilentWarp

No reason not too use uintptr_t in the case of csgo anyway.

Originally Posted by WasserEsser

uintptr_t is the type to choose when your cant use a pointer to a class (for instance if you have none).

Firstoff, you are using C-style casts, which should be avoided for some reasons. Secondly, you may need to use intptr_t instead of uintptr_t when you are working with negative values. I don't know which one you need, evidently because I'm not a guy with the gift of the prediction. However, intptr_t and uintptr_t are not guaranteed to exist (they were firstly introduced in C99), and from your example I can see you are just storing a pointer to something, so you can just cast it to void* also because you don't need big integer types like intptr_t/uintptr_t to hold a pointer value. Ofcourse, when you can you should avoid casts.

@WasserEsser you quoted me instead of him. I'm not the author.

Originally Posted by javalover

@WasserEsser you quoted me instead of him. I'm not the author.

Because I was specifically referring to your post about uintptr_t.
When will your pointers be negative, though?

Originally Posted by WasserEsser

When will your pointers be negative, though?

It has nothing to do with negative pointers. If you care of your numeric value of your pointer (eg. you need to do arithmetics with it and other), then you need to use the correct unsigned or signed type to get for example the correct shift.

Originally Posted by javalover

Code:

	uintptr_t LocalPlayer0 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\xA3\x00\x00\x00\x00\xC7\x05\x00\x00\x00\x00\x00\x00\x00\x00\xE8\x00\x00\x00\x00\x59\xC3\x6A\x00", "x????xx????????x????xxxx");
	uintptr_t LocalPlayer1 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\x8B\x80\x00\x00\x00\x00\x40\xC3", "xx????xx");
	uintptr_t LocalPlayer2 = (uintptr_t)FindPattern("client.dll", (BYTE*)"\xFC\xE8\x00\x00\x00\x00\x8B\x3D", "xx????xx") + 0x8;

	uintptr_t Client = (uintptr_t)GetModuleHandle(L"client.dll");

	AllocConsole();
	freopen("CONOUT$", "w", stdout);

	std::cout << std::hex << "LocalPlayer0: " << LocalPlayer0 - Client << "\n";
	std::cout << std::hex << "LocalPlayer1: " << LocalPlayer1 - Client << "\n";
	std::cout << std::hex << "LocalPlayer2: " << LocalPlayer2 - Client << "\n";

I don't think there is a good reason to use uintptr_t when you want to store a pointer. However, you should use freopen_s(), freopen() is deprecated:

Code:

FILE *fileout; // file pointer
freopen_s(&fileout, "CONOUT$", "w", stdout);

No reason not too use uintptr_t in the case of csgo anyway. Also the function is only deprecated for security reasons and those are not an issue for me

Originally Posted by javalover

It has nothing to do with negative pointers.

Originally Posted by javalover

Secondly, you may need to use intptr_t instead of uintptr_t when you are working with negative values.

Originally Posted by javalover

If you care of your numeric value of your pointer (eg. you need to do arithmetics with it and other), then you need to use the correct unsigned or signed type to get for example the correct shift.

Sorry, when will you ever bitshift a pointer to a memory location in a game?
You'll at most add or subtract.

Originally Posted by WasserEsser

Sorry, when will you ever bitshift a pointer to a memory location in a game?
You'll at most add or subtract.

I didn't never talk about negative pointers, I did talk about negative values. The difference is that the pointers cannot be negative, because they are not integers.

Originally Posted by WasserEsser

When will your pointers be negative, though?

Quote the part of the answer where I did talk about negative pointers.

Originally Posted by WasserEsser

Sorry, when will you ever bitshift a pointer to a memory location in a game?
You'll at most add or subtract.

Why do you take for granted he never has to bitshift into a memory location? Game or not, it's still an executable - and if he needs to when he has his good reasons, he can. However, it's an generic example. I will do a more in-context example: uintptr_t and intptr_t are 8-bytes, my value I want to get is 8-bytes too. Assume I know it will be negative (eg. similar to -60), I'd use a pointer to a signed value (intptr_t) to get the correct interpretation of that value, otherwise with uintptr_t I'd get a meaningless value.

Originally Posted by javalover

I didn't never talk about negative pointers, I did talk about negative values. The difference is that the pointers cannot be negative, because they are not integers.

Quote the part of the answer where I did talk about negative pointers.

Why do you take for granted he never has to bitshift into a memory location? Game or not, it's still an executable - and if he needs to when he has his good reasons, he can. However, it's an generic example. I will do a more in-context example: uintptr_t and intptr_t are 8-bytes, my value I want to get is 8-bytes too. Assume I know it will be negative (eg. similar to -60), I'd use a pointer to a signed value (intptr_t) to get the correct interpretation of that value, otherwise with uintptr_t I'd get a meaningless value.

You're completely ripping this out of the usecase of this thread.
This thread is all about storing the result of a pattern scan, which will result in a pointer to some memory location, be it an entity, a function, an address of a certain instruction or another offset.
These values will not be negative nor will you ever bitshift them.

Also, they will be 4 bytes since we're working with 32 bit process here.

Originally Posted by WasserEsser

You're completely ripping this out of the usecase of this thread.

Probably it wasn't if you didn't ask me about negative values. I didn't see any problem to reply you.

Originally Posted by WasserEsser

These values will not be negative nor will you ever bitshift them.

These values can be negative depending on how you interpret it (signed/unsigned). If you always interpret them as uintptr_t, ofcourse you won't see it is negative, rather you'd see a meaningless value (like 92380493092 instead of a signed -60) - the bitshifting was an example on why sometimes you need to distinguish them. This long discussion about intptr_t/uintptr_t started when you asked me about negative values:

Secondly, you may need to use intptr_t instead of uintptr_t when you are working with negative values

and if he needs that value, he will need to apply an intptr_t or uintptr_t, depending on his context. I'm not going to repeat things. If you want to read my whole answer, good for you, else don't expect another answer from me.

Originally Posted by WasserEsser

Also, they will be 4 bytes since we're working with 32 bit process here.

CS:GO is a 32 bit process, and it will be 4 bytes because you are a Windows user. In Linux we are talking about a 64-bit process, so in my case it's 8-bytes - sorry if I don't use Windows, dear WasserEsser. Maybe you'd prefer the example as this:

uintptr_t and intptr_t are 4-bytes (in Windows), my value I want to get is 4-bytes too. Assume I know it will be negative (eg. similar to -60), I'd use a pointer to a signed value (intptr_t) to get the correct interpretation of that value, otherwise with uintptr_t I'd get a meaningless value.

- - - Updated - - -

uintptr_t and intptr_t are 4-bytes (in Windows), in your case obviously because CS:GO is a 32-bit process, but not here.

Originally Posted by javalover

~

Let me just break this down in chronological order here:

Originally Posted by javalover

I don't think there is a good reason to use uintptr_t when you want to store a pointer.

Originally Posted by WasserEsser

uintptr_t is the type to choose when your cant use a pointer to a class (for instance if you have none).

Originally Posted by javalover

Secondly, you may need to use intptr_t instead of uintptr_t when you are working with negative values.

Originally Posted by WasserEsser

When will your pointers be negative, though?

Originally Posted by javalover

It has nothing to do with negative pointers. If you care of your numeric value of your pointer (eg. you need to do arithmetics with it and other), then you need to use the correct unsigned or signed type to get for example the correct shift.

Originally Posted by WasserEsser

Sorry, when will you ever bitshift a pointer to a memory location in a game?
You'll at most add or subtract.

Originally Posted by javalover

I didn't never talk about negative pointers, I did talk about negative values.

Originally Posted by WasserEsser

This thread is all about storing the result of a pattern scan, which will result in a pointer to some memory location, be it an entity, a function, an address of a certain instruction or another offset.
These values will not be negative nor will you ever bitshift them.

Originally Posted by javalover

These values can be negative depending on how you interpret it (signed/unsigned). If you always interpret them as uintptr_t, ofcourse you won't see it is negative, rather you'd see a meaningless value (like 92380493092 instead of a signed -60) - the bitshifting was an example on why sometimes you need to distinguish them. This long discussion about intptr_t/uintptr_t started when you asked me about negative values:

Secondly, you may need to use intptr_t instead of uintptr_t when you are working with negative values

Originally Posted by javalover

and if he needs that value, he will need to apply an intptr_t or uintptr_t, depending on his context. I'm not going to repeat things. If you want to read my whole answer, good for you, else don't expect another answer from me.

Okay, let me start with these two of your posts:

Originally Posted by javalover

I don't think there is a good reason to use uintptr_t when you want to store a pointer.

Originally Posted by javalover

The difference is that the pointers cannot be negative

You said you don't think there is a good reason to use uintptr_t to store the result of a pattern scan, a function which will return you a pointer to a memory location which can't be negative since it's a pointer. That doesn't even make sense. The discussion began when you said you don't think it's good to use uintptr_t. Using uintptr_t in this case is EXACTLY the way to go. Using an intptr_t doesn't make any sense, since, you said it yourself, a pointer can't be negative. Sure, you can use intptr_t to store pointers, but it doesn't make sense to use it over uintptr_t since a pointer can't be negative. On top of that, it can happen that your pointers point to a location over 2GB in RAM, which then breaks your application because your intptr_t is only capable of handling 2 GB instead of 4 GB like uintptr_t is capable of handling ( very specifically talking about 32 bit here ).

The whole topic here, and my answers were all referring to this, is about storing a pointer returned by a findpattern function. What I was talking about the entire time is that intptr_t is not to be preffered over uintptr_t.

Originally Posted by WasserEsser

uintptr_t is the type to choose when your cant use a pointer to a class (for instance if you have none).

Originally Posted by javalover

Secondly, you may need to use intptr_t instead of uintptr_t when you are working with negative values.

Originally Posted by WasserEsser

When will your pointers be negative, though?

Originally Posted by javalover

It has nothing to do with negative pointers. If you care of your numeric value of your pointer (eg. you need to do arithmetics with it and other), then you need to use the correct unsigned or signed type to get for example the correct shift.

As seen above, i was always referring to the topic of storing a pointer. Negative values are not the topic here.
Your arguments are that if you use intptr_t, you can use, for example, bitshifting.

When working with pointers, you won't use bitshifting, and if you'll ever ever use it, you can just cast your pointer to an integral type.
It can much rather happen that your pointer exceeds the 2 GB boundary than the case that you'll ever want to be able to bitshift your pointers.

Originally Posted by WasserEsser

This thread is all about storing the result of a pattern scan, which will result in a pointer to some memory location, be it an entity, a function, an address of a certain instruction or another offset.
These values will not be negative nor will you ever bitshift them.

Originally Posted by javalover

These values can be negative depending on how you interpret it (signed/unsigned). If you always interpret them as uintptr_t, ofcourse you won't see it is negative, rather you'd see a meaningless value (like 92380493092 instead of a signed -60) - the bitshifting was an example on why sometimes you need to distinguish them. This long discussion about intptr_t/uintptr_t started when you asked me about negative values:

Secondly, you may need to use intptr_t instead of uintptr_t when you are working with negative values

and if he needs that value, he will need to apply an intptr_t or uintptr_t, depending on his context. I'm not going to repeat things. If you want to read my whole answer, good for you, else don't expect another answer from me.

Again, you will NOT work with negative values at all since we're working with pointers here. I don't get why you're throwing arguments about negative values in this topic when all we're talking about here are pointers.

Patterns for LocalPlayer

Post a Reply

Similar Threads

Tags for this Thread