How do you protect your source code for online games?

The kind of games where there involve online features such as global leader-board, trophy, cloud saves etc, how would you guys handle the security? I mean I can encrypt or use hashing and then let the server(php, asp etc) do the decryption or hash matching. As we know the mono scripting backend is vulnerable to reverse engineering, I can almost see my games source and even a c# solution that I can bring into VS straight ahead[proof: ilspy]. While I don't care if somebody steals my gameplay code or like that, I do care about server security. Because a guy savvy enough to search for each www class I used, can potentially ruin my day I looked on the solutions so far, and it consists of

• Encrypting the .net codes after game export.
• Obfuscation of codes within editor before a build with various packages

I am not sure how much helpful those solutions are. If they are, please state your experience of various solutions out there for protection.

P.S. Its not always possible to use il2cpp. For example, current facebook sdk is broken with il2cpp.

 

They don't need your source code to hack the server. If you trust the client, you can be hacked. The only way to prevent someone from hacking your leaderboards is to calculate the scores server-side and not trust the client to provide it to you.

 

I am not sure how would I do this.
score = f(user's various activities in game);

Then the activities should be sent to server in order to process the score on server. Then again I am sending a derivative(different form) of the score. So by trust issue, still it the activities from user is trusted and hence vulnerable to hack. May be I am not getting your point

 

Basically, to make the server secure, you need to do all of the game logic on the server and make the client a more or less dumb display engine that displays what the server says to display, and that sends user input to the server. Then all of your score calculation can be done on the server in a place where it can't be tampered with.

 

As other said, the server is the master. E.g. player position on the client is updated from client info (so it seems responsive), but interpolated to the position you get from the server. For any decision, e.g. if an attack is possible or hits, the server decides based on his position data. The game runs on the server, the client just displays parts of it with some optimizations for responsiveness.

Another aspect is that you only send the client info the player can know. E.g. only enemies he can see atm. Otherwise hackers can use the extra info to show you e.g. units that are in fog of war or other infos that should not be available to a normal player.

 

Another thing is the security of your server. Just follow web-application security guidelines. E.g. only use prepared statements for SQL, and never trust any info from the client (you need input validation).

 

That kind of is the point - there's no way to fully protect this kind of thing if it's happening on the client.

As someone said in another thread quite recently, "you fundamentally can not hide a secret from a person you are sharing it with".

 

There is a way to secure the server, but it costs a bit of money and will reduce performance slightly. It is not published anywhere, so I will explain what I can.
You need 3 servers total. One for the web display (http server) one for the data storage, such as a SQL server and one for the gateway.
The gateway has the public facing address on one card and a private address on the other. The public facing card allows only HTTP and/or HTTPS connections. All other ports are re-routed, preferably into another outside server you can use to monitor attacks.....
The inside card sends http requests through to the web server (which has a private address) and the web server queries the SQL server (also private address). Each of those servers have only the ports open that they need, and if you are really creative, you alter them from standard ports.
This type of system has been used to secure banking data and such with great success. You may have to tailor it a bit to what you are doing, but it would accomplish what you need. Hope it helps.

 

This is indirectly the same as saying "all game logic must run on the server if you want to secure your leaderboards". You can have the most secure server setup in the world and I can still add money to my account if you trust the values I'm sending you.

 

If security is your priority - put the code on a disk and lock it in a safe. Under no circumstances hand it to players in any state.

 

Check out this thread https://forum.unity3d.com/threads/h...yption-key-in-the-client.431711/#post-2796805

It went into quite a bit of depth on the subject

 

Been there done that. I half hoped the place would burn down one day so we could see how effective the fireproof safe really was.

 

My take on it...

1.) Only use IL2CPP - I know this is not ideal, but releasing on Mono runtime is just opening up your game to get hacked. You don't need to use the Facebook SDK, you can use an alternative like GetSocial which offers Facebook like functionality across multiple social networks.

2.) For server side-peace of mind, using something like GameSparks, which has people working full time and years invested in making sure things on the server side are 'secure'. They also support server-side code through their JavaScript SDK, and all data is stored in a MongoDb, directly accessible from this Javascript SDK.

 

Quite literally a "smoke" test.

 

As a rule of thumb: Never trust the client.

Don't let clients do important things that affect others or gives the client advantages or things they shouldn't have. Only let clients replicate close to what the server does (it doesn't even need to be that close, as online games are full of trickery that no-one notices)

For my online game, practically everything's done on the server side, from scores, stats, player movement (client-prediction), projectiles, interactions, loadout selection, saving loadouts, destruction, weather, etc.
There is only one thing that is extremely difficult to do, and that is firing bullets with all these dynamic systems i have in place (will still try to, but likely not going to be able to do it).

All in all, if code is on the client, that the client can run, they WILL have access to it and be able to change it no matter how you hide it.

 

Here's what I'm doing for my game.

1. Sending client data via UnityWebRequest over 'https'. I'm sending even password as plain text. I'm not encrypting anything on client side as it's pointless.
2. Created a custom "NodeJS" server and deployed to "Heroku". This server is my custom REST endpoint and managing all the data integrity check and hashing the password with algorithms like BCrypt.
3. Once the user is logged in to the game all communication is handled via "session id" which is being generated by the server using "uuid". It's like the cookies & This session id saved on local client (Encrypted with UniqueDeviceID +usernames as salt) and being used for validating data before saving it to the database.. This prevents from user accounts being shared and playing at the same time.
4. I'm using CloudSQL as database and I've setup some "Before Save" and "After Save" triggers on database as final measure of validating the data.

I'm not an expert on this, also I have not tested it with live audience. These are the security measures I've implemented so far for my project under WIP.

 

How are you using HTTPS and also "not encrypting anything"? HTTPS itself uses either TLS or SSL.

Also, client side encryption definitely has a point, it's just nothing to do with protecting data from the user. It's all about protecting the data as it's transmitted between the user and the server. It's super important for things like passwords. (And before someone says "but who cares about passwords for games?", keep in mind that people reuse passwords.)

 

This is the first time I'm designing a server & database. Hence there'll be issues, I'm aware of that.

The reason I said, I'm not encrypting anything on client side is, I'm not doing any password hashing before it's being sent to server. Because, anyone could easily see the client side code with tools available and it's not good to show the client what algorithm is used for encryption.

I'm sending all data as simple formdata(UnityWebRequest). Since it's being sent via SSL it's fairly encrypted by default. And on the server side (NodeJS server), I'm running BCrypt algorithm to hash the (password+game specific custom salt) and all other data which require encryption. Once all the encryption and integrity check is completed it's written to database. (Here's an example password saved on my DB "$10$W8bJOPzoM5tE/RMDe/Nkmfgw3ege9kcp/XGieMFBRxLKmUv1IrnvYahOe").

Yes, I'm aware of the fact that people reuses their password.That's why I'm using a sessionID after successful login and saving it locally (not saving plaintext/locally encrypted password on client side). The server will return a sessionID (something like this 1e771e4a-3432-4d40-858d-274c1f4fa595 ) and I save this on client side for autologin and all further communication. This sessionID will get regenerated every time someone logs inn. Considering the security it's not safe to let the client know the encryption/decryption algorithm and the salt.

Following is my only implementation for server-client communication.
API Manager

Code (CSharp):

1.  
2. public enum APIAction { login, signup}
3. public static class APIManager
4. {
5.     private static string baseURL = "https://api.mydomain.com/";
6.  
7.     public static IEnumerator _Process<T>(WWWForm form, APIAction action, Action<T> callback)
8.     {
9.         string endpoint = baseURL + action;
10.         UnityWebRequest www = UnityWebRequest.Post(endpoint, form);
11.         yield return www.Send();
12.         if (www.isError)
13.         {
14.             callback((T)Activator.CreateInstance(typeof(T)));
15.         }
16.         else
17.         {
18.             callback(JsonUtility.FromJson<T>(www.downloadHandler.text));
19.         }
20.     }
21. }
22.  

API Helper class

Code (CSharp):

1.  
2. [Serializable]
3. public class LoginResult
4. {
5.     public bool success;
6.     public string status;
7. }
8.  

Test

Code (CSharp):

1.  
2. public class Test : MonoBehaviour
3. {
4.     private void Start ()
5.     {
6.         Login("user", "pass");
7.     }
8.  
9.     private void Login(string uName, string pass)
10.     {
11.         WWWForm form = new WWWForm();
12.         form.AddField("username", uName);
13.         form.AddField("password", pass);
14.         StartCoroutine(APIManager._Process<LoginResult>(form, APIAction.login, OnCompleteLogin));
15.     }
16.  
17.     private void OnCompleteLogin(LoginResult result)
18.     {
19.         if (result.success)
20.         {
21.  
22.         }
23.     }
24. }
25.  

 

You'll need to encrypt passwords and usernames if you care about protecting the user. Like @angrypenguin said, people reuse passwords.
If you use the basic public/private key encryption system, any client can see the algorithm but they can't do anything with it, because they don't have the private key (the server has). Even if someone spoofs the connection or can get a way to get that encrypted message, they can't do anything with it.

The only thing they could do is use that message to make the server think they are the client of that message, but that's why there's sessionIDs and other things to prevent that.

Anyone can encrypt anything with the public key, but no-one can decrypt it without the private key.


EDIT:

For the initial connection, one way for the server to know the client is the one that sent that message, is to give a time-stamp on the encrypted message with the username and password, so the server knows the correct client created that message.

The sessionID is also not that simple, since anyone can spy on the connection, see it and re-use it.

You can read some books on how to encrypt messages between client and server. This is just me talking a bit about security, but there are many other things out there.

Now, important thing to know is that we develop games. If you're not going to give any sensible information about the client through the network, then you probably don't need to care much about this, except for the initial connection with the username and password. Don't overdo the security on something that doesn't need that much security. A basic public/private key encryption should be enough for any message from client to server (with time-stamp).

 

Well, this makes much sense. I didn't thought end to end encrypted communication is required for games. But I guess I'll have to go by this way. Thanks @eskovas!

 

IL2CPP is in the manual. When we can get your hands on it ! [Windows] download link?

 

At this point that's about the only place it's at.

Standalone platforms are going to be practically the last ones supported. We'll be waiting a long time.

 

I had a play with auth0 when I was creating a xamarin project once, it would likely work fine for Unity too. Essentially all your app does is load a web view that points to a secure login mechanism, and the user can choose whether to use their Microsoft/Google/Facebook id to login, or to create a new username/password. The beauty of this is you never store any username, email or password on your servers, just a token, which is otherwise useless outside of your app. So if you get hacked, your game data could be manipulated/wiped, but they aren't otherwise going to get anything useful.

 

The downside is that you're relying on someone else to do your authentication, and if they go out of business, all of your users can no longer log into your service. You'll probably receive notice in time to find some workaround, but it's not going to be fun getting everyone transferred over.

I'm fine with using Google/Facebook/etc as logins, but asking a third party to be the intermediary for that is a step too far, IMO.

And of course, without that intermediary, you'll have to store the user/pass for anyone who doesn't want to use a social media login to play your game, so you haven't really avoided that.

 

Would any of you release an online competitive game without cramming most of the game logic on the Server? Hackers are gunna hack regardless. Maybe most of it is preventable, but likely not all of it. Instead I wager I can give the admin to any private server the ability to kick players. Maybe that will even out the community a bit. Thoughts?

 

As a general rule of thumb: Why waste the effort?

When AAA games are plagued with cheaters on a daily basis, no matter how well you think theyre doing to counter them, there is little actual hope.

The best you can do is, like them, crack down enough where the obvious cheaters are eliminated (like earning 999999 points when the max is 10.) Then simply allow the better (more hidden) cheaters alone.

Take Elder Scrolls Online for example. Heres a true story of a friend of mine. Someone who I'm sure believed in cheaters existing, but didnt know the reality is far worse than anything ppl think. Let's say like him, You play PvP 24/7 for months and so of course you'll know the top 10-20 players right? You see those leaders, lose to those guys constantly like theyre pro to your newb. Zenimax does a ban sweep, and all 10 are wiped off the next campaign's leaderboard. some rumored banned, others vanished, and the new top 10 are names youve never seen before. Ever. You encounter that one arch nemesis who always beat you, and suddenly he sucks? Then again and again? The next day he is back on top, then immediately after accusations suddenly sucks again in the same 30 minutes?

Not a coincidence. You were just unaware of the magnitude of cheating in online games. You were just fooled into thinking many "were just that good" as your peers mocked your complaints "QQ learn2play".

I've been competitively gaming for almost two decades. I've played (and lost) to pro players, but was able to remain competitive & atleast annoy them while losing. I can tell when someone is cheating, because it's obvious. Plus there's youtube to show you how easy it is.

So why, if it's always so rampant, would you think you could stop ppl who want to cheat?

Why, if AAA still lose even after spending lots of money to crackdown, would some A, B, or Indie title waste such effort?

Do what is easy, but know it's a losing battle, leaderboards are often a joke in all but the most serious AAA games (and even then...)

So judge how much it's worth it. Unity developers dont tend to have AAA budgets to crackdown & keep up.

Like piracy, the best thing you can do is slow it down initially, at least for a few weeks or a month to help boost those initial sales. After that, just knowing you lose.

For the gamer though? The best is a system that empowers THEM to avoid cheaters (or anyone they dont want to play against). Custom matches, smart matchmaking & cheat reporting blocking those users from being linked in the future, kick buttons, server authority for the owner, etc.

IMO, in a design perspective, the best leaderboard is one that doesnt exist. Get some fresh ideas that bring in the same reward & satisfaction as a leaderboard, but targeted toward each user. Because leaderboards are pretty much useless. All but the top 10-100 will care, and the skill (cheating) gap will be so enormous 99% of your users wont even care for it bc it's so unachievable. Give them something Average Joe Sixpack can enjoy, achieve, etc. Something that places him outside not only the cheater's scope, but also players infinitely better than him (and always will be), but don't let them know they're losers. Dont point out "Youre good, but still in Class J. You'll never be Class A. Loser!" Instead, focus on what ppl want. "You're doing better! You got to #1 for your goal! Heres a new list you're at the bottom of. Keep going, youre awesome!"
Reinvent the leaderboard to become something more than <1% of your users like.

Then you wont even have to worry about cheating. In fact, cheaters would then be in a class all on their own: which is fun for them too.

 

Because your customers (players) expect it. Nobody is going to play an online competitive game that refuses to even attempt to prevent cheating. I think a good-faith effort must be attempted, and even that may not be enough for many players.

 

Competitive multiplayer games, yes, but that sort of game has a server enforcing game logic rules so cheating becomes simpler to address. The general context of this thread is discussing online leaderboards, which is another beast entirely because there is generally not a server to do rule enforcement during game play.

 

Are you sure about this?

I have my doubts that most gamers would expect much of anything (at least on this front) from small time Unity developers. It's not like Unity devs are well known for their large budget MOBA releases.

As a gamer myself, I expect little from Unity games, except...I always expect poor peformance (low framerate, despite my awesome hardware). I also expect all but big budget indies (Kickstarter successes) to be limited in some way (not necessarily bad games. Just limited budget games.)

Plus it's Unity...one of the most popular engines (and thus well known by cheaters & hackers). You can make competitive games with Unity, you can put more code server side, but at some point you will lose. Unity games and small time devs will lose much quicker than AAA if their game were to get popular enough to see a flood of cheaters. Unless, like AAA, you can keep up with the cheaters, which is alot of work. You're always losing, but doing good enough to slow it down so it's not blatantly visible to the end user. You'd have to scale your work with the game's popularity.

Cheating is prevalent in even AAA online games. Those games still thrive & do fine. Cheating only ruins a game when it is out of control. In small time indie cases, not neceasarily by there being too many cheaters openly running rampant, but by the PLAYER having no control over their experience (game is entirely hosted by the developer's servers, which were poorly coded, with no ability to keep up).



And besides, what leaderboards ARENT spoiled by cheaters? What MMO economy NOT effected by gold farmers? What FPS game without aimbots? Like I said, the best you can do is be like AAA and prevent some of the more obvious, visible cheaters. And even that is often out of the scope of indie budgets.

For example if player hosted servers, the admin can simply ban cheaters. Problem solved. You don't hear ppl QQing to Valve about Left4Dead cheaters. But Left4Dead cheats are a download away, or just require admin priviledges.

So why not turn design principles on their head so your problem with cheaters doesnt even exist in the first place? Use your strengths as an Indie to do something different that both gives users a fresh experience AND alleviates all that anti-cheat work you'd have to do otherwise?

As an indie or low budget, you have to pick your battles. My suggestions were alternatives to give your players what they want without needing to combat leaderboard cheating.

All in the context of the type of games we see when Made with Unity.

 

There are rabbit holes you just should avoid. I know this may sound defeatist, but if you are really striving for a quality game, extreme pvp or player competitiveness might be something you want to avoid if you are a small indie developer. Your game can quickly get overwhelmed by cheaters and once a pvp/competitive game gets a reputation for cheating, it quickly snowballs because more players will research the cheats, and less honest players will bother playing. And the reality will be that most of your development time will be spent chasing cheaters, which is not fun and takes away new content from your non-cheating players.

I really feel it is just better for us small indies to find reasons to go co-op or non-competitive.