The See-Invisibility Exploit in Games: How it works
shenglong.posterous.com
shenglong.posterous.com
Because there's still a way to cheat: Packet sniffing. Sure, they won't get as much info as they used to, but because it doesn't interact with the client at all, they can't get caught. Then they just write an overlay for the client so they can visually see the invisible characters, and poof... They're undetectable again.
If I were to lead a game now, I'd definitely have things designed differently. You're right - a programming fix would've been desirable, but was unfortunately not a possibility at the time :(
Edit, looking at your other post: Can't the packet editor that's marking people visible send a fake name to the client?
If you want to know who is there, you have to request the name packet.
The "fix" has helped with PR: now the muggles are afraid to use it, so they don't feel so bad. But guaranteed the wizards are still using it.
This shenglong guy has zero credibility with anyone who has ever cracked a game. Judging by his inability to understand the programming issues, its entirely possible that his claims of "spies" are equally delusional and that Guild Masters are now telling him "No! No new cheat here!"
I'd also imagine that most (maybe all) of your cheaters had a reaction more along the lines "finally!" rather than "aww, shucks."
I remember in the game NetStorm (wasn't a big hit), everyone basically used a "money cheat." Why? Because you had to, since everyone else used it.
For instance, if you were to equip a Maya Purple card, all it would simply do is turn the visibility on, rather than the server doing a check for every player who has the card and changing the size of the packet for that particular person.
Walking animation is implemented by the client as well. If the invisible person was in the middle of walking and they were detected, how would you position a player with only their end position since initial position wasn't sent to the client? You can't. They'd just appear to the end position instantly, skipping the walking animation.
While you feel can feel superior to the developer and believe the programmers at Gravity are being bad programmers, you have to think about the reasons behind it, so you don't spring more leaks by fixing what you think is a trivial bug. It's sort of like a leaky water pipe. Fixing the leak in one area may induce pressure in other areas and cause leaks elsewhere.
"Let me give you an example of server load: On RO, potions can be consumed at a most, 10 per second. With 2,000 players all consuming on average 5 potions per second in Siege War, there are about 20,000 MySQL inserts per second, counting inventory and logs - which is taxing enough by itself."
I'm being nitpicky, but if you're using eAthena, I believe that inserts are batched rather than instantaneous. And each player is not consuming 5 potions per second on average, that'd be ridiculous. If you were to average it, it may amount to maybe 1 per second at most. 5 per second is only if you're tapping furiously. I'm sure if each person averaged 5 per second, all your players would either be cheating by packeting or have carpal tunnel.
For an accurate representation of how fast you can hit a button: http://www.blamethepixel.com/files.php?a=b&type%5B%5D=11... Download "tapometer". I believe the world record (can't confirm) is 33/second. I can manage about 14 myself on a desktop keyboard.
The rallying call of poor programmers everywhere.
Its not about ease of engineering. Its about consequences. The game designers wanted an invisibility card. There were two ways to program it, one easy and one hard (you're talking to HN, so I imagine a lot of people here can think of ways to implement a system with all of the constraints you describe).
They chose the easy one. Either because they couldn't think of the hard one, they didn't think the easy one would have consequences, or they were overruled. The OP's surprise seems to suggest a lack of forethought.
I think you rushed to a conclusion. Did people actually stop cheating? Or did they figure out a way to avoid sending that name-request packet back to the server?
I also had spies everywhere. If there was an ingenious method of getting around it, we probably would've known. In addition, no one really knew how we were catching them, so it would've required one of the developers to leak (unlikely), or someone extremely intuitive to find out.
I'll admit a possibility - but all the odds are against it.
Possible with ROPS.
Possible with OpenKore (a "new client" itself) in XKore mode.
[1] Silentium was Eternity's encryption system. I'll post the code some time in a later post, if anyone is curious.
if (visibility = no), then {player = visible}
if (visibility = yes ), then { request player name }
In addition, no one really knew how we were catching them
No: most people have no idea. The ones writing the attack know very well how you spot them.
You have succeeded in preventing the muggles from cheating and seem proud about it.
Okay, some people might have known. However, no one could be sure unless they did a lot of hit & miss testing. Even if they knew, there's no reliable way to circumvent this system that I can think of. You need the name packet for the exploit to be useful (or guild packet... but same thing).
I'm proud because of the results, not because of the solution. We worked with the extremely limited resources we had and found a fully functional solution. You don't think that's something to be proud of?
That you would even make these arguments, when counter-arguments are so immediately obvious, is why you will fail. Its like playing chess, but you can't see even one move ahead. You are basically arguing that h5 is a really silly place to put the queen because look, you can put your knight on f6 and attack it. [1]
You are engaged in a war of escalation, and yet you cannot even iterate strategy and tactics on paper. If you can't even imagine how someone might exploit the situation you describe, then you will forever be surprised when you encounter the exploit in the wild. You have no chance of proactively preventing any kind of cheat.
Your enemy is not the muggles. Your enemy is not your average programmer. Your enemy is someone who lives for winning the meta-game: of outwitting your programmers, not your games designers.
EDIT: For entertainment value:
Observe how I predicted what my "enemy" would do: Feel free to argue that this will require more than just replacing BNEs and CMPs with NOPs or JMPs. Or indeed making the executable bigger. Or indeed many other things that are "hard".
And how you did it anyway: Also note that hexing functions as opposed to flipping a value is very different.
Very different for you. You see, you replied anyway thinking that your statement demonstrated support of your argument. Whereas I wanted you to respond that way, because your statement actually supports my argument, which is that you are hopelessly outmatched and dont even know it.
EDIT: Adding link based on downgrade of expectation that the reference would be understood.
I get that there are time constraints, code no one wants to deal with, deeply ingrained bad decisions, and who knows what else going on here, but I really think this point could use more elaboration. It IS poor programming. Why not fix the underlying issue and stop sending updates about invisible players to players that can't see them? While ingenious, detecting the mouseover requests isn't really fixing the problem.
"this is a fairly common hack exists in just about every game that incorporates invisibility"
I doubt the "just about every" part of this statement. But I can only say for sure that World of Warcraft does not send players updates for invisible objects (players or otherwise). Not that WoW hasn't had its share of attacks, but it hasn't had this one.
It also puts vastly more load on the servers, even if perfectly implemented.
It also isn't easy even if you implement this from day one, and is usually going to be virtually impossible to retrofit.
The question isn't about "poor programming" or not; it's a call about the costs and the benefits. The costs are quite large, and as this article demonstrates, if the benefits can be obtained much more cheaply in other ways, it may be a bad engineering decision to spend that much time to do "good programming" on the problem. Quality code isn't free and resources are never infinite.
Also, it wasn't clear from the article itself what game was being talked about. After clicking around the site, I realized this was about a "private server" for Ragnarok Online. In other words, a reverse engineered fan-made server. Though there appears to be an actual company behind it, just not Ragnarok Online's actual developer, I'm not quite clear on whether there's a business here. Either way, I was thinking of this in a completely different context.
Indeed writing it properly isn't free, that's part of why people pay money to play these games! But in this case, people are perhaps not paying any money.
I wonder if the official Ragnarok Online servers have this issue?
Thinking about costs and benefits isn't just for businesses, it's for every programmer. Things like opportunity costs are always present, even when money isn't.
Do you have any evidence or experience to back up the "just about every game" comment? I still find that hard to believe. This is coming from having written code to "do it properly".
I would imagine that the proper way of programming invisibility, is that no packets should be sent, until the server confirms the player can actually see invisible characters. As I understand it, too many of these checks would limit efficiency, though.
I'm not so sure that applies to players who are invisible due to a stealth ability. The check there would not involve a lot of intense geometry calculation, but rather just a simple check to see if a given player can see through stealth.
My guess is that for stealth players the reason you have to still send their data to everyone is for AoE effect checks. In many games, AoE effects still hit stealth players. AoE effects are still subject to line of sight checks in many games, so you'd want the client calculating the potential targets for the same reason you use the client for line of sight visibility checks.
I wonder if any game companies have tried a statistical approach to catching cheaters? For instance, suppose on an AoE attack, the caster's client calculates which targets are hit and informs the server. Why not have the server randomly pick a small fraction of these attacks and verify them? This doesn't even have to be real time. The server could just log the relevant information (locations of both players, the spell that was cast), and a modified version of the client software could be used in a batch mode to go through these and verify that the user's client reported accurate results.
Anyone who fails the random test gets flagged for more random tests.
The client should not make any decisions and should only ask for permission. If the player wants to move forward then the client sends a request to the server to move forward. The server will respond with new player position data if the move was allowed. If the player asks to move through a wall then the server will not comply.
The server should also never send clients data about other players not in their field of view (or in the immediate area, all depends on the game). To send the client any information it shouldn't have or to allow the client to make any decisions that the server takes and runs with is absolutely poor programming in the multiplayer game space.
You just have to ask yourself if it's worth it to possibly save some time at the expense of introducing a systemic flaw in your client and server that allows cheating to occur. For a competitive multiplayer game I think it's worth the time to make sure you're not sending clients the position data of invisible players.
Edit:
The client will most likely also calculate some of these changes at the same time it requests a move though. This is called client-side prediction and it's done to keep the gameplay smooth over unreliable and slow networks. The clients will interpolate and extrapolate certain game moves and sync with what the server says as the data becomes available. That's why sometimes in Counter-Strike (for example) you can run in one direction for a second or two and then suddenly be in another location altogether, because the server corrected the client's increasingly inaccurate extrapolation of position.
Some reading if this sort of stuff interests you:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_N...
http://developer.valvesoftware.com/wiki/Latency_Compensating...
http://www.gamers.org/dEngine/q3suggest/final/generic.html
http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tr... [pdf]
That's the key point. I don't see any advantage in sending all that information, other than to correct for another bug which should never have been there.
You can avoid this by not sending the data, but that complicates the simulation a lot. You can also get a big latency hit when your forces quickly uncover lots of enemies, because then suddenly a lot of data has to be sent.
I don't know how the game of this post works, but I doubt that it uses the method RTS games use because there is far less going on that the player can see. So for their case it would be simple to modify the server so that it doesn't send position updates for invisible players, thus making it impossible to cheat that way, instead of requiring detection and threats by the game company.
For instance, when a player loads a new zone, why not do a simple check of where he was 30 seconds earlier? If he was not near any official portal, and did not use an official port spell or recall scroll or some such, then he must have used a warp cheat.
Data saving. How many locations at different times do you want to save? Do you save every second for the last 30 seconds? What is a comparable distance? On what events does the check trigger?
Even more of a concern: What if your algorithm breaks for a border case and causes a disconnect or ban? How do you deal with the consequences? Even more important than catching cheaters, is to make sure everything flows smoothly.
For RO in particular, there is a random-teleport skill/item, which makes your description impossible. As for attack speed hacks... there's a lot of variations. One simple variation is a memory edit with T-Search, since attack speed restrictions are almost always client-side, due to computation tradeoff.
this is a fairly common hack exists in just about every game that incorporates invisibility