One, background
As we all know, Android Studiodevelopment tools comes Analyze Apk, you can easily analyze Apk file. Specific menu located build >> Analyze APK...under the path, you can click to select Apk file in the destination path can even drag and drop files directly to the APK directly to the target Android Studioin less than a few seconds in time, will immediately generate a corresponding analytical results.
For example, micro-channel Apk this analysis are:
In another example, Alipay Apk results:
Moment feel very niubility, there is no?
Sometimes, we often use it to analyze their own Apk, for example, generate installation package in the end look like, inside the Resources / code that constitutes, Manifestin the configuration is as expected, or the number of ways, and so on. However, a sudden opportunity to develop their own analysis found that Ap can not, has been in a Parsing Manifeststate.
Look ignorant force, there is wood there?
Second, Saguin
This issue has been confused me a lot of time, until there is no specific research had to go. Now we are experiencing. Instantly think of Lu Xun said a word:
技术路上，会遇到很多看似莫名其妙的问题。
细心探究，解决了，就是成长。
无视它并避让过去，看似绕过了问题，
实际上失去了一次很好的技术历练的机会。
并且下次很可能还会遇到类似的，甚至一样的问题，
长期看将是困难和停滞。
复制代码
Since our ancestors have said so, that, bite the bullet and explain them?
2.1 AS log
Now gives the impression that Analyze APKthe implementation process is directly stopped, and the latter has been a long time in the analysis. In any case, after all, is operating in the AS, first check the log corresponding AS, see no Parsing Manifestlog or related information, can play a helpful.
Help >> Show Log in Finder, Open the log, the corresponding point of time looked and looked and could not find Parsing Manifesta direct correlation, but found the controls to show off the log:
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
复制代码Log can be seen from the inside out, the AS corresponding Analyze Apkassociated with a class name ApkEditor, ApkViewPanelthe package name com.android.tools.idea.apk.viewer. AS part of the log information is valid only so much.
2.2 System Global Search
AS log not, then there may exist valid information output systems in other places? So, take the time to direct, under the system of global search.
/ grep -rnl "Parsing Manifest" *
复制代码Output information in some warning messages like, finally found related information in the output:
Applications/Android Studio.app/Contents/plugins/android/lib/android.jar
复制代码Look at the directory name, AS plug-in is probably related to the corresponding lib Android toolkit. Find the corresponding position, open the corresponding jar file with the JD-GUI, specific look at.
Parsing Manifest
can indeed be targeted to a specific
ApkViewPanel
class and package names of AS on the upper face of the log can be, but is decomposed into java bytecode inverse process of an internal error. Try to use with jadx open because android.jar pack quite large, although a long time ,, final
ApkViewPanel
part of the contents can be displayed, but the interior still some internal error can not be displayed, and
Parsing Manifest
can not be directly displayed.
Location and Source Analysis 2.3 GitHub
But never mind, we try to go and find the source code and see. Search the corresponding package name: com.android.tools.idea.apk.viewer, select java class, and soon, we found the location of the corresponding source code.
Just, AS is the leading JetBrains products, Perfect!
Parsing Manifest
position:
setAppInfo()Method, the corresponding control content from the original Parsing Manifestinformation into a corresponding package name and version number.
Obviously, in the code myNameComponent.append("Parsing Manifest");and setAppInfo(result);between the program out of the question.
apkParser
corresponding object
ApkParser
class, and the
Archives
class. Continue to follow the
ApkParser
class, found that the main character is a shell classes,
apkParser.constructTreeStructure()
methods to position the main flow as follows:
ArchiveTreeStructure
class or before
Archives
class, class on these two key clues not in this project. According to the code file
import
to import, and soon, we found clues to be directed to the
com.android.tools.apk.analyzer
package.
From the point of view the package name, com.android.tools.apk.analyzerit should be Android Toolsa tool belt. Came to the project imldocument, we find related components associated with it. Wherein, the group name is: com.android.tools.apkparser, member apkanalyzername: .
2.4 tool body -apkanalyzer
At this point, let me summarize reasons under question.
AS comes with Analyze APK, actually through an integrated plug-in implementation, and internal plug-in, and by calling the name of Android Tools of apkanalyzeranalysis tools to achieve. So, you want retroactive cause of the problem, we need to go to the next track correspondence apkanalyzer.
If you are familiar Android Tools, we correspond to the tools directory look, and soon will be able to find apkanalyzer. In time are not familiar with, do not know the directory location does not matter, can not play the next global search.
Finally, the corresponding tool body in front of us.
In fact, if you compare the Google Developer familiar with, or in the search above, can also be directly integrated in Analyze APKto find the core information on the page, directly to the tool body - 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, a binary editing tool using the header information of such a problem .zip file corresponding to the four bytes of fill.
We recommend to Hex Friend tool, you can directly modify the corresponding hexadecimal binary file contents.
504B0304
, is used to indicate the corresponding zip format.
So we try to make up manually. Once saved, you can extract the .zip file found by the system tools.
Packaging verification again after replacement, can be found Android Studio Analyze APKcan be analyzed properly, apkanalyzerit can be used directly.
Third, resolve
The reason why the project here will remove the zip file first four bytes of storage, was the main consideration is the safety issue. Then the form of the code in the copy process, to make information corresponding to the byte corresponds modified.
Now not only does not want to affect the original logic, while pleasant to use Android Studio Analyze APKfor analysis, how to do it?
Through analysis, we found that the apkanalyzerthrown exception, appeared at the time of the zip file analysis, since the .zip file itself, byte header identify the .zip format has been removed, and that the program is to identify how it is. zip file of it, the high probability is directly through the file suffix. Find the file suffix .zip, directly been processed in accordance with the zip file format.
The corresponding call stack, we did not find the Archiveskind of openInnerArchiveapproach, which should be a corresponding jar package version of the problem. But never mind, the called procedure corresponding analysis along, we find the following logic.
Clearly, judgment is consistent with the logic guessing here, is directly in the format of the file name suffix to match.
That put it another thought, if such file itself, not the zip suffix, the program probably will not perform the analysis to determine the zip file, is not can it?
He went ahead, directly replace such non-standardized items in a zip file format, such as their own alternate format into a random thought, called .tfcit, and then make the program possible correction logic.
试试。果然，再次打包，分析，OK，完全木有问题！
四、启示
4.1 通过类似方式提高App安全防护
其实从反面来想，如果我们不想别人通过apkanalyzer来分析我们的Apk，可以通过此类技巧，直接放一个不符合规范的zip文件在assets目录中。例如本文中的将zip文件头四个字节去除。
如果自己想分析自己的Apk，加对应的文件移除即可。这样在一定程度上，防防一些开发者，提高一下安全的门槛，还是可以的。
是不是有点，尬？
实际上，我们发现很多App在提高反编译门槛时，都采取的类似的思路，通过分析对应的反编译工具的源码，在可能对应有逻辑漏洞的地方去设防，使得反编译程序运行到对应位置出现错误，以此达到反编译失败目的。
如针对ApkTool反编译工具使用的一些常见方法等。
4.2 加强文件格式的严谨判断逻辑
有时候，在内部项目或不太严格场景下的技术实现时，直接对文件后缀进行格式校验，也许也就可以了。但是，在一些通用的框架、工具或有外部交互及严格需求场景的情况下，对文件格式的判定，不应该只是简单的判断文件格式后缀。因为文件格式后缀是很容易被任意修改的，并不具有事实上的文件格式约束力。在文件格式后缀判断的基础上，必要时，增加上对文件事实上的格式判断逻辑，是很有必要的。在一定程度上来说，本例中发现的问题，其实也恰恰是apkanalyzer工具自身隐藏的一个bug。
五、结语
apkanalyzer是Android开发过程中，用来分析Apk中很有用的一个工具，经常被用到。因为其集成在AS中后，足够简单轻便，且能一定程度上满足我们分析Apk的需要。
项目在不断的迭代，维护和开发，项目中的技术问题也会不时出现，对每一个技术问题，其实都是一次很好的技术历练机会。认真分析，不断探因，最终会终有所获。
General product open team, the face of such problems, often bypassing the customary choice, because relatively busy in the requirements development process, no time this care. In fact, the entire project team for the long term, this is a serious problem. Such technical issues, like the kitchen Xiaoqiang, if you do not find all the solutions it will eventually lead to constantly multiply, one day, the owner of the house, will be the invasion of bacteria and viruses.
With its die-hard, as always the solution.
end~
Author: HappyCorn
link: https: //juejin.im/post/5d4972736fb9a06ae17d602e
Source: Nuggets
copyright reserved by the authors. Commercial reprint please contact the author authorized, non-commercial reprint please indicate the source.