Android系统视角下对APK的分析(1)- 静态分析APK文件

声明

  • 以Android手机用户角度来看,安装各式各样的APP,基本就是从应用市场上 “搜索->下载->安装” 三连。而对Android系统来说,这就是个大工程了,因为对Android系统来说APK是“外来户”,如何安装它、有限制地支持它的运行、如何防着它干坏事等问题就来了。
  • 写此专栏的起因是为了给客户在定制的Android系统中实现 大型APK快速安装的功能
  • 本专栏就来从Android系统的角度来分析下APK的整个生命周期(安装-运行-卸载),包含对APK的静态分析、PackageManagerService、pm命令、PackageInstaller、Installd。
  • 此篇代码基于LineageOS 14.1(Android 7.1.1),参考一些博客和书籍,不方便逐一列出,仅供学习、知识分享。

1 APK的文件结构

  Android 应用均是以 APK 文件格式进行发布和安装的。APK 文件同时包含应用程序的代码和资源,包括应用程序的 manifest 文件。它们还可以包含一个代码签名文件。APK 文件格式是 JavaJAR 的一种扩展格式,当然也是广为流行的 ZIP 文件格式的扩展格式,可以使用 ZIP 格式的压缩工具对其进行解压。如下是一个典型 APK 文件解压后的内容:

pedro@x86:$ tree -L 2
.
├── AndroidManifest.xml										APP属性定义文件
├── classes2.dex											Java源码编译后的代码文件
├── classes.dex
├── asserts													声音、字体、网页....资源
├── lib														应用中调用到的库
│   ├── armeabi
│   ├── arm64-v8a
├── META-INF												APK的签名文件(*.RSA、*.SF、*.MF 文件)
│   ├── androidx.activity_activity.version
│   ├── ...省略...
│   ├── androidx.viewpager2_viewpager2.version
│   ├── androidx.viewpager_viewpager.version
│   ├── CERT.RSA
│   ├── CERT.SF
│   ├── com
│   └── MANIFEST.MF
├── res														APP中使用到的资源目录
│   ├── anim												动画资源
│   ├── animator
│   ├── animator-v21
│   ├── anim-v21
│   ├── color												颜色资源
│   ├── color-v23
│   ├── drawable											可绘制的图片资源
│   ├── drawable-hdpi-v4
│   ├── drawable-ldrtl-hdpi-v17
│   ├── drawable-ldrtl-mdpi-v17
│   ├── drawable-ldrtl-xhdpi-v17
│   ├── drawable-ldrtl-xxhdpi-v17
│   ├── drawable-ldrtl-xxxhdpi-v17
│   ├── drawable-mdpi-v4
│   ├── drawable-v21
│   ├── drawable-v23
│   ├── drawable-v24
│   ├── drawable-watch-v20
│   ├── drawable-xhdpi-v4
│   ├── drawable-xxhdpi-v4
│   ├── drawable-xxxhdpi-v4
│   ├── interpolator
│   ├── interpolator-v21
│   ├── layout												页面布局文件
│   ├── layout-land
│   ├── layout-sw600dp-v13
│   ├── layout-v21
│   ├── layout-v26
│   ├── layout-watch-v20
│   ├── mipmap-anydpi-v26
│   ├── mipmap-hdpi-v4
│   ├── mipmap-mdpi-v4
│   ├── mipmap-xhdpi-v4
│   ├── mipmap-xxhdpi-v4
│   ├── mipmap-xxxhdpi-v4
│   └── xml													应用属性配置文件
└── resources.arsc											编译后的资源文件,如 strings.xml

  APK 中的 AndroidManifest.xml 文件中注册着 APK 所有的重要信息(四大组件、包名、META等),通过分析AndroidManifest.xml 更有助于我们了解整个应用的架构。APK 解压后的几个重要文件,classes.dex 文件、AndroidManifest.xml文件、so 文件(c/c++代码文件,存在JNI的情况下会有此文件 )、resources.arsc ( 资源文件)。

2 APP的种类

  Android 应用程序开发使用 Java 语言,若还使用 NDK 的话还需要 C/C++ 进行JNI调用。目前,市面上也存在着多种 Android 应用开发的语言。比如:PhoneaGap 提供使用 HTML5+JavaScript 进行开发,Cocos2dX 也是提供 C/C++ 语言进行跨平台开发等。

目前主流应用程序开发方式大体分为3类(如下图所示):

  • Web App (网页 App )
  • Hybrid App (混合App)
  • Native App(原生App)。
    在这里插入图片描述

2.1 原生 APP

  基于 Google 的 SDK 使用 Java 语言或 C/C++语言进行开发,称为Native App。Native App 指的是原生程序,一般依托于操作系统,有很强的交互,是一个完整的App,可拓展性强,需要用户下载安装使用。

  • 优点:打造完美的用户体验;性能稳定;操作速度快,上手流畅;访问本地资源(通讯录,相册);设计出色的动效,转场;拥有系统级别的贴心通知或提醒;用户留存率高。
  • 缺点:分发成本高(不同平台有不同的开发语言和界面适配);维护成本高(例如一款 App 已更新至V4 版本,但仍有用户在使用 V2、V3版本,需要更多的开发人员维护之前的版本 );更新缓慢,根据不同平台,提交-审核-上线等不同的流程,需要经过的流程较复杂。

2.2 Web APP

  采用 Html5 语言写的 App,不需要下载安装,类似于现在所说的轻应用,是生存在浏览器中的应用,可以理解为触屏版的网页应用。当然,也有些应用是将网页再通过Android SDK打包成APK文件的形式上传到市场上的。主要开发方式就是使用的HTML5+JavaScript,使用 WebView 作为本地接口进行开发,其架构如下图所示。

  • 优点:开发成本低;更新快;更新无需通知用户,不需要手动升级;能够跨多个平台和终端。因为开发与使用成本都比较低,所以很多巨头公司都推出了自己的 WebApp 搭建平台,又称为轻应用。
  • 缺点:临时性的人口,无法获取系统级别的通知、提醒、动效等用户留存率低,设计受限制诸多,体验较差。
    在这里插入图片描述

2.3 混合 APP

  半原生半 Web 的混合类App,需要下载安装,看上去类似 Native App,但只有很少的 UI WebView,访问的内容是 Web。常见的有新闻类App、视频类 App,普遍采取的是Native的框架、Web 的内容。
  Hybrid App 也包括使用其他语言(C#、JavaScript)进行开发的 App。使用第三方语言进行开发的原理基本都是将其编译为 so 文件,再通过JNI的方式调用其逻辑。

3 Android 代码签名

  Android 为何需要代码签名? 原因通常是:为了 完整性 和 可靠性。在执行任何第三方程序之前,你希望确保该程序没有被篡改(完整性),并且该程序确实由它所声称的创建者所创建(可靠性)。AOSP 的 build/ 目录中包含一个叫 signapk 的Android专用工具。
  Android 代码签名机制是基于Java JAR 签名机制,所以它跟许多代码签名方案一样,使用公钥加密和 X.509 证书。实际上,代码签名证书必须由一个信任平台 CA 颁发。虽然有很多颁发证书的 CA,然而仍然很难获取一个受所有目标设备信任的证书。Android 非常简单地解决了这个问题:它不关心证书的内容和签发者。因此你的证书不需要必须由 CA 颁发,实际上所有 Android 里使用的代码签名,均是自签名的。
  签名验证过程,既验证代码是否被篡改,同时又验证签名确实由所预期的密钥生成但是存在一个问题,代码签名不能直接解决代码签名者(软件发布者)能否被信任的问题。通常建立信任关系的方法是,要求代码签名者持有数字证书,并且将其附加到被签名的代码中去。验证者决定是否信任,可以基于一种信任模型(例如 PKI或信任网),或者具体案例具体对待。
  代码签名的另一个问题是,它不能解决被签名的代码是否确定是安全的

4 DEX文件

  Dex文件是Android上的可执行文件,由Java 虚拟机JVM编译后再由 Android 中的虚拟机 Dalvik 所编译后而成。
在这里插入图片描述

5 so文件

  Android平台的底层就是 Linux 系统,而 Linux 系统原本就是使用 C/C++语言的。只是Android在上面使用了一个 Dalvik/ART 虚拟机才使得应用程序的开发使用 Java语言。虚拟机 Dalvik/ART 本身支持JNI编程方式。
  NDK(Native Development Kit) 就是为了 “Java+C” 开发而提出来的工具库,使得在使用 C/C++ 开发时能够保证程序的兼容性、调试性与调用 API 的方便性。使用 NDK 进行应用程序开发也能够避免掉 Java 中的一些不足:

目的 说明
代码的保护 APK中的Java代码很容易被反编译、阅读和篡改,而对C/C++开发出来 so库进行反汇编难度较大
可以方便地使用现存的开源库 大部分现存的开源库(OpenCV、OpenGL等)都是用 C/C++代码编写的
提高程序的执行效率 将要求高性能的应用逻辑使用 C开发,从而提高应用程序的执行效率
便于移植 用 C/C++写的 so 库可以方便地在其他的入式平台上再次使用

6 APK逆向工程

  APK的逆向破解也是个大学问,我工作不涉及这个,所以就不研究了。

猜你喜欢

转载自blog.csdn.net/Xiaoma_Pedro/article/details/131150343