怎样检测APK应用是否安全，有什么好用的检测工具？

APK应用是否安全非常重要，开发者都要重视这一点，但局限于时间及精力有限，所以就不得不借助专业的检测工具，而选对工具，可以起到事半功倍的效果。根据我使用过的，个人觉得爱内测好用，操作方便，全方位检测，还能提供专业的安全分析报告，帮你找出APK的安全漏洞。

apk分析工具 app分析器

APK逆向 ZIP格式相关问题

由于经常分析apk，apk的格式就是zip，遇到了一些关于zip格式的问题，所以记录一下zip格式相关的问题，具体格式解析到处都有

附上官方文档：

apk有密码肯定是无法安装的，所以用解压缩工具打开apk文件时，提示要密码，肯定是密码标志位被修改了。

正常的标志位在504b0102后面第5、6个字节

最简单的方法就是搜索 50 4B 01 02 直接吧后面这两个字节改为 00 00

真正标记是否加密只用到了一个bit，两个字节共16个bit，最低位表示是否加密

zip格式很老，很久以前用软盘、光盘存数据时，由于容量限制，一个zip可能要分几个软盘存储，所以文件格式中有记录当前磁盘序号的内容

官方文档搜索06054b50(zip文件尾部的标记)，可以看到紧接着的两个字节就是 number of this disk ，标记了当前是第几个磁盘，接下来的两个字节标记了zip文件是从第几个磁盘开始的。

现在已经不需要分磁盘存储zip了，所以一般的zip文件这里都是 00 00 00 00 ，有些apk为了对抗分析，就吧这个值修改一下，部分分析工具使用的是专门解析zip格式（没有专门针对apk优化过）的库来解压apk，就没法正常分析了。

搜索 50 4B 05 06 吧后面的这几个字节改成 00 00 00 00 就行了

有些apk用jeb打开后，无法正常解析，报错 Expected an int at offset 336020Fh

而这个offset，就是apk的末尾，用010打开后用zip模板解析，最后的zip尾部结构如下图，第4，5个数字都是Entries数量，OnDisk可以猜出是在当前软盘的Entries数量(参见上面的multi disk)，但是现在已经不用软盘，zip都是在一个硬盘中存储，所以这个数量与下面的InDirectory的数量应该保持一致。EntriesOnDisk数量修改成2322后即可正常解析apk。

如何检查android应用被篡改

Android APK加密防篡改核心技术

1防内存窃取防止通过gdb、gcore，从内存中截取dex文件，获取代码片段，从而反编译APK，保证Android APK加密安全。

2防动态跟踪防止通过ptrace调试进程，跟踪、拦截、修改正在运行的应用，保护程序运行及Android APK加密安全。

3防逆向分析防止通过APKTool、IDA Pro等反编译工具破解DEX文件，从而获取APK源代码，保证Android APK加密。

防恶意篡改校验APK完整性，自动终止运行被篡改的APK，二次打包后应用都无法使用，保证Android APK加密。

Android APK加密技术加密特点

1so文件加密

Android APK加密，so文件定制加密

2资源文件保护

资源文件保护防窃取、防资源文件篡改，保证Android APK加密

36种加密方式

6种Android APK加密方式，满足不同用户、不同场景的使用需求

4增量最少

Android APK加密后增量最小，启动运行效率最优

5兼容最优

兼容性达到98%以上，实现ART全面兼容以及Android APK加密安全

END

总结

1如何帮助更多开发者Android APK加密防止Android应用被篡改，这需要一个长期的过程，首先需要开发者增加对Android应用篡改、APK反编译、盗版APP的重视，其次需要开发者从技术手段上加强对自有APK安全的保护，通过第三方服务平台进行Android APK加密保护。同时，也需要政府加大对盗版篡改的监测和打击，建立一个良好的产业环境。

小白的话，用豌豆荚应用洗白

APK的瘦身优化

随着不断的开发迭代，apk的大小不断的增大，在用户体验上变得不太友好，因此apk的瘦身显得很有必要。

首先要apk的大小需要分析，我们才知道那部分可以瘦身

在Android Studio工具栏里，打开build–>Analyze APK, 选择要分析的APK包

或者直接从project目录下面寻找build outputs下的apk包然后双击。

从上方的apk分析图中，我们可以看出apk中什么资源占据了较多内存，然后进行瘦身优化。

在gradle使用minifyEnabled进行Proguard混淆的配置，可大大减小APP大小：

混淆时候注意配置混淆

具体配置参考 混淆模版

这里的去除并不是物理上的删除，而是编译器自动帮我们找出没有使用到的资源并在build的时候将这些资源保存为1x1的位图，因此大大缩小了打包后这些重复资源占据的空间。实测大概只有几十b大小。

只保留中文，其余几十种语言都不需要。

在程序中我们会用到很多图片资源，png格式或者jpg的图片，这些图片少则十多k，多着几兆。

图片资源多了就会影响最后apk的大小。

其实在安卓5.0之后，谷歌就支持了svg矢量图，我们可以直接从美工小哥哥那里拿svg图然后使用。

或者使用自带的svg资源。

使用方法：

新建Vector资源：

在这里可以选择使用系统自带的资源或者，从本地选取。

其实，我们平常用的默认的ic_launcher.xml就是矢量图，点击去看看，你就会发现其中有Vector的节点。

除了矢量图可以节约图片本身的大小，那么我们还可以使用Tinit着色器，减少一些重复的图片使用。

当然这里的重复也并不是说同样的图片，其实在平常的开发中，我们会用到很多图片资源只是颜色不同而已，为了做出点击效果或者按压效果等。

其实这些不同颜色效果的图片都可以用同一张图片实现，那就是Tinit着色器。

除了直接写死，当然也可以尝试下selector.xml哦，做出按压效果。

我们平常会使用到很多JnILibs下面的.so库来进行一些功能的集成，但是在接手项目或者使用别人的库的时候，看到JnILibs下面有很多不同名字包下都有同样的.so文件。

这些都必须吗？都能用得着吗？

那不一定哈，具体看你使用在什么设备上面，一般来说使用一个armeabi-v7a就行了

如果程序需要上架到GooglePlay上面的，从2019年8月1日起，就必须支持64位的啦！

这点还是需要注意下哈 GooglePlay上架强制支持64位

顺便说一下这个动态库的 含义 ：

简单来说就是：

Android 设备的CPU类型(通常称为”ABIs”)

armeabi-v7a: 第7代及以上的 ARM 处理器。2011年15月以后的生产的大部分Android设备都使用它.

arm64-v8a: 第8代、64位ARM处理器，很少设备，三星 Galaxy S6是其中之一。

armeabi: 第5代、第6代的ARM处理器，早期的手机用的比较多。

x86: 平板、模拟器用得比较多。

x86_64: 64位的平板。

刚刚说过，我们可以使用svg矢量图来代替png等图片减小图片大小。那么如果非要使用png等图片又怎么办呢？

答案谷歌也给我们提供好了，那就是使用自带的webp有损压缩。

测试了大概1mb的图片最后就会变成100kb，压缩效果很明显，也不会出现图片失真太多。

使用方法：找到图片，然后右键，直接找到最下面的convert to WebP

最后效果

感觉还可以吧。

res资源文件混淆 我还没尝试过，希望大家可以在评论区互相启发一下怎么给apk瘦身，还有什么方法？