Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Diablo III Economy Broken by an Integer Overflow Bug

minimaxir.com

Post reply on HN
Print view View original

111–120 of 129 posts

Re: Diablo III Economy Broken by an Integer Overflow Bug

#111

Post by EvilLook »

scrollbar wrote: post #103
EvilLook wrote: post #90

Earlier quoted context omitted.

Not any more than SimCity 2013 was an MMO. There may have been free-to-play MMO-like monitization of every little thing but the game mechanics are all single-player/small-group-of-players.

No, Asheron's Call was an MMO in every sense of the term. There was no free to play (at least in the pyreal scarab bug time period), monthly sub fee was it, and the game would have been wholly uninteresting without the full on massively multiplayer element.

Sorry, I was unclear. I was talking about Diablo III in my original comment and about it not having an offline mode or a mode where online play could be had on non-Blizard official servers (either dedicated server model or peer-to-peer).

Re: Diablo III Economy Broken by an Integer Overflow Bug

#112

Post by astrodust »

mckilljoy wrote: post #79
astrodust wrote: post #45

It is odd that they're using 32-bit numbers when you'd be hard pressed to find a 32-bit only CPU and machines with over 4GB of memory are the standard. Good luck overflowing a 64-bit unsigned.

I don't find it that odd. 32-bit applications are still very common, if not the standard. Most processes don't need more than 4GB. More importantly, blindly increasing all of your 32-bit integers to 64-bit is going to double your memory usage, and ultimately just mask the real issue (i.e. improper bounds checking).

It's not about blindly increasing it, but using "long long" where normally "long" would be used, especially for values that have the possibility of wrapping.

The real impact on memory usage is likely the 8-byte pointers, but if you have a non-trivial amount of memory, it's rarely an issue worth fretting about.

If we cared about pointer sizes, we'd still be writing 16-bit code.

Re: Diablo III Economy Broken by an Integer Overflow Bug

#113

Post by TwoBit »

Jabbles wrote: post #57
mikevm wrote: post #56

The scary thing is that integer overflows are considered rare so unlike things like null-pointer dereference no one really checks for them (heck, it seems impractical checking for it). In this case, how should they defend against an overflow? Impose an arbitrary limit on gold?

Use 64 bit integers everywhere.

Why not 128 bit integers.

Re: Diablo III Economy Broken by an Integer Overflow Bug

#114

Post by astrodust »

lucian1900 wrote: post #52
astrodust wrote: post #43

Earlier quoted context omitted.

Long-scale should be officially retired, it's needless. Keep rocking with fortnights and stone if you must, nobody else is laying claim to those. It's things like having three different "gallons" that all mean wildly different things that make communication difficult.

Or perhaps short-scale should be retired instead, since pretty much all other languages use long-scale anyway.

Short's as much as a standard and pairs well with SI units. Long's an anachronism in comparison.

Re: Diablo III Economy Broken by an Integer Overflow Bug

#115

Post by mckilljoy »

UnoriginalGuy wrote: post #89
mckilljoy wrote: post #82

Earlier quoted context omitted.

Depends on the situation. I assume this was probably a server side bug, since all the accounting would never be trusted to the client side. If you are writing highly-performant server code, the actually memory size is extremely important. You cannot (should not) abstract away the machine specifics of the datatype if you want to write optimized code. In some cases where the underlying datatype isn't a concern (e.g. Ja…

Most servers are x86-64 these days. So using 32 bit signed ints barely improves performance at all. Could have gone with a 64 bit unsigned int as it is a positive value all of the time.

A x64 CPU will take a single instruction to operate on a both a 64-bit and 32-bit integer, and the CPU registers are all 64-bit, so in that context you are right that it doesn't matter that much between the datatypes.

However, the physical size of the integer as stored in the CPU cache, RAM, and HDD is still going to be 2x as big for a 64-bit integer. In a hypothetical worst case, you are cutting your CPU cache and memory bandwidth in half, which is tragic.

Additionally, while most physical servers are x64, the OS, server software, and virtualization layer is still often 32-bit -- maybe for legacy, maybe for performance, maybe for a lot of reasons. Upgrading that whole stack up to 64-bits just for the luxury of having default 64-bit integers seems misguided.

Re: Diablo III Economy Broken by an Integer Overflow Bug

#116

Post by csense »

unwind wrote: post #5
ebbv wrote: post #2

420,081,335,014 is 420 billion not 420 trillion.

English is handy enough to have two "scales", where these words have different meanings. In the short scale, you'd be right, but the author probably uses the long scale. See http://en.wikipedia.org/wiki/Long_scale#Comparison . It's one of those things that makes English ... interesting to learn as a foreign language. :) EDIT : Actually no, I mis-read the table on the Wikipedia page. The author was simply mistaken, an…

I'm a native English speaker (USA) with lots of math and science education, and I'd never heard of the long scale until you posted this article.

It sounds so strange. Are you sure this isn't another Wikipedia hoax masterminded by Stephen Colbert?

Re: Diablo III Economy Broken by an Integer Overflow Bug

#117

Post by mckilljoy »

astrodust wrote: post #112
mckilljoy wrote: post #79

Earlier quoted context omitted.

I don't find it that odd. 32-bit applications are still very common, if not the standard. Most processes don't need more than 4GB. More importantly, blindly increasing all of your 32-bit integers to 64-bit is going to double your memory usage, and ultimately just mask the real issue (i.e. improper bounds checking).

It's not about blindly increasing it, but using "long long" where normally "long" would be used, especially for values that have the possibility of wrapping. The real impact on memory usage is likely the 8-byte pointers, but if you have a non-trivial amount of memory, it's rarely an issue worth fretting about. If we cared about pointer sizes, we'd still be writing 16-bit code.

At the time the original code was written, it wasn't possible for a 32-bit integer to overflow, which is presumably why they didn't use 64-bit. That possibility was only introduced in the patch, and no one caught the bug that came with it.

Running 64-bit would have "prevented" this bug simply by virtual of that fact that the default datatype would have been big enough to avoid overflow, but it isn't really a solution. I just find 32-bit vs. 64-bit to be inconsequential to the real mistake, which was an improper software development process.

Re: Diablo III Economy Broken by an Integer Overflow Bug

#118

Post by mckilljoy »

kabdib wrote: post #98
mckilljoy wrote: post #79

Earlier quoted context omitted.

I don't find it that odd. 32-bit applications are still very common, if not the standard. Most processes don't need more than 4GB. More importantly, blindly increasing all of your 32-bit integers to 64-bit is going to double your memory usage, and ultimately just mask the real issue (i.e. improper bounds checking).

The actual money fields are probably small compared to the infrastructure used to track them. It's not going to double the amount of memory usage. I'd be surprised if memory use, network traffic and database I/O went up by more than a percent or two.

I agree for this one integer, they obviously should have been using 64-bit. I just take issue with the implication that Blizzard is somehow at fault or unusual for (presumably) not running a 64-bit stack.

They made a mistake for sure, but 32-bit vs. 64-bit architectures should not be on trial.

Re: Diablo III Economy Broken by an Integer Overflow Bug

#119

Post by FullyFunctional »

specialist wrote: post #60
lmm wrote: post #3

Just another reminder that it's never worth bypassing the normal deployment process. Every year or two I learn a similar lesson myself: it's so tempting, the fix is so small, it couldn't possibly break anything (heck, I once had a data-gathering script that made a bunch of read-only calls to our system's API cause a live issue). Just say no.

Hmmm. I dunno. Why wouldn't currency by handled by the type system? You could still have an overrun. But it'd be handled more appropriately. Long ago, I wrote a budgeting / estimating tool. Costs were represented with binary coded decimals (BCDs). Not floating point numbers. Just like an accounting system. Competing products could have weird roundoff errors. Not mine.

For accounting, why not just use scaled integers? Isn't there a limit to many many digits you want after the period? BTW, I think BCD is outmoded. Seems it's getting replace by DPD which has far less overhead (http://en.wikipedia.org/wiki/Binary-coded_decimal#Higher-den...).

Re: Diablo III Economy Broken by an Integer Overflow Bug

#120

Post by mickeyp »

Luyt wrote: post #107
mickeyp wrote: post #24

Earlier quoted context omitted.

Those games (Frontier Elite and First Encounters included) had loaaads of bugs like that. Another one in FE had you put in passenger holds, fill them with passengers, then sell the holds -- this would obviously not work as you had to evict the passengers first, however the game logic credited you with the cash anyway because the check came after the money had changed hands.

The amount of cash you had was stored in savegame files as 4 bytes. A few changes with a binary editor and suddenly you had millions of cash ;-)

Yeah but that's true of most things that're not obfuscated. I used to use the Amiga Action Replay on my Amiga to alter memory on the fly in games like that.
Post reply on HN