i think bway to face this kind of hack is encrypting.
That doesn't really work, because the data is available in the memory of the client, and it's easy to DLL inject or debug attach to a process, and change the data right in the process memory. Instead, you have to put all the important game rules on the server, and send player moves/commands from the client. Don't send "unit A moves to position X, Y" -- instead, send "unit A moves range R in direction D." Then verify that that unit has that much movement range, and that direction D is in fact clear to move on the server, and move the unit. Send back "Unit A is now at position X, Y." Do the same method for all other important actions that can change important game state.
next one is sql injection that i dont know really how does it work but i think its some kind of hack that they can change in your database.
Here is a piece of server code (in PHP) which can be SQL injected:
$result = db_query("SELECT * FROM customers WHERE customer_id=$_POST[customer]"); // VERY BAD
Here is the same code without the possibility of SQL injection:
$result = db_query("SELECT * FROM customers WHERE customer_id=:cid", ['cid'=>$_POST['customer']]); // BETTER
The difference is that the user could change the output of db_query in case 1 by sending a "customer" named something like "0 OR 1 = 1" which would return all the customers. For another illustration:
http://xkcd.com/327/or next one is ddos hack that send a lot of traffic to your server that it cant handle it.
The three defenses against DDoS are:
1. Don't piss of anyone or seem like a target (doesn't work in the long term.)
2. Don't be so dependent on uptime that a DDoS is a real problem (communicate to your players on Facebook, and hope they go away after a while.)
3. Contract with a DDoS prevention company like CloudFront or Neustar or Verisign or whatever. When the DDoS hits, work with them and follow their instructions. (Ideally, try the procedure once before you're attacked, so you know it works :-)
a much more exprienced friend in networking said if you just do all security rules there will be just little group of people can hack you game
Sadly, that small group, if it doesn't like you (or has economic incentive) will create a hack script that anyone can download (or buy) and hack your game.
Put rules on the server. Write safe server-side code. Subscribe to vulnerability mailing lists (like CERT.) Patch all your servers (and client libraries you use) as soon as there is a vulnerability (not next week, not next day, as soon as!) Write good server logs; keep the logs for a reasonable amount of time. Keep netflow logs for attack analysis. Go through the logs at some regular interval, and look for new patterns you haven't seen before. Set up good server monitoring and warning systems. Keep good connections with your community, and listen to them when they complain about cheaters and hacks and broken behavior -- sometimes they're right, othertimes they aren't. Keep good backups. Run databases with time delayed replication slaves. Buy external penetration testing services. Configure a firewall well to only allow in (and out) the data you *know* that your service needs (use white-listing, not black-listing.)
The set of good operational practices goes on and on (and on.) If this is ACTUALLY the biggest problem for you, hiring an experienced operations manager is likely a smart move for you. Chances are, your CURRENT biggest problem is likely that "we don't yet have a game that's fun enough that people would care." After you solve that, your biggest problem will be "nobody knows about us, and buying advertising is so expensive, and all the app stores have a million apps that are ranked higher than us, so nobody knows that they want to play our game." After that, your biggest problem might be "oh, our payment and customer service system is all wrong and doesn't actually make it easy for users to give us money (and take care of the cases where that fails for some reason.)" After THAT you probably actually need to start thinking about managing all your infrastructure for real. Unless you are really, really, REALLY sure that you'll actually get all the way there, spending too much work on the operational aspects now is probably wasted.
Meanwhile, making sure that all commands are executed and validated on the server, is something you should do up front -- it's the same cost to write it server-side or client-side, but doing it server-side is "right" and doing it client-side is very hard to "fix" later.
