The See-Invisibility Exploit in Games: How it works

http://shenglong.posterous.com/interlude-the-see-invisibility-exploit

by Shenglong • 15 years ago

59 39 15 years ago

shenglong.posterous.com

> We succeeded. People were scared, and they realized we weren't lying. The amount of invisibility-exploiters dropped from over 50% to less than 1%, and we went through several Sieges without catching a single cheater. This remarkable feat gave us a lot of credibility in terms of catching cheaters.

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?

Shenglong11• 15 years ago

It's impossible to do that, unless they managed to write a new client. If they don't request that packet on the original client, it'll cause the client to crash. It also would be of no use to them, because then they wouldn't know who, from which guild, whether it was an ally or enemy, was there.

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.

copypasteweb• 15 years ago

>It's impossible to do that, unless they managed to write a new client.

Possible with ROPS.

Possible with OpenKore (a "new client" itself) in XKore mode.

ldar155• 15 years ago

So you describe in your post that the original hack involves modifying the client but now claim that it can't be done?

  if (visibility = no), then {player = visible}

How about:

  if (visibility = yes ), then { request player name }

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".

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.

wccrawford• 15 years ago

#1 rule: Never trust the client. You're sending the client data that it doesn't need (the invisible characters.) Instead of having it tattle when the client can see things it shouldn't, you should just not let it have that information in the first place.

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.

Shenglong11• 15 years ago

It's impossible. The server doesn't send a name packet unless requested. If they request it through individual packets, the requested IP is still recorded, and can be matched (we log all login-in events with an IP) to an account.

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 :(

Dylan16807• 15 years ago

The point is for the cheater to not ask for the name. Even simpler than an overlay, if you figure out how cheater detection works, is to filter the outgoing name request packet.

Edit, looking at your other post: Can't the packet editor that's marking people visible send a fake name to the client?

ldar155• 15 years ago

The consequence of breaking Rule #1 is that the cheat will be so straightforward that it can be distributed by wizards to muggles and 50% or more of your players will be using it.

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!"

larrik• 15 years ago

I like how instead of "how can we make cheating technologically impossible", you instead went "how can we make cheating completely undesirable."

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.

Ogre4• 15 years ago

"Otherwise known as the Maya Purple Hack, this is a fairly common hack exists in just about every game that incorporates invisibility. On RO--and probably most other games as well--his hack works because of unneccesary information being sent from the server to the client. There are semi-logical reasons for it, but in the end we have to blame it on poor programming."

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.

jerf2• 15 years ago

Poor programming is a bit of a harsh read of the situation. The "obvious" solution of having the server simulate everything the client is simulating, then only sending the data that the client actually needs to display isn't free. It's a great deal more programming effort, with code that will tend to expose every bug in it. What features will you trade away for that? Will the lack of those features end up entirely killing the project?

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.

Ogre4• 15 years ago

"poor programming" was a quote from the article.

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?

tzs2• 15 years ago

I understand that argument when it comes to "see through walls" cheating. The server can't do real-time line of sight calculations for every player and only send them information on other players who they have line of sight on.

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.

coderdude• 15 years ago

I don't think that 'poor programming' is too harsh in this situation at all. You call it the obvious solution, but really there is only one solution worth spending your time on. The correct solution is to simulate the game on the server and update each client with only the information it is allowed to know.

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]

http://gafferongames.com/game-physics/networked-physics/

http://gmc.yoyogames.com/index.php?showtopic=415538

stonemetal• 15 years ago

I am not sure the solution is so easy. Invisible players might still make noises, attack, or interact with the environment in some way. So completely dropping them from the update stream might not be possible.

agnesi• 15 years ago

If you had that much power, you should have gotten your team to write something fun for the remaining 1% users of the hack you uncovered. Something like mark each player caught clicking on an invisible toon, wait until a certain time, and then WHABAM: Everyone caught gets a 5 day un-cleansable debuff that removes x% percent of their max health per second, but never making the killing blow. Put a cryptic tooltip for the debuff icon saying something like: Those who weild the eyes of the devil are now paying with their souls. Also, if their health drops below 10 percent, start automatically making them consume their potions at 10/sec!

boredguy8• 15 years ago

Famously (well, famous if you were into MMOs & high-end raiding 10 years ago), EQ did something similar to what you describe. An end-zone boss wasn't supposed to be reachable before obtaining certain keys that weren't even in the game yet. Folks that had used in-game mechanics to bypass the doors one day logged on to find items like http://everquest.allakhazam.com/db/item.html?item=17057 replacing their original loot.

ChuckMcM• 15 years ago

Another solution I've seen programmed for the invisibility hack is to fill the game space with characters who are 'invisible' unless you have the hack. (its a variation on authors solution). People who are cheating have their field of view swamped by all these non-characters sitting around.

ldar155• 15 years ago

That just requires interceptors to be maintain some more state than they already do.

tzs2• 15 years ago

Looking forward to more...I would particular like to see coverage of how speed hacks and warping hacks work. I don't understand why those aren't easy to catch on the server without undo resource use.

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.

Shenglong11• 15 years ago

I will definitely make a note about this, but the main reason for your question:

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.

jules• 15 years ago

This is a problem in RTS games. In many of those games you can only see enemies close to your forces. But because the games work by simulating the same thing on every client, the position data of the enemy pretty much has to be sent to each other client, thus enabling see everything hacks.

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.

hardy263• 15 years ago

The purpose of the visibility feature was for positioning purposes. Determining player position is not a trivial task, and the information is not unnecessary, it was an engineering generalization that made certain game features easier to develop. It was not because of poor programming.

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.

Shenglong11• 15 years ago

eAthena is batched inserts, which actually makes the problem worse. I'm not speaking from theory when I pose this problem - potion consumption actually caused the server to lag every few seconds (players at the time will attest). If you believe players are consuming one potion per second, I don't think you've played competitive WoE.

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.

mukyu• 15 years ago

You are saying every player goes through 36k whites/slim whites a WoE, 5 times a week. I can see going through that many if you are an LK running around trying to break the precast, but if you are just sitting in a wizline you might go through 200 in two hours.

ldar155• 15 years ago

it was an engineering generalization that made certain features easier to develop

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.

andypants• 15 years ago

   this is a fairly common hack exists in just about every game that incorporates invisibility

I think not.

The See-Invisibility Exploit in Games: How it works

Related Stories