Jump to content
  • Advertisement
Sign in to follow this  
3TATUK2

Cheat prevention?

This topic is 2129 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement

I got into this conversation with a friend, and he suggested modifying the compiler to use fewer registers, preserving "important stuff" in those newly unallocated registers.  It's a very heavy-handed way to go about it, will lead to serious repercussions in performance, and still isn't fool-proof, but it's damned hard to get around because it requires a lot of inside knowledge to know what gnarly asm to inject.

 

In the end, trying to fight cheaters without leveraging a server isn't a war you can win.

Share this post


Link to post
Share on other sites

I am one of those who would ship a game with built-in cheats, unless the game is competitive and multiplayer simultaneously.

So, I absolutely hate the fact that Sanctum 2 has a built-in cheat detection feature, but neglected the most basic feature of all times: pausing the game. In other words, make your cheat detection, but do not leave basic stuff aside so you can do it.

 

If you want your game to be cheat-proof, you'll have nightmares.

Usually, you'll want a Client application of your game to manage only two things: Rendering and Input. This would pass everything else to a server, that does all the heavy stuff.

 

If you want to create simple memory scan shields, you can store the values on 2 or 3 different places, maybe compound storing, where you have to multiply two values to get your HP, for example, and the second changes randomly every X frames, adjusting the other one to keep the result. Like in the little snippet here.

typedef struct compound_value {
	float *value;
	int *multiplier;
} cvalue;

bool create_compount_value (cvalue* cv, float p_value) {

	//Set Multiplier
	try{
		cv.multiplier = Allocate(INT_VAR);
	}
	catch (allocate_exc exc){
		return false; //Or throw the exception
	}
	
	cv.multiplier[0] = random_number(1, 5000);
	
	//Set value
	try{
		cv.value = Allocate(FLOAT_VAR);
	}
	catch (allocate_exc exc){
		return false; //Or throw the exception
	}
	
	cv.value[0] = p_value/( (float) cv.multiplier[0]);
	
	return true; //Success
}

void update_compound_value (cvalue* cv, float p_value) {
	cv.value[0] = p_value/( (float) cv.multiplier[0]);
}

void randomize_compound_value (cvalue* cv) {
	cv.value[0] = cv.value[0] * (float) cv.multiplier[0];
	cv.multiplier[0] = random_number(1, 5000);
	cv.value[0] = cv.value[0] / ( (float) cv.multiplier[0]);
}

float get_compound_value (cvalue* cv) {
	return ( cv.value[0] * (float) cv.multiplier[0] );
}

As an example.

The Cheat Engine gurus would still be able to hack a game with this code. They would even consider it a challenge, having even more fun while doing so!

 

All cheat detection will have a cost on development time of your games, not a little, usually. On top of that, will always have a performance cost, one that gets bigger with better detection methods. Cheat prevention on local games (by that, I mean not client-server games), well, I'd say one can't do it easily, unless you are really good.

 

Also, note that this is just an idea, please use it only if you have an implemented memory pool and other performance allies.

There's probably dozens of better ways to do it.

Edited by dejaime

Share this post


Link to post
Share on other sites
Wat?


Using "fewer registers" doesn't make any sense. First of all, that means more stuff will be spilled to stack memory, where it's actually easier to find and modify. Secondly, it's going to be transiently limited to the runtime of a single function at most, so those values still have to go back to stack or free-store memory at some point. Finally, on platforms like x86-32, there's already so few registers available that this is just... not smart to try.

And for all that, it wouldn't stop a determined reverser for more than about 5 seconds, and then they'd laugh at how silly your "protection" is and trivially crack it anyways.

 

 

Yep.  I'm no expert, and I don't mean to be.  I just thought the notion was amusing at best.  In the end, trying to protect a locally-controlled (to the user) game is foolhardy and not worth pursuing.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!