/首页
/开源
/关于
关于Android 7以及以上版本抓包和API安全问题
发表@2019-05-12 13:42:30
更新@2023-04-28 10:26:27
周六日实际上并不是真正的休息日，周一到周五才是真正的休息日。  对于本行业，我是深谙其行业规则的，放心，规矩我都懂，看破不说破。 反正至于别的行业圈子的微信咋样我不知道，但是我行我圈的微信，都是周一到周五火爆异常，一到周六日就静悄悄：这就是传说中的带薪聊天。 而我今天要做的就是在闲暇时间里抽个空抓紧时间写点儿技术文章，而且文章内容还不能太繁琐太浪费大脑，就是应该搞成那种【我告诉你这个东西有何用以及怎么用】类型的：一看就懂，一用就会，成就感爆棚，而且说出去既装逼又拉风；上能应付面试官，下能应用到项目工程。 今天的事儿，要从我的【前任】（可能真的是CN最大陌生社交APP）和我【前前任】（群里应该都知道是哪儿，不说了）说起。 今天的事儿，一共两件事儿： - 一是安卓7.0以上对https协议进行【数据分析】的问题 - 二是如何才能像【前任】那般优秀，提高被【数据分析】的门槛和成本 ### 第一件事儿：青花瓷和https 如果不出意外，在座的各位...应该和我一样，一般都会用青花瓷搞【数据分析】，你们看下图标是不是和我一样。如果一样，肯定是你用了我的Licence：。 青花瓷的分析https的教程我不赘述，但是我需要简述一下。可能很多宝贝儿们都有“ 我们API都用https了，还能被【分析】了？ ”的严重神经错觉。你只需要做的只有两步： - 你的设备上信任一下青花瓷的根证书 - 然后再在青花瓷里配置一下SSL Proxy域名 上述过程熟手老皮们一般两分钟内就可以搞定，然后你就可以在青花瓷里开开心心【数据分析】别人家的https API了，裤子都给你脱光了。 然而，从安卓7.0开始，【谷人希公司】提高了系统安全性，系统不会再信任除了系统内置以外其他根证书了，也就是说上面配置的青花瓷根证书不再被安卓信任了，所以，很多人使用青花瓷搞https【数据分析】的时候就会出现下面的截图，你们感受一下：  ？？？  所以，安卓7.0以上的小伙伴们怎么办呢？来，老李手把手教你如何解决这个问题，其实非常简单，首先你需要两个工具： - https://github.com/android-hacker/VirtualXposed - https://github.com/Fuzion24/JustTrustMe 首先安装第一个VirtualXposed，不需要你ROOT手机的，把心放宽；然后打开VirtualXposed，从VirtualXposed的 “ 添加应用 ” 中找到JustTrustMe的apk安装包并执行安装，JustTrustMe是VirtualXposed的一个模块，所以安装完毕JustTrustMe后，记得在VirtualXposed的模块管理里勾选一下JustTrustMe模块，最后重启一下VirtualXposed让它生效。最后不要忘记了，你想对谁家app进行数据分析，你需要在VirtualXposed里重新安装一边这个app。你就把VirtualXposed粗暴当虚拟机对待就行了。 而iOS来说，听说传闻据说好像大概似乎传说就比较简单了，毕竟我手里没有iOS设备无法证实。大概就是在iOS里安装了青花瓷的根证书后，在系统安全选项里选择信任该证书就OK了，不需要安卓这么费劲。 ### 第二件事：【前任】和【前前任】 在【前前任】的时候我就一直致力于API安全问题，从最早的http协议裸奔到后来升级到https协议，然而这并有解决问题。因为有青花瓷们的存在，所以我们的API和数据依旧是还是没穿裤子在跑。后来，我决定学习一下业界标杆，看标杆的成绩咋样，也就是我的【前任】，然而，【前任】的表现实在是...优秀！ 我裤子都脱了，【前任】却给我展现了TA的铁裤衩，我贴图你们感受一下：  上述界面，我拿到的数据是这样：  没有对比，就没有伤害。看下【前前任】，你们感受一下：  比如上述界面（首先我要甩锅一下这是我离职很久后的新功能，与我无关，不是我做的）的数据，就白花花的一大片躺在你的面前：  十分友好贴切的把用户的经纬度以及详细地址都告诉你了，如果你真的十分喜欢这个用户，你一定会去这个地方蹲点守候的；你连蹲点守候都不愿意为TA做，你还敢说你喜欢TA？ ### 最后一件事：解决方案 回到正文上来，为毛【前任】的数据一坨黑乎乎的玩意？很明显，是加密过的数据咯。那么问题到这里，一般说来摆在你面前就两条解决方案了： - 对称加解密，比如AES - 非对称加解密，比如RSA 如果说用安全性更高的RSA来接解密，我估计你CTO会打死你的。第一个问题是用于RSA那一对公私钥的管理都特么是个问题；第二个问题是RSA真的需要你们堆CPU，我以前曾经做过一个RSA加解密的实验，机器配置一般，我运行了10，000次，加解密十几个汉字，你们猜用了多长时间？  如果说我们AES来解决这个问题，那么就是API和客户端需要持有一个相同的密钥。客户端访问了一个API后，API会用密钥将数据加密后发送给客户端，然后客户端再利用这个密钥解密还原数据。然而，这种问题情况下，密钥的安全性就成为问题了。服务器端倒是无用担心，主要是客户端的密钥一定程度上是有可能会被逆向看到的；如果说密钥可以定期更换，比如半个小时密钥就更换一次，但是密钥通过API下发本身就是一件很扯淡的事情。 那么，业界一般是如何解决这个问题的。注意，我没说【前任】怎么解决的，我说的是业界是如何解决这个问题。 这个世界上存在一种 “ 你看我一眼，我看你一眼，然后我们就心有灵犀拥有相同想法 ” 的高端实现，这种实现叫做密钥协商交换算法，关键字是DH和ECDH，好了，想知道具体原理的自己去搜，我就不负责科普了。 这种东西的具体表现大概就是： - API下发一坨无所谓保不保密的数据A给客户端 - 客户端提交一坨无所谓保不保密的数据B给API - 然后API和客户端就能各自计算出一个相同数字C - 利用AB计算出C是很容易的一件事，但是从C逆向出AB来则“ 蜀道难 ”。你别问我为什么，人家数学家证明出来的。 说到底就是利用非对称协商出一个对称密钥，上面提了半天的https就是这种理论的最佳实践！https实际上首先利用非对称协商出一对称加解密的密钥，然后开始利用这个对称加解密的密钥进行数据加解密。 辣么，DH或者ECDH这种东西如何应用到我们项目中来呢？不管出于啥理由，比如你想防止API被扒光裤子被人写出第三方客户端，又或者你们数据真的很金贵，又或者说你需要搞点儿KPI项目了... 下面开始进入安利时间，但是不涉及钱也不割韭菜，请不要紧张。无论你是处于学习还是尝鲜学习又或者是真的需要在你项目里部署这东西。我跟【东北大嫖客】和【于巨蛀】还有【阿尼特】搞了一个DH项目，目前已经情况如下：  项目地址：https://github.com/ti-dh 用来学习扩展一下视野甚至直接在项目里使用，是完全没有问题的，协议十分宽松，如果你对代码有想法可以欢迎提交issue或PR。 ### 后记 我在【前前任】的时候调研了很多解决方案，其中有ECC（只不过当时对这块儿东西的认识没有全面，不足以支撑一个清晰点儿的体系）。后来的事儿，就是我离职跑路了。所以所有调研中的、实施中的东西都直接halt掉了... 我刚到【前任】那会儿，做的第一件事情就是想确认【前任】的铁裤衩实现是不是和我预想的差不多。于是我就去API部门问一些仁兄们，由于我是刚去的再加上态度比较逗逼，所以他们误认为我是来偷代码的，在我解释清楚后就抛给我大概讲了讲...Got it check！... 我好像听到有人在背后说我是来骗github star的？ 本文搜索关键词：DH、ECDH、青花瓷（Charles）、VirtualXposed、JustTrustMe
