一、前言
在看内涵段子的时候,总是发现一些广告,瞬间就到几千的赞,这引起了我的注意,于是开始了探索之路。
首先是预判,为什么可以瞬间这么多,我猜的原因有以下
- 1 、广告狗有几千个小号,轮流点赞
- 2 、点赞有bug,同一个帐号可重复点赞
- 3 、内部员工直接修改数据库
就根据可能性来说,最大的可能排序为 2 > 1 > 3 ,第二个可能性是最大的。我们先来分析。
二、分析
2.1 开始抓包
抓包是利用Fiddler2这个工具,使用方法请百度,这里不讲述。
手机打开到随便一条段子的评论界面,然后打开Fiddler,对某条评论进行点赞,可以看到fiddler已经拦截到了请求。Fiddler左边是请求的链接信息,在右边的 Inspectors -> WebForms 下面可以看到请求的数据。
完整的Url为(还有隐藏的post参数): http://iu.snssdk.com/2/data/comment_action/?iid=16539392360&device_id=34695026312&ac=wifi&channel=xiaomi&aid=7&app_name=joke_essay&version_code=661&version_name=6.6.1&device_platform=android&ssmix=a&device_type=MI+2SC&device_brand=Xiaomi&os_api=19&os_version=4.4.4&uuid=860670023013591&openudid=704c458a9904e206&manifest_version_code=661&resolution=720*1280&dpi=320&update_version_code=6613
返回的json内容为:
bury_count=0
comment_id=1582210742671533
digg_count=1
errno=0
message=success
stable=True
user_bury=0
user_digg=0
根据返回的json内容,可以看到几个有用的数据:
- comment_id: 点赞的评论id
- digg_count: 这个评论已经有多少个赞了
- message: 文本信息
- errno: 错误代码,为0就是成功了,说明不为0就是失败了。
2.2 分析头信息
在Fiddler Inspectors -> Headers 可以看到头信息:
可以看到有cookie数据,然后里面有sessionid等等其他参数,这就有点懵逼,感觉有做身份验证的样子,不怕,继续探究下去。
2.3 分析拼接参数
从链接可以看到存在直接字符串拼接的参数:
iid=16539392360&
device_id=34695026312&
ac=wifi&
channel=xiaomi&
aid=7&
app_name=joke_essay&
version_code=661&
version_name=6.6.1&
device_platform=android&
ssmix=a&device_type=MI+2SC&
device_brand=Xiaomi&
os_api=19&
os_version=4.4.4&
uuid=860670023013591&
openudid=704c458a9904e206&
manifest_version_code=661&
resolution=720*1280&
dpi=320&
update_version_code=6613
可以看到拼接提交的参数有这么多,根据参数名可以猜测是提交的手机相关信息和app的信息,例如app_name,version_code,os_api等等,都是一些基础信息,这些忽略,对我们的重点评论完全没有关系。
2.4 分析Post参数
在Fiddler的WebForm的body下面,看到post提交的参数:
参数名 | 值 |
comment_id | 1582210742671533 |
action | digg |
group_id | 71854834345 |
item_id | 71854834345 |
iid | 16539392360 |
device_id | 34695026312 |
ac | wifi |
channel | xiaomi |
aid | 7 |
app_name | joke_essay |
version_code | 661 |
version_name | 6.6.1 |
device_platform | android |
ssmix | a |
device_type | MI 2SC |
device_brand | Xiaomi |
os_api | 19 |
os_version | 4.4.4 |
uuid | 860670023013591 |
openudid | 704c458a9904e206 |
manifest_version_code | 661 |
resolution | 720*1280 |
dpi | 320 |
update_version_code | 6613 |
好,又是一堆的参数,我们利用猜测法去掉无相关的参数,剩下有用的参数:
参数 |
comment_id |
action |
device_id |
group_id |
item_id |
iid |
uuid |
openudid |
为什么我留下的是这些参数呢,因为这些参数都是一些id数字,是比较敏感的。
看完了参数之后,得出观点,如果是有用户身份验证的话,那么参数里面并没有看到用户的身份信息,头信息可能有用户信息,我们先不管头信息,就直接分析参数。
- comment_id: 评论的id,这个很容易理解
- action: 动作,点赞动作
- device_id: 设备id,这个感觉有用,记录手机的id
- group_id: 组id,这个估计没用
- item_id: 项id,感觉也没用
- iid:这个猜不出来
- uuid:随机数
- openidid:开放的udid,设备的标识
2.5 筛选参数
在确定了参数之后,接下来进行验证,回到Fiddler。我们先直接重复提交一遍请求,看看行不行,右键刚刚点赞请求 -> Replay -> Reissue Requests
结果肯定不行的。。。。
接下来进行参数的修改:右键刚刚点赞请求 -> Replay -> Reissue and Edit(编辑并且发送请求)。
然后会看到右边的WebForm会显示为一个编辑状态,修改我们最有可能的参数,我首先修改device_id
,为什么呢,因为这是设备id,有可能是根据设备id来点赞的。
把device_id的值随便修改一个数字,然后点击Run to Completion进行提交。
这时候,奇迹来了,可以看到,返回的json数据digg_count比上次大了1,然后重新看看评论的点赞数量,可以看到是增加了1。 到这里,我们就可以确定了,评论的点赞数量是根据设备id来进行区分的,所以,我们可以搞事情了。
接下来,我们把其他参数都去掉,只留下comment_id和device_id,然后修改device_id进行提交看看能不能成功。
提交之后发现digg_count又增加了1,完美。
三、 编写App
根据上面的分析,我们即可编写刷赞的App
App编写中…,下班,明天在搞
四、已GG
已经被修复了,现在已经有做session验证身份了,