Whats stopping people from changing code in the client application

[Termination]

My question is:

Whats stopping people from changing code in the client application as if people wanted to, they could easily just unpack all the class files and repackage them.

If I was to write a server/client system, how would i go about checking that the client hasn't been changed...

[theagentd]

You can't. That's why there's stuff like aimbots and wallhacks.

[OttoMeier]

you cant. "never trust the client"

Games published by our own members! Check 'em out!

[Jimmt]

The best you can do is run as much as humanly possible on the server, and to obfuscate using JShrink or something.

[JohnyCilohokla]

The best you can do is run as much as humanly possible on the server, and to obfuscate using JShrink or something.

It will only stop beginners from changing the code.
But the same thing goes for c++ or any other language (you can always change stuff in assembler), and there is no way to stop it.
And if you will be able to prevent that somehow, there are still things like packet sniffer and proxy to manipulate the data send and received.
The only reason to use JShrink(or the other ones) is to make the file smaller and optimize the code a small bit.
The best thing to do is to concentrate on server side security.

[Best Username Ever]

Whats stopping people from changing code in the client application

Mainly lack of interest.

[DrHalfway]

A good server cannot assume that the data sent by the client is correct, checks on data is always needed in some way or form.

Think of a client/server hosting a game with 12 people. Everyone is playing legit except for one player, who modifies the data packet for character "speed" or "location" before data is sent to server. If the server does not do a range validity check on this variable, it will simply distribute it to every client, the result is a speed hack, being able to either move extremely fast or "warping" mechanics. However if the server performs a validity range check on variable, which can be up to a certain logical tolerance, client hacks like these would be fairly meaningless.

Solving problems like these involves a lot of effort. The example above is very simple to implement, however, how would you be able to detect aim bots? how do you know its an aim bot and not a truly talented player? does an algorithm exist to catch these things? maybe some kind of complex pattern recognition algorithm running for every client server side?

As you can see, the problem itself increases. Implementing such methods for catching cheaters also takes performance away from the server, so the server will need to be fast enough to be able to run these tests in a timely manner.

[HeroesGraveDev]

Aimbots are undetectable as far as I can see.
Speed hacks etc are easily preventable by only sending player input to the server. That way the server still handles the movement.

EDIT: I am assuming you are still trying to make an MMORPG with hardly any experience? I hope you read the articles I posted in that other thread.
You really should use Google more.

[HeroesGraveDev]

You can't. That's why there's stuff like aimbots and wallhacks.

You can. That's why there could be (but isn't) stuff like viruses that lock down your computer whenever you try and edit/decompile the client.

[ReBirth]

Check the modified time? or use dropbox trick?

nvm, miss understood

Games published by our own members! Check 'em out!

[Termination]

Aimbots are undetectable as far as I can see.
Speed hacks etc are easily preventable by only sending player input to the server. That way the server still handles the movement.

EDIT: I am assuming you are still trying to make an MMORPG with hardly any experience? I hope you read the articles I posted in that other thread.
You really should use Google more.

It was a question, atm Im currently working with openGL and LWJGL.

As such if I have a question, id rather know the answer as soon as possible than just leave it back.

Sorry for asking a question seems like Im being continuously pushed away by this community.

[deepthought]

Just a random idea i have (Please don't beat me with the soggy end of my own arm), but it might be possible by using asm to transform classes at run time ex. Server class: randomly multiply variables after receiving data. Client class: divide by the same amount before sending the data. The server sends instructions on what transformations to apply.'if the client is altered, the transformations would probably break it.

[HeroesGraveDev]

Aimbots are undetectable as far as I can see.
Speed hacks etc are easily preventable by only sending player input to the server. That way the server still handles the movement.

EDIT: I am assuming you are still trying to make an MMORPG with hardly any experience? I hope you read the articles I posted in that other thread.
You really should use Google more.

It was a question, atm Im currently working with openGL and LWJGL.

As such if I have a question, id rather know the answer as soon as possible than just leave it back.

Sorry for asking a question seems like Im being continuously pushed away by this community.

I know what you mean about wanting to know the answer to a question even if it isn't relative.

I don't mind about what your asking about, and I don't mind you trying to learn. It's what you do besides that. I am annoyed that you keep on acting like we're pushing you away when we are actually trying to put you on the right track. Whenever you start acting like this 'sorry for asking question' stuff with that tone, people will start to get annoyed.

I'm sorry that you have taken this the wrong way. Please understand that we are trying to help, even if you don't immediately see how.

If I interpret your other statement correctly, it's good to see you are stepping back and doing things in order.
Try doing things in this order:

G - Game. First step
RPG - Role playing game. Second step
MRPG - Multiplayer RPG. Third step
ORPG - Online RPG. Third alternative step
MORPG - Multiplayer Online RPG. Fourth step
MMORPG - Probably best not to do this one. Requires too much money.

I really hope you read those articles.

[cheatsguy]

Just a random idea i have (Please don't beat me with the soggy end of my own arm), but it might be possible by using asm to transform classes at run time ex. Server class: randomly multiply variables after receiving data. Client class: divide by the same amount before sending the data. The server sends instructions on what transformations to apply.'if the client is altered, the transformations would probably break it.

I'm not sure, but this just might work! Give it a number, and tell it to divide by jump height, multiply by run speed, etc... And if it comes up with the same result as the server, it will connect, if not it won't! The only problem might be locating every single variable that needs checking, or having the hacker simply setting up the code to return the right value instead :/

[sproingie]

Bots tend to be detectable if you can exploit behavior in the bot that a human wouldn't.  Perfectly aiming at and hitting a 100% transparent model for example is kinda suspicious.  Since there's overhead in putting in such "bot-traps" that gets worse (and less accurate) as bots get smarter, modern stuff like Punkbuster and VAC just scans memory looking for signs of tampering.

Ultimately you cannot prevent cheating unless you lock down the entire platform (such as with a console) or make the entire client nothing but a dumb display and even then it's possible, it's just too much work for the average cheater.

[sproingie]

Just a random idea i have (Please don't beat me with the soggy end of my own arm), but it might be possible by using asm to transform classes at run time ex. Server class: randomly multiply variables after receiving data. Client class: divide by the same amount before sending the data. The server sends instructions on what transformations to apply.'if the client is altered, the transformations would probably break it.

The gist of this is "encrypt the data stream", and it's certainly one step in making cheating inconvenient, but ultimately the client has to decrypt it.  A skillful cheater will just take it as a challenge, and given how easy the JVM is to hook, not a particularly difficult one.

[Agro]

Valve is crazy with their AntiCheat systems. They even post their methods online so you can go check it out. For example, if you want to send movements of a player to the server, you would originally want to send the positions. But there are 2 downfalls to this: server lag and player hacking.

So what you would do is send the keypresses instead, and send those to the other client, and interpolate between the 2 to create "smooth" movement. At least that's how Valve does it. And if someone "headshots" somebody, you would send things like your current position, the player's position you killed, gun, etc.

And one precaution to everything is like if you have a protocol and your position packet consists of user ID, player X, player Y, and you receive more/less of the data, you can assume the player is hacking. This is only when you use TCP and stuff. Server logic is a huge topic.

[DrHalfway]

You will find that some of the best methods for everything is known by everyone. This also goes true for encryption algorithms. In my opinion, if some method is kept a secret, then it obviously has a huge flaw that can be exploited by knowing the said method. Valve is very good with their anti-cheat systems, wouldn't mind working for them at some point (if I can get lucky enough for an interview, and then there's the question of passing the interview).

[Best Username Ever]

Client side "cheat protection" is unnecessary. It creates an arms race scenario. In a business, you might decide whether or not it's more revenue-minus-costs-able (profitable) to fight an arms race than it is to maintain a community. Some forms of cheating a very visible. You could install a trojan on your player's computer, but it wouldn't be absolute. (You shouldn't do this yourself if you've ever complained about Windows being insecure or of Apple trying to control you). Or you could take advantage of naturally developed social reputations and player web of trusts to make cheating be considered outside the norm and shameful. It means you have to enable more player to player interaction and cannot use certain (boring) multiplayer elements like highscore tables.

With one option, you have people striving for having a reputation of being a skilled player and fun opponent. (Which is fine because you don't need a global ranking system.) In the other, you have people that try to cut in line to get unearned status symbols.

If your game is designed so that the player is meant get a rush out of having invested more time getting points, experience points, wins, or other tokens, then there will be much more incentive to cheat. That and the fact that major games tend to focus on selling new games or content is probably why companies opt for an arms race. You're going to buy something else from them soon anyway.



Just use good network coding practices, make your server (and clients, too) secure - without confusing cheating for a security vulnerability, maintain game synchronization, and let multiple clients resolve conflicts using consensus. The first two should not be ignored simply because you're working on a game and not something else. (I feel I need to make that explicit.) Synchronization and verification prevent blatant cheating. The conflict resolution is to make cheating harder to achieve without cooperation from other players... (In which case it would be modification, not cheating. It should be obvious why this might be frowned upon in big commercial games...) while also leaving room for benefit-of-the-doubt (in player behavior and legitimate latency issues). The final point is analogous to self-refereeing in amateur sports games.

[masteryoom]

You could handle everything on the server, so you send key presses and it sends player positions, other player positions, players killed etc. This means that you can't hack it, because it's all done on the server side (please correct me if I am wrong )

[Joshua Waring]

You could handle everything on the server, so you send key presses and it sends player positions, other player positions, players killed etc. This means that you can't hack it, because it's all done on the server side (please correct me if I am wrong )

Unless they hack the server and change the program

[sproingie]

Making the client "dumb" removes cheats that falsify data, but it doesn't prevent things like aimbots and other macro automators.  This is usually good enough for most games, but otherwise you're basically talking about a turing test without the benefit of being able to ask any questions.

[Jimmt]

You could handle everything on the server, so you send key presses and it sends player positions, other player positions, players killed etc. This means that you can't hack it, because it's all done on the server side (please correct me if I am wrong )

I'm sorry but literally anything that's online is hackable . No I am not part of Anonymous. All you need to do is 1. feed the server bad data (same thing used in SQL injection) or 2. hack into the server itself. Obviously you can't do 100% of everything on the server unless you are playing the game on the server itself, which is obviously not feasible for distributed games.

[masteryoom]

What if you host the server on your computer?

[Jimmt]

Other people will still connect to the server, and people can still hack you computer...it's a scary world out here

[masteryoom]

Hash tables!

[ReBirth]

Don't put a value straightly! Follow every '=' and setter with encodeToSomething()!

[masteryoom]

I suppose you could send the "key" to the computer and the hash, and have a different one every time...

[Roquen]

Q: What does this thread have in common with the random changing of bits thread?
A: Everything.

Solution: Don't worry about unsolvable problems.

[deepthought]

i guess we don't really need to worry for most scenarios. if you have a competition, just make everyone record a demo.

Just a random idea i have (Please don't beat me with the soggy end of my own arm), but it might be possible by using asm to transform classes at run time ex. Server class: randomly multiply variables after receiving data. Client class: divide by the same amount before sending the data. The server sends instructions on what transformations to apply.'if the client is altered, the transformations would probably break it.

The gist of this is "encrypt the data stream", and it's certainly one step in making cheating inconvenient, but ultimately the client has to decrypt it.  A skillful cheater will just take it as a challenge, and given how easy the JVM is to hook, not a particularly difficult one.

it's more along the lines of "insert certain instructions in a certain place. if the client code is changed, the new instructions could reference missing variables, so the client screws itself". Of course, this doesn't do anything to prevent wall hacks.