Questions About Protecting Against Hacks
#1
Posted 09 January 2008 - 04:47 AM
So these are pretty much questions for hackers:
What do you have control over? (I mean what can you change when you hack a GM made game)
If I make it so the only thing the client has control of is input (I mean it sends if keys are pressed, spots are clicked, etc), what can you all do?
Do dll's like Gameshield/Hackshield/Others protect alot?
I was thinking if my original plan worked, I could go without any protection, save space, and let hackers still keep their programs...
*fingers crossed*
#2
Posted 09 January 2008 - 08:22 AM
Those are the hardest things to block.
My server checks for each message that it gets if the action is possible.
However, coorinates hacks and room hacks arent that easy to block.
Well, okay, room changign can be blocked by letting the server check the room now and then...but packet sniffing and re-sending would be a hard one...unless its a message that you can normally just send each minute...this way you could run a timer on the server and check if the palyer is even allowed to send the message.
In the beginning of your game you should be aware of teh fact that you'll get some wannabe-hackers ^^,
Somehow it became a hobby of some people to scare newcomer online games with hacks ^^,
May I ask what your game is about?
Whats the genre? =)
#3
Posted 09 January 2008 - 12:52 PM
Instead, make sure that all sensitive data is kept, controlled and checked by the server. Essentially, hackers may control what information goes back to the server. It's up to the server to check whether that data is valid and, within the context, possible.
#4
Posted 09 January 2008 - 02:18 PM
Well, Im only gonna have them send wether, lets say, left or right keys are pressed. Not their x and y. It would then be calulated by the server, and they would most around in the server's room. The rest is sent to them for a visual.
@BlaXun: its gonna be a sort of rpg-ish platformer mix
I'm not sure how it can be hacked then, so I'm just asking.
#5
Posted 09 January 2008 - 02:31 PM
But my favourite way:-
Most people will try to use a hex editor to edit your values ingame.
Sol- You should have multiple variables with similar name and same values, and always check them against the others to make sure they havent been tampered with. Like say for x you can have x, xx, new_x, go_x, goto_xx, ...
when you have a new x, modify them in a block in the game, but those using a hex editor, will search and land on any one of those at a time, so if they change one, you can easily detect that one of the variables has changed but others are different, so you can say its a hack attempt......but this is a long process and requires careful programming......
#6
Posted 09 January 2008 - 02:55 PM
It is also a temporary solution. There is no method to hide information from a hacker. He has your game on his computer. You have given him the box with goodies, so he will try and break it open.
Trying to hide or obfuscate stuff may make things more difficult for him, but it doesn't mean he will not succeed. Don't let your other players suffer from time-consuming and speed-degrading security checks, only because your server-client design was flawed.
Concentrate on the server. It is the secured application the hacker has (or at least should have) no access to.
Best Games Forever, from what you describe I wouldn't worry that much. Keystrokes tell the server what happens, so all the client application does is show the results of his actions. At best, a hacker can only mimic user input, but a game is usually too interactive to automate that in a profitable manner.
#7
Posted 09 January 2008 - 06:31 PM
bluemagica, it is a very bad idea to add a lot of surpluss weight to the application through bogus variables and checking rows of them against hacks. Your game grows bigger and slower.
It is also a temporary solution. There is no method to hide information from a hacker. He has your game on his computer. You have given him the box with goodies, so he will try and break it open.
Trying to hide or obfuscate stuff may make things more difficult for him, but it doesn't mean he will not succeed. Don't let your other players suffer from time-consuming and speed-degrading security checks, only because your server-client design was flawed.
Concentrate on the server. It is the secured application the hacker has (or at least should have) no access to.
Best Games Forever, from what you describe I wouldn't worry that much. Keystrokes tell the server what happens, so all the client application does is show the results of his actions. At best, a hacker can only mimic user input, but a game is usually too interactive to automate that in a profitable manner.
I totally agree.
Fake variables arent a nice idea.
Most hackers check for numbers with specific number...if they found the x value they can find all variables with that value.
And, if the server really checks on everyting then there shouldnt be anything to worry about besides macros
#8
Posted 09 January 2008 - 10:20 PM
Best Games Forever, from what you describe I wouldn't worry that much. Keystrokes tell the server what happens, so all the client application does is show the results of his actions. At best, a hacker can only mimic user input, but a game is usually too interactive to automate that in a profitable manner.
And, if the server really checks on everyting then there shouldnt be anything to worry about besides macros
So in otherwords... It would be, at least on the client side, unhackable?
That would be awesome!
And I'm not worried about macros at all. I think moving platforms would make that a little hard.
But if they get past that... theres nothing they can really do...
#9
Posted 09 January 2008 - 10:56 PM
Moving platforms combined with your anti-hack system though may make the game completely unplayable. If you're only sending the player controls to the server, who then calculates it and sends the data back, then you're going to be introducing a huge delay in interaction. It's one thing to see other players jump around madly in lag, it's quite another to try to control your own through lag. Even though giving the client any sort of local data is a security hole, there are some things that are a necessary evil, like making your player react to input in a timely, instant, manner.[...]
And I'm not worried about macros at all. I think moving platforms would make that a little hard.
[...]
#10
Posted 09 January 2008 - 10:58 PM
Lets say there is a inventory.
When they started all slots were empty (0)
The structure could be like this:
items[1] = 0
items[2] = 0
items[3] = 0
items[4] = 0
When the player logged in you sent him all those infos.
Lets say he hacks a variable now and changes items[1] to 9
Now on his client he might have a item in his inventory, but when he tries to SELL or USE it you just send the item SLOT that he wants to sell/use.
Your server will now be informed that the client wants to sell/use something.
Now we check:
if items[slot] = 0
{
we got a hacker!
}
what we did was check if the player even had something on there.
And if he didnt we got him hacking!
Now lets say he had item[1] = 3 without any hacking.
Item 3 was a bone...the item is not useable...
now the client hacks the item to...lets say...a bubble-gum.
The bubblegum is useable.
the client now uses his hacked gum on slot items[1]
We inform teh server that he wants to use it, now the server should check if the item can even be used, remember, teh server still has item[1] =3!
item with id 3 cant even be used, so we found a hacker.
Okay, another scenario:
item[1] is 5 without hacking, id 5 is the gum, its useable.
Now the Client hacks the item[1] to 6, 6 would be an item that adds 100 points to your score.
Now when the players uses it he would inform teh server about the item slot again.
Now teh server checks and sees that there is a gum on that position, server uses it and now item[1] is 0 again.
The server realized that there is just a game, the client may think he used the item that gave points, but since te server knew better the client wouldnt get any points. =)
SAme with point changing...if teh client just changes the variable the server wont be interested.
Now lets say the client got 1000 points through a hack, but the server knows the client got just 10 points in reallity.
Now the client wantds to buy an item for 1000 points.
He walks into teh shop and buys it cause he got those 1000 points.
We now send a message to teh server that the plyer wants to buy an item that costs 1000 points.
Let the server check how much points the client has in reality.
OOPS! he doesnt have those 1000 points!
Yap, we caught him hackign again
So, really important variables arent hackable if you keep it protected like this on the server =)
#11
Posted 10 January 2008 - 12:50 AM
but anyways... I should see how it works out before I worry about that.
Anyways I'm STILL not woried about some stupid macros
@BlaXun: or i could keep the inventory server side, and the client only sends what spot was clicked, not what was in it.
#12
Posted 10 January 2008 - 01:04 AM
Well it all comes down to adjusting the balance between the server's processing time, the bandwidth and hack protection.
(I for one as example would choose least processing time and as few as possible use of the bandwidth above hack protection any time!)
#13
Posted 10 January 2008 - 01:06 AM
@Tahnok: maybe no mp's then?
but anyways... I should see how it works out before I worry about that.
Anyways I'm STILL not woried about some stupid macros
@BlaXun: or i could keep the inventory server side, and the client only sends what spot was clicked, not what was in it.
Ehm, in the small test I wrote it IS all server sided.
It never sends a ID of an item, it always just sends the SLOT that was clicked.
#14
Posted 10 January 2008 - 03:16 AM
Personally, I think the moving platforms are the least of your worries. Try coding up a real quick platform game where you can add in a delay between when controls are pressed and released and when the game actually notices those changes. Now, slowly start increasing that delay until you get to twice the maximum ping you expect to run into with your game (twice because the packet would have to go there and then another come back). I can pretty much guarantee you that it will seem as though you aren't directly controlling the player (and in some respects you aren't). Removing the link between the player and the character is a fatal flaw that will make the game less rewarding to play.@Tahnok: maybe no mp's then?
but anyways... I should see how it works out before I worry about that.
Anyways I'm STILL not woried about some stupid macros
[...]
#15
Posted 10 January 2008 - 04:12 PM
@blaxun: yet that would require a massive load on the server-side, it essentially has to run a "game"/var checking for each client connected..
Well it all comes down to adjusting the balance between the server's processing time, the bandwidth and hack protection.
(I for one as example would choose least processing time and as few as possible use of the bandwidth above hack protection any time!)
It might, but i'm not sure everyone playing will be selling/using/droping/picking up items non-stop, unless the game had like 10,000 players on at the same time, maybe then it would be a problem, but lets be honest, it is going to be pretty hard to make a game good enough in game maker, and if your good enough to make that game, you will be good enough to solve this problem a better way
and also, if your that successful with your game, I'm sure you'd be rich enough to buy multiple servers for the game lol.
Edited by Clarkyboy, 10 January 2008 - 04:18 PM.
#16
Posted 10 January 2008 - 08:48 PM
Here's a practical scenario:
you have a player attacking a monster, the user is seeing only the server's ouput.
For example, the server would send out things like: attack, exp, total exp... but essentially, the server keeps count.
Problems? Yes, it's highly failsafe, but very slow because the server has to do alot of work for each user.
#17
Posted 11 January 2008 - 12:05 AM
1. Assume the client is compromised. No matter how many tricks you leave to fool the hacker (eg, 4 copies of variables, multiplying them by a constant, etc...) you can assume they have been found out (and they will be by anyone competant.) So do not bother wasting the bandwidth/memory.
This means:
- the client should only send requests to the server; eg "player1 requests to move to coordinates x,y" or that "player2 wants to sell item Z"
The server should then varify if it is possible, and take appropriate actions, just as if a player in a platformer had requested (by pressing the keyboard) to move to the left, the game should check if there is a wall there, not immediatly move him to the left, hoping he had sense to avoide it.
- Any information given to the client is known by the player. If player1 decides to use 'invisibility' then don't tell player2 anything about player1's location (player2 could 'easily' make the object visible again).
As a bonus, this also saves on bandwidth
2. Assume all data packets have fallen 'into the wrong hands'. For the love of god, do not send an unencrypted password.
Okay, that one's more obviouse but; what about regular data?
Lets say you (the server) get a packet; "Player1 requests to drop 5000gold from their inventory"
The player has 5000gold, it checks out okay (they are allowed to preform that action.) All fine and dandy?
What if Player2 used a tool to spoof Player1's packet (the requested to drop 5000gold) so Player2 could steal it? You then need a way to verify that Player1 really did send that packet (Ie: that "I am who I say I am"). So some type of encryption would need to be used here. Of course, this is worst case scenario, I would say that most games here won't need to worry about that (at least not immediatly.)
3. Your game isn't hackproof untill you can hand a hacker your (clients) source code (with comments, etc...) without fear of him hacking your game. If one of your methodes of hack-prevention can be broken or bypassed this way, it's probably not worth it... Not that you would want to give away your source code
And remember, there's nothing preventing someone from creating their own client entirely; if they figure out the packet protocol (encrypting the packets helps slow this, but isnt a perfect solution.)
-Andrew
Edited by andbna, 11 January 2008 - 12:06 AM.
#18
Posted 11 January 2008 - 12:42 AM
Or what about games where there is no central server? If your players are making their own servers then it might be worth investing more anti-hack resources into a good ban system so that your players can police the game for you. Really, if a player is running a server and has the ability to kick anyone out of it then whether or not a player can hack gameplay is irrelevant if they just keep getting banned from servers.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users











