Forum Forum Home Bandit’s Posts Today’s Posts

[cobmanchester WANTED $2 Outlaw]

how can a game be PHSYICALLY not possible,  can be not possible true but physically…………

[ja jamie_evans WANTED $18 Outlaw]

4 – Streamers get Winmode from the casino to show them winning. UNTRUE. It’s physically not possible to give a player a game result thay wins. For the games to be provided No one can touch a gameround from it being hit spin by the player, the RNG doing it’s verified spin, the result being sent from the provider to the casino to the player. Not possible. Casinos cannot, and would not, do this. Casinos pay the provider a % for each amount lost on their games (averages around 12%) and the casinos keep 88% for them.

I’m fairly certain you’re right about streamers getting “winmode” being untrue, but that it’s not possible isn’t strictly correct.

The casino ultimately has full control of the slot.  Not because it can alter a result generated by the provider (though it can in some cases reject it and I’ll come to that later) but because it controls the interface through which you access the slot.  And this power enables casinos to do anything they want.  Because most slots are now HTML5 based, anyone (including the casino) can download the full front end of the slot, modify the link sources, and host it themselves.  But what about the RNG / result generator?  Well, if you reconfigure the front-end to look at a back-end other than that of the provider, such as an API of your own, you could send any result you wanted.  It’s not easy to reproduce and manipulate providers responses, but it is very easy to record the message payloads (results) of a very successful and legitimate session, stick them in a database, and send them sequentially on request.  This is similar to how providers reproduce videos of bonuses, like BTG did for the Tesla competition recently, except they already have the game data.  To keep this a secret I imagine it would be virtually impossible, unless almost every employee of the casino were totally corrupt and trusted not to spill the beans, and the casino were not thoroughly audited – but then I know what technical audits are like and the evidence you provide is never interrogated.  It’s not difficult to conceal from a technical perspective though.

So back to the rejection of results.  The communication path for a spin of a typical slot is player (request) > provider (request) > casino (response) > provider (response) > player.  The provider request is the important part here.  The result of a game is generated by the provider before any communication is done with the casino or the player.  In the provider request, they’re doing three things all at once, but not in the order one would expect:  (1) They’re notifying the casino of the result of the game in their request, (2) checking that the response is okay (3) reading the updated balance which the casino has calculated from the result of the game.  Step 3 is necessary because, although providers are able to keep track of your balance from the play of the slot, they don’t have visibility of all the games you’re playing and you could be playing two different slots at the same time, or have made a deposit while playing.  Some slots will show a deduction in your balance as soon as you press spin, and update with any win amount, but not update with the true balance the casino responded with until spin is pressed again.  This is why many slots need to be spun twice for a new deposit to appear.  So the order of steps 1 and 2 are the issue here, and their precipitated by this four-way RESTful design pattern.  The provider is notifying the casino of a game result before even checking that you have sufficient funds to cover the game round.  The casino is able to make a decision on whether or not to credit your account with a win.  If the casino were to respond to say you don’t have enough funds because they wanted to reject your win, then the provider would have a log of this and which would be potential evidence of foul play sitting outside of the casino, if investigated.  Plus, the player would be wondering what the hell was going on when they get a message in the slot saying insufficient funds.  But what if the casino didn’t respond at all?  What if they allowed the connection in, read the request, decided nah we’re not giving the player this win, and just held the connection open until it timed out?  Or it responded to the provider with a server error?  The provider can’t show you the win because it doesn’t even know if your balance was ever sufficient to play in the first place.

I realize this is very cynical, but wherever money goes, greed and corruption will follow.  And this simple little trick could be carried out with minimal people knowing.  Maybe just a single developer or single engineer.  And the big boss of course.

Sorry if the above seemed ignorant of your knowledge on the matter, I went in to detail more for the laymen of the forum.

[ar argyl53 WANTED $419 Outlaw]

It is technically possible for a dodgy casino to rip off a legit game, yes, this has actually happened – rogue casinos have been known to host their own illicit and unlicensed copies of NetEnt and Novomatic games.

But it’s important to point out:

1. There has never been a case of a UK licensed casino doing this, the regulation and audit checks and indeed ability to be sued by the provider are far too stringent for anyone to get away with doing that here.

2. It’s obvious when it happens if you know what to look for, primarily that the game should be loading from a known legitimate CDN. So any casino which tries it is very swiftly caught out, as happened with the few cases to which I refer.

[Seyahkram1977 WANTED $706 Outlaw]

jamie_evans wrote:

4 – Streamers get Winmode from the casino to show them winning. UNTRUE. It’s physically not possible to give a player a game result thay wins. For the games to be provided No one can touch a gameround from it being hit spin by the player, the RNG doing it’s verified spin, the result being sent from the provider to the casino to the player. Not possible. Casinos cannot, and would not, do this. Casinos pay the provider a % for each amount lost on their games (averages around 12%) and the casinos keep 88% for them.

I’m fairly certain you’re right about streamers getting “winmode” being untrue, but that it’s not possible isn’t strictly correct.

The casino ultimately has full control of the slot.  Not because it can alter a result generated by the provider (though it can in some cases reject it and I’ll come to that later) but because it controls the interface through which you access the slot.  And this power enables casinos to do anything they want.  Because most slots are now HTML5 based, anyone (including the casino) can download the full front end of the slot, modify the link sources, and host it themselves.  But what about the RNG / result generator?  Well, if you reconfigure the front-end to look at a back-end other than that of the provider, such as an API of your own, you could send any result you wanted.  It’s not easy to reproduce and manipulate providers responses, but it is very easy to record the message payloads (results) of a very successful and legitimate session, stick them in a database, and send them sequentially on request.  This is similar to how providers reproduce videos of bonuses, like BTG did for the Tesla competition recently, except they already have the game data.  To keep this a secret I imagine it would be virtually impossible, unless almost every employee of the casino were totally corrupt and trusted not to spill the beans, and the casino were not thoroughly audited – but then I know what technical audits are like and the evidence you provide is never interrogated.  It’s not difficult to conceal from a technical perspective though.

So back to the rejection of results.  The communication path for a spin of a typical slot is player (request) > provider (request) > casino (response) > provider (response) > player.  The provider request is the important part here.  The result of a game is generated by the provider before any communication is done with the casino or the player.  In the provider request, they’re doing three things all at once, but not in the order one would expect:  (1) They’re notifying the casino of the result of the game in their request, (2) checking that the response is okay (3) reading the updated balance which the casino has calculated from the result of the game.  Step 3 is necessary because, although providers are able to keep track of your balance from the play of the slot, they don’t have visibility of all the games you’re playing and you could be playing two different slots at the same time, or have made a deposit while playing.  Some slots will show a deduction in your balance as soon as you press spin, and update with any win amount, but not update with the true balance the casino responded with until spin is pressed again.  This is why many slots need to be spun twice for a new deposit to appear.  So the order of steps 1 and 2 are the issue here, and their precipitated by this four-way RESTful design pattern.  The provider is notifying the casino of a game result before even checking that you have sufficient funds to cover the game round.  The casino is able to make a decision on whether or not to credit your account with a win.  If the casino were to respond to say you don’t have enough funds because they wanted to reject your win, then the provider would have a log of this and which would be potential evidence of foul play sitting outside of the casino, if investigated.  Plus, the player would be wondering what the hell was going on when they get a message in the slot saying insufficient funds.  But what if the casino didn’t respond at all?  What if they allowed the connection in, read the request, decided nah we’re not giving the player this win, and just held the connection open until it timed out?  Or it responded to the provider with a server error?  The provider can’t show you the win because it doesn’t even know if your balance was ever sufficient to play in the first place.

I realize this is very cynical, but wherever money goes, greed and corruption will follow.  And this simple little trick could be carried out with minimal people knowing.  Maybe just a single developer or single engineer.  And the big boss of course.

Sorry if the above seemed ignorant of your knowledge on the matter, I went in to detail more for the laymen of the forum.

Soo what your saying is …….. it’s magic

[eejit101 WANTED $312 Outlaw]

jamie_evans wrote:

4 – Streamers get Winmode from the casino to show them winning. UNTRUE. It’s physically not possible to give a player a game result thay wins. For the games to be provided No one can touch a gameround from it being hit spin by the player, the RNG doing it’s verified spin, the result being sent from the provider to the casino to the player. Not possible. Casinos cannot, and would not, do this. Casinos pay the provider a % for each amount lost on their games (averages around 12%) and the casinos keep 88% for them.

I’m fairly certain you’re right about streamers getting “winmode” being untrue, but that it’s not possible isn’t strictly correct.

The casino ultimately has full control of the slot.  Not because it can alter a result generated by the provider (though it can in some cases reject it and I’ll come to that later) but because it controls the interface through which you access the slot.  And this power enables casinos to do anything they want.  Because most slots are now HTML5 based, anyone (including the casino) can download the full front end of the slot, modify the link sources, and host it themselves.  But what about the RNG / result generator?  Well, if you reconfigure the front-end to look at a back-end other than that of the provider, such as an API of your own, you could send any result you wanted.  It’s not easy to reproduce and manipulate providers responses, but it is very easy to record the message payloads (results) of a very successful and legitimate session, stick them in a database, and send them sequentially on request.  This is similar to how providers reproduce videos of bonuses, like BTG did for the Tesla competition recently, except they already have the game data.  To keep this a secret I imagine it would be virtually impossible, unless almost every employee of the casino were totally corrupt and trusted not to spill the beans, and the casino were not thoroughly audited – but then I know what technical audits are like and the evidence you provide is never interrogated.  It’s not difficult to conceal from a technical perspective though.

So back to the rejection of results.  The communication path for a spin of a typical slot is player (request) > provider (request) > casino (response) > provider (response) > player.  The provider request is the important part here.  The result of a game is generated by the provider before any communication is done with the casino or the player.  In the provider request, they’re doing three things all at once, but not in the order one would expect:  (1) They’re notifying the casino of the result of the game in their request, (2) checking that the response is okay (3) reading the updated balance which the casino has calculated from the result of the game.  Step 3 is necessary because, although providers are able to keep track of your balance from the play of the slot, they don’t have visibility of all the games you’re playing and you could be playing two different slots at the same time, or have made a deposit while playing.  Some slots will show a deduction in your balance as soon as you press spin, and update with any win amount, but not update with the true balance the casino responded with until spin is pressed again.  This is why many slots need to be spun twice for a new deposit to appear.  So the order of steps 1 and 2 are the issue here, and their precipitated by this four-way RESTful design pattern.  The provider is notifying the casino of a game result before even checking that you have sufficient funds to cover the game round.  The casino is able to make a decision on whether or not to credit your account with a win.  If the casino were to respond to say you don’t have enough funds because they wanted to reject your win, then the provider would have a log of this and which would be potential evidence of foul play sitting outside of the casino, if investigated.  Plus, the player would be wondering what the hell was going on when they get a message in the slot saying insufficient funds.  But what if the casino didn’t respond at all?  What if they allowed the connection in, read the request, decided nah we’re not giving the player this win, and just held the connection open until it timed out?  Or it responded to the provider with a server error?  The provider can’t show you the win because it doesn’t even know if your balance was ever sufficient to play in the first place.

I realize this is very cynical, but wherever money goes, greed and corruption will follow.  And this simple little trick could be carried out with minimal people knowing.  Maybe just a single developer or single engineer.  And the big boss of course.

Sorry if the above seemed ignorant of your knowledge on the matter, I went in to detail more for the laymen of the forum.

Nice post, very in depth. More info is always good. Its strictly true, but not quite as simple as a technical workaround.

On the winmode – I work on casino back offices daily. If winmode was a thing, even if it was slightly a thing, people would be super rich, as the providers would realise in just a few minutes. They get say 15% of losses on their games. If one player ID keeps winning, and the bill from the casino to the operator drops down below 0 in a weird fashion, they check. Immediately. They dont mess around. I once had a smaller provider see a win and 11 minutes later inform me that checks were done and it was ok. 11 minutes!

Providers check casinos that have their games on. they get reports, then test games. The regularly test the API calls and god knows what else. They test all of it for us a lot of the time. Freerounds need the proper function, as does the wagering and bonus configuration.

Plus – huge point – anyone ever caught doing this on an actual licence is fucked. And i mean sued fucked. UKGC fine for this is – does maths – eleventy gajillion pounds.

Plus x 2 – There are signs as argyl said. The URL, the game version, the authenticity, and the redirects and even the thumbnails. You would tell. Copied games Ive never seen on a UK or MGA casino in the last 2 years, aside from the legal copies (i.e Magic Mirror 2 by Merkur and blueprint) as thats the same damn company anyway.

[eejit101 WANTED $312 Outlaw]

BTW who do you work for. You know (mostly) your stuff!

[ja jamie_evans WANTED $18 Outlaw]

Currently out of work.  I used to be an Infrastructure Architecture for a fintech company.  Now I’m just a freak with too much time on his hands.

[eejit101 WANTED $312 Outlaw]

well your tech and API stuff is good, just some is impossible with what we get from providers. We cant as easily fuck with games as you think. EVen faked games are next to impossible

[Anonymous WANTED $55 Inactive]

Mickeyvondickey wrote:

I wonder if @MurciPete still knocks about on here? Haven’t seen him around in a while.

Yup, im still here,  but don’t participate really anymore as its too argumentative and stressful,  i might sound like a wuss but don’t really like the way people call each other C’s everyother sentence.      Also I have got bored of gambling.   After reading the threads on here for 20 mins I feel like slitting my wrists!

[Author]

Posts