The See-Invisibility Exploit in Games: How it works(shenglong.posterous.com)
shenglong.posterous.com
The See-Invisibility Exploit in Games: How it works
http://shenglong.posterous.com/interlude-the-see-invisibility-exploit
10 comments
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 :(
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 :(
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?
Edit, looking at your other post: Can't the packet editor that's marking people visible send a fake name to the client?
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.
If you want to know who is there, you have to request the name packet.
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".
[deleted]
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!"
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 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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
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?
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.
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.
>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.
Possible with ROPS.
Possible with OpenKore (a "new client" itself) in XKore mode.
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.
[1] Silentium was Eternity's encryption system. I'll post the code some time in a later post, if anyone is curious.
So you describe in your post that the original hack involves modifying the client but now claim that it can't be done?
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.
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.
If you only request names for visible players, what use is seeing the invisible player? You wouldn't know whether it was your ally or enemy, and revealing everyone has terrible consequences as certain defense procedures can only be executed in hiding. Also note that hexing functions as opposed to flipping a value is very different.
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?
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?
I can think of a number of solutions, some human, some programming, to the arguments you put forth here.
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.
[1] http://en.wikipedia.org/wiki/Scholars_mate
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.
[1] http://en.wikipedia.org/wiki/Scholars_mate
"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.
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.
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.
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.
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
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
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.
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.
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.
"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?
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?
"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.
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.
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.
Yes, they do have the issue - and a lot more issues. eAthena never rewrote the client - just the server code. Some of the eA guys (ultramage is -amazing-) are very smart.
I guess that would follow. If the client is set up to receive invisible players and not display them, then the original architecture must have been the same.
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".
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 meant this type of hack tends to exist in every game that incorporates invisibility - not that it's all done the same way. Sorry for the misunderstanding.
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 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 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
That just requires interceptors to be maintain some more state than they already do.
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.