码迷,mamicode.com
首页 > 移动开发 > 详细

Android中一个有趣的crash的日志分析

时间:2019-02-19 10:20:17      阅读:252      评论:0      收藏:0      [点我收藏+]

标签:roi   程序   全局   状态   其他应用   访问   启动   简单   ESS   

 很久前写的一篇文章,发出来以作纪念:)

Android中一个有趣的crash的日志分析

首先看看bugly平台中异常的统计信息,表面上是一个NullPointerException:

技术图片

发生异常设备统计信息如下图,有意思的是全部都是root过的机器:

技术图片

接下来看跟踪日志,在最下面可以看到这样的日志,抛出了NullpointerException:

技术图片

引起异常的是com.lishu.net.LishuNet$2类,从类名看显然是某一个类的内部类。

第一个反应,当然是搜索一下应用的源代码,看看是不是有com.lishu.net.LishuNet这样的类,或者异常。如果有,那自然就是继续分析代码了。经过一番搜索,居然没有找到,看来有点意思。

其次自然想到,应用集成了很多第三方SDK,或许是某个SDK里抛出的异常?不急,解压出所有集成的.jar包,然后批量反编译,导入工具中全局搜一下,有没有这个字符串了。费一番周折发现,还是没有这个字符串。越来越有意思了,代码中没有相关的类,SDK中也没有,奇怪。

回来继续翻看日志上下文,只有如下信息可用,看来是个http访问超时异常:

技术图片

有问题,这个异常和其他异常不太一样,日志里居然连com.chebada包名都没有显示出来的。也许是统计平台出错了,压根不是我们应用导致的crash?

只有抛异常前打出来的一行日志,看起来有些关系

技术图片

访问这个网址看看,有时连不上,有时拒绝服务。源代码里也没有这样的网址。

这个时候线索好像真的断了,再搜索日志,看不出来和我们的应用有什么关联。

还是没有思路,再翻一下其他异常,发现异常列表中有些日志会打出来类似下面的内容,之后再访问上图中的网址(http://120.24.74.141:8080/lishu008AppManager/phone/LogicSimpleAction.action):

技术图片

总结多个crash日志,发现每次都是先有这个js警告,再访问120.24.74.141域名。

js又是/data/data目录com.chebada包下的脚本,也许,是WebView的访问触发了相关异常,或许是url劫持?也不像。统计平台异常列表中有些并没有报这个js警告,问过服务器相关同事,js也没有访问http://120.24.74.141:8080/lishu008AppManager这样的网址。

不过所有crash日志都有访问http的超时异常。

疑点都集中在http://120.24.74.141:8080/lishu008AppManager这里。

继续万能的百度搜索,lishu008AppManager露出一点端倪。有一个名叫“008神器”的安卓应用引起了我的注意,该下载链接中有lishu008AppManager字样。打开主页看看该应用能干什么,结果吓一跳:

技术图片

下载一个看看,运行需要root过的机器。 找了一台root过的机器,运行后按提示安装框架、安装模块。期间需要重启几次。

需要的框架、模块都安装好了,再次运行,提示软件到期。卸载重新下载一个破解版的“008神器”,运行后发现,能改的东西还真多,连手机串号也能改:

技术图片

这个时候看看日志,发现了LishuNet的踪迹:

技术图片

等等,“008神器”的包名不是com.soft.apk008Tool吗,怎么会报com.lishu.net.LishuNet错误呢?反编译apk安装包,原来,除了com.soft.apk008Tool,还有另一个包com.lishu.net这个包,其中有LishuNet这个类,LishuNet还有一个内部类com.lishu.net.LishuNet$2,继承自Thread:

技术图片

显然在该线程中触发了NullPointerException异常。往下跟跟,具体打印出异常的地方:

技术图片

这个就是在连接http://120.24.74.141:8080失败时,比如连接超时、服务器拒绝服务等异常情况下,打印出异常信息的地方了。原来只要连接出错,就会打印出错信息。

除了反编译代码中有com.lishu.net这个包,在 “008神器”安装包的assets文件夹下还发现了Apk008Tool.apk这个安装包,安装后会多一个“008神器工具箱”的应用。再反编译“008神器工具箱”,原来com.lishu.net是“008神器工具箱”的包名,而“008神器”中com.lishu.net包下的代码,都是从Apk008Tool.apk来的,最有可能的就是,“008神器”和“008神器工具箱”是同一个作者开发的。

那是什么触发了异常呢?各种尝试,后来发现运行“008神器”,就会访问网址http://120.24.74.141:8080/lishu008AppManager/phone/LogicSimpleAction.action,接着log中就能看到异常信息,过滤后显示如下图:

技术图片

原来只要运行“008神器”就会报异常。继续跟踪com.lishu.net.LishuNet:

技术图片

LishuNet对象调用postMessage()方法,在该方法中new一个LishuNet$2的对象,也就是新建了一个Thread线程,并开始运行。异常就是从这个线程里抛出来的。

那么,哪里调用了LishuNet的postMessage()方法呢?继续搜索,原来是在Apk008Activity的onResume()中:

技术图片

其他地方也有调:

技术图片

稍微跟踪一下代码,会发现,在“008神器”启动、启动其他应用、网络状态变化、调用工具箱修改了系统属性值时,验证“008神器”的签名时,等等,都会触发这个线程,调用postMessage()方法,向http://120.24.74.141服务器发送特定数据。以启动“008神器”应用发送的数据为例:

技术图片

启动时发送的数据是手机的IMEI、系统版本号、系统版本名称。其他不一一列举。

原来异常是和我们的应用没有关系的,可以这样验证:卸载我们的应用,单独运行“008神器”时,log中依然会不停的报com.lishu.net.LishuNet$2的这个异常。

Bugly中报这个异常,极有可能是因为,bugly统计平台的SDK在安卓系统log中恰巧同时检测到了com.chebada,和com.lishu.net.LishuNet抛出的异常,就将两者结合,视为com.chebada的bug了。这也可以解释,为什么几千条LishuNet$2抛出的异常,没有统一的错误信息。后续有时间再反编译看看bugly统计SDK的代码,验证一下。

至于解决方法,实现起来就简单了,既然改不了框架层的东西,就在应用层修改。在应用启动时判断,如果存在“008神器”或“008神器工具箱”,就退出应用。OK,打完收工。

当然,如果使用008神器或者xposed框架接口,在系统服务层API屏蔽了008神器应用,那使用这种方式就不起作用了。

 

 

附:

“008神器”工作原理引起了我的好奇,各种改系统功能是怎么实现的呢?经过学习发现,是利用了xposed框架,而xposed框架是需要root权限才能正常运行的,这也解释了为什么报这个crash的设备全部都是root过的了,没有root权限,“008神器”就没法正常工作。

Xposed框架是开源的,不过作者(也是Supersu的作者)好久没有更新了,所以该框架只支持安卓4.0.3-4.4版本的系统,这个可以解释统计平台设备版本分布情况:安卓系统4.4版本以上信息不会报这个异常。

有兴趣的同学可以学习研究下这个框架,框架基本原理是修改了安卓系统的心脏zygote,等于在安卓的Java虚拟机上加了一个接口,这个接口为框架修改系统、提供系统级的服务提供了支持,当然,如果拿来搞破坏,其威力也是相当惊人的,可以在应用不知情的情况下,肆意获取输入的用户名、密码等敏感信息。下图是我写的框架Demo程序运行结果截图,拦截了应用登录页面输入的用户名、密码信息:

技术图片

经本人实验,不修改第三方应用、不经用户同意,就可以在应用运行时动态拦截、修改应用的数据,并完全可以做到开启后台线程,将用户的数据发送至特定的服务器。

Android中一个有趣的crash的日志分析

标签:roi   程序   全局   状态   其他应用   访问   启动   简单   ESS   

原文地址:https://www.cnblogs.com/areful/p/10399409.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!