5 ms·
The article is missing the most interesting part, for me at least: how the bug worked. Not from the outside (the article has the sequence of steps to exploit th
by cesarb 12y ago
The article is missing the most interesting part, for me at least: how the bug worked. Not from the outside (the article has the sequence of steps to exploit the bug), but from the inside. What change in the control flow the "Double Up" feature did which caused it to remember the previous payout and multiply it by the new denomination?
- minimaxir 12y agoHypothetically, if pressing DoubleUp forces a recalculation of the payout immediately, that would create a vector for a timing bug.
- cesarb 12y agoFrom what I could gather from the article, the bug happened even if the user never used the Double Up feature. But the bug disappeared if that feature was disabled. My guess would be that, for the Double Up feature to work, the program saved some state (or delayed clearing that state), so it could double the payout (I'm guessing that the "Double Up" feature is something used after a win, something like "flip a coin to choose between 2x or 0x payout"). Some other part of the program expected that state to be cleared. Without the Double Up feature enabled, the code skipped saving that state (or cleared the state earlier), which is why disabling that feature prevented the bug. That is, something like the classic "MissingNo." bug in Pokémon, where there was a strip of terrain which didn't setup the random encounter table, and the space for that table was also used as temporary space to copy the player's data during an event in the game. Trigger that event, go to that strip of terrain, walk until you get a random encounter, and what was on the player data is used as the encounter data.