Forum ‹ Games ‹ Hack Proof Your Game!

[ASH1138]

I have been thinking about how players can prevent a hacker from meddling with your game and cheating, without having to let your server do the work (I mean, send a request, validate it, send it back, refresh, its inconvienient, and uses a lot of bandwidth!) and I think I have found a solution:

You can add a piece of code to convert a loaded SWF down into its byteCode, like to byteArray.
247 255 32 0 9


etc

Then you add a piece of code in your client swf to take the logarithm(2) of each byte, and sum it up.

The principle is that, if Hacker modifies the code, the bytes will be different. A logarithm essentially finds the product of all the bytes in the swf. If we simply used a sum, the hacker could add some bytes in a portion of the program and remove the same number of bytes from another. For example, change HP from 1 to 7, and damage rate from 17 to 11. But if we multiply, its harder to compensate for the change without making the other value decimals.But if you make decimals, ints become Numbers, and you screw up everything.

And then transmit the number to the server. In encyrpted form. So for example, 2,309,192,592,806 becomes X,EIE,LOE,!Q@,[-=1. The server check the value to see if its valid. The encyrption key should use a dynamic pseudo-random number generator , which varies by the current UTC time (hr or min) , so that if a hacker sees X,EIE,LOE,!Q@,[-= on his message interceptor, and then tries to send out the same value in his hacked game the next time, he will get an error.

The hacker will then try to find the piece of code which encrypts or computes the bytes, but if he disables it, the client will send out 0, an instant fail. If he modifies it, the bytecode WILL be changed, so the sent number will be wrong!

See if you can find a way to hack past this firewall!

The only problem is, how do you make a swf read into its bytes?

[wgfunstormcontest]

As I posted in the other thread you suggested this, it's easy. Once decompiled find the piece that calls the encryption function. Write down the number of bytes of the unmodified swf. Change the encryption function to use a fixed value (that you wrote down) instead of the actual number of bytes.

As long as bad guys can modify the source code, it can never be considered secure. Because anything you can do, they can undo. And there's no way to stop them from modifying the swf source code. If you try and use tricks like this, it will take you a lot longer to create than it will take them to undo.

But there's already a good solution! They can't change the files on your server. So use that to do things that need to be done securely.

[Henrik]

See if you can find a way to hack past this firewall!

I download the Player.IO client library, make a game that uses your game's connect-id, authenticate as myself using QuickConnect or whatever, and modify my PlayerObject or any other BigDB object I have access to, in any way I want.

Your game runs on my machine. No matter how you try to lock down the game, you also have to give me the key to unlock it, otherwise I can't play the game. This means that no matter what you do in the client, I can figure out exactly what you are doing, and change it, hack it, fix it, cheat.

Which is why security on Player.IO starts with the assumption that the client is compromised, instead of hoping that it isn't. This is why BigDB and PayVault all have client access rights, so that you can control server-side what each client is allowed to do. This is why we have the multiplayer server, so that you can have execute game-logic securely. This is why we have QuickConnect, so that players can authenticate securely and not access each other's data or impersonate others.

[ASH1138]

Your game runs on my machine. No matter how you try to lock down the game, you also have to give me the key to unlock it, otherwise I can't play the game. This means that no matter what you do in the client, I can figure out exactly what you are doing, and change it, hack it, fix it, cheat.

.

What do you mean by "you also have to give me the key to unlock it?

I wouldnt try to add security on the client if not for the fact that it would be impossible to run the game on the server alone.
There are certain issues, such as saving Objects ,the 100ms code timeout restriction, and the latency problem. So thats why I have to find a workaround on the client.

[dreamora]

What he means is: If you encrypt data, then your client must be able to decrypt them to use them.
if the client can do it, you can reverse engineer what the client does and replicate it to missuse it in any other form too.

In short: The only form of 'secure' that exists is the one where your critical data never leaves the area thats solely under your access -> the server

Any data that goes to the client and any data the client can modify is 'open to be modified' by cheaters and hackers.

[ASH1138]

The eventual goal is to make it so hard for the hacker to hack it that he wouldnt bother. And Im certain that is possible. The question is, how.

I could obfuscate the code. That would make it difficult for the hacker to modify anything without corrupting the game.

I could also download the game from GameFS as a bytearray, and add a PRNG encyrpted timestamp to restrict authentication to one play only.The timestamp will be added on the server.
When the hacker decompiles the game and plays it without downloading it again, its timestamp would no longer be valid,and he would not be allowed to enter.
The problem is, would downloading games from GameFS count as bandwidth or not, and at 20MB per play, its a pretty hefty price. And, how do I create serverside code which can add bytes to GameFS assets?

I could also download a encryption hash from the playerIO server for bigDB objects every few seconds. Every time the hacker intercepts the hash, it would require a few seconds to store it somewhere and decipher the code, and create a new message/apply a modification based on that code. By then, a new hash code will be sent and it would no longer be relevant. The problem is, I need to understand how bigDB encodes its objects.

I could also add code on the server to listen for the interval between messages. Basically, my clients send messages every 500ms. They should therefore be received 300ms later on the server , with roughly the same interval. Whenever a message is received that bucks the trend, for example, received 50ms after the previous message, I can be sure someone else wrote it or intercepted and modified it.

[ASH1138]

What he means is: If you encrypt data, then your client must be able to decrypt them to use them.
if the client can do it, you can reverse engineer what the client does and replicate it to missuse it in any other form too.

In short: The only form of 'secure' that exists is the one where your critical data never leaves the area thats solely under your access -> the server

Any data that goes to the client and any data the client can modify is 'open to be modified' by cheaters and hackers.

Like I said, I have to make the reverse engineer part so damn difficult and tedious, no one will bother to do it.
There exist certain series in mathematics that are easy to encode, but extremely difficult to inverse. These would make the ideal encyrption function.

[Henrik]

I could obfuscate the code. That would make it difficult for the hacker to modify anything without corrupting the game.

The game runs in the ActionScript Virtual Machine, which means I have full access to your game as it is running, I can debug it live, I have access to your objects, data structures, everything.

I could also download the game from GameFS as a bytearray, and add a PRNG encyrpted timestamp to restrict authentication to one play only.The timestamp will be added on the server.
When the hacker decompiles the game and plays it without downloading it again, its timestamp would no longer be valid,and he would not be allowed to enter.

I download your game, extract the timestamp, put that in my hacked client, and I can play with that. How do I decrypt your timestamp? Well, your game has to be able to decrypt it, so you have to put the decryption key in the game, which I have full access to, which means I can grab it myself.

I could also download a encryption hash from the playerIO server for bigDB objects every few seconds. Every time the hacker intercepts the hash, it would require a few seconds to store it somewhere and decipher the code, and create a new message/apply a modification based on that code. By then, a new hash code will be sent and it would no longer be relevant. The problem is, I need to understand how bigDB encodes its objects.

This makes no sense. If your game can receive some sort of encryption key for BigDB data and apply it, then my hacked client can do exactly the same, in exactly the same amount of time. Besides, relying on timing between server and client is really bad, you would lock out legit clients that simply happen to be on a very slow connection.

I could also add code on the server to listen for the interval between messages. Basically, my clients send messages every 500ms. They should therefore be received 300ms later on the server , with roughly the same interval. Whenever a message is received that bucks the trend, for example, received 50ms after the previous message, I can be sure someone else wrote it or intercepted and modified it.

You can't be sure of anything regarding the timing of network traffic. The internet is a big and scary place, and packets routinely get lost, re-routed, or dropped, and the whole point of TCP is to ensure you get all the data in the correct order, but it makes no guarantees on timing whatsoever. Which means that messages from legit game clients will arrive randomly at the server.

[Henrik]

There exist certain series in mathematics that are easy to encode, but extremely difficult to inverse. These would make the ideal encyrption function.

Yes, you can easily encrypt your game client or the data sent betwen your game and Player.IO in such a way that it is impossible to brute-force decrypt it.

But your game has to be able to decrypt itself and the data, otherwise I can't play your game. And to do that, your game has to have the decryption key and the code for decrypting. Which means that I have everything I need to decrypt your data, and then your encryption is useless.

So, the only way to secure your game is to assume that the client is compromised, restrict access client-side, and move the game logic that needs to be protected to the server-side.

[ASH1138]

The game runs in the ActionScript Virtual Machine, which means I have full access to your game as it is running, I can debug it live, I have access to your objects, data structures, everything.

Thats true, but then again, even if you debug, how would you guess which function/variable does what when all you see are tens of thousands of UE&#HEYEYD? Even I take hours understanding and debugging my own unobfuscated code after taking a weeklong vacation. I dont think a hacker would be able to understand the squibbles without much effort.

When the hacker decompiles the game and plays it without downloading it again, its timestamp would no longer be valid,and he would not be allowed to enter.
I download your game, extract the timestamp, put that in my hacked client, and I can play with that. How do I decrypt your timestamp? Well, your game has to be able to decrypt it, so you have to put the decryption key in the game, which I have full access to, which means I can grab it myself.

Ah, I never decrypt the timestamp on the client The sole decryption function will be on the server for validation. The sever sends the timestamp as part of the bytes of the swf, the client sends it back, and never modifies it!
If the hacker decompiles and recompiles , he would need to connect again (timestamp varies with session) , and the timestamp that is included in the previous file will no longer be valid.
I would have to find out how and where I can inject bytes into swfs without corrupting their bytecode tho.

This makes no sense. If your game can receive some sort of encryption key for BigDB data and apply it, then my hacked client can do exactly the same, in exactly the same amount of time.

Yes, but then the hacker would need to write his own app to pull out the encryption key from the intercept program, decrypt the stuff that comes along, it and put it back into the intercept to make it fast enough to do it in a few s. Otherwise, he would have to do so manually, and thats not possible. That would deter most hackers but the most professional.

You can't be sure of anything regarding the timing of network traffic. The internet is a big and scary place, and packets routinely get lost, re-routed, or dropped, and the whole point of TCP is to ensure you get all the data in the correct order, but it makes no guarantees on timing whatsoever. Which means that messages from legit game clients will arrive randomly at the server.

I agree. maybe i should drop the last idea. Thanks!

Like I said, the objective is not to make a antihack foolproof, but deter most hackers.

[ASH1138]

A certain forum member I chatted with said load the swf from an external url from a container application, but I wonder if its effective?

How professional would a hacker need to be to extract the swf from the memory cache, rather than the browser cache anyway?

[dreamora]

that solution does not help much.
Your loader knows where to get the swf -> hacker knows it -> hacker gets the real swf -> game begins again

or alternatively

hacker starts wireshark -> starts your loader -> looks at the http request -> knows where to get the game

this kind of stuff is trivial and an absolute nobrainer. Even script kiddos can do that, you do not even need anyone with dedication and skill for this kind of stuff

[ASH1138]

that solution does not help much.
Your loader knows where to get the swf -> hacker knows it -> hacker gets the real swf -> game begins again

or alternatively

hacker starts wireshark -> starts your loader -> looks at the http request -> knows where to get the game

this kind of stuff is trivial and an absolute nobrainer. Even script kiddos can do that, you do not even need anyone with dedication and skill for this kind of stuff

yes, thats why I was wondering thanks.

Back to the drawing board again.

If i cant move my game code to the server because of certain reasons, then what do you think is the best way to protect the client from hack?

[ASH1138]

ahem, I should say BEST, as in BEST POSSIBLE, I dont mean FOOLPROOF.

If possible, the trick should take several days or weeks to crack.

Thanks.

[ASH1138]

that solution does not help much.
Your loader knows where to get the swf -> hacker knows it -> hacker gets the real swf -> game begins again

or alternatively

hacker starts wireshark -> starts your loader -> looks at the http request -> knows where to get the game

this kind of stuff is trivial and an absolute nobrainer. Even script kiddos can do that, you do not even need anyone with dedication and skill for this kind of stuff

Hey wait a minute. If say I post my swf to gameFS, and the script kiddo can still get the game, that means gameFS is not secure!

[skipgamer]

If i cant move my game code to the server because of certain reasons, then what do you think is the best way to protect the client from hack?

What are the certain reasons would be a better question?

[ASH1138]

If i cant move my game code to the server because of certain reasons, then what do you think is the best way to protect the client from hack?

What are the certain reasons would be a better question?

If I trasferred everything to the server, it would suffer from playerIO's restrictions.

1. My game's FPS consistently goes below 10fps for periods of time. I accomodate for this without making the game look slow by implementing multiple refreshes in one frame. BUT, if it were on the playerIO server, it would be terminated, causing players to desync.

2. Latency. Right now, I want the players to get the immediate effects of their actions, say use stuff from a bigDB object. If i had to send things over to the server and back again, there would be a lag of 500ms, and the player will "die" . Also, if there was an error returning bigDB object for one of the players, and all the other client successfully uses/add objects to the bigDB object, there would be a desync problem.

3. No statics allowed and restricted classes: Serverly compromises the complexity of the game.

4. Most of my code is already built into the clientside as a single player before I got wind of playerIO, so I would have to port everything over again!

5. A send request, callback loop is alot more difficult to debug than an instant refresh on the client. If I place a breakpoint on the callback, the debugger wont navigate to it, instead it will say MethodInfo587 < Anonymous> No source available. BIG HEADACHE!
6. Bandwidth. My bigDB object has many properties. If I wanted to refresh a player's inventory, I would have to load the whole object again( few KB), every few seconds! Ben and his guys have no way of simply loading the changes.

[Benjaminsen]

In short, as you have learned yourself, security is hard boring work. However there is no way to secure a game efficiently besides removing the users ability to interact with it locally. (E.g. run things on the server).

This is the same reason that DRM does not work, if you cannot trust the user, there is nothing you can do on the users computer to prevent them from cheating.

[ASH1138]

In short, as you have learned yourself, security is hard boring work. However there is no way to secure a game efficiently besides removing the users ability to interact with it locally. (E.g. run things on the server).

This is the same reason that DRM does not work, if you cannot trust the user, there is nothing you can do on the users computer to prevent them from cheating.

No offense, but you havent answered the question. The sources on the books and web say there are ways to prevent most hackers from hacking simply because its not worth their while, as in DRM. Its only worth hacking DRM if you can make money by selling pirated copies, but it isnt worth it to hack DRM just to gain a game advantage. But you guys keep saying its impossible. I know its impossible to hack proof something, but how do you have it so tedious that its not worth it to hack?
For example, making hacking a five hour job instead of a five minute job? Or dont tell me all hackers can hack something within 5 mins?

[Benjaminsen]

In short, as you have learned yourself, security is hard boring work. However there is no way to secure a game efficiently besides removing the users ability to interact with it locally. (E.g. run things on the server).

This is the same reason that DRM does not work, if you cannot trust the user, there is nothing you can do on the users computer to prevent them from cheating.

No offense, but you havent answered the question. The sources on the books and web say there are ways to prevent most hackers from hacking simply because its not worth their while, as in DRM. Its only worth hacking DRM if you can make money by selling pirated copies, but it isnt worth it to hack DRM just to gain a game advantage. But you guys keep saying its impossible. I know its impossible to hack proof something, but how do you have it so tedious that its not worth it to hack?
For example, making hacking a five hour job instead of a five minute job? Or dont tell me all hackers can hack something within 5 mins?

You are just starting a weapons race with your users. Try goggling any successful game and cheat, and you will see that there are pre-made hacks for almost any game.

Even worse, Player.IO is based on a standardised API. Thus whatever you do in your client has no effect on the transport layer.

[ASH1138]

I just suddenly realised that cheating on client based games will immediately cause a desync with other players which will immediately be apparent! So no anti hack function is needed!

Lets say a player cheated such that his character has 10000000 health. But, his character on the other clients will still have 100 health, and be dead when the player in the cheater's client character is still alive, causing an immediate desync! Identifiying him as a cheater, unless the other players are cheats as well.

I want to build a checksum function to check the playerObject of a player against copies of them stored in other players' clients. The other clients will load the same playerObject as the cheater, and then send them to the server when the player leaves, for checking. The theory is that, the playerObject copies will be updated at the same time and samely as the playerObject of the creator, unless he cheats, that is.

So , perhalps Ben can help point me in the right direction. How do I duplicate a bigDB object? Also, how do I compare bigDB objects with each other? ANd if possible, how should I save cached copies of playerObject (checksums) ?

Thanks! Sorry for bothering you with a big "argument!"

[waleeed12]

Player.IO is based on a standardised API. Thus whatever you do in your client has no effect on the transport layer.

____________________
solarmovie
shanann watts
young justice

[asdarty12]

There exist certain series in mathematics that are easy to encode, but extremely difficult to inverse. These would make the ideal encyrption function.

Yes, you can easily encrypt your game client or the data sent betwen your game and Player.IO in such a way that it is impossible to brute-force decrypt it.

But your game has to be able to decrypt itself and the data, otherwise I can't play your game. And to do that, your game has to have the decryption key and the code for decrypting. Which means that I have everything I need to decrypt your data, and then your encryption is useless.

So, the only way to secure your game is to assume that the client is compromised, restrict access client-side, and move the game logic that needs to be protected to the server-side.

https://apkmodule.com/app-cloner-premium-mod-apk/