It's been said over and over that impossible to design a system without faults, and to date no game has ever gone without being hacked at some point or other. Reducing the number of security faults and thus the number of ways or ease in which a game can be hacked is a given, but what about when it harms game performance? In a game, performance equates to playability and is therefore one of the top considerations beyond all others. By using less secure designs, like performing the majority of calculations on the client end, performance can be drastically increased, costs reduced, and bandwidth saved but this of course makes hacking far more easy. Since hacking is inevitable though, is killing performance the right way to go? Unscrupulous use of ban commands coupled with watchful game monitors and an easy means of reporting troublemakers by worried clients would in theory reduce the "damage" hacking could cause, and would discourage the practice if the bans were truly irrevocable. Players who hack would loose everything and therefore have no possible gains (except greifers who's goal is just to cause disruptions) and this would make actually playing the game more rewarding than hacking... at least in theory. Already I see a fault here - the size of the staff would have to correlate with the size of the player population, as a GM can only monitor so many users. In a small game, that's not so much of an issue if a few trusted individuals can be found, but in any model that's particularly large, it'd be a nightmare. The only other fault I see in this is the need to limit registration in some manner so that banned users can't easily create a new account, or must do so at some cost to themselves, so that the loss of an account actually means something. My ideas in this regard are rather shallow - all I can think of is a paid CD-key, which means anyone who gets caught has to pay real world cash in order to do it again, and some kind of limiter on what a newly made account can do (for an easy to see analogy, your level is capped at X for the first Y hours of play). The first might work, except that I myself am opposed to pay-to-play models (I prefer RMT/Premium Shops, like maplestory), and the second would be a hassle for honest-to-goodness new users. So really, I'm curious as to how effective simply watching for and removing invalid users would be as a means of security in an otherwise insecure game? Have I missed any obvious reason why this would not work? And does anyone have any suggestions on how to make such a model more workable? Any thoughts or comments would be greatly appreciated.

Look at it this way. System written with security in mind gets hacked from time to time due to sequrity aspects usually overlooked during the implementation or later changes. Some of these hacks shows up as quite obvious, other gain enough publicity to be found by the developer. Both these gets fixed quite quickly. However, the hacks which is not obvious or well known will probably go undetected.

Allowing the client to have a large say in matters will only open up more potential issues. Even if you fix/ban 90% you will still end up with potentially a lot more hacks which is very hard to detect.

The problem as i see it is a cheat can spread from a hacked account to a legit one. Take a mmorpg for example. The hacker creates some accounts and duplicate the really rare wand xmastreeofterror... then he "sells" it for 1 gold to his own other accounts and some of his friends.. Now you have 50 ppl running around with the really rare wand even if you ban the hackers account. You can't prove that the others knew about this (maby he sold it for gold so some ppl payed weeks worth of gameplay cash to buy it)...

Also as a mmorpg player myself if i was in pvp and got beaten by a guy that obviously used a hack i would be pretty pissed off (even if that guy got banne a week later... usually i dont keep track of what ppl gets baned or not)

Thank you for the input, it's certainly food for thought.

I had done some thinking about the transfer of illegitimate items. The best method I was able to come up with was based on a number of post mortems I read, which talked about this problem (I think it was Ultima online in particular, where they were unable to tell what had come from mass duplications and what was looted) was a little database heavy, but possibly workable. It's possible to store all transactions within a database, and provide a unique ID for each instance of an item, and backtrace an item's exchanges. Any item that originates from an invalid source can be eliminated (two items from a person who only had one, for instance). If done magnificently (hyperbole appropriate), it would be possible to reverse any transaction involving an illegitimate item, provided it was an exchange of items/gold for items, and it was done in a single exchange. Automating that process may be difficult, however, and doing it by hand an endeavor of love.

However, I think item generation should always be handled server side, because it isn't intensive and doesn't hurt performance by much, even if there were thousands of such actions going on simultaneously. There will be bugs there too, of course, but that's more of a database problem than anything else. Things like collision detection, movement, and physics simulation are what I was speaking of when mentioning insecure practices. The major threats to this system are things like god-mode (ex: I never report collisions with projectiles), speed hacks (ex: I lie about where I should be), collision-free hacks (ex: walls mean nothing to me!), unlimited ammo hacks, aimbots, or things of that sort. In the articles and posts I've read, most games adopt a server-sided simulation of the majority of variables and a duplicate run on the client. I was speaking of a simulation where actions are simply logic checked rather than compared to a complete or near-complete simulation. 10 perfect shots at a distance greater than viewing range? 100x normal speed? A firing rate greater than maximum possible? - these things would not require a complete simulation, and are relatively inexpensive operations to carry out, even hundreds of times per second.

Admittedly, I had FPS and twitch-type games in mind when I first thought of this, so I didn't consider database vulnerabilities, as few points of data are persistent in such a game. This design however can be applicable to RPG and MMO format games as well, though there's a lot more that can go south in that case.

Quote:It's been said over and over that impossible to design a system without faults

False premise. As a matter of fact, there are ways to prove programs are correct with formal methods, and designing programs without them by using instead test-driven development often leads to quite correct programs as well.

Quote:By using less secure designs, like performing the majority of calculations on the client end, performance can be drastically increased, costs reduced, and bandwidth saved but this of course makes hacking far more easy. Since hacking is inevitable though, is killing performance the right way to go?

Hacking is not inevitable.
It's not about "more or less secure designs", it's about trusting the client the data it sends is compliant with the world rules or not.
If you choose to not trust the client about anything (especially about something that is clearly the responsibility of the world, not that of its agent), like you do normally for any client/server design, there is no potential fault in the design.

Quote:Unscrupulous use of ban commands coupled with watchful game monitors and an easy means of reporting troublemakers by worried clients would in theory reduce the "damage" hacking could cause, and would discourage the practice if the bans were truly irrevocable. Players who hack would loose everything and therefore have no possible gains (except greifers who's goal is just to cause disruptions) and this would make actually playing the game more rewarding than hacking... at least in theory.

Such an approach is obviously not fair, since it will often result in both false or true positives, so people are usually banned without tangible proof.
Games usually need to have a clause in their EULA that says they can ban anyone whenever they feel like it in order for it to work, and of course that's not really a good quality of service for the user (but since when do businesses care about their consumers anyway?).

That kind of behavior is also known as totalitarian (instilling fear in people to control them with harsh and immediate punishment pronounced without a fair trial), and while services are certainly no democracies, such rules remain quite despicable.

Quote:he only other fault I see in this is the need to limit registration in some manner so that banned users can't easily create a new account, or must do so at some cost to themselves, so that the loss of an account actually means something.

Easy workaround: just don't ban users in the first place. If you need to ban something, it's just IPs that are doing DDoS attacks (and often only temporarily).

Quote:Original post by loufoque

Quote:It's been said over and over that impossible to design a system without faults

False premise. As a matter of fact, there are ways to prove programs are correct with formal methods, and designing programs without them by using instead test-driven development often leads to quite correct programs as well.

i don't think so you can't secure program to have no bugs in it, BUT you try to make it secure enough if i am a manager in MMORPG team i would focus on game elements more than the security(not to be manic but to make it secure enough).

Quote:Original post by loufoque

Quote:It's been said over and over that impossible to design a system without faults

False premise. As a matter of fact, there are ways to prove programs are correct with formal methods, and designing programs without them by using instead test-driven development often leads to quite correct programs as well.

And what do you do to prove that your tests cover all the branches your code can take? Even assuming you use a toolset which lets you verify this, how do you prove your tests are correct in the first place?

Modern programming requires we interact with black box APIs which have their own faults and failure conditions. How do we prove are programs never stumble across any of them? On any hardware configuration? Modern programmers can't even be assed to stop making buffer overflows, a class of error that by now we completely understand the cause of, and various solutions to, including automatic range checking.

We can prove things about programs, sure. We can use such methods to decrease the number of faults, sure. But we can't prove they're faultless -- among other things, you'd first have to exhaustively define what faultless is, and hackers are all about thinking about the fault that you didn't think about.

Quote:And what do you do to prove that your tests cover all the branches your code can take?

Tests don't prove your code is correct, they only help seeing it is likely to be if they're well made.

Quote:Modern programming requires we interact with black box APIs which have their own faults and failure conditions. How do we prove are programs never stumble across any of them?

You read the documentation and you make sure you fulfill the precondition of any call of the API you're using.

Quote:Modern programmers can't even be assed to stop making buffer overflows, a class of error that by now we completely understand the cause of, and various solutions to, including automatic range checking.

We probably have a different notion of what modern programmers are then.

Quote:But we can't prove they're faultless

Yes you can, but that requires using formal methods to design the system (i.e. you can't just use a traditional programming language, you have to use a language integrated within a model checker and shit), which is quite a pain in the ass.
Aviation and rocket science are mostly the only ones using that kind of thing I believe.

Quote:you try to make it secure enough if i am a manager in MMORPG team i would focus on game elements more than the security

The reason they don't do it on MMORPGs is not because being secure is hard, it's because they assume it would be a performance overhead for their server.
The same code needs to be done anyway; they just choose to do it on the client instead of the server.

To any person writing a web application (and we all know that this is quite a big business, especially with this new web 2.0 trend), not trusting the client and doing what needs to be done on the server there is natural, and they usually end up with quite secure applications. (of course, we all know of how many ones are broken and unsecure, but still, the more serious stuff is quite secure)

[Edited by - loufoque on July 12, 2009 9:37:47 AM]

Quote:Original post by Konidias
I think one of the best methods to prevent or defend against hacking is to set up an automated logging system that only red flags things out of the ordinary.

Actually, I would think logging all events would be more efficient, though certainly some events should be flagged more than others. Only redflag events would automatically alert GMs, but noting only what appears to be odd events means that an unforseen exploit might go unlogged. If everything is logged, and a new exploit rolls around, it would be possible to undo it's damage (which I think is a great benefit), track who abused it, and who didn't. It's much better than having to do a rollback or server wipe to eliminate an error (as per what happened with the early Ultima Online).

Quote:This way you're catching people cheating without being obvious about it.

I envisoned stealth GMs lurking in rooms/instances/the world. There is no notification of the client that the GM is present or absent, and they have the authority to ban a client that they spot cheating with impunity. Admitedly, that's putting a lot of power into the hand of a GM, but if it's for the sake of the game, I have no trouble with it. This would work best in an online FPS (think counterstrike) as cheats there are easy to spot. Things like packet related exploits (double packeting causing a DB error or some such thing) would be far more difficult.

Quote:That's why I advise in a logging system. Just make sure the logging system has a flood protection so that someone can't exploit it and flood your server with logs.

I would agree that a logging system would be well advised for such a model. I hadn't, however, even considered an attack against the log itself, rather I was focusing on attacks directed at the database (like item duplication). Thank you for the food for thought.

Quote:Basically the best form of defense against cheaters is to think like a cheater.

True, but they'll always be a number of steps ahead, as defenses are static until updated, and attacks are always dynamic in nature.

I'll say this about the debate about the inevitability of hacks: Name one defensive system that is not supported by a multi-million dollar organization (military, government, corporation) that has not been in some way cracked. All of the online games I have encountered have had some form of hacking, even and perhaps especially large, mainstream games - to even begin to assume your code is safe is a dangerous thing to do, as hackers will prove you wrong every time.

In theory, you can create the perfect system. In practice, however, it is not possible.