第一篇地址: https://bbs.pediy.com/thread-225630.htm
首先,感谢看雪，感谢上文 @dalao 兄的邀请，以及其他几位兄弟的捧场。
然后,特别感谢 milo兄关于QQ的指点，及这篇的审校。

最后，如第一篇所言，随手报了3个，均被忽略，赞tx!

刚开始专攻Exploit，对漏洞的评估有不足，感谢TSRC的 qwerty 的回复。

这里做个总结，希望各位老司机多多批评指正。

目前的代码主要组成是从Android QQ来的，版本7.2.0。

漏洞一: YY的DOS攻击
不到20分钟就给我忽略了，20分钟就忽略了，忽略，了，，，我这算是审核最快的报告吗？？？
大兄弟！老心！扎铁了！！！我仿佛看到了红旗在飘你们内心在奸笑！！！/[手动愤怒]
milo兄给我发了这篇(http://www.qcloud.com/blog/?p=1457),于是我又看了看其他文章,这一个就不多说了。
尽管我仍然认为是可实施的。

漏洞二:反序列化对畸形数据包检测不足 (针对server，没实质危害)
这个在提交TSRC之前，纯属猜测服务端在反序列化时会触发，由于担心server是C的怕造成crash没测就提了。
被忽略之后，便使用获取好友功能测试了下，会返回脏数据，可能完全没有数据格式(即客户端无法解析，由于我是1:1还原的，所以判断这里可能就是返回了乱码)。

之后milo兄告诉我了tars ( https://github.com/Tencent/Tars )，读了下源码，如果QQ Server使用的版本和GitHub上的版本是一样的，那可以确认问题是存在的。

原理:
客户端发送逻辑:

服务端接收逻辑:

序列化函数的类: https://github.com/Tencent/Tars/blob/master/java/core/src/main/java/com/qq/tars/protocol/tars/TarsOutputStream.java

反序列化的类: https://github.com/Tencent/Tars/blob/master/java/core/src/main/java/com/qq/tars/protocol/tars/TarsInputStream.java

在Android版本中分别对应 JceOutputStream 和 JceInputStream.

举个例子:大家看 JceInputStream 的 readHead

构造畸形数据包的方式很多，最简单的方式可能是直接修改 JceOutputStream 来生成。

剩下的就是攻击思路的问题，比如构造格式正常但逻辑却异常的数据包过掉Server，使数据可以到达好友客户端。
比如根据序列化原理，构造个可以被放大的包(打个比方原始数据占100字节内存，反序列化后占10000字节内存，反正意思就是这个意思)，再配合第一个YY的DOS攻击。

使server异常的攻击都没有什么实质危害，但畸形数据到客户端就难说了。

.

漏洞三:QQ钱包支付密码猜解 (这个我觉得是有点风险的)

QQ钱包支付是使用https，证书校验方式只是 https://zhuanlan.zhihu.com/p/22426761 中描述部分，强度应该还需要加强。
我的话不够权威，来个比较权威的，省去大家的质疑时间: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

在这里我再补充下我的理解，不了解HTTPS原理的兄弟先去熟悉下HTTPS,这里就不占用篇幅了。

然后我们思考个问题: 纯净的Android手机 HTTPS 一定是安全的吗？对，纯净的。
一定吗？
一定吗？？
一定吗？？？

我认为不一定。

现在我们来回想一下，HTTPS之所以大家都在说足够安全的前提是什么？
前提就两条:1,可信的证书链    2，足够强的算法和密钥

算法肯定够强啊，秘钥也肯定够啊，1024都是最低标配了吧，所以第二条是可以保证的。

可是，可信的证书链能保证吗？怎么保证的呢？
这一点，在Android里，要分2个角度说，一个是系统层面，一个是webview层面。

首先说webview。
在Android里，不论是Webview组件apk，还是Chrome，包括火狐等浏览器，都是把根证书与apk打包在一起的。
比如Webview组件apk，大家可以把这个apk(包名:com.google.android.webview)拖出来，解压，找最大的那个so文件，ida打开，翻一翻就可以找到一堆的证书了。
比如PC版的chrome，证书是放在一个dll里的。
也就是说，webview、浏览器这种，保证证书链可信的方式是：升级。不升级就无法保证。

然后说系统。
系统的证书是放在了 /system/etc/security/cacerts/，我记得这个路径好像是写死的，大家去翻翻Android 源码，我上一次看得时候记得有一处是写死的这个路径，另外一处还是几处是拼接的，但结果是一样的，有时间的同学可以去确认下。
所以，系统是怎么保证证书可信的呢？对的，也是升级。
比如小米手机是升级补丁的时候会升掉，这一点还不错。
我算是华为的半个粉丝了，可是我可以说MATE1我首发时购买，直到用了5年扔掉，一次升级提示都没有过吗....

所以说，如果手机没升级、webview没升级，证书链就不一定可信，证书链不可信，那HTTPS就保证不了安全性。
那有实例吗？有的，很多，随便搜几个：
https://www.wired.com/2011/03/comodo-compromise/
https://docs.microsoft.com/zh-cn/security-updates/SecurityAdvisories/2011/2607712
http://www.williamlong.info/archives/3690.html
https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnnic-intermediate-certificate/

说到这里，我们也就明白了，若要HTTPS请求安全，除了降级攻击这种常规防御之外，还要保证证书链可信。

HTTPS有不可信的可能了，就打开了攻击中最重的那个大门。

第一步完成之后，我们看下如何猜解支付密码。业务功能是发红包。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课