Termination
Senior Newbie 
|
 |
«
Posted
2012-12-17 00:38:21 » |
|
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
|
 |
«
Reply #1 - Posted
2012-12-17 00:43:22 » |
|
You can't. That's why there's stuff like aimbots and wallhacks.
|
Myomyomyo.
|
|
|
OttoMeier
|
 |
«
Reply #2 - Posted
2012-12-17 00:44:46 » |
|
you cant. "never trust the client"
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Jimmt
|
 |
«
Reply #3 - Posted
2012-12-17 00:53:09 » |
|
The best you can do is run as much as humanly possible on the server, and to obfuscate using JShrink or something.
|
|
|
|
JohnyCilohokla
Senior Newbie  Exp: 5 years
|
 |
«
Reply #4 - Posted
2012-12-17 01:11:41 » |
|
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
|
 |
«
Reply #5 - Posted
2012-12-17 01:56:26 » |
|
Whats stopping people from changing code in the client application Mainly lack of interest.
|
|
|
|
DrHalfway
|
 |
«
Reply #6 - Posted
2012-12-17 02:17:51 » |
|
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
|
 |
«
Reply #7 - Posted
2012-12-17 02:26:48 » |
|
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
|
 |
«
Reply #8 - Posted
2012-12-17 02:31:17 » |
|
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
|
 |
«
Reply #9 - Posted
2012-12-17 02:53:40 » |
|
Check the modified time? or use dropbox trick?nvm, miss understood 
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Termination
Senior Newbie 
|
 |
«
Reply #10 - Posted
2012-12-17 03:07:59 » |
|
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
|
 |
«
Reply #11 - Posted
2012-12-17 03:24:20 » |
|
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.
|
Mad Scientist
|
|
|
HeroesGraveDev
|
 |
«
Reply #12 - Posted
2012-12-17 03:27:25 » |
|
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
Junior Devvie   Medals: 3
Gamer turned Pixel Artist turned Programmer
|
 |
«
Reply #13 - Posted
2012-12-17 03:36:32 » |
|
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 :/
|
Busy between school, work, life, games, programming and general screwing around. If you'd like some pixel art for your game, send me a PM, i'll see what I can do. Current project: http://elementalwarblog.wordpress.com/
|
|
|
sproingie
|
 |
«
Reply #14 - Posted
2012-12-17 03:39:49 » |
|
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
|
 |
«
Reply #15 - Posted
2012-12-17 03:46:59 » |
|
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
|
 |
«
Reply #16 - Posted
2012-12-17 03:48:50 » |
|
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
|
 |
«
Reply #17 - Posted
2012-12-17 04:14:11 » |
|
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
|
 |
«
Reply #18 - Posted
2012-12-17 04:49:21 » |
|
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
|
 |
«
Reply #19 - Posted
2012-12-17 05:33:23 » |
|
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
|
 |
«
Reply #20 - Posted
2012-12-17 05:37:28 » |
|
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 
|
The world is big, so learn it in small bytes.
|
|
|
sproingie
|
 |
«
Reply #21 - Posted
2012-12-17 05:39:45 » |
|
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
|
 |
«
Reply #22 - Posted
2012-12-17 05:44:08 » |
|
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
|
 |
«
Reply #23 - Posted
2012-12-17 05:45:05 » |
|
What if you host the server on your computer?
|
|
|
|
Jimmt
|
 |
«
Reply #24 - Posted
2012-12-17 05:47:26 » |
|
Other people will still connect to the server, and people can still hack you computer...it's a scary world out here
|
|
|
|
masteryoom
|
 |
«
Reply #25 - Posted
2012-12-17 05:48:41 » |
|
Hash tables!
|
|
|
|
ReBirth
|
 |
«
Reply #26 - Posted
2012-12-17 05:54:36 » |
|
Don't put a value straightly! Follow every '=' and setter with encodeToSomething()! 
|
|
|
|
masteryoom
|
 |
«
Reply #27 - Posted
2012-12-17 05:56:54 » |
|
I suppose you could send the "key" to the computer and the hash, and have a different one every time...
|
|
|
|
Roquen
|
 |
«
Reply #28 - Posted
2012-12-17 06:30:32 » |
|
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
|
 |
«
Reply #29 - Posted
2012-12-17 13:01:36 » |
|
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.
|
Mad Scientist
|
|
|
|