→ ts1993: 0.3%中奖 你要扯多少才能去抗议对方胡扯 07/18 13:04
针对这点解释。机率确证可以用实体抽奖类比，其实这类说明也被提过几次了。
我先给你1000盒封住(加密)的奖品，让你自己从中挑一盒。
当你决定好之后，再让你打开盒子(给你密钥)看你抽到什么。
你也可以把剩下999盒都打开，确定1000盒里真的有3盒大奖，没抽到的话是自己手气差。
从程式的观点来看，因为服务器只是提供加密资讯、接收选择、提供密钥，
包括抽选在内的部分都是在客户端进行，因此随时可以验证机率正确与否。
当然现在游戏有没有实作这类模式那是另一回事了。

就程式设计的角度而言，我会跟你说这样就非常好破解...

实作上client只负责表演，奖项都是server提供的

如果抽选是在客户端进行的话你就会发现各种破解外挂了

电脑能动手脚的部分太多了，搞这么麻烦也会有人不信

目前加密算没办法破解吧，不然勒索病毒赚什么

和游戏内容与营收相关的随机参数放在client端是很不智的

尤其是谁跟你说每个箱机率相等的

我不用破加密 我改内容就好

如果是PC上还行，手机上的话还要考虑运算效能的影响

都是在server端算啦 不适合在client

橘子就玩过这个了，四个箱子让你抽，开完一箱之后亮出

那可以选后系统才产生密钥给你

其他三箱的内容，通常有一箱会是大奖，然后你可以付钱

那是程式的bug吧XD，当然多这些工对厂商也是徒增问题

严格说厂商可以给一个假的机率表，除非差距极大，不然玩

橘子那个说白了就是告诉你箱子会出什么而不是那个箱子有什么

在三箱里面再抽两次。

而且这边还有另一个程式功力不够又要增加防破解机制的游戏

你花钱抽得瞬间就决定你抽到什么了 那个箱子只是给你玩的

挖太佛了吧，结果大奖永远都在抽不到的最后一箱

其实随机的部分还是伺服端在运作

要做到真的可被检验的公正，可能要第三方公正机构介入

没错，电脑的东西机率还是掌握在官方手上，完全没办法

红心辣椒以前也有出过类似的活动 我就做过测试了

我随便选一个 再去查配送名单 奖品早就出来了

mikapauli 所以你也导向抽取结果在server制作的部分了，那从

告诉你四箱，没告诉你机率是四分之一

现在重点不在装置负担吧，只是描述一个能确证机率又不会被破解的方法而已

厂商真要搞，程式码没公开谁知道公式怎么跑的？

所有的随机都是在服务器阿,随机的资讯内容,随机的加密

有心要骗你，抽奖这种东西就没有所谓的确证

只有"选择"这个人为随机在客户端

这个方法也可以在server端做验证，"实作"的问题就是这个方法"最佳选择"是放在server端

乐透这种至少会在开奖机器实物上公开跟规格认证真要真的公正公开，我能想到的只有第三方介入

加解密你可以自己写程式拦截封包做阿,不用client的code当然这个封包不能再加密就是

http://i.imgur.com/yFxXUe9.jpg要确保机率没骗人这种机制最好哦

你把选择放在server消费者就不能随时验证了阿

池里共100样固定物 抽一次剩99样 抽100次必定全池的东西都拿到

你这种就像转蛋机，只有保底而已

厂商也可以SSR是到80抽后才能抽的到也说不定

sokayha大的例子是只有在只需一张就能用的卡上才合适，如

果要两张以上，那即使第一次就抽到了，但还是要把卡持全抽光才能换下个卡池

若真得这样做，卡池可以reset

s大那个我只要把机率拉到后面就好了，让你第一次根本不

所以你果然不懂嘛...就说把运算端放在客户端非常容易被破

前面提到每箱机率不相等，那也是自己的问题

最里面XD 会怕这种那没完了 我认输

@tonyxfg 它有重置键 你抽到目标物可以重置再抽新的100样

要避免被修改，重要资料、计算得伺服端处理。但这样对客

摆server消费者不信 放client会被修改

那就算程式bug了阿，你服务器自己不记得自己发送过什么

户端就是一种黑箱。理论上要公正得伺服端公开，但就算法

mikapauli 那你知道只要攻击中间负责加密的部分的机器就很容

律明写要公开，要钻的厂商也会公开假的。那么就得保证公

你提出的概念是"可以考虑实现"的，但不是"各方考虑下实作的

像乐透就是透过律师跟物理性质，把机率独立于厂商之外

伺服端加密，客户端解密，你是指那部分被攻击?当然没人会去实作阿，这种对厂商几乎没帮助的事情XD

"加解密你可以自己写程式拦截封包做阿,不用client的code"

回传结果到服务器端的时候改吧 实作上

你知道你这段就是在说"由server处理抽取参数"吗?

前面提到修改内容的，服务器其实不需要你告诉他抽到什

结果你自己也提到没人会这样实作，那大家也是讨论心酸了wwww

伺服端可以一次产生N组密钥，再看你选择给你解到较差奖品的密钥吧？

么，他只要知道你的选择。把加密讯息和密钥给你只是让验证而已

加密方式我自己写，给你抽一百个钥匙开一扇门都可以

骗伦，抽奖机率放在服务器上比较多，很少放在客户端。

linzero你这样已经算是破解加密方法了(根据任意明文和

我加密100组金钥，最烂的都是第1组，然后玩家开启必定开第一也不用啥破解，server送上来的都帮你排好了，client也帮你选只会先开第一个

密文产生对应金钥)。使用错误金钥解密只会得到一堆乱码

那100组今要的产品真的是用自然机率算出来的，但我排序是人为的，打包再一起送出去，很容易就达成linzero说的情况client和server金钥肯定是match的，但我在加密前就排好了所以client就是接收到由自然机率产生但排序人为的奖励

所以才说就算client没open source，相关封包也要能让人

不太理解 这篇原po说的方法 不是避不掉标准的老千手法吗 说给1000组让玩家选 但玩家怎么确认他选之前和选的当下内容没被调换？ 选的是ssr那组但翻牌时给你r

读取。不然通通加密起来对消费者一样都是黑箱

你这论点就是其他人的结论啊，拿个新概念讨论半天结果绕回来

抽选什么地都塞在client的有个例子 初版麦当劳app

sokayha所以才要把所有奖项在你做出选择前都给你让你能验证

server只判断你今天有没有抽过 不过这资料也拦的下来

这是很常见的密文验证阿，当然不是我想的XD

总之如果是不信任官方的话 除非有个第三方随时可透明浏览数据 不然怀疑论是没有弥平的可能的事前都给你让你验证 就不构成抽卡了？已经知道1000组的各自内容了啊？

全部内容是厂商声明的，各自内容是事后验证，只是先给你来保证不会更改

没用啊 声明的结果事后改掉就好啊 反正你也不知有没改

各自内容都先给你了，只是先封起来，等你挑完才能看看了发现与声明不合就是厂商有问题了

封起来你就不能保证庄家不会偷换底牌你事先也看不到声明内容 怎么知道声明内容没被改？

大概懂你的意思了。也就是同时提供明文跟密文，但顺序没

你这应该算linzero偷换解钥的想法

抓到了 FEH转蛋就是你写的

声明内容就是中奖率0.3%，要验证的只有这个而已

五张 你选了第三张 然后这时全翻开五张是 sr sr r sr sr，我官方再宣称一开始我就是给你sr sr r sr sr，你根本没得确认官方有没骗人一样是80%中奖 你永远不会中

linzero类似你的说法，只是其实是全部连在一起只有一组密文和密钥，因为产生密钥是最需要计算的地方

讲正经的啦 那这个1000盒的内容要怎么决定

没有第三方公证抽前抽后 数据/解答/密钥 没更动 就没搞头

所有出现物的机率取最大整数倍数那一定是个很庞大的数字你又要怎么去选一个至于宝箱被掉包之类 我只觉得叫警察去搬服务器比较快

我觉得还是之前我po图的那种保底手法相对可信 怕奖被放到最后的话 第一官方无法准确认知玩家目前最想要的是哪个第二玩家彼此之间的抽数对照就能统计出有没有合理毕竟总抽数上限被固定在例如100，同一目标物的所需抽数在统计上应该常态分布

玩家抽取数算是最站不住立场的证据(叹，只要穿差几个"特例"甚至于官方表明"这些玩家都只是刚好在偏差，我们数据中还有XXX玩家有在此机率之上，且分布都与这些玩家不同(ry"就像原PO的密钥想法，都有方法可以"制作"出有利于厂商的手法

以前可能是 现在抽抽实况那么流行 太明显做假会被抓到吧 记得之前猴女就是事例？玩家们抽数总和起来足够大数是会有质疑力道的

猴女那次其实真正违反景品的是新角色的优良误认只是玩家风像都只烧向猴女，而非优良误认的角色变成营运方就顺水推舟两个打包一起解决而且猴女最后我记得是有抽到，但花了70万日币

是啦 但我意思是那是玩家用统计结果去质疑官方的事别XD

而且那时候GBF有内建公告别人抽奖的机制

加上有一次开机时被人发现营运商的帐号在测试抽抽池

Romulus的确有这个太长的资讯不适合频繁传输的问题

但现在大部分转蛋游戏机率都是万分之一的倍数，因此这问题还好

你这还有高负载load balance的问题啊(茶

大部份万分之一 你这个夸张了XD cgss非当期0.022%，高了两倍有余！(x

如果万分之一机率，那表示要给玩家的选项得达10000个？

"理念不错，但欠缺实用"大概就是这样的结论吧

这真的是这样，频繁的变换加密很操服务器

load balance就转出去给另一台server，还好吧

"技术"不是问题，"营运概念"才是问题，上头就不给你多的机器玩家感受到的是什么? 就是你SERVER烂工程师偷懒啊QQ

画面上出现10000个让你点是不太实际就是了XD让玩家用输入数字的方式选也很没fu

课长：我一次课几百几千个，你要我一个个选？

文组文

在client抽很容易炸，流程一不小心没弄好就会被洗1. client一直重复抽抽到中才把资料送server2. client重复送中大奖的封包给server还有很多族繁不及备载不用改code就可以洗爆你的方法

送之前不会知道中奖与否, 楼上那是私钥系统才有的问题也不太能说是私钥系统, 应该说只要加入公钥系统中单向函数的概念, 楼上这些顾虑都会不复存在