Android Studio Analyze APK 一直显示 Parsing Manifest探因及解决

一、背景

大家都知道,Android Studio开发工具自带了Analyze Apk,可以很方便的分析Apk文件。具体位于菜单build >> Analyze APK...路径下,点击后可以选择目标路径下的Apk文件,甚至可以直接将目标APK文件直接拖拽到Android Studio中,不到几秒中时间,马上就会生成对应的分析结果。

例如,微信Apk分析结果是这样的:

 

又如,支付宝Apk分析结果:

 

瞬间感觉自己很niubility,有没有?

有时候,我们也经常用它来分析自己的Apk,例如,生成的安装包到底长什么样子,里面的资源/代码构成,Manifest中配置是否如预期,又或者方法数,等等。但是,一次突然的机会,发现自己开发的Ap分析不了,一直处于Parsing Manifest状态。

 

 

一脸懵逼,有木有?

 

二、探因

这个问题曾经困惑了我不少时间,之前也没有具体去研究过。现在又遇到了。瞬间想到鲁迅说的一句话:

技术路上,会遇到很多看似莫名其妙的问题。
细心探究,解决了,就是成长。
无视它并避让过去,看似绕过了问题,
实际上失去了一次很好的技术历练的机会。
并且下次很可能还会遇到类似的,甚至一样的问题,
长期看将是困难和停滞。
复制代码

 

 

既然先辈都这样说了,那,硬着头皮解一下?

2.1 AS日志

现在给人的感觉是Analyze APK执行过程中直接停住了,后者长时间一直在分析。但不管怎样,毕竟是在AS中的操作,先查一下对应的AS日志,看看有没Parsing Manifest或相关的日志信息,可以起到帮助的。

Help >> Show Log in Finder,打开日志,对应时间点看了又看,没找到Parsing Manifest直接相关的,不过,找到了控件显示先关的日志:

2019-08-08 19:21:25,323 [entQueue-0]   INFO - ools.idea.apk.viewer.ApkEditor - Disposing ApkEditor with ApkViewPanel: com.android.tools.idea.apk.viewer.ApkViewPanel@7a608115 
2019-08-08 19:21:25,323 [entQueue-0]   INFO - s.idea.apk.viewer.ApkViewPanel - Cleared Archive on ApkViewPanel: com.android.tools.idea.apk.viewer.ApkViewPanel@7a608115
复制代码

从日志里面可以看出来,AS中对应的Analyze Apk相关的类名有ApkEditorApkViewPanel,包名是com.android.tools.idea.apk.viewer。AS日志部分的有效信息只有这么多了。

2.2 系统全局搜索

AS日志中没有,那有没有可能存在有效的信息输出在了系统其它的地方?于是,直接花点时间,系统全局搜索下。

/ grep -rnl "Parsing Manifest" *
复制代码

输出信息中有一些警告信息之类的,最终在输出信息中找到了个相关的:

Applications/Android Studio.app/Contents/plugins/android/lib/android.jar
复制代码

看目录名,大概是AS插件中对应的Android相关的lib工具包。找到对应位置,用JD-GUI打开对应的jar文件,具体看下一下。

通过全局搜索关键字Parsing Manifest,的确可以定位到具体的ApkViewPanel类,且包名与上面AS日志中都能对的上,但字节码反解成java过程中有内部错误。尝试着用用jadx打开,因为android.jar包还挺大,时间比较长,、最终虽然ApkViewPanel部分内容可以显示,但内部依然有部分内部错误无法显示,且Parsing Manifest不能直接显示。

 

2.3 GitHub定位与源码分析

不过没关系,我们试着去找找源码看看。搜索对应包名:com.android.tools.idea.apk.viewer,选择java类别,很快,我们找到了对应的源码位置。

github.com/JetBrains/a…

 

正好,AS就是JetBrains主导的产品,Perfect!

很快,我们找到了对应Parsing Manifest的位置:

 

setAppInfo()方法中,将对应的控件内容从原来的Parsing Manifest改成了对应的包名和版本号等信息。

 

显然,在代码myNameComponent.append("Parsing Manifest");setAppInfo(result);之间,程序出了问题。

这之间关键的类,主要有apkParser对象对应的ApkParser类,还有Archives类。继续跟踪ApkParser类,发现其主要也是一个外壳性质的类,apkParser.constructTreeStructure()方法主要流程来到如下所示位置:
现在,我们发现,无论是此处的ArchiveTreeStructure类,还是之前的Archives类,这两个关键线索上的类都不是在这个项目中。根据代码文件中的import导入,很快,我们发现,线索被定向到了com.android.tools.apk.analyzer包中。

 

从包名上来看,com.android.tools.apk.analyzer应该是Android Tools中带的一个工具。来到项目iml文件,我们发现与之相关的构件。其中,组名是:com.android.tools.apkparser,构件名是:apkanalyzer

 

2.4 工具本体-apkanalyzer

至此,我们先总结下问题的原因。

AS中自带的Analyze APK,实际上是通过集成了插件实现,而插件内部,又通过调用了 Android Tools中的名叫apkanalyzer的工具实现的分析。因此,想要追溯出现问题的原因,我们需要再去对应追踪下apkanalyzer

如果熟悉Android Tools,我们对应去tools目录下找找,很快便能找到apkanalyzer。及时不熟悉,不知道目录位置也没关系,打不了全局搜索下。

 

终于,对应的工具本体出现在我们面前。

实际上,如果对Google Developer比较熟悉,或者直接在上面搜索下,也能直接在Analyze APK页面上找到核心信息,直接指向工具本体—apkanalyzer
developer.android.com/studio/buil…

 

啊哈,饶了半天,原来官方文档上直接有啊,哭了,有木有?

 

 

同样的,通过反编译工具查看apkanalyzer.jar代码终究不太方便,且内部也有不少INNER ERROR。于是,我们继续去GitHub上找找。

GitHub上搜索到的apkanalyzer相关的零零散散,好像都是个人的,不太官方,也不符合我们的预期。怎么办呢?

源码不够,Google Source来凑!

直接Google Source搜索可能的关键字,马上得到了结果。

 

 

 

显然,这正是我们需要的。

但此时,如果直接源码跟踪下去,还是有难度的。

2.5 apkanalyzer查因

apkanalyzer作为一个工具,是独立的。在实际使用时可以直接脱离AS环境,Google Developer官网上也有专门的篇幅进行了介绍。
developer.android.com/studio/comm…

实际使用时,我们通过不同的命令行命令及参数,可以得到我们期望的结果,如用来分析APK基本属性,Manifest,dex或资源等。

由此,我们可以多试几个,反正AS中Analyze APK最终用的也是它。在一定的命令上,结果肯定是一样的。也就是说,通过命令行直接执行apkanalyzer,肯定也会有问题,但有个好处时,命令行执行往往都能抛出对应的错误日志。

有了进一步的错误日志提示,就有了异常栈和关键性的真正的错误原因信息。

那我们就试一试吧。

➜  bin apkanalyzer -h apk file-size Corn-dev-debug.apk
46.9MB

➜  bin apkanalyzer apk summary Corn-dev-debug.apk
com.corn	10300	10.3.0.0

➜  bin apkanalyzer manifest print Corn-dev-debug.apk
<?xml version="1.0" encoding="utf-8"?>
<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="10300"
    android:versionName="10.3.0.0"
    package="com.mymoney"
    platformBuildVersionCode="27"
    platformBuildVersionName="8.1.0">

    <uses-sdk
        android:minSdkVersion="19"
        android:targetSdkVersion="26" />

    <uses-permission
        android:name="android.permission.GET_ACCOUNTS"
        android:maxSdkVersion="22" />

...
...
...
复制代码

说明直接分析Manifest文件都是没有问题的。

➜  bin apkanalyzer dex list Corn-dev-debug.apk
classes7.dex
classes6.dex
classes5.dex
classes4.dex
classes3.dex
classes2.dex
classes.dex
复制代码
➜  bin apkanalyzer resources configs --type drawable  Corn-dev-debug.apk
anydpi-v21
anydpi-v26
default
watch-v20
v21
v23
ldpi-v4
mdpi-v4
ldrtl-mdpi-v17
hdpi-v4
ldrtl-hdpi-v17
xhdpi-v4
ldrtl-xhdpi-v17
xxhdpi-v4
ldrtl-xxhdpi-v17
xxxhdpi-v4
ldrtl-xxxhdpi-v17
复制代码
➜  bin apkanalyzer files list Corn-dev-debug.apk
Exception in thread "main" java.util.zip.ZipError: invalid END header (bad central directory offset)
	at com.sun.nio.zipfs.ZipFileSystem.zerror(ZipFileSystem.java:1605)
	at com.sun.nio.zipfs.ZipFileSystem.initCEN(ZipFileSystem.java:1045)
	at com.sun.nio.zipfs.ZipFileSystem.<init>(ZipFileSystem.java:130)
	at com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:117)
	at java.nio.file.FileSystems.newFileSystem(FileSystems.java:326)
	at java.nio.file.FileSystems.newFileSystem(FileSystems.java:276)
	at com.android.utils.FileUtils.createZipFilesystem(FileUtils.java:538)
	at com.android.tools.apk.analyzer.Archives.openInnerZip(Archives.java:48)
	at com.android.tools.apk.analyzer.ArchiveTreeStructure.create(ArchiveTreeStructure.java:100)
	at com.android.tools.apk.analyzer.ArchiveTreeStructure.create(ArchiveTreeStructure.java:65)
	at com.android.tools.apk.analyzer.ApkAnalyzerImpl.filesList(ApkAnalyzerImpl.java:803)
	at com.android.tools.apk.analyzer.ApkAnalyzerCli$Action$6.execute(ApkAnalyzerCli.java:430)
	at com.android.tools.apk.analyzer.ApkAnalyzerCli.run(ApkAnalyzerCli.java:163)
	at com.android.tools.apk.analyzer.ApkAnalyzerCli.main(ApkAnalyzerCli.java:130)
复制代码

终于,在用命令显示Apk内所有文件列表的时候出现了问题。并且有对应的调用栈信息抛出。

从调用栈中我们发现,命令行的调用方式,是通过ApkAnalyzerCli中的main方法去接收命令参数的。在ApkAnalyzer.jar同级的目录中,我们发现了有对应的ApkAnalyzerCli.jar,其作用,就是基于ApkAnalyzer.jar基础上封装的一个Client,以方便程序被外部调用执行,如通过命令行的方式等。

并且,突然间发现,此处的栈信息与之前GitHub上JetBrains/android项目中分析到的源码位置相同~!!

at com.android.tools.apk.analyzer.ArchiveTreeStructure.create(ArchiveTreeStructure.java:100)
复制代码

看来,这就是真实的原因所在了。

2.6 项目查因

ArchiveTreeStructure主要作用是分析apk文件中的档案文件树形结构,且从最终抛出的错误信息可以看出:Apk包中zip文件出现的问题,zip文件头部信息无效。

java.util.zip.ZipError: invalid END header (bad central directory offset)
复制代码

抓住这一关键点,那就好办了。直接搜索整个项目中的.zip文件,发现还真有不少。并且存在于assets目录下。主要存放的是一些资源。

 

直接解压缩.zip文件,发现有问题,果然,此处有问题的.zip文件导致apkanalyzer在分析Apk过程中,分析到这些.zip文件出现了问题。

.zip格式显然是不符合.zip规范的,那么,具体是什么问题呢?

查找到项目使用到这些文件的代码位置。

 

 

泪奔了,有木有?!

 

2.7 核验

到现在位置,整体逻辑已经很清晰了。项目中因为存在移除了表示zip格式的头字节的zip文件,导致在使用Android Studio Analyze APK分析Apk时,出现程序错误,从而只显示Parsing Manifest

究竟对不对呢,可以以简单方式核验下。
1,通过移除此类有问题的.zip文件,重新打包,发现可以使用Android Studio Analyze APK进行分析了,直接使用apkanalyzer命令行分析时,也木有问题。

2,使用二进制修改工具,将这类有问题的.zip文件对应的四个字节的头信息给补上。
此处推荐使用 Hex Friend 工具,可以直接以十六进制修改对应的二进制文件内容。

Hex Friend打开zip文件后,发现文件头字节中,确实不符合zip规范。zip文件头四个字节是固定的,504B0304,用来表示的是对应的zip格式。

 

于是,我们手动补上试试。保存后,发现.zip文件可以通过系统工具解压了。

替换后再次打包验证,发现可以Android Studio Analyze APK可以正常分析,apkanalyzer可以直接使用。

三、解决

项目中之所以此处将zip文件头四个字节去除存放,当时主要考虑是安全性问题。然后通过代码的形式在拷贝过程中,去补上对应的字节信息,相当于进行了修正。

现在既想不影响原有逻辑,同时又能愉快的使用Android Studio Analyze APK进行分析,怎么办呢?

通过分析,我们发现,apkanalyzer抛出的异常,是在对zip文件进行分析的时候出现的,既然.zip文件本身,文件头标识.zip格式的字节已经被去除,那程序是如何识别其为.zip文件的呢,大概率是直接通过文件后缀了。发现文件后缀为.zip,就直接按照zip文件格式进行了处理。

对应的调用栈上,我们没有找到Archives类的openInnerArchive方法,这应该是对应的jar包版本问题。不过没关系,沿着对应的调用过程分析,我们找到了如下的逻辑。

 

 

显然,此处的判断逻辑与猜测一致,直接是按照文件名称中的格式后缀去匹配的。

那换一种思路,如果这类文件本身,不是zip后缀,程序很可能就不会执行到zip文件的分析判断上,是不是就可以了呢?

说干就干,直接将项目中此类非规范化的zip文件格式替换,例如替换成一种自己随意想的格式,就叫.tfc吧,然后程序中做好可能的逻辑修正。

试试。果然,再次打包,分析,OK,完全木有问题!

 

 


四、启示

4.1 通过类似方式提高App安全防护

其实从反面来想,如果我们不想别人通过apkanalyzer来分析我们的Apk,可以通过此类技巧,直接放一个不符合规范的zip文件在assets目录中。例如本文中的将zip文件头四个字节去除。

如果自己想分析自己的Apk,加对应的文件移除即可。这样在一定程度上,防防一些开发者,提高一下安全的门槛,还是可以的。

是不是有点,尬?

 

实际上,我们发现很多App在提高反编译门槛时,都采取的类似的思路,通过分析对应的反编译工具的源码,在可能对应有逻辑漏洞的地方去设防,使得反编译程序运行到对应位置出现错误,以此达到反编译失败目的。

如针对ApkTool反编译工具使用的一些常见方法等。

4.2 加强文件格式的严谨判断逻辑

有时候,在内部项目或不太严格场景下的技术实现时,直接对文件后缀进行格式校验,也许也就可以了。但是,在一些通用的框架、工具或有外部交互及严格需求场景的情况下,对文件格式的判定,不应该只是简单的判断文件格式后缀。因为文件格式后缀是很容易被任意修改的,并不具有事实上的文件格式约束力。在文件格式后缀判断的基础上,必要时,增加上对文件事实上的格式判断逻辑,是很有必要的。在一定程度上来说,本例中发现的问题,其实也恰恰是apkanalyzer工具自身隐藏的一个bug。


五、结语

apkanalyzer是Android开发过程中,用来分析Apk中很有用的一个工具,经常被用到。因为其集成在AS中后,足够简单轻便,且能一定程度上满足我们分析Apk的需要。

项目在不断的迭代,维护和开发,项目中的技术问题也会不时出现,对每一个技术问题,其实都是一次很好的技术历练机会。认真分析,不断探因,最终会终有所获。

一般的产品开团队,面对这类问题,往往习惯的选择绕开,因为在相对繁忙的需求开发过程中,无暇此顾。其实,对整个项目组来说,长期来看,这是一个严重的问题。这类技术性问题,就像厨房中的小强,如果发现了不一一解决之,最终会导致不断的繁衍,终有一日,屋里的主人,会被细菌病毒侵袭。

与其积重难返,不如时时解决之。

end~

关注下面的标签,发现更多相似文章

作者:HappyCorn
链接:https://juejin.im/post/5d4972736fb9a06ae17d602e
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
posted @ 2019-12-05 20:38  HappyCorn  阅读(831)  评论(0编辑  收藏  举报