Page 1 of 1

Randomization in DB

Posted: Thu Oct 19, 2023 11:52 am
by winmat
Hello guys,

I have a "simple" question.

speaking with friends, and as I have read several times around the internet, we often talk about the method of randomizing shuffles.

On the internet there is talk of methods that are used by other simulators, and it is hypothesized that similar algorithms, such as "Fisher-Yates", are also used for DB.

Obviously people have a hard time understanding that the randomization of a simulator is better than a draw, even if the irl draw is more fun at times.

It is possible to clarify this aspect and know which randomization method is used by DB? (it would be ideal to make it open source so as to close all doubts once and for all).

Thank you

Re: Randomization in DB

Posted: Fri Oct 20, 2023 4:08 am
by ominous
You can't program "random"... Like... By definition.

Re: Randomization in DB

Posted: Fri Oct 20, 2023 12:48 pm
by winmat
Really Interesting... -.-"

Re: Randomization in DB

Posted: Wed Oct 25, 2023 7:26 pm
by Icarus89
Honestly, I'm kinda surprised no one answered this question.
DB must have adopted a randomization standard, so I don't see why not telling it. That would give users more trust in the platform, without compromising security (that's why there are standard).
It should be a win-win.

Re: Randomization in DB

Posted: Thu Oct 26, 2023 3:22 am
by greg503
Because who cares? At the end of the day, it's just advancing a seed. This isn't random dot org's "using the chaos of weather as the seed"

Re: Randomization in DB

Posted: Thu Oct 26, 2023 3:38 am
by Christen57
Icarus89 wrote:Honestly, I'm kinda surprised no one answered this question.
DB must have adopted a randomization standard, so I don't see why not telling it. That would give users more trust in the platform, without compromising security (that's why there are standard).
It should be a win-win.


Wouldn't telling us their randomization standard allow people to figure out how to exploit it and cheat, manipulating their coin tosses and die rolls?

Re: Randomization in DB

Posted: Thu Oct 26, 2023 4:44 am
by Genexwrecker
Christen57 wrote:
Icarus89 wrote:Honestly, I'm kinda surprised no one answered this question.
DB must have adopted a randomization standard, so I don't see why not telling it. That would give users more trust in the platform, without compromising security (that's why there are standard).
It should be a win-win.


Wouldn't telling us their randomization standard allow people to figure out how to exploit it and cheat, manipulating their coin tosses and die rolls?

^

Re: Randomization in DB

Posted: Thu Oct 26, 2023 8:32 am
by winmat
Genexwrecker wrote:
Christen57 wrote:
Icarus89 wrote:Honestly, I'm kinda surprised no one answered this question.
DB must have adopted a randomization standard, so I don't see why not telling it. That would give users more trust in the platform, without compromising security (that's why there are standard).
It should be a win-win.


Wouldn't telling us their randomization standard allow people to figure out how to exploit it and cheat, manipulating their coin tosses and die rolls?

^


Maybe a few things are getting mixed up.

What was asked is just a clarification regarding the snippet/algorithm/portion of code that concerns randomization.

Making that part known, in any program and not just on dueling books (aka open source) would improve security because since the code is within the reach of users it would allow security problems to be immediately detected (it is one of the principles that pushes developers to continue making code, open source). The matter would be different if the entire dueling book code were required (although I believe that in this case too there would be many security advantages, for the same reasons)

After that, the problem with very robust (widely used) algorithms does not arise, because those are already known and if exploits could be developed I believe that people would not exploit them on platforms like DB.

In essence there would only be advantages, including technical ones, in communicating details on the randomization method.

Finally, I believe that the advantage would also be reputational since it would mean being transparent (I'm not saying that DB isn't transparent now, but I'm saying that it would be an added value).

Re: Randomization in DB

Posted: Thu Oct 26, 2023 8:57 pm
by Christen57
winmat wrote:
Genexwrecker wrote:
Christen57 wrote:
Wouldn't telling us their randomization standard allow people to figure out how to exploit it and cheat, manipulating their coin tosses and die rolls?

^


Maybe a few things are getting mixed up.

What was asked is just a clarification regarding the snippet/algorithm/portion of code that concerns randomization.

Making that part known, in any program and not just on dueling books (aka open source) would improve security because since the code is within the reach of users it would allow security problems to be immediately detected (it is one of the principles that pushes developers to continue making code, open source). The matter would be different if the entire dueling book code were required (although I believe that in this case too there would be many security advantages, for the same reasons)

After that, the problem with very robust (widely used) algorithms does not arise, because those are already known and if exploits could be developed I believe that people would not exploit them on platforms like DB.

In essence there would only be advantages, including technical ones, in communicating details on the randomization method.

Finally, I believe that the advantage would also be reputational since it would mean being transparent (I'm not saying that DB isn't transparent now, but I'm saying that it would be an added value).


Let me see if I understand what you're asking. You want users to be able to see the code that determines randomization so users would then be able to find security problems, even though showing said show would also allow users to exploit said problems in order to cheat?

So say duelingbook shows the code, the users find security problems, and the users point those problems out to duelingbook so duelingbook can fix them. However, because duelingbook showed the code, duelingbook now needs to completely rework said code so users can't exploit it, replacing the old code with brand new code...

but then, because brand new code was implemented, duelingbook would have to show it again so users could check for problems, resulting in this problem repeating itself where users now see the code, meaning duelingbook has to completely change it again and hide the new code to prevent cheating, resulting in duelingbook having to show the new hidden code again so users could check for flaws... and so on.

Re: Randomization in DB

Posted: Mon Oct 30, 2023 4:21 pm
by Goatobed
Christen57 wrote:You want users to be able to see the code that determines randomization so users would then be able to find security problems, even though showing said show would also allow users to exploit said problems in order to cheat?


This is nonsense. Just because you're showing me which function you use to determine randomness, it doesn't mean I can exploit it.

ominous wrote:You can't program "random"... Like... By definition.


Algorithms being deterministic does not preclude the possibility to producing provable randomness as an output.

I think the answer to the OP is that Duelingbook does not care about the few people who would want code audit.

Re: Randomization in DB

Posted: Mon Oct 30, 2023 8:59 pm
by Christen57
Goatobed wrote:
Christen57 wrote:You want users to be able to see the code that determines randomization so users would then be able to find security problems, even though showing said show would also allow users to exploit said problems in order to cheat?


This is nonsense. Just because you're showing me which function you use to determine randomness, it doesn't mean I can exploit it.


Yes it does. In order for duelingbook to be able to keep things random, ordinary users like us who aren't members of their staff aren't supposed to know how randomness is programmed into the game.

I've seen this kind of exploitation happen in many games, so I know what I'm talking about and that I'm not making anything up here. In Golden Sun: The Lost Age, players figured out how the game "randomly" decides which item the blacksmith will award the player, allowing players to ensure they get the specific item they want. https://www.youtube.com/watch?v=YwDxaGVqfPo

In pokemon games HeartGold and SoulSilver, players learned out how the game "randomly" decides many things such as Secret ID and the likelihood of encountering a shiny — things the developers clearly wanted random — resulting in these things getting manipulated and exploited. https://www.youtube.com/watch?v=PSIbk9CYRd0

Re: Randomization in DB

Posted: Tue Oct 31, 2023 1:03 am
by Goatobed
@Christen57, in my Duelingbook private server I have used Math.random() when shuffling hand and deck. I'm genuinely curious as to how you can exploit that.

For the record, if you've broken Math.random(), then you can perhaps turn half the Internet down?

Edit: Just saw your videos. In both games, the randomness is produced on a client level. You can obviously replace the part of the code which uses the RNG with something predictable. Shuffling deck and hand in Duelingbook happens on the backend (server-side), which can't be exploited unless you compromise the server.

Re: Randomization in DB

Posted: Tue Oct 31, 2023 1:08 pm
by Christen57
Goatobed wrote:@Christen57, in my Duelingbook private server I have used Math.random() when shuffling hand and deck. I'm genuinely curious as to how you can exploit that.

For the record, if you've broken Math.random(), then you can perhaps turn half the Internet down?

Edit: Just saw your videos. In both games, the randomness is produced on a client level. You can obviously replace the part of the code which uses the RNG with something predictable. Shuffling deck and hand in Duelingbook happens on the backend (server-side), which can't be exploited unless you compromise the server.


Seems I misunderstood you then. When you were asking duelingbook to show you how they do randomization, I thought you meant they should show exactly how things like their randomization worked, such as math.random.

In that case, no, simply knowing that a website uses math.random wouldn't be enough to exploit it. I'm sure duelingbook uses that method anyways. Seeing exactly how math.random itself worked, and how exactly it decides which number(s) to generate "randomly," on the other hand would lead to exploitation.

Re: Randomization in DB

Posted: Tue Oct 31, 2023 2:21 pm
by winmat
Christen57 wrote:
winmat wrote:
Genexwrecker wrote:^


Maybe a few things are getting mixed up.

What was asked is just a clarification regarding the snippet/algorithm/portion of code that concerns randomization.

Making that part known, in any program and not just on dueling books (aka open source) would improve security because since the code is within the reach of users it would allow security problems to be immediately detected (it is one of the principles that pushes developers to continue making code, open source). The matter would be different if the entire dueling book code were required (although I believe that in this case too there would be many security advantages, for the same reasons)

After that, the problem with very robust (widely used) algorithms does not arise, because those are already known and if exploits could be developed I believe that people would not exploit them on platforms like DB.

In essence there would only be advantages, including technical ones, in communicating details on the randomization method.

Finally, I believe that the advantage would also be reputational since it would mean being transparent (I'm not saying that DB isn't transparent now, but I'm saying that it would be an added value).


Let me see if I understand what you're asking. You want users to be able to see the code that determines randomization so users would then be able to find security problems, even though showing said show would also allow users to exploit said problems in order to cheat?

So say duelingbook shows the code, the users find security problems, and the users point those problems out to duelingbook so duelingbook can fix them. However, because duelingbook showed the code, duelingbook now needs to completely rework said code so users can't exploit it, replacing the old code with brand new code...

but then, because brand new code was implemented, duelingbook would have to show it again so users could check for problems, resulting in this problem repeating itself where users now see the code, meaning duelingbook has to completely change it again and hide the new code to prevent cheating, resulting in duelingbook having to show the new hidden code again so users could check for flaws... and so on.


You just described how open source works, which has existed for dozens of years and works perfectly. Obviously at a certain point (after a while the code is no longer weak and hopefully no exploits can be developed). There are hundreds of thousands of source codes (even concerning certainly more sensitive topics such as cryptocurrency wallets) that are on github for this very reason: if there were a security problem it would be immediately identified. Usually, however, robust code requires small fixes each time.

In any case, what is being asked is not to make the entire part of the code free, but only that which concerns randomization or to give a nod to its core or which algorithms (famous or less famous) are implemented and this is most likely not enough to develop exploits. Indeed, if the code were robust it would not even be useful to have larger portions of code.

But it would be enough, I repeat, just to mention how functions are used. In summary it would be nice to carry out a small code audit on that part of the code, in order to understand once and for all how the randomization is distributed. Obviously knowing that the math.random function is used is useless and certain methods, as some have described, if they were vulnerable, would create much bigger problems :)