strange games

[RicardoRix]

I'm guessing there was zero checks done server side on the client ajaxcalls. So the player could continue and stop whenever they liked. But yes, this still doesn't explain how they were able to stop the immediate loss, especially without seeing anything dodgy in the replays.

[robinzig]

Yes, it's all still a bit of a mystery, that clearly I'm not the only one waiting for the answer to. And we were promised it a couple of weeks ago

Once it has been fixed and deployed, we'll post the solution to the mystery.

[voriki]

Yes, it's all still a bit of a mystery, that clearly I'm not the only one waiting for the answer to. And we were promised it a couple of weeks ago

Once it has been fixed and deployed, we'll post the solution to the mystery.

We did get the answer.

We have deployed a new release this morning with a patch for this issue.

What it was NOT:
- it was not an issue with the random number generator (RNG)
- it was not a security issue allowing to inject the desired values.

What it was:
- it was a specific use case where a player could prevent an immediate loss, and allow the player to just re-roll.
- it was pretty specific, and has been limited to Can't stop / Dörte; it seems that Dörte was clever enough to notice this use case, understand how it could be exploited, and use it. In a way, it was really intuitive and clever from her. Ironically, she had found a case where she literally... "Couldn't Stop".

Not sure what happened, as obviously they can't go into too much specifics how they did it. You roll the dice, and when you're supposed to go bust, it sends this message to the server, somehow. And your rolls stop.
But they were able to stop the message to the server that they went bust, and could continue to roll.

[RicardoRix]

But they were able to stop the message to the server that they went bust, and could continue to roll.

The server decides you went bust. There is no message. But without seeing the source code it's impossible to definitely say.

The only message you can send to the server are the same as any of the button controls you see. 'Continue' / 'Stop' / 'I choose these rolls'.

When the client sees that they go bust, this is a message from the server, and is just an animated effect being displayed, the state of the server is already that they went bust and play passes to the next player.

[robinzig]

We did get the answer.

We have deployed a new release this morning with a patch for this issue.

What it was NOT:
- it was not an issue with the random number generator (RNG)
- it was not a security issue allowing to inject the desired values.

What it was:
- it was a specific use case where a player could prevent an immediate loss, and allow the player to just re-roll.
- it was pretty specific, and has been limited to Can't stop / Dörte; it seems that Dörte was clever enough to notice this use case, understand how it could be exploited, and use it. In a way, it was really intuitive and clever from her. Ironically, she had found a case where she literally... "Couldn't Stop".

Not sure what happened, as obviously they can't go into too much specifics how they did it. You roll the dice, and when you're supposed to go bust, it sends this message to the server, somehow. And your rolls stop.
But they were able to stop the message to the server that they went bust, and could continue to roll.

I disagree, this wasn't an answer, it was just an update that the issue had been fixed. And since we trust that it had been fixed, I don't think it's "obvious" at all why they can't go into specifics. Obviously they wouldn't want to give instructions on how to exploit the vulnerability while it was still active, but that has gone away if it has been fixed.

Unless of course the same issue might exist in other games (although that possibility seems to be discounted in the last point of Een's message quoted). You see, apart from sheer curiosity, one of the main reasons I want to know what was up here is that, if this issue had lain undetected for years until one player decided to exploit it pretty constantly (who knows how many others might have been exploiting it too, but infrequently enough to evade suspicion), there's probably a fair chance that whatever subtle mistake was made by whoever coded Can't Stop might be repeated, with similar consequences in other games. So I would like to see something shared for the education of the growing BGA developer community as well (although this forum obviously isn't the place for that).

It's common in the online security field, when vulnerabilities are discovered in commonly-used software libraries/frameworks, for these to be publicised once they are fixed. Without understanding the details of how attackers (in this case, unscrupulous players) do things they shouldn't be able to, developers can easily be oblivious of these issues and end up repeating the same mistakes.

As for the technicalities of this particular case, I agree with Ricardo - even with the semi-explanations given so far, I'm completely at a loss to know how this was done. While I haven't looked at the code for Can't Stop, what I am sure happens (and would have been picked up straight away when BGA looked at the code, had this not been the case), is that when the user presses the button to reroll the dice, the server in the space of that one request does all of:
1) rerolls the dice
2) if bust, removes (in the game database) the player's progress and proceeds to the next player's turn
3) sends notifications to the client side about all of this

Notably, 3) would notify all players as well as any spectators, so there's no way a player could manipulate anything here that would keep the other players oblivious of any "funny business". The exploit presumably involves affecting 2) somehow, but I don't see how that could be possible without injecting code into the server side, which we're told it was not. (And, were it possible, would likely be a major security issue across all games, not just this one.)

About the only thing I can think of would be if the developer perhaps put in for debugging purposes an additional request parameter which made the dice always reroll until not going bust, and this was left in the production version somehow and the player concerned here discovered it. That seems unlikely though - it would have come out loud and clear from a casual inspection of the requests, and from how this developed we know that the BGA team initially saw nothing suspicious from looking at the requests.

But the only way to stop me speculating is for the answer to be revealed!

[dschingis27]

I think that giving the details about the cheating method and the solution against it would only challenge some dedicated nerds to find a way around it.
So while my curious brain is also not satisfied, I can fully understand that the details are kept secret.

[BenInJapan]

I think that giving the details about the cheating method and the solution against it would only challenge some dedicated nerds to find a way around it.
So while my curious brain is also not satisfied, I can fully understand that the details are kept secret.

If that would be true that would be horrible, because that would mean the problem has not been fixed but only circumvented, and somebody will find the way around sooner or later anyways, probably without anyone noticing...

Best solution here really would be to disclose the problem, that way basically anybody can verify that the fix really solves the problem and no more cheating utilizing this flaw will be possible any more. Also, if the problem has been fixed properly, there's absolutely no risk in disclosing.

[frogstar_A]

From the way it was written I think robinzig is correct and that some debugging or test code was left in that Dorte accidentally discovered how to use.

Any of us that have programmed games know this kind of think - you program it so that if you press a certain combination of buttons before you roll it makes the option “roll again” appear even when you are bust. Kind of like a video game cheat.

Then you release the game but leave it in accidentally - oops.

[robinzig]

From the way it was written I think robinzig is correct and that some debugging or test code was left in that Dorte accidentally discovered how to use.

Any of us that have programmed games know this kind of think - you program it so that if you press a certain combination of buttons before you roll it makes the option “roll again” appear even when you are bust. Kind of like a video game cheat.

Then you release the game but leave it in accidentally - oops.

Although I did speculate that this may be the cause, I also ruled it out in the same post. Because if this was the case, the BGA team would easily have discovered this by inspecting the requests (for reasons I don't understand, game actions are implemented on BGA as GET requests rather than POST so it would just take casual inspection of the request URL to discover an unusual parameter). And if you follow the whole thread, you'll see that at one point the BGA team, having been alerted by this thread, inspected this player's activity, including requests, and initially concluded there was nothing to see. Only some later detective work, of a so-far unspecified kind, apparently revealed what was going on.

But thanks for keeping this thread alive, so I can ask Een for the explanation again

[Mr_Magic]

Did any more info come to light on this at all?