微信网页游戏刷分BUG利用——抓包分析记录

前言

同学今早上跟我说，他们做的诗词小游戏被人破解后台接口然后刷分了。问我能不能分析一下怎么做到的，该怎么修复。然后我就看了看，学习一下移动端（微信网页）分析技术

抓包 分析

我只了解PC端网站抓包分析，移动端没有做过。所以最开始的思路是把小游戏放到PC上来搞。
“请在微信客户端打开链接”这个判断很好骗，在UA上面加上MicroMessenger/6.6.2.501 就好了。整体的UA如下：

Mozilla/5.0 (iPhone; CPU iPhone OS 13_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/83.0.4103.116 Mobile/15E148 Safari/604.1 MicroMessenger/6.6.2.501

可是这也只能处理一般的网页，获取微信用户ID及授权的步骤还是没办法搞。在github上也没找到相关的工具。看来只能作罢。还是老老实实的抓手机的包吧。

移动端设置使用burpsuite抓包

参考：burpsuite抓取手机数据包
我猜的坑：

1. burpsuite安装半天，因为jdk不对没装上。使用jdk1.8u221+版本搞定。
2. burpsuite代理地址设置为所有接口。因为我是同局域网下，不是开得热点。
   
3. 证书安装，应用目的是vpn和应用，不是wlan。或者两个都弄了也行。

ok，其他就没啥了，开始抓包分析。

请求分析

setp1，start——开始答题，获得题目

这里能拿到题目列表。
而且发现修改用户id可以轻松突破答题次数，因此可以无线获得题目

setp2，answer——提交选项，判断对错

对每道题的提交都用这个，可以判断出正确答案。
又发现题目id有规律，是递增的，所以题库最多就256*3个题目吗

至此，有方法，多次请求题目，获取所有问题，再进行答案的判断，最终 获得 题库。 但是方法比较笨，而且应用复杂，还是要靠人操作。

再分析！

setp3，submit_result——提交game，获得分数

由于手机加了证书和代理后，变得非常慢，所以我足足等了20分钟才把10个题目做完，拿到这个请求。不过总算没有白等。这个非常关键，因为这个是加分项。我就想，那我多来几次，重复提交不久好了吗？
试了一下，失败了，显示游戏已结束。果然，gameID用过了就不行了。那我就fake ID重新申请game。试了一下，成功了，但是加了0分。因为没有做题。
于是我在中间提交一个问题，N次，发现成功了，不过只有一道题的分数。

至此，运行逻辑清楚了：

1. 用户根据UID获取题目，和gameID，开始游戏。
2. 游戏过程中，提交答案至gameID，累计分数。
3. 游戏完成，提交gameID完成游戏，并把分数加到用户的总积分。

***在此过程中，后台基本没有什么判断和限制。***

在burpsuite 的Repeater工具里面进行的测试过程：
1 伪造uid，获取游戏id

2 对游戏id回答问题，随便啥问题都行，哪怕不再问题列表里面

3 提交成绩，获得积分

脚本编写

使用requests进行post访问，把burpsuite里面的cookie和header拿过来用。
几个函数：

1. 根据fakeID获取gameID
2. 根据gameID答题（先查询10个问题和答案，一直用这10个就好）
3. 提交gameID到用户积分

逻辑也很简单。记录一下踩得坑：

1. Header忘了加了，只加了post参数
2. 没了很简单

脚本地址:poc
基本上就是想刷多少分刷多少分，想给谁刷给谁刷（不过要知道ID）

自己的ID获取方法

点开游戏连接，不带任何参数的。然后自己登陆，分享给别人。分享的连接里面，refererid就是自己的UID。

修复方法

1. 伪造 UID获取gameID（无限获取游戏次数）： 可以通过比较UID和用户其他信息，防止伪造 UID。不过这个不是很重要。
2. 对gameID提交任意题目答题（用重复的一套题回答所有游戏）：记录gameID与他的题目ID。也不重要。
3. 提交gameID得分到用户（刷分的关键点，把fake UID的游戏得分提交任意一人）：非常重要！！！把gameID和UserID对应起来，在申请和最终提交的时候都加上判断，就能防止刷分，确保每人每日游戏次数是有限制的。

现在想想，即便是修复了，还是能搞一下。虽然不能刷高分，但是可以保证题目全对，而且最重要的是，可以让积分考前的人每天得不了分。（通过积分榜获取前面人的ID，每天凌晨就把他们题目刷干得0分，让他们没法再答题。）

rank信息直接是get 就可以

总结

分析过程，和采坑点都很重要，值得回味。这个bug就是在最开始设计的时候，没有安全意识。其实最后只要简单判定就好了，应用逻辑问题。

在分析过程中，一定是对完整的流程进行分析，千万不要分析一般就放弃，后者以为了解了所以。最后那个等了20分钟的请求出来后，我才知道了整个流程。对流程梳理清楚后，才能更好地分析问题。