用户名*
邮箱*
密码*
确认密码*
验证码* 点击图片更换验证码
找回密码
忘记密码了？输入你的注册邮箱，并点击重置，稍后，你将会收到一封密码重置邮件。
这两天围观了喜马拉雅和蜻蜓的撕逼大战，作为一个圈内技术狗，实在是被喜马拉雅的行为震撼到了，这flag一路立的飞起，感觉是不想在圈里混的节奏了，那我就扒你一把送送你。
喜马的代码混淆了，反编译后简单看了看结构，搜了一些域名地址关键词这些都没有，继续磕代码会比较慢，先假设存在刷量，从抓包分析开始找证据，开个fiddler，打开app首屏就有广告，顺利找到doubleclick请求。
点击二级页面，看到也在发doubleclick，嗯也有banner属于正常，点击进入一个功能页，嗯就这么容易，又看到了doubleclick， 这一瞬间我有种还没开始发力你就倒下了的赶脚。。。
又到处试了试，发现刷的机制很简单，页面切换、后台到前台、锁屏到解锁都会触发，嗯应该是写在onResume里的。
解锁的:
切到前台的:
再补一个综合成果:
都是doubleclick。略叼略叼！就是这么刷假数据的~
嗯就这么简单，flag立的好啊，咬之前也不把自己处理好点，就这手段也敢出来现，还tm挑衅行业底线，技术实力着急，智商着急。
我觉得我开了个好头哈，其他人感兴趣可以继续扒，看有没有牛人从混淆代码里再抓出来点更直接的证据，给丫们再好好上一课，不过得抓紧，有可能是纯在线控制的，丫们看到这个估计就会关了。
这帖子可能得罪人，得匿得匿~
楼上都是技术角度，我从资本这个角度回答一下，长文，抛砖引玉。
其实数据造假这个在国内是公开的秘密，在国内做APP你不加个自启动代码刷出3倍5倍的活跃用户骗骗投资人都不好意思在圈里混……但是为什么之前这种撕逼很少呢？
第一，之前是一个（所谓的）蓝海，大家更愿意和谐共处。
第二，之前的投资估值是对标的。
什么叫对标？比如说，我的一个项目，准备融资，目标是1000万。
正在这时，我的竞争对手融资了，数据比我差，却融了2000万！（鬼知道实际上是多少……）
接下来形式对我就很有利——首先，投资人不仅投项目也投赛道，对手融到了钱，就说明赛道没问题。（真的吗？）
其次，估值要对标。他融了2000万，我至少可以融2500。
最后，投资人其实是有业绩压力的。行内有句话叫“不怕失败，就怕踩空”。比如说，O2O这一波，如果一个VC居然一个O2O也没投（而且其它项目投的也不怎么样），那恐怕没什么机会再找到LP了。
所以这种情况下，大家都在跟风投，估值越来越高。这种情况下，创业者之间为什么要撕逼呢？你的估值低了，对我没有任何好处，只有坏处啊！
但是资本寒冬，情况就不一样了。
随着估值越来越高，VC都希望套现了……股市情况又不好，纳斯达克中概股哀鸿遍野，至于A股……
所以就有了‘’B轮死，C轮合，老大吃肉老二喝汤老三死翘翘‘’的说法。现在音频这个行业比较典型，版权费越来越高，变现比视频还困难，蜻蜓，喜马拉雅估值都是过亿美元，考拉，荔枝紧随其后，最近又来了个企鹅，然而到现在都没分出老大来。
所以现在的情况就是:谁先拿到下一轮，谁就是老大。
那老二呢？要么像大众点评，赶集，快的被合掉，要么融不到钱，等死。
这种情况下，喜马拉雅拼了命也要想办法把蜻蜓的融资搅黄。
喜马拉雅显然准备了很久，蜻蜓显然也没预料到，被动挨打。
但是你有技术团队，我也有啊。你会分析代码，我不会吗？你有钱做公关，我没有吗？最主要的，数据造假彼此彼此，谁怕谁啊？
所以为什么这个事能炒的这么热烈？很简单，两家都卯足了劲想干掉对方，所以撕起来也很正常嘛！
至于结果？
双输呗！最大赢家反而是考拉和荔枝，我猜过段时间就会传出两家融资的消息了。
利益相关:FM类产品只用喜马拉雅，只用来听一周一次的罗辑思维，不过现在还占着手机里几十兆内存。至于我算不算他们的活跃用户——谁知道呢？
扫码关注，加入青年创业社群，期待你与我们一起，创造无限可能。
唯一的原因是蜻蜓融到钱了， 喜马拉雅没融到就疯了。
看楼上发的喜马拉雅抓包分析启发了我，我反编译了一下喜马拉雅app。从原来的抓包分析中看到带有
在混淆的代码中grep一下find_banner，只出现了一个文件RecommendCategoryFragmentNew。
看这个名字应该是主页的推荐首页。根据之前抓包情况，在亮屏时能抓到doubleclick和miaozhen的包，那就肯定是在onResume里了。
RecommendCategoryFragmentNew.java中onResume():
这里每次onResume调用都会触发statFocusAd，也就是说，在APP每次启动、前后台切换、解锁时，都会启动广告刷量！
因此这里的statFocusAd会被大量的频繁调用。
再查看ThirdAdStatUtil.getInstance().statFocusAd(mFocusImages,true)：
看名字像是做广告统计的，但是除了所谓的广告统计，其实还会广告检测请求。注意参数里的third_url就是find_banner里的thirdStatUrl，也就是用户点击的广告地址。
以下是实际执行的广告刷量代码：
这里的s正是这个focusimagemodelnew.third_url。这里代码做了混淆，但是看到start方法像是开个线程去做广告刷量，果不其然：
这里混淆的比较难读，大部分变量名或函数名都变成了a、b、f、obj这样的字母。s就是third_url，付给了a，然后再封装成了一个对象obj。接下来obj作为参数传给f.a().a(*)调用。
但是刷量逻辑很清晰的，关键代码就在f.a().a(*)函数中，让我们来看这个函数做了什么
其中f()是类的构造方法，里面定义了e，是个AsyncHttpClient，用来做异步网络请求，后文会提到。f.a()获取singleton单例，下一步是f.a().a(*)的调用。
f.a().a(*)中的s就是上文中的third_url，即doubleclick的检测链接。代码里用上文中的e（AsyncHttpClient）调用了这个链接。
总结，在RecommendCategoryFragmentNew的每次onResume调用，都会向配置的third_url发送一次请求。而这个onResume是在什么时候调用呢？应用启动时，切到后台再切回来时，锁屏再亮屏时，打开其他应用再回来时；而且由于这个fragment是放在viewpager里，那么切到别的tab再切回来时也会调用。所以这个third_url在应用使用期间会被大量频繁的访问，恐怕比真的展示多了不只几倍的量。这也解释印证了楼上童鞋提到的抓包分析里面的现象。
我们再回过头看下third_url刷了哪些第三方广告监测平台。
首页广告api：
内容分类中的广告
配置的是秒针的刷量链接.
是否有其他刷量的地方，我没有深挖，因为混淆过再反编译的代码阅读起来实在是不怎么顺畅。但这段广告监测请求的逻辑放在onResume里就足以说明一切。
作为一个资深码农，不得不说，喜马拉雅在刷量这件事上确实动了脑筋。一是代码混淆，隐藏的很深；二是动态下发刷量链接，方案可扩展性极强。利用这种原理，除了刷广告监测，其他http类的请求都可以动态生成访问，想象空间还是很大的，有兴趣的同学可以继续研究，（提示一下，启动的时候有下载其它app的功能，看看有没有同学能分析出来）。
最后附上反编译的source code：
有兴趣的童鞋可以自行下载深入研究研究～
看大家都在引用贴里面那么热闹，本来的技术贴倒是冷静了。
跟着楼上的指引去看了看那个URL，发现刚刚果然把那个thirdStatUrl置空了…
本校陈浩副教授曾在Mobisys上发表过一篇如何检测Android ad fraud 的论文，有兴趣的可以看看:
Cheating FM
用苹果自带的播客就可以解决一切问题的，安卓的话可以购买Pocket Casts。而国内的音频应用…除了最近的“路上读书”，任何一个我不用，广告太多，使用体验也不行。
早在08年那波金融危机之后，PC端客户端软件刷广告流量就已经逐渐发展为业内通用的手段了。还记得当年销售总监拿着某华南友商的广告数据跑老大那哭诉说，再不刷广告根本没法卖，数据上我们比别人差好几倍！
这就是典型的囚徒困境，一家开始作假导致整个行业都被拖下水了。喜马拉雅看似只砸了蜻蜓的牌子，但实际上恐怕无数人心里暗自吃了一惊吧，底裤都扒的这么光了，让老子以后还怎么在圈里混！
不知道喜马拉雅内部，做刷量的同这次扒蜻蜓底裤的是不是同一拨人。若是同一拨只能说没张脑子；若不是就热闹了，这乌龙闹的。。。
点了那个链接看，好像配置的刷量链接已经撤掉了？反应好快…
昵称*
E-Mail*
回复内容*
回复 ( 10 )
这两天围观了喜马拉雅和蜻蜓的撕逼大战，作为一个圈内技术狗，实在是被喜马拉雅的行为震撼到了，这flag一路立的飞起，感觉是不想在圈里混的节奏了，那我就扒你一把送送你。
喜马的代码混淆了，反编译后简单看了看结构，搜了一些域名地址关键词这些都没有，继续磕代码会比较慢，先假设存在刷量，从抓包分析开始找证据，开个fiddler，打开app首屏就有广告，顺利找到doubleclick请求。
点击二级页面，看到也在发doubleclick，嗯也有banner属于正常，点击进入一个功能页，嗯就这么容易，又看到了doubleclick， 这一瞬间我有种还没开始发力你就倒下了的赶脚。。。
又到处试了试，发现刷的机制很简单，页面切换、后台到前台、锁屏到解锁都会触发，嗯应该是写在onResume里的。
解锁的:
切到前台的:
都是doubleclick。略叼略叼！就是这么刷假数据的~
嗯就这么简单，flag立的好啊，咬之前也不把自己处理好点，就这手段也敢出来现，还tm挑衅行业底线，技术实力着急，智商着急。
我觉得我开了个好头哈，其他人感兴趣可以继续扒，看有没有牛人从混淆代码里再抓出来点更直接的证据，给丫们再好好上一课，不过得抓紧，有可能是纯在线控制的，丫们看到这个估计就会关了。
这帖子可能得罪人，得匿得匿~
楼上都是技术角度，我从资本这个角度回答一下，长文，抛砖引玉。
其实数据造假这个在国内是公开的秘密，在国内做APP你不加个自启动代码刷出3倍5倍的活跃用户骗骗投资人都不好意思在圈里混……但是为什么之前这种撕逼很少呢？
第一，之前是一个（所谓的）蓝海，大家更愿意和谐共处。
第二，之前的投资估值是对标的。
什么叫对标？比如说，我的一个项目，准备融资，目标是1000万。
正在这时，我的竞争对手融资了，数据比我差，却融了2000万！（鬼知道实际上是多少……）
接下来形式对我就很有利——首先，投资人不仅投项目也投赛道，对手融到了钱，就说明赛道没问题。（真的吗？）
其次，估值要对标。他融了2000万，我至少可以融2500。
最后，投资人其实是有业绩压力的。行内有句话叫“不怕失败，就怕踩空”。比如说，O2O这一波，如果一个VC居然一个O2O也没投（而且其它项目投的也不怎么样），那恐怕没什么机会再找到LP了。
所以这种情况下，大家都在跟风投，估值越来越高。这种情况下，创业者之间为什么要撕逼呢？你的估值低了，对我没有任何好处，只有坏处啊！
但是资本寒冬，情况就不一样了。
随着估值越来越高，VC都希望套现了……股市情况又不好，纳斯达克中概股哀鸿遍野，至于A股……
所以就有了‘’B轮死，C轮合，老大吃肉老二喝汤老三死翘翘‘’的说法。现在音频这个行业比较典型，版权费越来越高，变现比视频还困难，蜻蜓，喜马拉雅估值都是过亿美元，考拉，荔枝紧随其后，最近又来了个企鹅，然而到现在都没分出老大来。
所以现在的情况就是:谁先拿到下一轮，谁就是老大。
那老二呢？要么像大众点评，赶集，快的被合掉，要么融不到钱，等死。
这种情况下，喜马拉雅拼了命也要想办法把蜻蜓的融资搅黄。
喜马拉雅显然准备了很久，蜻蜓显然也没预料到，被动挨打。
但是你有技术团队，我也有啊。你会分析代码，我不会吗？你有钱做公关，我没有吗？最主要的，数据造假彼此彼此，谁怕谁啊？
所以为什么这个事能炒的这么热烈？很简单，两家都卯足了劲想干掉对方，所以撕起来也很正常嘛！
至于结果？
双输呗！最大赢家反而是考拉和荔枝，我猜过段时间就会传出两家融资的消息了。
利益相关:FM类产品只用喜马拉雅，只用来听一周一次的罗辑思维，不过现在还占着手机里几十兆内存。至于我算不算他们的活跃用户——谁知道呢？
扫码关注，加入青年创业社群，期待你与我们一起，创造无限可能。
唯一的原因是蜻蜓融到钱了， 喜马拉雅没融到就疯了。
看楼上发的喜马拉雅抓包分析启发了我，我反编译了一下喜马拉雅app。从原来的抓包分析中看到带有
在混淆的代码中grep一下find_banner，只出现了一个文件RecommendCategoryFragmentNew。
看这个名字应该是主页的推荐首页。根据之前抓包情况，在亮屏时能抓到doubleclick和miaozhen的包，那就肯定是在onResume里了。
RecommendCategoryFragmentNew.java中onResume():
这里每次onResume调用都会触发statFocusAd，也就是说，在APP每次启动、前后台切换、解锁时，都会启动广告刷量！
因此这里的statFocusAd会被大量的频繁调用。
再查看ThirdAdStatUtil.getInstance().statFocusAd(mFocusImages,true)：
看名字像是做广告统计的，但是除了所谓的广告统计，其实还会广告检测请求。注意参数里的third_url就是find_banner里的thirdStatUrl，也就是用户点击的广告地址。
以下是实际执行的广告刷量代码：
这里的s正是这个focusimagemodelnew.third_url。这里代码做了混淆，但是看到start方法像是开个线程去做广告刷量，果不其然：
这里混淆的比较难读，大部分变量名或函数名都变成了a、b、f、obj这样的字母。s就是third_url，付给了a，然后再封装成了一个对象obj。接下来obj作为参数传给f.a().a(*)调用。
但是刷量逻辑很清晰的，关键代码就在f.a().a(*)函数中，让我们来看这个函数做了什么
其中f()是类的构造方法，里面定义了e，是个AsyncHttpClient，用来做异步网络请求，后文会提到。f.a()获取singleton单例，下一步是f.a().a(*)的调用。
f.a().a(*)中的s就是上文中的third_url，即doubleclick的检测链接。代码里用上文中的e（AsyncHttpClient）调用了这个链接。
总结，在RecommendCategoryFragmentNew的每次onResume调用，都会向配置的third_url发送一次请求。而这个onResume是在什么时候调用呢？应用启动时，切到后台再切回来时，锁屏再亮屏时，打开其他应用再回来时；而且由于这个fragment是放在viewpager里，那么切到别的tab再切回来时也会调用。所以这个third_url在应用使用期间会被大量频繁的访问，恐怕比真的展示多了不只几倍的量。这也解释印证了楼上童鞋提到的抓包分析里面的现象。
我们再回过头看下third_url刷了哪些第三方广告监测平台。
首页广告api：
内容分类中的广告
配置的是秒针的刷量链接.
是否有其他刷量的地方，我没有深挖，因为混淆过再反编译的代码阅读起来实在是不怎么顺畅。但这段广告监测请求的逻辑放在onResume里就足以说明一切。
作为一个资深码农，不得不说，喜马拉雅在刷量这件事上确实动了脑筋。一是代码混淆，隐藏的很深；二是动态下发刷量链接，方案可扩展性极强。利用这种原理，除了刷广告监测，其他http类的请求都可以动态生成访问，想象空间还是很大的，有兴趣的同学可以继续研究，（提示一下，启动的时候有下载其它app的功能，看看有没有同学能分析出来）。
最后附上反编译的source code：
有兴趣的童鞋可以自行下载深入研究研究～
看大家都在引用贴里面那么热闹，本来的技术贴倒是冷静了。
跟着楼上的指引去看了看那个URL，发现刚刚果然把那个thirdStatUrl置空了…
本校陈浩副教授曾在Mobisys上发表过一篇如何检测Android ad fraud 的论文，有兴趣的可以看看:
Cheating FM
用苹果自带的播客就可以解决一切问题的，安卓的话可以购买Pocket Casts。而国内的音频应用…除了最近的“路上读书”，任何一个我不用，广告太多，使用体验也不行。
早在08年那波金融危机之后，PC端客户端软件刷广告流量就已经逐渐发展为业内通用的手段了。还记得当年销售总监拿着某华南友商的广告数据跑老大那哭诉说，再不刷广告根本没法卖，数据上我们比别人差好几倍！
这就是典型的囚徒困境，一家开始作假导致整个行业都被拖下水了。喜马拉雅看似只砸了蜻蜓的牌子，但实际上恐怕无数人心里暗自吃了一惊吧，底裤都扒的这么光了，让老子以后还怎么在圈里混！
不知道喜马拉雅内部，做刷量的同这次扒蜻蜓底裤的是不是同一拨人。若是同一拨只能说没张脑子；若不是就热闹了，这乌龙闹的。。。
点了那个链接看，好像配置的刷量链接已经撤掉了？反应好快…