Mercury confirmed what Lax reported and I wrote about yesterday. The detection that banned the botters was patched into 2.4.2, not into Warden. He wrote that he expects any Glider or Innerspace user who used it between the 13th and the 20th got banned. He has also has a beta version up of Glider that circumvents the latest detection.
So let’s see… Blizzard bans on the 20th. It takes Lax one day to circumvent the new detection. Mercury has his circumvention up in two days. It’s taken all of 2 days for Blizzard’s latest detection scheme to be defeated by both of the major botting authors.
If the current trend continues of one major banwave a year, then the botters will be down for maybe four to six weeks while they level to 70. Then they’ll be able to happily bot for at least 10 months before the next major wave. All that’s standing between them and the banstick are player reports.
Don’t get me wrong, I applaud the win by Blizzard against Lax and Mercury. This is a significant setback that will certainly cost them users. They might be able to market themselves as “bot at your own risk” but people are really only going to bot if they feel they can do so safely. It doesn’t take a degree in economics to realize that this type of thing doesn’t instill oodles of confidence in Lax or Mercury. Banwaves strike at the credibility of the bot author and cause their users to rethink the whole prospect of botting.
However, I also think it greatly illustrates just how completely ineffective “client-side” detection is in the war against cheats. The client will always be the weak chain in this relationship and always be easily exploitable by cheaters. The simple fact is that a botter has free access to anything that loads into their computer’s memory. There are developer tools designed for debugging code that allow a knowledgeable user to dissect any program.
At the most basic level, it would be very easy to write a program that simply scanned known memory values for things like health, mana, nearby targets and positional data. Then, using this information simply automate keystrokes and mouse movements to make the bot act in the desired manner. This is EXACTLY what Glider does currently. The reason Glider gets caught is because it’s a known program and Blizzard can actively search for it and its behavior. If some guy wrote his own version and never distributed it, then Blizzard wouldn’t never even know to look for it.
Alternately at the other extreme, if you knew which data needed to be sent back and forth between the Client and the Server – you could write your own client. In other words, you wouldn’t even need WoW loaded at all to bot, just your own clientless bot that sent back bits of data the correct way. The advantage of such a method is that you completely eliminate the client as a detection method and you lower the resources required for a single computer to process the bot. In other words, you could have far more bots running on a single computer. While no such bot publically exists, I have seen some code snippets that indicate that significant progress on such a bot was made and that a private version existed.
Now – consider that it took TWO DAYS to circumvent the latest client-side detection. So while I applaud the success, I am disgusted that Blizzard spends such considerable effort in an area that can be so easily defeated. Understandably, you can see why I dislike how much Warden violates our privacy. It’s bad enough that we willingly give up our privacy to play the game, but what drives me nuts is that it absolutely serves no purpose. None. It stops no one for any prolonged period of time.
The only real long-term solution is SERVER side. The botters fear server side detection more than anything because the difficulty in circumventing server side detection is several magnitudes more difficult than client side. Blizzard has implemented some of these in the past (teleport hack, speed hack) to detect exploits, but they need to focus their considerable anti-cheat brain trust on things that can’t get circumvented easily.
I understand that server side detection places a bigger burden on the servers. However, computers are much more scalable then they once were AND I am not advocating monitoring every single person at every single moment. There are lots of ways to identify and selectively monitor suspicious accounts. I suspect that most botters often do so at non-peak hours as well to reduce the risk of getting player reported. It stands to reason that you can devote more server time to bot detection during these hours.
Also, I’m not saying to remove client-side detection all together. In fact, I think a strategy of frequent minor changes would be a very effective way to drive up costs for people like Lax and Mercury.
Every time something changes, they need to shut things down to figure out what is different. A very very minor change here and there to Warden every day or so would make it difficult and costly for them to keep up. In turn, it would also make them more susceptible to human error when you dropped something big on their lap since the expectation is that it’s just another minor update.
Many of their customers won’t even return to botting until a week or two has passed after a patch or Warden update. Keep updating and those customers will never feel it is safe enough to ever return to botting.
Thursday, May 22, 2008
Subscribe to:
Post Comments (Atom)
3 comments:
And you didn't even get to intermittent reinforcement techniques - grin.
As in - change warden, frequently, but most of the time in an insignificant fashion. Add or edit a comment to change the size of the program. Add a nonsense value to be transmitted here or there - with the server having a "if the number makes no sense, do such and so" routine built in that doesn't care where the number is within the whole missive. Add a random transmission/reception segment so each data string is led by an identifying code, but the order of transmission varies each change. And do this frequently. But every so often, make a significant change.
And the botters have to stop and check every single change just in case this one is significant.
Oh, I agree with your points. It's just that there are tools that haven't yet been brought into play.
And you didn't even get to intermittent reinforcement techniques - grin.
As in - change warden, frequently, but most of the time in an insignificant fashion. Add or edit a comment to change the size of the program. Add a nonsense value to be transmitted here or there - with the server having a "if the number makes no sense, do such and so" routine built in that doesn't care where the number is within the whole missive. Add a random transmission/reception segment so each data string is led by an identifying code, but the order of transmission varies each change. And do this frequently. But every so often, make a significant change.
And the botters have to stop and check every single change just in case this one is significant.
Oh, I agree with your points. It's just that there are tools that haven't yet been brought into play.
100% agreed. Keep tripping the Trip Wire. At the very least, it serves as a persistent disruptive measure and annoyance that will keep botters offline simply because they have to wait for the "All Clear!" sign from the bot authors.
Post a Comment