Android逆向之旅—Android中分析某音短视频的数据请求加密协议(IDA动态调试SO)第一篇

Android技术篇 尼古拉斯.赵四 29903℃

一、前言

最近萌发了一个做app的念头,大致什么样的app先暂时不说,后面会详细介绍这个app的开发流程和架构,不过先要解决一些技术前提问题,技术问题就是需要分析解密当前短视频四小龙:某音,某山,某拍,某手这四家短视频的数据请求加密协议,只有破解了加密协议,才能自定义数据请求拉回数据。不多说了,本文先来第一站搞定某音和某山这两个数据请求的加密协议,为什么说是这两个呢?因为我们在后面分析会发现这两个app其实用的是一套加密协议,毕竟这两个app都是某头条内部孵化的项目。所以只要搞定一个即可。我们决定搞定某音吧,毕竟我比较看好和喜爱看某音。

 

二、逆向分析

不多说了,赶紧来分析吧,不过本文不在利用粗暴的静态方式去破解了,应广大同学要求,就介绍IDA动态调试so来进行破解,这样也能给大家带来IDA的使用技巧。毕竟我写文章技术都是为了你们。这种分析请求数据的突破口一般都是抓包,这不用多说了。不过都是用了https请求,所以需要手动在设备中安装Fiddler证书,才能抓到正确的数据信息:

打开某音之后,看到数据刷的很快,发现一个feed的接口是返回的首页的数据,在分析它的请求参数中有三个字段是minCursor,maxCursor,count其实这三个字段就是后面他进行数据分页请求的关键,到后面再详细说。不过这里看到还没有什么问题,不过问题往下看他的更多请求参数,会发现两个字段:

这时候会发现其他参数都和本地设备有关或者直接写死的,唯独这两个参数信息是始终变化的。所以猜想这两个字段是用于请求协议数据加密和服务端进行校验的。那么如果我们想单独构造信息去请求,这两个字段的信息一定要正确,不然请求不到正确的数据的。好了,这里简单了,使用Jadx打开某音app即可,直接全局搜索字段的信息”as=”:

看到这里是构造了as和cp两个字段的值,直接点击进入即可:

这里大致的逻辑也比较简单,利用UserInfo.getUserInfo函数获取字符串,然后对半开给as和cp两个字段,右移操作就是除以2的意思。这里不分析代码来看看参数怎么来的,直接用Xposed进行hook这个函数打印参数看结果,粗暴快捷,以后其实这都是快速解决问题的一种方式,hook大法是最无敌的:

先来看一下这个加密方法的参数信息,看到是native的,也就是说加密操作是在so中做的,后面需要调试的也是这个so了。也不管了,hook这个方法然后打印信息看参数构造:

直接运行模块,打印日志看信息:

看到三个参数打印的值,发现大致三个参数的意义是:当前时间戳,请求url,请求参数的数组信息。好了,我们现在可以新建一个Android工程,然后构造这三个参数信息,然后调用它的so函数,为了找到这个so名称,全局搜索字符串信息”System.loadLibrary”即可:

这样就找到了这个so名称了,到libs目录下把这个so拷贝出来到我们自己构建的demo工程中,这里先不着急调试去分析native的加密函数功能,还是老规矩,拿来主义,直接上层构造一个和他一样的包名的native函数,调用它的so获取结果即可:

然后就开始构造参数信息了,这里为了简单,先把那些公共的参数信息写死,比如设备的sid,aid,版本号等信息:

这里我们利用公众参数信息,构造请求字段数组信息,然后还有单独的几个字段值不能参与操作,可以通过之前的打印日志分析出来。当然时间戳也是服务器格式,和本地是少三位的,直接除以1000即可。下面为了简单直接把公众参数写死即可,当然后续优化就是把这些参数值进行动态获取填充即可:

构造好参数之后,然后就开始调用native函数,然后获取返回结果即可:

到这里,我们构造的工作就完成了,下面就开始直接运行吧,不过可惜的是,没有这么顺利,直接运行闪退了:

这里应该进行加载so出现问题了,那么我在回过头看看我们是不是有些环境没初始化,看看UserInfo类中是不是还有一些初始化方法没调用:

这里看到的确有两个方法有点可疑,全局查看这两个方法的调用地方:

看到全局中就一个地方调用了setAppId方法,而且值就是写死的为2,另一个方法initUser就有点麻烦了,不过还是万能的hook大法,直接hook这个方法打印他的参数信息即可:

运行模块,查看打印的日志信息:

看到了,参数信息一致都是这个字符串信息,直接拷贝出来赋值调用即可:

 

三、IDA调试SO

在次运行,发现可惜了,还是报错,而且诡异的是日志没打印,也就说setAppId和initUser函数没有调用就退出了,那么就会想到?是不是so中的JNI_OnLoad函数中做了一些判断逻辑呢?直接用IDA打开这个so文件即可:

打开之后找到JNI_OnLoad函数,F5查看他的C代码,发现果然内部有很多判断,然后直接调用exit函数退出了。所以如果想成功的调用它的so方法,得先过了他的这些判断了,这里就要开始进行调试操作了,其实这里可以直接静态分析有一个快捷的方法,但是为了给大家介绍动态调试so技巧,就多走点弯路吧,后面再说一下粗暴简单的技巧。

下面就来开始进行调试so文件了,关于IDA调试so文件,我之前已经写过一篇非常详细的文章了:Android中IDA动态调试so文件详解;这里不会在详细介绍具体步骤了,直接上手干:

第一步:拷贝IDA安装目录下的android_server文件到设备目录下

第二步:运行android_server命令

第三步:转发端口和用debug模式打开应用

这里有同学好奇为什么不需要修改xml中的debug属性呢?因为我调试的是我自己的demo工程,而Eclipse默认签名打包出来的apk这个属性值就是true的,所以不需要进行修改了。

第四步:启动IDA附件进程

设置本地地址和一些选项:

因为现在已经知道需要调试JNI_OnLoad函数,所以需要设置挂起load函数处,然后选择调试的应用进程:

第五步:查看调试端口连接调试器

在Eclipse中的DDMS中查看有红色小蜘蛛的调试应用端口号是8647,然后连接调试器:

这里一定注意端口正确,不然链接操作的。

第六步:点击IDA中的运行按钮,或者F9快捷键

这时候发现红色蜘蛛变成绿色了,而且调试对话框也没有了。这时候就进入调试页面了:

为了安全起见,再一次查看debug选项有没有挂起load函数:

如果发现没有,还需要进行手动勾选上:

因为我们给JNI_OnLoad函数挂起了,而一个应用会加载很多系统的so文件,所以这里一直点击运行或者F9:

过了系统so加载步骤:

这些都是系统的so文件加载,所以一路往下都直接运行越过调试即可:

可以看到这里会加载很多系统的so文件,当我们点击应用的按钮,加载自己的libuserinfo.so文件的时候才开始进行调试工作:

点击OK加载进来,然后就停留在了挂起状态了,这时候,我们在右侧栏查找这个so文件:

然后点击,继续查找他的JNI_OnLoad函数:

点击进入JNI_OnLoad函数处,下个断点:

因为我们在之前静态分析了这个函数内部有很多个exit函数,为了好定位是哪个地方exit了,所以在每个exit函数之前下个断点,来判定退出逻辑,这里下断点有技巧,因为是if语句,所以在arm指令中肯定就是CMP指令之后的BEQ跳转,所以在每个CMP指令下个断点即可,这里发现了9个地方,所以下了断点也很多,慢慢分析:

第一处的CMP指令下个断点,然后运行到此处,查看R3寄存器值是否为0:

是0,那么第一处exit就没问题,接着往下走,直接按F9到下一个CMP判断指令断点处:

发现第二处的CMP中的R3寄存器值也是0,所以也没问题,直接F9到下一个断点:

到了第三处判断发现R3寄出去你的值不是0了,而是1,所以为了继续能够往下走,就修改R3寄存器值即可,在右侧栏的寄存器中右击R3寄存器,然后点击修改值:

把1改成0,保存即可:

修改成功了,运行发现就过了判断:

就继续往下走,到下一个断点:

这里有问题了,我们如果直接F9到第四处CMP的话,发现直接退出调试了,说明在3和4处判断中间有问题了,最终发现是这个跳转指令出现的问题,这里需要多次单步调试F7键,定位出现问题的地方了,我们进入这个跳转地址:

然后发现内部还有BL指令,出现问题了,继续深入查看:

看到了,这里发现问题的原因了,有一个GlobalContext类,这个类应该是Java层的,native层应该用反射机制获取全局的Context变量,我们直接去Jadx中搜索这个类:

那么问题就清楚了,因为我们的demo工程中压根没这个类,所以native中获取全局context变量就失败了,所以就exit失败退出了,解决办法也简单,直接在demo工程中构造这个类,然后在Application中初始化context即可:

构造的时候一定要注意包名一致,然后在demo中的Application类进行设置context即可:

然后再次运行项目,可惜还是不行,所以还得进行调试JNI_OnLoad函数了,方法步骤和上面类似,不多说了,不过这里应该是过了上面的Context获取失败的问题了,继续往下走,发现了重要信息了:

这里有一个类似于MD5的值,继续往下走BL处:

看到R0寄存器中的值,发现是demo应用的签名信息,继续往下走BLX看看:

这里看到大致清楚了,是获取应用签名信息,也就是签名校验了:

好吧,在这一处判断exit函数中,应该是通过反射获取Java层的context值,然后在获取应用的签名信息和已经保存的原始某音签名信息做对比,如果不对就退出了。那么过签名校验也很方便,直接利用我之前的kstools原理,把hook代码代码拷贝到工程中,拦截获取签名信息,然后返回正确的签名信息即可:

具体的hook代码去看我的kstools实现原理即可:Android中自动爆破签名信息工具kstools;然后hook代码一定要在Application的第一行代码调用,不然没有效果的。这样操作完成之后,其实已经出数据了,不过为了能够进入加密函数进行调试分析具体的加密算法,我们继续调试JNI_OnLoad函数:

继续往下走,会发现在第五个exit判断之后,有一个函数出问题了,就是这个BL,进入内部查看:

哈哈,发现了这个字符串信息,弄过调试的同学大致都猜到了,这个是反调试操作,继续往下走:

这里可以百分百确定是读取status文件中的TracerPid字段值来进行反调试检测了,给下面的两个CMP指令下个断点:

发现R3寄存器中的确不是0,所以为了过了反调试,直接修改R3寄存器值为0即可:

这样就过了反调试检测了,单步往下走到下一个exit的判断断点,最终还有一个地方需要处理就是第七个CMP指令:

处理方法直接修改R3寄存器中的值为0即可,就这样我们成功的过了JNI_OnLoad中的所有判断exit的地方了:

然后给加密函数getUserInfo下个断点:

直接点击进入即可:

 

四、加密结果输出

也成功到达了加密函数断点处,这里已经没有任何判断逻辑了,就是一个单纯的加密函数了,不过这里不在进行调试分析了,感兴趣的同学可以自己操作了,因为我们的目的达到了,就是成功的获取到了加密之后的数据了:

看到了,我们成功的获取到了as和cp值,然后构造到请求url中,也成功的拿到了返回数据。我们这里多了一步解析json数据而已,原始的json数据是这样的:

之所以要解析,也是为了后面的项目准备的,到时候我会公开项目的开发进程。不管怎么样,到这里我们就成功的获取某音的加密信息了。主要通过动态调试JNI_OnLoad函数来解决so调用闪退问题,在文章开头的时候说到了,其实本文可以直接用简单粗暴的方式解决,就是万能大法:全局搜索字符串信息,这里包括Jadx中查找和IDA中查看,因为字符串信息能给我们带来的信息非常多,有时候靠猜一下就可以定位到破解口了,比如这里,我们在IDA中使用快捷键Shift+F12打开字符串窗口:

凭着这些关键字符串信息就能断定so中做了哪些操作。记住这些敏感的字符串信息,对日后的逆向非常关键。

 

五、技术总结

上面就解决了某音的请求数据加密信息问题了,下面来总结一下本次逆向学习到的技术:

  • 第一、看到在native层用反射去调用Java层的方法获取信息也是一种防护so被恶意调用的方式。比如本文的context变量获取。
  • 第二、签名校验永远都不过时,其实本文当时没想到他有签名校验,因为看到native函数中都没有传递context变量,谁知道他是用反射调用Java层方法获取的,长知识和经验了。
  • 第三、反调试也是永远不过时的,不过他这里的反调试检测有点简单了,就一处而且就一个进程,如果高级点应该启多个进程,循环检查tracepid值进行校验,会增大难度。
  • 第四、在逆向中有时候在Java层没必要去花时间分析一个方法的参数和返回值构造情况,直接利用Xposed进行hook大法打印方法的参数信息靠猜也就出来了。
  • 第五、静态方式分析永远都不会过时,全局搜索字符串也是最基本法则,靠猜就可以快速获取结果。

六、某山小视频加密分析

上面解决了某音的加密问题,下面再来看一下某山小视频的加密信息,突破口依然是使用Fiddler进行抓包查看数据:

通过抓包会很神奇的发现,和某音的数据结构字段几乎异曲同工,果然是自家兄弟,继续查看他的加密字段:

不想多说了,既然加密的字段都是一样的。那么我们直接不多说用Jadx打开某山小视频,看看他有没有那个native类UserInfo信息:

哈哈,看来不用多一次分析了,完全一样,那么直接用同一个so,同一个加密即可,在demo工程中运行查看日志:

初始化都是一样的,直接运行:

看到了,数据也回来了,看看他的原始json数据:

到这里,我们就成功的破解了某音和某山小视频的数据请求协议了,有了这两个短视频数据,后面我们开发app就简单了,当然在文章开始的时候也说了,现阶段短视频四小龙:某音,某山,某拍,某手,那么已经干掉了前面两个,下一个是谁呢?猜对有奖。争取在年底把这四个app全部爆破成功,能够请求到他的数据。为我们明年的app作为基础

严重声明

本文的意图只有一个就是通过分析app学习更多的逆向技术,如果有人利用本文知识和技术进行非法操作进行牟利,带来的任何法律责任都将由操作者本人承担,和本文作者无任何关系,最终还是希望大家能够秉着学习的心态阅读此文。鉴于安全问题,样本和源码都去编码美丽小密圈自取!

七、总结

通过本文可以发现,我们其实没有真正意义上的破解它的算法,但是结果却是我们想要的,这就够了。而对于现在很多app把加密算法放到so中,在对so做一些防护,这样就很难利用本文的技术去调用app的so了。不过so再怎么防护就是那么几种方法,我们依然可以用动态调试来解决。有人在文中很好奇,那些判断校验不能直接修改so指令做到吗?比如签名校验,没必要在Java层进hook呀,直接修改CMP和BEQ指令呗?的确可以这么做,但是这是下一篇介绍的内容,因为我们下一篇要破解下一个短视频app,就用到这种方式过校验。敬请期待!

《Android应用安全防护和逆向分析》

点击立即购买:京东  天猫

更多内容:点击这里

关注微信公众号,最新技术干货实时推送

编码美丽技术圈
微信扫一扫进入我的”技术圈”世界
扫一扫加小编微信
添加时请注明:“编码美丽”非常感谢!

转载请注明:尼古拉斯.赵四 » Android逆向之旅—Android中分析某音短视频的数据请求加密协议(IDA动态调试SO)第一篇

喜欢 (68)or分享 (0)