frida如何抓apk网络包

今天给大家介绍一下frida如何抓apk网络包。文章的内容小编觉得不错，现在给大家分享一下，觉得有需要的朋友可以了解一下，希望对大家有所帮助，下面跟着小编的思路一起来阅读吧。从系统的角度去寻找hook点，而不是为了抓包而抓包。上面是okhttp官网的一个demo，关键代码就在client.newCall。从此处接口调用开始，终会调用至okhttp框架, okhttp本是sdk，后来aosp已经集成至系统，所以可以归类至框架层。框架层不详述，主要就是这几个java类:其实client.newCall终会通过URL获取一个connection这里的urlConnection其实就是HttpURLConnectionImpl的实例，该类有getInputStream getOutputStream方法，内部分别会调用HttpEngine的getBufferedRequestBody，getResponse。刚开始我尝试hook过这两个接口，比如hook getResponse后，可以将response打印出来.之后我发现Request只能打印header，并不能打印body。所以又埋头继续分析，getBufferedRequestBody这个函数刚好可以入手，获取一个sink，最后以RetryableSink为突破点，比如hook 其write函数就可以将body打印出来。write函数对应于app层面的urlConnection.getOutputStream().write。后来发现一个Request,调用getBuff免费云主机域名eredReuqestBody函数可能不止一次，所以会有数据重复的问题，后来我又寻找到了CacheStrategy$Factory.get点进行Hook，发现还是有数据重复。发现以上hook均有弊端数据重复非okhttp调用无法抓取接着又继续从native层的send,sendmsg,write,recv,read打印调用栈。最后折腾了三天，决定放弃治疗，还是采取工具吧。android.util.Log不打印匿名内部类获取成员需要反射android.os.Bundle打印，需要将Bundle unparcel踩到的坑其实不只上面的，刚开始也百度过一些frida网络拦截的方案，还仔细的研究了okhttp的Interceptor方案，最后发现app也是用了拦截器，所以就发生冲突，导致无法使用该方案。也纯粹的分析过app的smali，寻找调用栈以及网络请求，最后，只有几个比较小的收获，可能对读者没有用处，不过记录一下，方便自己以后回忆。java.net.URL拦截拦截app调用http请求前使用json的地方，这只是其中之一trace http相关classRequest$Builder拦截property_get拦截分析adb log,进程有 java.security.cert.CertPathValidatorException的打印，之前也看过一些frida拦截抓包绕过证书的帖子。先试一把暴力搜索：调用verify直接暴力返回true，依然无法登陆，报错是同样的ssl问题。百度搜索后找到了答案。apktool解包，然后修改重打包签名后运行一把，fiddle抓到了包，app也能正常登陆了，这次也是运气好吧，app的ssl校验只有单向app校验，服务器并没有进行校验。从周二下午一直折腾到周五，最后从系统层面的HttpEngine寻找hook点并不是很好的方法，弊端也已明了。所以趁着周日的时间，再试一下各种百度到的方法—-抓包工具，然后一步步将遇到的问题pass掉。下面是抓到的两个包：以上就是frida如何抓apk网络包的全部内容了，更多与frida如何抓apk网络包相关的内容可以搜索云编程开发博客之前的文章或者浏览下面的文章进行学习哈！相信小编会给大家增添更多知识,希望大家能够支持一下云编程开发博客！

相关推荐: 交换机CPU负载高达90%以上（一）【新任帮主】

交换机CPU负载高达90%以上（一）一.前言自从工作以来 ，接触了很多的项目，也遇到了无数多的问题，有些问题看似很奇葩，其实从理论上来解释都是行的通的，当然我们排除是设备或是软件自身的bug问题，因为这样的问题令人很恶心，想必同道中人 也是深有感触吧；总结这几…