Slashdot Mirror
Integer Overflow Bug Leads To Diablo III Gold Duping
Nerval's Lobster writes "Online economies come with their own issues. Case in point is the Auction House for Diablo III, a massively multiplayer game in which players can pay for items in either in-game gold or real-world dollars. Thanks to a bug in the game's latest patch, players could generate massive amounts of virtual gold with little effort, which threatened to throw the in-game economy seriously out of whack. Diablo series publisher Blizzard took corrective steps, but the bug has already attracted a fair share of buzz on gaming and tech-news forums. 'We're still in the process of auditing Auction House and gold trade transactions,' read Blizzard's note on the Battle.net forums. 'We realize this is an inconvenience for many of our players, and we sincerely apologize for the interruption of the service. We hope to have everything back up as soon as possible.' Blizzard was unable to offer an ETA for when the Auction House would come back. 'We'll continue to provide updates in this thread as they become available.' Diablo's gold issue brings up (however tangentially) some broader issues with virtual currencies, namely the bugs and workarounds that can throw an entire micro-economy out of whack. But then again, 'real world' markets have their own software-related problems: witness Wall Street's periodic 'flash crashes' (caused, many believe, by the rise of ultra-high-speed computer trading)."
It seems likely the gold duping was due to a simple integer overflow bug. A late change added to the patch allowed users to sell gold on the Real Money Auction House in stacks of 10 million rather than stacks of 1 million. On the RMAH, there exists both a cap ($250) and a floor ($0.25) for the value of auctions. With stacks of 1 million and a floor of $0.25, a seller could only enter 1 billion gold (1,000 stacks) while staying under the $250 cap. When the gold stack size increased, the value of gold dropped significantly. At $0.39 per 10 million, a user could enter values of up to 6.4 billion gold at a time. Unfortunately, the RMAH wasn't designed to handle gold numbers above 2^31, or 2,147,483,648 gold. Creating the auction wouldn't remove enough gold, but canceling it would return the full amount.
And this class, is why we use explicit type casting and do sanity checks (checking limits) prior to processing. Now, if you'll look on your screens, you'll see another example of this. Here is a failed mission to Mars, caused because the wrong unit of measurement was put into the computer, a problem caused by the lack of the human brain's compiler to make use of any data type except 'variant' and 'object'... So, what have we learned?
#fuckbeta #iamslashdot #dicemustdie
I remember the day when you could strip the gear off anyone playing a multiplayer game with the trainer. I usually used it on jerks who came in collecting ears. If someone came in you could quickly look at their inventory and if they had several ears you could clear out their inventory and gear. They wouldn't know visually until they tried to hit you at which time they would be completely naked. It was really fun when they re-spawned and came back to loot their body and you started dropping some of the ears they collected on the ground.
You couldn't be more wrong. Signed ints are usually the best way to go in C/C++.
>in C an unsigned int must behave in a very predictable manor
"unsigned int x = -3;" generates no compile errors or warnings.
If you don't believe me, listen to the creator of C++ (Bjarne Stroustrup):
"The unsigned integer types are ideal for uses that treat storage as a bit array. Using an unsigned instead of an int to gain one more bit to represent positive integers is almost never a good idea. Attempts to ensure that some values are positive by declaring variables unsigned will typically be defeated by the implicit conversion rules."
Integer underflow. Imagine a situation where a player has 100 gold and a bug in the code subtracts 101 gold for whatever reason. If you use a 32-bit unsigned integer, that player now has 4,294,967,295 gold. A 64-bit unsigned is even worse, of course.
A simple if statement would catch this as well, right? But think of how often you do addition and subtraction (and everything else) throughout your code! Do you put an if around each one? Can you handle the error situation in each case? How do you ensure that you found every addition and subtraction, including future changes?
A better solution is to make a Money class with well-defined operations, and throw an exception if you try to exceed the boundaries. Sounds easy ... but it has to be flexible enough to handle all situations (the class has to be used for all intermediate values -- it's no good to resort to an int, where problems might come back) while still being robust. ("I know, I'll use a class!" ... now you have two problems. "I know, I'll use exceptions!" ... now you have three.)
This is not an easy problem to solve for non-trivial software, which is why bugs like this come up periodically.
Actually, he's not wrong at all. He said signed integers don't behave in a very predictable manner, and he's right. Signed integers have undefined (actually, to be more precise, implementation-defined) behavior for mod and div of negative values. You cannot be sure whether -4 / 3 is -1 or -2, without knowing how your compiler implements it. Some round toward zero, others toward negative infinity. Recent drafts of C++ are trying to fix this.