Hai nyit-nyiters mania, Setelah membaca kasus di China, ditangkap karena cheaters berjualan cheat Please sign in/up to view this image/link disebuah website jual/beli yaitu TaoBao. Penjual ditangkap dan diberi hukuman beberapa tahun. Namun hari ini ribuan lainnya muncul sebagai sifat manusia yang berkompetitif dalam mencari nafkah. Di tangkap 1, muncul yang lain, ditutup 1, timbul sifat berontak. Itu alami dan benar-benar terjadi. Berikut adalah fakta hubungan antara cheaters dan sebuah game publisher. Baik itu online ataupun offline dalam bahasa Inggris: Rule #1: If you build it, they will come -- to hack and cheat. Rule #2: Hacking attempts increase with the success of your game. Rule #3: Cheaters actively try to keep developers from learning their cheats. Rule #4: Your game, along with everything on the cheater's computer, is not secure. The files are not secure. Memory is not secure. Services and drivers are not secure. Rule #5: Obscurity is not security. Rule #6: Any communication over an open line is vulnerable to interception, analysis, and modification. Rule #7: There is no such thing as a harmless cheat or exploit. Cheaters are incredibly inventive at figuring out how to get the most out of any loophole or exploit. Rule #8: Trust in the server is everything in a client-server game. Rule #9: Honest players would love for a game to tip them off to possible cheating. Cheaters want the opposite. Remember: The Client Is Always Right, this is the problem and we call it on Cheating classifications: - Reflex augmentation - Authoritative clients - Information exposure - Compromised servers - Bugs and design loopholes - Environmental weaknesses itu hanya rangkuman point dari N3. Lebih lengkap silahkan baca Please sign in/up to view this image/link Saya akan paste disini supaya bisa dibaca dan dipahami oleh para publisher. How to Hurt the Hackers: The Scoop on Internet Cheating and How You Can Combat It I had planned to begin this article by sharing my own true experiences with online cheating as it pertained to a particular game. But I think the long version of my story would cast an unnecessarily negative light on the game and the company that made it. And since the developers are good friends of ours, I'll stick to the short version that goes like this. Last year I became hooked on a certainfirst-person shooter (FPS) game. After a couple months of addictive online gaming, I became convinced that some players were cheating and things suddenly changed that day. I was ready to walk away from the game in disgust and tell everyone else to do the same. Instead, I decided it was time to learn what I could about the alleged cheaters, their motivations, and most importantly their methods. In my case, I discovered at least three distinctly different methods of cheating that could explain what I experienced -- though as just a player I could not prove conclusively which methods, if any, were being used against me. The aim of this article is to bring the subject of online/multiplayer cheating out of the shadows and talk about it in terms of real problems with real games and to help build a framework for classifying and understanding the various details. I will cover some of the ways that players are able to cheat at various games; at times I will go into the working details, ways to prevent those cheats, and limitations of various game architectures as they relate to multiplayer cheating. This is by no means a comprehensive and exhaustive tome on the issue, but it is a start. There is a serious lack of information on this subject, and paranoia among developers that talking about it will reveal secrets that will only make the problem significantly worse. Several individuals at various companies declined to talk to me about cheating and their games for this and other similar reasons. I respect that, but I think developers have everything to gain by sharing our knowledge about cheaters and how to combat them. Just how seriously should you as a developer take the possibility of online cheating? If your game is single-player only, then you have nothing to worry about. But if your game is multiplayer only, the success of your entire product is at stake. If your game does both, you're somewhere in the middle. As more games are released with online play as an integral component, drawing ever-larger audiences (and the corollary development of online communities and sites based around the game), it becomes ever more important to insure that each online game player experiences what they believe to be a fair and honest experience. I'm reminded of a quote from Greg Costikyan's excellent report, "The Future of Online Gaming" ( Please sign in/up to view this image/link ): "An online game's success or failure is largely determined by how the players are treated. In other words, the customer experience -- in this case, the player experience -- is the key driver of online success." Our short version is, "Cheating undermines success." Consider the well-known case of Blizzard's Diablo -- deservedly a runaway best-seller and great game that acquired a significant reputation for a horrible multiplayer experience because of cheaters. Many people I know either refused to play it online, or would only play over a LAN with trusted friends. Blizzard did their best to respond, patching it multiple times, but they were fighting an uphill battle. Cheating hit closer to home for me while I was working on the final stages of Age of Empires II: The Age of Kings. Cheating online became a widespread problem with the original Age of Empires. Tournaments had to be cancelled due to a lack of credibility, the number of online players fell, and the reputation of my company took a direct hit from frustrated users. Unable to spare the resources to fix the game properly until after Age of Kings was done, we just had to endure our users turning their anger upon us -- probably the most personally painful thing I've experienced as a developer. What about your next game? This is a good time to introduce my first two rules about online cheating: Rule #1: If you build it, they will come -- to hack and cheat. Rule #2: hacking attempts increase with the success of your game. Need more reasons to take online cheating seriously? Go onto eBay and type in the name of your favorite massively multiplayer game. Now look at the real money changing hands for virtual characters and items. What if those items being sold were obtained via some sort of cheat or hack? Let's not overlook the growth of tournaments and contests for online games. Consider the public relations nightmare that would ensue if the winner of a cash prize in a tournament had cheated. Enough to give you a headache, eh? Understanding the Hackers and Cheaters The sad truth is that the Internet is full of people that love to ruin the online experiences of others. They get off on it. A great many cheaters use hacks, trainers, bots, and whatnot in order to win games. But while some openly try to wreak havoc, many really want to dominate and crush opponents, trying to make other players think they are gods at the game -- not the cheaters they are. The only thing that seems to bother them is getting caught. Beyond that, no ethical dilemmas seem to concern them. The anonymity and artificiality of the Internet seems to encourage a moral vacuum where otherwise nice people often behave in the worst possible way. A big factor in this is a lack of consequences. If a player is caught, so what? Are they fined or punished? No. Are they rejected by the people they played against? Usually, but it's so easy to establish another identity and return to play that discovery and banishment are no barrier to those with ill intent. Another interesting aspect of online cheating is the rise of clans and how cheats get propagated. If a member of a clan hacks a game or obtains a not-readily-available program for cheating, it will often be given to other members of the clan with the understanding that it's for clan use only and to be kept secret. The purpose being, of course, to raise the standing and prestige of the clan. If the cheater is not a clan member, odds are he will keep the secret to himself for a while and not advertise his advantage. The logic here is simple: If anyone goes public with a cheat, a) he will lose his advantage, b) he will probably be identified by his opponents as a cheater, and c) the developer can then patch the game, invalidating the cheat. As a result of this secretive behavior we get to rule number three. Rule #3: cheaters actively try to keep developers from learning their cheats. Tools of the Hackers So how do they discover the hacks and create the programs to cheat at your game? Consider rule number four: Rule #4: Your game, along with everything on the cheater's computer, is not secure. The files are not secure. Memory is not secure. Services and drivers are not secure. That's right, you gave them a copy of your game when they purchased it. The hackers have access to the same tools that you had while making the game. They have the compilers, dissemblers, debuggers, and utilities that you have, and a few that you don't. And they are smart people -- they are probably more familiar with the Assembly output of an optimized C++ file than you are. The most popular tool among the hackers I surveyed was NuMega's excellent debugger, SoftIce - definitely not a tool for the wimpy. On another day, you just might be trying to hire these people. Many of them possess a true hacker ethic, doing it just to prove it can be done, but more do it specifically to cheat. Either way we get the same result: a compromised game and an advantage to the cheater. Hacking games is nothing new, it's been going on as long there have been computer games. For single-player games, it has never been an issue, since no matter what a player does with a game, he's only doing it to himself (and therefore must be happy about it). What's new is bringing the results of the hacking to other players, who never wanted or asked for it. I've lost count of the number of developers I've encountered who thought that because something they designed was complicated and nobody else had the documentation, it was secure from prying eyes and hands. This is not true, as I learned the hard way. If you are skeptical, I invite you to look at the custom graphics file format used in Age of Empires. Last year, I received a demanding e-mail from a kid who wanted the file format for a utility he was writing. I told him to go away. Three days later he sent me the file format documentation that he reverse-engineered, and asked if he missed anything. He hadn't. Thus, this is a perfect example of rule number five. Yes, I've borrowed it from cryptography, but it applies equally well here. Rule #5: Obscurity is not security. Sometimes we do things, such as leaving debug information in the game's executable, that make the hacker's job easier. In the end, we cannot prevent most cheating. But we can make it tough. We don't want effective cheating to be a matter of just patching six bytes in a file. Ideally we want hacking a game to be so much work that it approaches the level of having to completely rewrite the game -- something that goes outside the realm of any reasonableness on the hacker's part. One of biggest things we often do that makes it easier for a hacker, and thus harder on us, is include Easter eggs and cheat codes in the single-player portion of our games. Considered to be practically a requirement, they expose extralegal capabilities of our game engines and make it much easier for the hackers to locate the data and code that controls that functionality. Models of Multiplayer Communications Most online games use one of two communication models: client-server and peer-to-peer. For our discussion, the deciding factor is where game event decisions are made. If only one player's (or a separate) computer makes game event decisions or has the game simulation data, it is client-server. If all players' computers make some or all of the game event decisions, or have the full game simulation, then it's peer-to-peer. Many of the cheating methods described here are applicable to both models. Oh Look, It's the Terminator... The first type of cheat is reflex augmentation, which is when a computer program replaces human reaction to produce superior results. This type of cheating is really only applicable to games where reflexes and reaction times matter, and thus is most applicable to action games. During my FPS obsession, I believe that I encountered a form of reflex augmentation known as an aiming proxy. An FPS aiming proxy works like this: The proxy program is run on a networked computer and the player configures it with the address of the server they are going to play on. They then run the FPS game on another machine and connect to the proxy machine, which in turn connects the game to the server, acting just like an Internet packet router. The only hitch is that the proxy monitors and attempts to decode all of the packets it is routing. The program keeps track of the movements and locations of all the players the server is reporting to the game, building a simple model. When the proxy sees a Fire Weapon command packet issued by the cheating player, it checks the locations and directions of all the players it is currently tracking and picks a target from them. It then inserts a Move/Rotate command packet into the stream going to the server in front of (or into) the Fire Weapon command packet that points the player straight at the selected target. And there you have it: perfect aim without all the mouse twisting. When aiming proxies for Quake first appeared a couple of years ago, their targeting wasn't too sophisticated and didn't take into account things such as the player's field-of-view (FOV) or lag. Giveaways, such as players shooting weapons out of their backs, tipped people off that something foul was afoot. One of the first countermeasures to be developed was a server add-on that statistically identified players whose aim was too good to be true, then kicked out and banned the perpetrators. This naturally proved controversial, since some people really are "railgun gods," and the issue of possibly falsely identifying a person as a cheater was raised (and has yet to go away). And of course, the aiming proxies evolved with time. Later versions were improved to consider only the player's current FOV and compensate for lag, and added just enough randomness in their aim to stay below a server's "too good to be legit" identification threshold. This big vulnerability is summed up in rule number six. Since the proxy is not running on the same computer as the game client, definitive detection can be next to impossible. Making the development of the proxy extremely difficult then becomes a priority. Rule #6: Any communication over an open line is vulnerable to interception, analysis, and modification. One way to inhibit this form of cheating is to encrypt the command packets so that the proxies can't decode them. But there are limits to the extent that encryption can be used on communications. Most FPS games can send and receive a couple of kilobytes of data or more per player per second, and have to allow for lost and out-of-order packets. The encryption therefore has to be fast enough not to impact frame rate, and a given packet's encryption can not be dependent on any other packet unless guaranteed delivery is used. And once the encryption is cracked, the game is vulnerable until the encryption is revised, which usually involves issuing a patch. Then the hacking starts over. Another way to make life more difficult for the proxy creator is to make the command syntax dynamic. Using something as simple as a seed number that's given to the game when it connects and a custom random number function, the actual opcodes used in the communication packets can be changed from game to game, or even more often. The seed itself doesn't have to be transmitted; it could be derived from some aspect of the current game itself. The idea here is that since a proxy sees all the communications, but only the communications, the random seed is derived from something not explicitly communicated. Foolproof? No. But it's far more difficult to hack, forcing the hackers to start from scratch. If guaranteed delivery is used, another communications protection technique is to serialize each packet. Taking it a bit further, you could make a portion of the next serial number dependent on a checksum of the last packet. While there are speed issues with the delivery, it's an excellent way to make it difficult to insert or modify packets. Though reflex augmentation seems to be exclusive to FPS games, the vulnerability extends to any game where quick reflexes can make a difference and game communications can be sniffed.