Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Whats stopping people from changing code in the client application  (Read 3344 times)
0 Members and 1 Guest are viewing this topic.
Offline 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...
Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #1 - Posted 2012-12-17 00:43:22 »

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

Myomyomyo.
Offline OttoMeier

Senior Devvie


Medals: 4
Projects: 1



« Reply #2 - Posted 2012-12-17 00:44:46 »

you cant. "never trust the client"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 139
Projects: 4
Exp: 3 years



« 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.
Offline JohnyCilohokla

Senior Newbie


Exp: 2 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.
Offline Best Username Ever

Junior Devvie





« Reply #5 - Posted 2012-12-17 01:56:26 »

Quote
Whats stopping people from changing code in the client application

Mainly lack of interest.
Offline 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.

Offline HeroesGraveDev

JGO Kernel


Medals: 310
Projects: 11
Exp: 3 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« 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.

Offline HeroesGraveDev

JGO Kernel


Medals: 310
Projects: 11
Exp: 3 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« 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.

Tongue

Offline ReBirth
« Reply #9 - Posted 2012-12-17 02:53:40 »

Check the modified time? or use dropbox trick?

nvm, miss understood Tongue

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline 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.
Offline 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.

jocks rule the highschools. GEEKS RULE THE WORLD MWAHAHAHA!!
captain failure test game
Offline HeroesGraveDev

JGO Kernel


Medals: 310
Projects: 11
Exp: 3 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« 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. Wink

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. Smiley

Offline 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/
Offline sproingie

JGO Kernel


Medals: 202



« 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.

Offline sproingie

JGO Kernel


Medals: 202



« 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.
Offline 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. Wink

Offline 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).

Offline Best Username Ever

Junior Devvie





« 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.
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« 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 Grin)

Smiley
Offline 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 Grin)
Unless they hack the server and change the program Grin

The world is big, so learn it in small bytes.
Offline sproingie

JGO Kernel


Medals: 202



« 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.
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 139
Projects: 4
Exp: 3 years



« 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 Grin)
I'm sorry but literally anything that's online is hackable persecutioncomplex. 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.
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #23 - Posted 2012-12-17 05:45:05 »

What if you host the server on your computer?

Smiley
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 139
Projects: 4
Exp: 3 years



« 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
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #25 - Posted 2012-12-17 05:48:41 »

Hash tables!

Smiley
Offline ReBirth
« Reply #26 - Posted 2012-12-17 05:54:36 »

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

Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« 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...

Smiley
Offline 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.
Offline 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.

jocks rule the highschools. GEEKS RULE THE WORLD MWAHAHAHA!!
captain failure test game
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (33 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (51 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (58 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!