That's an interesting method and the last part perfectly shows the collision part. One thing they didn't show is if the player who ran through the line could attack stuff behind it. We saw that the character could be attacked in front of the line where the server knows it is and reports to other players, but could the hacking player cause damage? That's more of a theoretical question I suppose since I don't know how unity handles stuff.
Fix your ****
Love that part.
tanwedar said:That's an interesting method and the last part perfectly shows the collision part. One thing they didn't show is if the player who ran through the line could attack stuff behind it. We saw that the character could be attacked in front of the line where the server knows it is and reports to other players, but could the hacking player cause damage? That's more of a theoretical question I suppose since I don't know how unity handles stuff.
Fix your ****Love that part.
I would assume not since your character would not really be there, and would likely just be swinging at space infront of your real postion.
image said:It doesn't matter what the game is, if you don't have some form of anti-cheat there are enough people out there who will disect your game to their advantage. Way back in the early EQ days this had a lot of problems, which for example included people changing their hp regen client side to allow insane regen, you could also enable the /zone command which was only supposed to be for GM's. PVP servers had issues with players clicking off buffs because the client handled things like root/snare/etc and the server did nothing to enforce that.
So what does this mean:
a) Don't trust the client, period. The client is there to show the world and let them interact with it, majority of logic should be server side or at least affirmed on the server.
b) Lack of an anti-cheat is going to make your lives as devs/support/etc harder and likely more frustration from players (more commonly in PVP, but PVE servers are not immune).Kilsin said:
While that sounds good in theory, an anti-cheat is basically a small speed hump for cheaters, the people who make the programs will code their way around it so it will need to be updated constantly and then once it is, they will code around it again, it is an ongoing cat and mouse for every game with every anti-cheat.
I was able to find the thread that we discussed this in great detail so I will go ahead and close this one down and I will copy my post below but please continue the conversation over in that thread if you folks have any more to add but a lot of it has already been covered: https://www.pantheonmmo.com/content/forums/topic/3253/anti-cheat-precautions
My Quote:
"It is tough on the Devs too, the more secure and thorough the anti-cheat needs to be, the more intrusive it needs to be and then there is all kinds of privacy issues which a lot of companies do not want to risk breaching, therefore, they tolerate some cheats more than others, not because they want too but because it could hurt them quite badly if they went after them too hard.It really does suck, I would prefer a more intrusive method via installing software on my PC to allow the game to be more thorough in detecting cheating software but many do not want that but still cry foul over hacks and cheaters and so the vicious circle continues, usually with some half-measures to stop the obvious hacks/cheaters while the more complicated and technical ones go undetected unless physically seen in-game."
Quoting you from the other thread in which you linked to this one, I'm going to have to agree with what image said.
Every measure should be taken to ward off cheaters, To me this means making everything as much as possible “server side” as shown in that video I posted.
Beyond that other measures should be included, as I don’t think relying on any one measure will be enough.
Everything from;
Client side anti cheats that scans the users computer (Vac, Nexon,Punkbuster)
Server side anti cheats that checks for abnormality’s in stats (Fairfight)Additionally as you mention taking reports from the players, but also having something similar to CSGO overwatch where players can review video evidence would go along way to reducing reports for GM’s or staff member to investigate.
Finally, and equally as important, Taking a visibly stance on the issue in my opinion also thwarts potential cheaters and keeps moral about the issue high.
Overwatch by blizzard made big headlines due to their stance and apparent effectiveness on the bans, and gained much respect from the player base because not only were they banning the cheaters, they were making in extremely difficult for them to renter the game once banned
As a player were constantly bombarded with evidence of cheaters, be that someone in game who clearly doesn't know a thing about their class, but somehow has a max level toon, or the constant advertisement of gold selling links hitting the chat.
This over time, lowers moral and trust in game, and its “fairness”, some players may just succumb to the pressure and buy the gold, many will just abandoned the game.
Most games typically have a no naming and shaming policy, and that is fine for forums, but I have seen a few cases where the developer's announce (in game) when someone has been caught cheating and banned.
This to me combats some of the moral issue because while I may see evidence of cheaters, Knowing, and I mean knowing, (not lip service) something is being done helps a lot to restore that trust.
To further that id love to see public executions of said cheaters character for all to watch when you the developer knows with 100% certainly they cheated.
I feel this could boost moral on the issue while encourage the player base to report cheaters. To many times Ive reported “suspected cheaters” with no indication anything was being done, while the cheaters continue to grow in numbers and visibility. Eventually people stop reporting, loose interest in the game and quit.
So to me, the most important system in the game is its security.
This post was edited by HemlockReaper at November 1, 2016 4:24 AM PDT
Apologies in advance for necroing an old thread, but this topic is very dear to me (cheating heavily contributed to my "taking a break" from my previous MMO) and through my search of the forums this appeared to be the most recent/active thread. If there is a more appropriate thread to hold this discussion, I'd appreaciate it if you could point me there. That said, here are my thoughts about cheating.
Firstly, I think cheating really should include both actively tampering with the game, e.g. through third-party software that enables stat boosts, speed hacks and so on, and exploits, i.e. the abuse of existing game mechanics. The reason why I think exploits must really fall under the category of cheating is because the effects of exploiting are essentially the same as "hardcore" cheating. Exploiters undermine the sense of fairness that should exist in a game. It's true that IRL the world belongs to the smart, so if someone spots an opportunity that isn't illegal, they are free to take advantage. Yet even IRL otherwise legal actions can have negative moral implications. And it's never enough to stress that a game is not real life - people play games to compete, spend time, test their skills and in general to enjoy themselves.
Abusing in-game mechanics to obtain unintended outcomes affects the community as a whole, either by skewing the playing field in someone's favour (e.g. combat exploits), or by hurting the in-game economy (e.g. item duplication exploits), or by creating de facto strategies that avoid intended mechanics and become necessary for competitive play (e.g. map exploits to speed run through raid content). To argue that these are fine simply because they make use of existing game mechanics seems to me disingenuous, since every game has and will have bugs that take time to correct, but that shouldn't mean players should be free to negatively impact the community while the issues are being dealt with. Exploits can and do ruin games, as I've experienced first-hand, and it's unfair and unrealistic to expect that any game as complex as a modern MMORPG would have no exploitable mechanics. So whenever I mention cheating from now on, I will be including exploits.
Moving on, in my opinion there are two major vectors in dealing with cheating. The first includes automated cheat detection and prevention mechanisms; the second refers to other developer actions. I have serious doubts regarding the effectiveness and efficiency of the first. Memory/process scanners, client or server-side validation, etc. are a game of cat-and-mouse where developers create new ways to detect cheating and players make up new ways of defeating them. They also take a toll on clients and servers that can become quite heavy and bring down game performance. This isn't to say I think Pantheon should completely skip automated cheat detection/prevention, even because they act as a first line deterrent, but I do strongly feel that they will not be enough. Dealing with cheats and cheaters will require clear and focused action by the developers. The following are what I would like to see in the game.
These are my two cents on the issue, I'd love to see what other people think. Also, since the thread has been calm for a few months, I wonder if there are any new developments on the subject of cheating that the developers could share at this time.
This post was recently linked in another (locked) discussion on cheating. I really hope that VR is ready to tackle these issues since some of EQ's more prolific cheaters are here and active on these forums, even some who have been caught actively warping and automating gameplay in the last few months.
Zaide said:This post was recently linked in another (locked) discussion on cheating. I really hope that VR is ready to tackle these issues since some of EQ's more prolific cheaters are here and active on these forums, even some who have been caught actively warping and automating gameplay in the last few months.
We take this topic very seriously and if you have information on known cheaters please feel free to forward it on to me so we can watch them more closely.
How appropriate that this topic is showing some activity right now, given the recent news that Windrows 10 Fall Creators Edition is adding its own OS-level anti-cheating mechanism.
The system seems to be part VAC-like signature scanning for known cheating engines, part sandboxing and securing game processes such that other processes are unable to access them or change data stored in that process memory. If it detects a cheat, it supposedly forwards anonymized information to the app developer to act on (privacy concerns go here, though VAC, Warden, etc. do the same). It's also supposedly opt-in, but if a game is flagged as requiring it players won't be able to play without opting in.
One downside is that it seems to be restricted to UWP apps, i.e. those sold in the Windows Marketplace. I think this is possibly due to Microsoft's handling of those apps, which are currently already sandboxed, and also to try and make the Marketplace more appealing to developers and more competitive against Steam and other sales channels.
While I dislike the tying of this system to the Windows Marketplace, the concepts sound interesting. Food for thought.
Reading through all of this just reminds me that we've all become hypernormalized to many client-side cheats because so many games (MMOs in particular) have gotten them wrong. Things like local stat boosts, speed hacks, etc in the client that the server allows by trusting information from the client. This doesn't have to be the case.
For example, movement could be communicated in (at least) 2 ways:
The client tells the server it's moving to position (x,y,z). In this case, the server needs to validate that those coordinates can actually be reached since the last movement request, given the speed, pathing, etc. This can be a very expensive verification if the update times are relatively slow, as would be seen with a few dropped packets), so instead the server is probably going to put some trust in the client messages, leaving room for a speed exploit.
Alternatively, the client could tell the server it is moving on a particular heading (angle) for some amount of time (or continuously until the next update). In that case, the server has a single path to trace for collisions, some bounds checking on the change in angle (if limited), and checking that the time is less than the time since the last move command. Cheap, fast, easy, secure. No amount of local memory hacking can produce a speed hack here; the speed is never sent from the client to the server.
Another example is local stat boosts. The only way modifying stats locally could have any real effect (again, other than messing with client prediction which can really only be used to divulge info from the client) is if the client is allowed to send stat-derived values to the server and the server trusts them.
If the client tells the server "I attack Decaying_Skeleton001 with my Short Sword and +2 str mod" then there is room for exploits (changing weapon, str mod, and possibly attack speed by sending packets more frequently).
If the client can only tell the server "I turn on autoattack" then there really isn't any room for an exploit at all. All of the attack parameters (target, weapon, mods, speed, etc) are handled by the server.
Now, that's not to say that local memory hacking can't still get you some advantage by getting the client to divulge info. For example, a local speed hack may be able to fool your client into divulging info you shouldn't have access too, like a quick peak around a corner or through a wall before you get synced back to your rightful place (as communicated by the server). But really there are far more effective ways to get this kind ways to get this info out the client (wall hacks, anyone?).
And, of course, server-side checking alone will not stop things like bots/3rd-party clients. Limiting the information going to the client is the only real mitigation against these kinds of hacks, which VR is already doing.
Local scanners like VAC & Warden can help, but it's a cat & mouse game.
Limiting the info going TO the client is only half the battle.
You have to be careful about what can come FROM the client as well, and assume that if the protocol allows for it then cheaters will try to exploit it. Don't rely on the client software to provide ANY info to the server except user inputs and always assume that data from the client to the server has been tampered with. The server holds the source of truth and must always protect the sanctity of that truth.
EDIT: formatting
I'm over the cheating value judgement. People play these games in all sorts of ways I find nauseating, most of them do not involve any form of 3rd party utility. They just play the game in a way that I hate, and sometimes compel me to stop playing. But in ways players cheat, there is probably a running theme.
Here are the things in EQ that I see the cheat programs doing: warping, mob information, power skilling/trading/autobuff macros, UI modifications, bots.
The Warden - Sounds ominous. Easily defeated for anyone not a script kiddie using pre-compiled binaries. If you know what you're doing, there isn't a cheat system out there that can keep you out. Welcome to PC gaming, you will need to accept some level of cheating or go back to consoles. Fundamentally the PC is not a secure platform, and that's a topic for a different forum.
Warping - This must be handled server side. Clients may not even be aware it is happening. Always bad, always game breaking. High impact issue.
Mob information sent to the client should just be presented to the players period. If you do not wish players to see it, do not send it. It is bad when it obviates a player skill (e.g. Tracking), and undermines the social game when a player is deselected for lack of omniscience (i.e. who wants the puller who doesn't see the named on the other side of that wall?). Present all information available to the client natively, restrict that based on what's efficient for server loads. Yes having "radar" is not immersive, but in a land of magic, I would hope some wise magician created a HUD. This just has to be a concession to MMOness, there's no way to stop client side hacks here.
Power skilling - mashing a button for 12 hours on end should not be a thing. No one should need or want to do this. If it can be automated, it will be. If you do not want that, then do not have such an element. Taking this out makes most sense: fewer reasons to create a cheat, means less interest in creating a cheat.
UI enhancement - At risk of flames, WoW did this best, hands down the best feature ever. It's odd that they did that in a game that is so PvP focused: without any question those with custom UIs were advantaged against anyone with the native UI. But they did it. Since this is a PvE game: embrace it. Give players the power, and take away the motive for cheaters to offer it selectively.
There's no way to stop bots really. The best solution is to look at why they are created: #1 farming, soloing, xp grinding. It seems like there are solutions to these that would eliminate the need.
Remember people who write these cheat programs are programmers and engineers who *usually* have better things to do with their time. Often they spec it out and pay someone overseas to go do it for them. The best way to turn them off is just to take the motivation away: money. Take away as much of the feature-set of cheat tools as you can, make it so the market is as weak as possible.
And for God's sake, learn from EQ. Learn from every MMO since. The #1 fund for cheat utilities continues to be farmers and RMT. The solution is not technical: take away their business model. I do not want to play a mobile "buy gems!" game, I do not intend to buy any item or currency and will be very upset if it even remotely appears necessary. However, I assume many people will do so. I don't like how they play, but the best solution is to let them pay YOU, and make sure it's priced so that farmers can't get in the door. If I log in to this game and dungeons are basically camped and items I want are impossible to get because farmers, I will stop playing, period. I've had quite enough of that.
Exploits take many forms. There's the "big stuff" like ShowEQ but then there are also players just finding creative ways in-game to circumvent intended game mechanics.
Case-in-point, the ancient cyclops ring for the jboots quest in EQ was a lore item. You were only supposed to have a single lore item. People started farming rings for multi-questing and would corpse them. Since you didn't lose experience in a player duel and the game didn't check your corpses for lore items, it became a very common practice. There would be a constant lineup of the same people who constantly farmed and had maybe 10-20 corpses laying in the water off-shore.
Corpsing also became common practice for preventing no-rent keys from decaying. This became an accepted strategy, but clearly wasn't want the devs had in mind when they were designing those zones and items.
Arguably, even multi-questing wasn't supposed to be a thing. I hope Pantheon doesn't duplicate either of these game mechanics. MQ seemed like such a major short-circuit to the intended quest lines and distribution of power outside of the intended player level. Lore should mean lore, even if the item is in the bank or on a corpse.
So my point is that no matter how well designed you think the game is or tight you make your game security, players are going to find exploits and shortcuts. The real issue is how VR deals with these creative minds: do they nod and smile and say "we didn't think of that" and ignore it or do they say "nice try" and fix it in the next patch?
For the big serious exploits like knowingly running a program like ShowEQ it largely about how the community and VR react. If the community takes a zero tolerance view and snitches on cheaters and VR takes a zero tolerance view and consistently enforces cheating as a bannable offense, then perhaps the risk vs reward tips significantly so that fewer people will cheat. Combine a high chance of getting caught and punished with, as others have said, reducing the benefit/reward to the cheater and this problem mostly is under control.
We have to trust that this isn't Brad and company's first rodeo. The VR team fully understand what cheating does to a game and how it impacts the vast majority of its paying customers.
Will chime in here once - read most of it but not all of it (man that's a lot of data to parse! Good discussion).
In other form of industry I work in where we need to protect the client/server relationship when it comes to client data we simply provide a one-time modifier that is generated by the server that must be used by that user client session only. Every packet and every process is then obfuscated off of that modifier for that session/data to be considered valid from the user by the server. The time to break the obfuscation is longer than any one person would be interacting with the client/server for that session. This way of protecting system processes/network traffic is generally much faster than encryption and offers similar protection for a limited duration.
I have no idea if this type of thing can be applied to game design (note - I am not a game designer), but if it could this might provide the level of protection people are looking for without the invasive checks or performance degradation in encryption overhead when it comes to system modifcations in the memory and packets.
If someone wanted to defeat the obfuscation they would need to calculate based on that session/client for every user. Just make sure the calculation to break it would take longer than an average session would be (I doubt people would be in a game for longer than 24 hours in a single go) and if they do stay longer make them log out and back in again.
Logging in would take longer for sure (15-30 seconds longer maybe). No idea if this would even be applicable in game design or even if it could be used without redesigning the client which may just be unrealistic at this point.
edit: spelling ftw
skotch said:Will chime in here once - read most of it but not all of it (man that's a lot of data to parse! Good discussion).
In other form of industry I work in where we need to protect the client/server relationship when it comes to client data we simply provide a one-time modifier that is generated by the server that must be used by that user client session only. Every packet and every process is then obfuscated off of that modifier for that session/data to be considered valid from the user by the server.
This is usually a real encryption (called stream encryption) with a shared key, rather than just an obfuscation, and yes it is widely used in games as well. However, trusting that just because a packet was properly signed/encrypted/etc does NOT necessarily mean it wasn't tampered with. With DLL injection, a cheater can stuff custom-made packets into the encryption pipeline (e.g. Glider for WoW) or the key could be extracted from local memory and the network traffic tampered with (e.g. ShowEQ and MQ2 for EQ1).
Rendall said:Sadly the more this is openly discussed about , the more peoples will want to know and give it a go.
I agree but I'd argue that is a good thing, especially this early in the process. During alpha & beta, these kinds of issues should be discovered, filed as bugs, and fixed before release. No matter how good the devs are, there WILL be mistakes that will be exploitable. The more we can fix before release, the better!
Celandor said:Exploits take many forms. There's the "big stuff" like ShowEQ but then there are also players just finding creative ways in-game to circumvent intended game mechanics.
Every game will have exploitable mechanics, unfortunately. The more we can find & fix them in alpha & beta, the better, but this is one of those times when the devs & community need to be ever-vigilent.
Bots and 3rd-party clients fall into the same bucket as ShowEQ: they can give a huge advantage when used but can be difficult or impossible to detect. Let the cat & mouse game of local-cheat-detection begin! (see Blizzard's Warden or Steam's VAC).
There is a huge class of hacks that CAN be prevented by doing everything on the server instead of trusting the client. That is much easier said than done, which is why EVERY MMORPG has gotten it wrong to some extent. It needs to be thought about, planned for, and tested constantly. There are things like Security by Design Principles to guide the early design so that you don't hit combinatorial explosions.
To reuse my earlier example, a protocol that allows the client to send a message like "Move to (x,y,z)" vs. "Turn to angle x and go forwards". These are both perfectly valid designs, but the former has a much larger attack surface and requires far more work on the server to validate: it has factor in pathing among moving objects, speed changes, and dozens of other things and exploits take the form of speed hacks, flying, no-clip, etc. The latter has a really small attack surface (changing heading). Usually characters in an MMORPG don't have limited turn speed so that isn't even really exploitable. Even if turn speed is limited, the verification check on the server is a 1D bounds check instead of a 3D motion/pathfinding problem!
skotch said:
Rendall said:Sadly the more this is openly discussed about , the more peoples will want to know and give it a go.
I agree but I'd argue that is a good thing, especially this early in the process. During alpha & beta, these kinds of issues should be discovered, filed as bugs, and fixed before release. No matter how good the devs are, there WILL be mistakes that will be exploitable. The more we can fix before release, the better!
Indeed, I was not talking about in game mechanic coding issue these of course need to be fixed.
Rendall said:Sadly the more this is openly discussed about , the more peoples will want to know and give it a go.
Shining a spotlight on security problems is the absolute best way to work toward resolution. Security through obscurity is a weak defence, one which is easily circumvented. Building with security at the core of the design is always the preferred route. Anything you bolt on later is usually going to be less efficient or more easily co-opted. I don't know much about the way game client design works, especially with Unity, but I suspect there are APIs and limited choices available to the VR devs. Some of these concepts may have to be addressed/embraced upstream by the Unity team. I'll have to leave that to the experts.
So far as more people wanting to try to hack Pantheon because we're discussing this in the forum, that's where the diligence of the server community and the willingness of the VR time to consistently ban offenders comes to play. If there are big deterrents, the idly curious will go back to behaving themselves. Most of us won't do it because it's cheating and we're not cheaters.
I remember a post on the World of Warcraft forums that asserted that, based on information they had collected, that suspensions were a more effective way of deterring cheaters than bans because it lowered the rate of reoffense. I don't know the specifics but it's worth investigating.
At the end of the day, people have to realize that a very small number of people will probably slip through the cracks, but look at it this way.
You have ShowEQ, MacroQuest 2, etc. floating around. The most common forms of cheating in EQ. Both of these things have some things in common, which is that they are developed by an external entity and are simple and intuitive to set up and use. Due to these factors, it is basically impossible to control without making systemic (and expensive) changes to the game, something that just isn't feasible any way you slice it. The number of players actually capable of cheating in some meaningful way on their own is ridiculously small, though.
As long as it isn't extremely prevalent, it shouldn't be hard to prevent most of it by just having people proactively reporting cheaters while the staff at VR proactively listens to the playerbase and deals with these things swiftly and heavy handedly.
I'm sure that the devs of Pantheon are keenly aware of all of this, considering that most of them have probably played EQ and are aware of its flaws to begin with. They'll figure it out.
zynn said:This is usually a real encryption (called stream encryption) with a shared key, rather than just an obfuscation, and yes it is widely used in games as well. However, trusting that just because a packet was properly signed/encrypted/etc does NOT necessarily mean it wasn't tampered with. With DLL injection, a cheater can stuff custom-made packets into the encryption pipeline (e.g. Glider for WoW) or the key could be extracted from local memory and the network traffic tampered with (e.g. ShowEQ and MQ2 for EQ1).
I was thinking of was a software based stream cipher - when it comes to DLL's maybe it's just me that checks internal processes/data as I don't even trust my own program from step to step :)
skotch said:Will chime in here once - read most of it but not all of it (man that's a lot of data to parse! Good discussion).
Every packet and every process is then obfuscated off of that modifier for that session/data to be considered valid from the user by the server.
This only works to protect MITM attacks. You cannot trust the client, it's trivial to create an injection attack to get that key. With slightly more effort you can have the client decrypt it all for you and not even have to deal with it all. In terms of "the more we post, the more 'they' know", nonsense. The people who do this know what they're doing, nothing we say here will be new to them. Now for everyone who hasn't done this or doesn't know how it works that may want to figure it out: go for it (but beware, the banhammer is real in most games, you better get it right). The more knowledge out there on this, the more likely they will get fixed and we can play the game we want to play.
I would compare this to tax avoidance. People get upset when they hear so-and-so uber large company isn't paying taxes, and claim they are cheating. Usually they are not, usually they are following the law. It's the law that's broken (probably intentionally, but politics). The same for cheats: they find broken design choices and exploit them. The sooner its public knowledge, the faster it gets fixed.
Tralyan said:Ya'll make me wish I, like, knew stuff.
But yeah. Cheaters R bad.
ya.. you can stop most cheating by a shadow system but the client still needs to have the area data for the character you play...
being good is close to know what's coming
though.. as computer power, connections and game play evolve, some aspects require less resources compared to others, opening up avenues not considered before.
skotch said:Will chime in here once - read most of it but not all of it (man that's a lot of data to parse! Good discussion).
In other form of industry I work in where we need to protect the client/server relationship when it comes to client data we simply provide a one-time modifier that is generated by the server that must be used by that user client session only. Every packet and every process is then obfuscated off of that modifier for that session/data to be considered valid from the user by the server. The time to break the obfuscation is longer than any one person would be interacting with the client/server for that session. This way of protecting system processes/network traffic is generally much faster than encryption and offers similar protection for a limited duration.
I have no idea if this type of thing can be applied to game design (note - I am not a game designer), but if it could this might provide the level of protection people are looking for without the invasive checks or performance degradation in encryption overhead when it comes to system modifcations in the memory and packets.
If someone wanted to defeat the obfuscation they would need to calculate based on that session/client for every user. Just make sure the calculation to break it would take longer than an average session would be (I doubt people would be in a game for longer than 24 hours in a single go) and if they do stay longer make them log out and back in again.
Logging in would take longer for sure (15-30 seconds longer maybe). No idea if this would even be applicable in game design or even if it could be used without redesigning the client which may just be unrealistic at this point.
edit: spelling ftw
Yeah. I mentioned something similar ion the other, now locked, thread. It's basically a "one time pad" encryption key.
zynn said:skotch said:Will chime in here once - read most of it but not all of it (man that's a lot of data to parse! Good discussion).
In other form of industry I work in where we need to protect the client/server relationship when it comes to client data we simply provide a one-time modifier that is generated by the server that must be used by that user client session only. Every packet and every process is then obfuscated off of that modifier for that session/data to be considered valid from the user by the server.
This is usually a real encryption (called stream encryption) with a shared key, rather than just an obfuscation, and yes it is widely used in games as well. However, trusting that just because a packet was properly signed/encrypted/etc does NOT necessarily mean it wasn't tampered with. With DLL injection, a cheater can stuff custom-made packets into the encryption pipeline (e.g. Glider for WoW) or the key could be extracted from local memory and the network traffic tampered with (e.g. ShowEQ and MQ2 for EQ1).
Rendall said:Sadly the more this is openly discussed about , the more peoples will want to know and give it a go.
I agree but I'd argue that is a good thing, especially this early in the process. During alpha & beta, these kinds of issues should be discovered, filed as bugs, and fixed before release. No matter how good the devs are, there WILL be mistakes that will be exploitable. The more we can fix before release, the better!
There are way to help mitigate the DLL injection, such as signed components and application hashes, but they're all just really "stop-gaps". If someone REALLY wants to cheat they will find a way. The only thing you can really do is make it "unprofitible". Security is like an onion. To be truely effective, it must be in layers. You can never completely get rid of cheating. All you can do is mitigate it as much as possible.
DLL injection.. I suddenly think of the Windows File Protection system (it talks of XP, but it's in W10 too)
This is NOT recommended, but the client sould have it's own mechanism.
From what I've been reading over on a very well known reverse engineering for games forum (some of you will know exactly what I'm talking about) WoW just released obfuscated binaries for WoW, along with other measures that were already mentioned previously in this post, in order to combat botters and cheaters.
It seems like it has really stirred up some commotion in the botting community, specifically the big named ones who are struggling to release updates even before the new chage, due to offsets constantly changing.
It's truly just a game of cat and mouse...