• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
3TATUK2

Cheat prevention?

37 posts in this topic

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.

0

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
0

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.

0

Share this post


Link to post
Share on other sites

One thing i'm specifically interested in is... say the address of the variable *does* change - but changes predictably... for example, only between one of two addresses... Is something like CheatEngine able to exploit this? I've tested with a friend of mine and he couldn't quite figure it out... If he locked both addresses, for example, then the game would crash

0

Share this post


Link to post
Share on other sites

Interesting topic, how does this work with games developed in Mono/.NET? Are these as simple to cheat?

2

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.

 

 

If I saw that happening (and it would be a little hard to notice, though it wouldn't slow down a disassembler for one second) I'd rejoice because it would mean that it would be easier for me to write assembly hacks. Registers reserved for hacking! Yay!

0

Share this post


Link to post
Share on other sites

The thing that makes interpreted languages hard to hack is their complexity, not just the fact that they move things around.

 

Any compiled language can emulate that level of complexity, but if it were that simple tons of games would be doing it.

In fact, that level of complexity requires generating a whole new language and optimizing it enough to be of use during run-time.  The only reason Java and C# can get away with being “unhackable” (not to be taken literally) is because they had huge teams and millions in investments backing them.

 

This is obviously not plausible for any game team, and especially not for a single person.

 

If it was that simple, nothing would be hackable, as all game teams would jump onto the bandwagon.

 

Reiterating the point, if you try to emulate this with a compiled language by moving around variables, it will require more time and money than any hacker is worth, and it will cost you in performance as your game constantly looks up the value each time it is accessed.

 

 

L. Spiro

Edited by L. Spiro
2

Share this post


Link to post
Share on other sites

 

The thing that makes interpreted languages hard to hack is their complexity, not just the fact that they move things around.

Of course, that is balanced by a few of attributes that make VM languages very easy to hack:
- Obfuscated bytecode is way clearer to understand than obfuscated x86 assembly.
- Way less potential for weird memory, flow control and register tricks.
- Many de-compilers available that get you back to (mostly) readable source code.

 

It’s not so helpful for making a stand-alone cheat that you can distribute.
#1: Very few tools specialize in disassmbling interpreted languages. I wrote an x86 disassembler because there was a demand. I would not go out of my way to write one for Java, even though it is over 10 times easier to do so (I’ve at least looked into it). What is my target audience?
#2: Somewhat a strong point. Just that it won’t prove to help nor hurt conventional hacking methods, which simply aim to seek the locations of values or code. All forms of local game hacking boil down to either “locking” values (as we say) or changing code (through injection or otherwise). Flow control almost never enters into the picture and registers even less often. Hacking a register requires attaching a debugger and placing breakpoints. And weird memory would be considered helpful, though limited in its ability to thwart hackers.
#3: Even if you have the source code, it’s only helpful if you have the addresses, at least in most cases. It’s true that source can help you crack algorithms and decryption schemes, but game companies have wisely given up on these tactics. But basically all hackers are trained to do their “jobs” without source code, since they have never had it anywhere else, so having it or not will ultimately make no difference.


L. Spiro

Edited by L. Spiro
2

Share this post


Link to post
Share on other sites

That’s not just theory.  Yes, it could be done.

 

It’s just a matter of eliminating all but the most dedicated.  That person will write an entire VM just because no other practical alternatives exist.

By the time he’s finished making the whole thing stable and made the garbage-collection system stable and efficient, and optimized it enough to actually play the game at a reasonable speed, the game is already outdated and no one cares about his hacks anymore.

 

But of course it may be useful for the next game.

 

 

Until now no one has ever gone that far out of his or her way and given the evidence it will likely never happen.  The game that motivates you will definitely be dead by the time you finish, so only those who believe 2 games in a row will motivate them would even begin such a project.  The ultimate weakness in interpreted languages is somehow not its downfall, thanks to the extreme amounts of effort required to exploit it.

 

 

L. Spiro

Edited by L. Spiro
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0