逆向分析XX校园，手把手带你云返校！Ruger的博客-

背景

       现在很多地方的大学都已经有条不紊的开学了，已经开学的同学们都忙着拍毕业照片，按期参加毕业典礼，在寝室享受着最后的大学时光。然而我所在的大学却因卫生不合格，不能按期开学，眼瞅着就要毕业了，想想在家云毕业心里就很憋屈。从疫情开始，学校就让我们每天都使用XX校园打卡登记健康情况与位置信息，既然学校不让我们回去，我就在想能不能通过修改位置信息来实现云返校，学校虽然限制了我的肉体不能返校，但我的精神却永远是自由的！// 很奇怪的动机。

尝试抓包

       既然是获取位置信息，现在市面上的应用差不多都使用了第三方网络接口，最后再将结果提交到服务端。既然如此，我就先尝试用Charles抓包一下试试。这里如何使用解析HTTPS数据包我就不多说了，网上教程一搜一大把。

       在安装完证书并设置代理后，再次打开应用时发现抓包失败了，说明应用本身应该是做了证书校验。可以使用Xposed的JustTrustMe来跳过证书校验，JustTrustMe简单的来说就是Hook所有证书校验API，通过篡改数据来跳过证书校验过程。这样的话，想要抓包就必须要把手机Root了，并需要安装Xposed和JustTrustMe，而且高版本Android手机可能系统API都已更改了不能进行Hook，很是不爽。

       出于学习目的，这篇文章将继续分析，看看能不能不使用Hook手段来完成跳过证书校验过程。
       看来想要解决这件事情必然是要对整个应用进行逆向分析了。

逆向分析

       apk文件其实就是一个zip格式数据压缩包，解压后存在三类二进制文件：dex文件、AndroidManifest文件与recourse.arsc文件。
这里简单对这三类文件进行介绍一下

1. dex文件
   也就是dalvik字节码文件，Android5.1之前跑在Dalvik虚拟机上，Android5.1之后跑在ART虚拟机上，是由Java字节码转化而成，记录着项目的所有类结构以及代码逻辑。
2. AndroidManifest文件
   对应着项目中的AndroidManifest文件，记录着四大组件的配置信息，以及权限的声明，与项目中的AndroidManifest文件不同的是，这里是以二进程进行存储，所占用空间更小，解析速度更快。
3. resource.arsc
   ARSC文件则记录了项目中的所有资源信息，包括各种布局、动画以及字符串数据等等，同时也记录着资源与resID的映射关系。

       现有的apktool工具以及jadx均是根据文件的格式文档来对这些文件进行二进制逆向解析。不同的是Jadx使用ASM技术动态生成Java字节码便于对项目代码逻辑进行分析, 分析java代码可比smali代码容易多了。这里我使用了jadx工具完成对apk文件进行逆向解析

       惊讶发现这个下载量超800万的应用居然没有做任何安全防护，源码没有进行混淆就进行了发布，业务逻辑完全暴露出来，丝毫没有安全意识。既然这个应用敢这样做，那我们就可以放开手脚开搞了。我们首先对AndroidManifest文件进行分析修改，把调试开关打开，方便后续动态调试，更清晰地了解业务逻辑。

       修改完成后回编译，重新签名
       这里签名工具使用的jarsigner，数字签名是自己用keytool生成的，具体流程网上也是一搜一大把。重新签名之后，将原来的app卸载重新安装，替换新的公钥

可以进行动态调试了

证书校验

       证书校验的API还是比较多的，但是一般都会将自己所信任的校验证书存放本地，等待创建网络请求实例时动态进行绑定，这也为我们逆向分析提供了一个很好的思路，首先我在项目文件夹中搜索cer看看会有什么有用信息

       居然还真发现了一个文件夹叫做cacertList，我们进入这个文件夹看看里面有什么

       可以看到这里有一堆以:<hash_name>.0命名的文件，这个其实是pem格式证书的命名方法，我们可以在/system/etc/security/cacerts中发现很多这样的文件，这些文件都是系统在出厂时所预先安装的数字证书。文件命名中前面的hash_name是使用特定的hash算法计算得到的，可以使用openssl来计算生成(后面会介绍)，后面的数字则是避免证书hash_name重复，因为hash_name可能会出现碰撞的case。我们可以猜测这里存放的是项目信任的所有证书。为了验证，我在项目中搜索cacertList看看能不能获得什么有价值的信息

       这里会遍历读取这个文件中的所有文件，然后将每个文件的字节数组存放到一个名为CERTIFICATES_DATA的List中，我们可以继续看看这个List在哪里会被读取



       可以看到，在所有创建okHttp请求实例时都会设置这个文件夹的所有证书内容，为了确保分析的准确性，接下来采用断点动态调试来验证。我们在读取证书时加断点，看看什么时机会进行读取。

       当我点击应用时第一时间就会被断点拦截，可以猜测这里应该就是本项目所信任的所有证书存放位置，接下来就比较好操作了，我只要把pem格式的charles证书放到里面，然后计算hash_name后更改文件名称，然后回编译重新签名就可以了。


       这里可以看到抓包成功了，成功绕过了证书校验，接下来就是篡改位置信息了，想想马上就可以云返校了还是蛮激动的！

位置修改

       首先我们看一下提交页面是哪一个Activity。

       可以看到，当我们进入提交页面后栈顶activity名为BrowsePageActivity，看到这个Browse使我瞬间联想到这可能是一个webView，为了确认这件事情，我们去项目的BrowsePageActivity.java文件来寻找答案。

       果然没猜错，确实是使用了webView来加载提交页面，其实想想也觉得是应该的，毕竟这个app并不是完全为了我们打卡用的，所以项目代码中确实不应该耦合打卡页面。虽然使用了webView，但是最终还是离不开第三方定位api。
我们抓包看看这个项目到底使用了哪家api来完成定位的。


       可以看到这里同时使用了高德地图和百度地图进行定位，但是高德地图鉴权失败了，但是百度地图却正常返回了。
       这次猜测可能是新版本app替换了高德地图的公钥，但根据我实际测试发现，这个高德定位仅作为表单展示时使用，最后提交仍然使用的是百度地图所获取的位置信息，所以我们修改百度地图返回数据即可。首先我将正常返回的response数据拷贝了一份，然后对其进行修改。

       接下来使用Charles的map local功能实现网络请求数据的重定向。

       可以看到数据已经重定向成功了，只要点击提交就可以了～！

       哈哈，成功空降学校附近，云返校愿望达成～！

总结

       这篇文章主要介绍在XX校园中如何绕过证书校验完成数据抓包并进行篡改。本文仅以学习目的，不想涉及到任何利益纠纷，所以这里就不散播修改后apk文件了，以免后面被请去喝茶，感兴趣也想篡改地址信息的小伙伴可以私信联系我进行获取。

严重说明

       本文的目的只有一个就是学习逆向分析技巧，如果有人利用本文技术进行非法操作带来的后果都是操作者自己承担，和本文以及本文作者没有任何关系。