Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

This game is really secure, in a smart way.

Joined
Jun 8, 2007
Messages
1,985
Reaction score
490
Note: This is a failed attempt at reverse-engineering, but I decided to share it anyway.

Hey guys, I thought I'd share this game I've been playing, and one I was testing the security of to find any vulnerabilities and what-have-you. It's an 8-bit MMO with retro graphics and retro gameplay- open-world with no restrictions on PVP, and you interact with mobs by talking to them in-game, the same way you would talk to a player. No sub-windows pop up so you can concentrate on the game itself, and be ready for PVP at any time. The game is .

The client was recently ported to JavaScript and canvas. After breaking through the minification, I was able to view (more/less) the source code of the client, and I quickly started listening to all the packets, and summarizing them to clean up the noise. The packets are not encrypted, but this is admirable, as you all should know encryption is merely patch-work security that is able to be bypassed, usually very easily (because the client has access to the decryption function and key one way or another, in order for the game to be playable). The lack of encryption made it apparent to me that the game had rock-solid security, as I could see what packets the server and client were sending to each other, and the actual data that was being transferred with ease.

The server sends 3 kinds of packets (not counting the initial connection/handshake packets).
  • Sound data - What sound file to play, when to play it, etc.
  • Server Message - Is the server going to go down in 10 minutes? Is there a latency correction stall? Was there a crash? etc.
  • Drawing data - Draw rectangles, draw pixels, what color to draw, begin of draw, end of draw, etc.

The client sends user-input packets only.
  • Keyboard events.
  • Mouse events and cursor position.

The client has no knowledge of the game what-so-ever. All the client knows is that the server is going to send one of those 3 types of packets, and each one has sub-types the client is concerned with. The client doesn't know what items you have in your inventory, it doesn't anticipate a user is going to keep walking a certain direction, it doesn't know the velocity of a fireball- nothing. All the client knows is that the server told it to draw some pixels on the screen in a certain order, and to play a sound file, or to write text on the screen in a set location. The client knows where you click, but it has no knowledge of what item you actually click on, or whether or not there is an item there at all- the client is as dumb as the monitor on your desk- all it see's is pixels.. The server handles all of the game logic. The lack of encryption made me concerned at first, but shortly after my concern I was thrilled to see this design. The server doesn't even send image data- it sends numbers necessary for the client to draw the images itself! Idk, it fascinates me. :)

There are far too many games that fiddle with encryption and efficiency, trying to cram game logic into the client to save some load on the server in exchange for security. I just wanted to share my findings for this game, so you all can see how a game like this should be developed. Security like this is done at the very beginning of the game development process, and patch-work security is nowhere near a substitute for this rock-solid design.
 
Last edited:
Not working on UnitedFlyf
Member
Joined
Apr 21, 2009
Messages
1,385
Reaction score
934
This is probably ideal for security, but I don't think it would work very well for games with more complex graphics. This reminds me of the concept of "streaming" games, where the player would just send input to the server and the server would stream video output back to the player. The flaw is obviously latency. Even with very low latency, the difference is notable and significantly degrades the experience of any game with modern graphics.

Also, would this game be vulnerable to botting?(as in, does it have an economy of any sort? or competitive pvp?) A bot wouldn't have to be too complex to parse 8bit game graphics to figure out what is what. That seems like the most obvious exploit that would remain.
 
[emoji848]
Legend
Joined
Dec 3, 2011
Messages
2,232
Reaction score
1,518
I agree with Mootie here. This might be applicable for retro games but for big environments and a big load of players? Just nope. Unless everyone is surrounded with great internet connections and Server GPUs are actually a thing, I can't see how that concept would have success any time soon.
 
Joined
Dec 15, 2009
Messages
1,387
Reaction score
236
I agree with Mootie here. This might be applicable for retro games but for big environments and a big load of players? Just nope. Unless everyone is surrounded with great internet connections and Server GPUs are actually a thing, I can't see how that concept would have success any time soon.
As your name implies - Future
 
Not working on UnitedFlyf
Member
Joined
Apr 21, 2009
Messages
1,385
Reaction score
934
I agree with Mootie here. This might be applicable for retro games but for big environments and a big load of players? Just nope. Unless everyone is surrounded with great internet connections and Server GPUs are actually a thing, I can't see how that concept would have success any time soon.

Even with very minimal ping, games with aiming like FPSes would still feel clunky. Using this approach to improve security seems like overkill unless you're also targeting low-spec client machines with games that aren't latency sensitive.


The packets are not encrypted, but this is admirable, as you all should know encryption is merely patch-work security that is able to be bypassed, usually very easily (because the client has access to the decryption function and key one way or another, in order for the game to be playable). The lack of encryption made it apparent to me that the game had rock-solid security, as I could see what packets the server and client were sending to each other, and the actual data that was being transferred with ease.

This segment is also a bit strange. If your code is secure and bug-free, you can do a ton of logical processing client-sided without any security holes. In addition to the potential of botting, there are also logical exploits that can be executed through standard input if the game is insecure.

You say encryption is patch-work security, but this is also security through obfuscation. Properly written MMOs that use standard networking also do any security sensitive processing server-sided. The only difference is some processing is done on the client-side before being sent to the server for validation and execution. There isn't any issue with this approach as long as the server doesn't trust the client, which is a rule that only very poorly managed development teams would make.

While this method would also prevent things like wall-hacking, this is also possible via traditional networking, although latency can be an issue(which this method doesn't fix). It's just another barrier, just like executable obfuscation or complex encryption.
 
[emoji848]
Legend
Joined
Dec 3, 2011
Messages
2,232
Reaction score
1,518
You are right, and also imagine the workload on the server. If the server has to simulate everything live, you should set it to at least 20, better 30 ticks per second. So 30 times a second simulating and querying all clients, doing hit detections, and so on and so on, and the game environment is huge. It's not really what server are meant for. They are no games they are servers, lol.
 
[emoji848]
Legend
Joined
Dec 3, 2011
Messages
2,232
Reaction score
1,518
Says the future :p
Search for Server GPUs..... You will see that this is more than uncommon atm.
 
Back
Top