芯查查开发板组装游戏公测送Pico，Pico不算多贵，毕竟是公测，找漏洞还是主要任务。
问题
兑换ID累加而非随机
元件兑换码是15位数字，例如529772844564186，看着很安全对吧？
但是他的APP分享链接是这样的：
https://app-h5.xcc.com/mobile/friend/puzzle/give?redeemId=13看到后面那个redeemId没有，那个是累加的，而非随机。
也就是说，可以通过穷举redeemId来达到将所有人分享的元件兑换掉。
这个漏洞太明显了，开发肯定偷懒了，而且估计没有内测直接公测，不然应该早发现了。
想起以前写的短链接网站，mysql主键一加、自增一开，长链接往里面一丢返回个自增的id，直接用自增id作短链接，不知道芯查查这个redeemId的原理是不是这样。每人每天兑换次数无上限
这个本身问题不大，正常情况下一个分享一个兑换没什么问题，最多就是有些无聊的人会AB两个账户互相分享刷服务器资源。
但是结合上面的漏洞，一个人就可以兑换光所有兑换码，两者结合算是一个严重的漏洞了
抽奖随机程度不足问题
基本上连抽抽中的都是前一个元件，随机性差。
看着抽中这堆按键陷入沉思。
助力不方便问题
在微信中助力，打开后需要转跳到浏览器，转跳到浏览器后还要再转跳到APP，十分麻烦。
题外话
助力链接id也是累加的，不过这个没影响，就是感觉改成userid应该方便。
https://app-h5.xcc.com/mobile/friend/puzzle/get?helpId=666解决
陌生人刷元件问题
方法一
将redeemId生成方式由累加改为随机生成，结合大小写字母和数字或者多位纯数字。
方法二
限制每人每天兑换次数上限，这个只能是临时方法。
因为即使限制每人每日兑换上限，依旧可以兑换陌生人分享的元件，当用户量起来后依旧是个问题。
只适合在使用方法一改代码期间临时用。
随机性问题
改进随机算法。
助力不方便问题
方法一
直接像淘宝拼多多那样在聊天框分享字符串，复制后打开APP自动识别。
方法二
基本操作同方法一，但把复制助力字符串的方法改成赠送元件的那样，打开网址后复制。
好处
- 能展示活动信息，估计这也是设计
redeemId而不是直接使用redeemCode的原因。 - 直接对
helpId处理后展示就好，改起来方便
半夜帮别人找BUG，自愿加班了属于是，还没工资。
不知道能不能奖我块RPI Zero 2W [滑稽]。
2022-04-13 更新
昨天的问题情况
刷元件问题
刷元件问题解决，如下为现在的链接：
https://app-h5.xcc.com/mobile/friend/puzzle/give?redeemId=647293849相比于原来的累加，现在使用了9位随机数作为redeemId，通过遍历获取redeemCode的漏洞解决了。
9位数有约10亿个号，目前公测有842名参与活动的用户，即使第二期增加100倍也足够用了。
助力不方便问题
目前没改，毕竟只是影响体验不是漏洞，不急。
今天的新问题
助力、点赞界面设计问题
活动图如下：
例如好友助力的计算方式：
拉1人 - 2次
拉3人 - 3次
拉5人 - 5次
拉6人 - 7次
拉9人 - 10次以5人为一个循环，以此重复。
但是图中并未标明，加上文字说明“累计助力值可增加对应次数”以及图片中的“1人、3人、5人”，很容易让用户误以为每人活动期间只能让人帮忙助力5次。
新问题解决方法
助力、点赞界面设计问题
拿点赞举例，可以在前面加一个上一次循环的个数，下面的1次、2次改为+1次、+2次：
但上面的方法有个缺点，一是如果多人点赞达到了三位数，有可能放不下或者不美观。
如果把上面的次数也改成+感觉就好多了，而且左边还有足够空间放上一循环点赞数：
