

The See-Invisibility Exploit in Games: How it works - Shenglong
http://shenglong.posterous.com/interlude-the-see-invisibility-exploit

======
wccrawford
#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.

~~~
Shenglong
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
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?

~~~
Shenglong
No, because the client is not telling the server the player's name. The server
already knows, and sends that info to the client. You can definitely not ask
for a name, but that would be a moot point, because it wouldn't be very useful
at all.

If you want to know who is there, you _have_ to request the name packet.

~~~
zeteo
It still seems quite useful to know _someone_ is there, and where they are.
There's a big difference between "invisible enemy" and "stranger with a mask".

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

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

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

~~~
Shenglong
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...](http://www.blamethepixel.com/files.php?a=b&type%5B%5D=11&page=2)
Download "tapometer". I believe the world record (can't confirm) is 33/second.
I can manage about 14 myself on a desktop keyboard.

~~~
mukyu
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.

~~~
Shenglong
I should clarify... 5/second, during battles. Battles don't happen the entire
two hours. More realistic is 6000 slims a WoE. Also, things have changed. Wiz
no longer pot slims because they're too heavy.

------
pavel_lishin
> 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?

~~~
Shenglong
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
>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.

~~~
Shenglong
OpenKore wasn't working with Eternity's Silentium[1] active at that point.

[1] Silentium was Eternity's encryption system. I'll post the code some time
in a later post, if anyone is curious.

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

~~~
jerf
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.

~~~
Ogre
"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?

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

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.

~~~
Ogre
My point was more that the benefits in this case are likely not as great as I
had originally thought, not that individuals or amateurs shouldn't think about
it. Same thing you're saying really.

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

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

~~~
Shenglong
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.

------
andypants

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

I think not.

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

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

