Android内涵段子评论无限点赞分析与刷赞App[已和谐]

一、前言

在看内涵段子的时候，总是发现一些广告，瞬间就到几千的赞，这引起了我的注意，于是开始了探索之路。

首先是预判，为什么可以瞬间这么多，我猜的原因有以下

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验证身份了，