本章概述了 Android 应用的内部结构。了解应用是如何在引擎盖下构建的、安装在设备上时是什么样子、它们是如何运行的，等等都是至关重要的。我们在其他章节中利用了这些知识，讨论了逆向工程和 Android 应用测试等主题。本章涵盖以下主题：
- Android 应用的基础知识
- 应用构建过程
- 了解 Android 应用如何在 Android 设备上运行
- Dalvik 虚拟机（DVM）和安卓运行时（艺术）
- Android 应用的基本构建块
我们从 Play Store 或任何其他来源下载并安装的每个应用都有扩展名.apk。这些 APK 文件是压缩的归档文件，其中包含我们稍后将讨论的其他文件和文件夹。通常，最终用户通过接受所需的权限下载并安装这些应用，然后使用它们。让我们深入了解一些技术细节，比如这些应用包含哪些内容，它们实际上是如何打包的，安装它们时会发生什么，等等。
首先，让我们从作为最终用户使用的最终二进制文件开始。如前所述，Android 应用的扩展名为**.APK**（简称Android 应用包），是各种文件和文件夹的存档。这通常是最终用户或渗透测试人员会得到的结果。由于 Android 应用是一个存档文件，我们可以使用任何传统的提取工具对其进行解压缩。下图显示了未压缩 APK 文件的文件夹结构。一般来说，这与任何 APK 都是一样的，但有一些细微的差异，例如当应用中包含其他库时，有一个额外的lib文件夹：
解压 APK 文件的步骤：
-
将文件扩展名从
.apk更改为.zip。 -
在 Linux/Mac 中，使用以下命令解压缩文件：
Unzip filename.zip -
在 Windows 中，我们可以使用 7-Zip、WinRAR 或任何其他类似工具来提取内容。
让我们看看这些文件/文件夹中包含的内容：
AndroidManifest.xml：此文件保存了应用的大部分配置细节。它还包括包名、应用中使用的应用组件的详细信息、每个应用组件的安全设置、应用请求的权限等。classes.dex：此文件包含由利用人员编写的源代码生成的 Dalvik 字节码。此 DEX 文件是应用运行时在设备上执行的文件。在本章后面的一节中，我们将看到如何在 Android 设备上手动生成和执行此 DEX 文件。resources.arsc：此文件保存已编译的资源。Res：此文件夹包含应用所需的原始资源。例如，应用图标等图像。Assets：此文件夹允许利用人员放置他感兴趣的文件，如音乐、视频、预装数据库等。这些文件将与应用捆绑在一起。META-INF：此文件夹包含申请证书以及申请中使用的所有文件的 SHA1 摘要。
如果您想要获取您选择的特定 APK 文件，以下是获取该文件的方法：
-
从 Play Store
-
下载 APK 如果您想从 Play Store 下载 APK 文件，只需从 Play Store 复制应用的完整 URL，并使用以下网站获取 APK 文件：
-
-
从设备中拉出 APK
如果应用已经安装在您的设备上，则只需执行几个 adb 命令即可从设备中提取 APK 文件。
根据是谁安装了应用以及安装过程中提供了哪些额外选项，Android 设备上有不同的存储位置。让我们看看每一个。
用户安装的应用将放置在此位置下。让我们看看在此文件夹下安装的应用的文件权限。以下摘录显示，所有这些文件都是世界可读的，任何人都可以复制它们，而无需额外的权限：
root@android:/data/app # ls -l
-rw-r--r-- system system 11586584 1981-07-11 12:37 OfficeSuitePro_SE_Viewer.apk
-rw-r--r-- system system 252627 1981-07-11 12:37 PlayNowClientArvato.apk
-rw-r--r-- system system 14686076 2015-11-14 02:28 com.android.vending-1.apk
-rw-r--r-- system system 5949763 2015-11-13 17:39 com.estrongs.android.pop-1.apk
-rw-r--r-- system system 39060930 2015-11-14 02:32 com.google.android.gms-2.apk
-rw-r--r-- system system 677200 1981-07-11 12:37 neoreader.apk
-rw-r--r-- system system 4378733 2015-11-13 15:22 si.modula.android.instantheartrate-1.apk
-rw-r--r-- system system 5656443 1981-07-11 12:37 trackid.apk
root@android:/data/app #
前面的摘录显示了/data/app/文件夹下 APK 文件的全局读取权限。
系统映像附带的应用将放置在此位置下。让我们看看在此文件夹下安装的应用的文件权限。以下摘录显示，所有这些文件都是世界可读的，任何人都可以复制它们，而无需额外的权限：
root@android:/system/app # ls -l *.apk
-rw-r--r-- root root 1147434 2013-02-01 01:52 ATSFunctionTest.apk
-rw-r--r-- root root 4675 2013-02-01 01:52 AccessoryKeyDispatcher.apk
-rw-r--r-- root root 51595 2013-02-01 01:52 AddWidget.apk
-rw-r--r-- root root 21568 2013-02-01 01:52 ApplicationsProvider.apk
-rw-r--r-- root root 2856 2013-02-01 01:52 ArimaIllumination.apk
-rw-r--r-- root root 7372 2013-02-01 01:52 AudioEffectService.apk
-rw-r--r-- root root 147655 2013-02-01 01:52 BackupRestoreConfirmation.apk
-rw-r--r-- root root 619609 2013-02-01 01:52 Bluetooth.apk
-rw-r--r-- root root 5735427 2013-02-01 01:52 Books.apk
-rw-r--r-- root root 2441128 2013-02-01 01:52 Browser.apk
-rw-r--r-- root root 11847 2013-02-01 01:52 CABLService.apk
-rw-r--r-- root root 200199 2013-02-01 01:52 Calculator.apk
-rw-r--r-- root root 92263 2013-02-01 01:52 CalendarProvider.apk
-rw-r--r-- root root 3345 2013-02-01 01:52 CameraExtensionPermission.apk
-rw-r--r-- root root 141003 2013-02-01 01:52 CertInstaller.apk
-rw-r--r-- root root 215780 2013-02-01 01:52 ChromeBookmarksSyncAdapter.apk
-rw-r--r-- root root 7645090 2013-02-01 01:52 ChromeWithBrowser.apk
-rw-r--r-- root root 1034453 2013-02-01 01:52 ClockWidgets.apk
-rw-r--r-- root root 1213839 2013-02-01 01:52 ContactsImport.apk
-rw-r--r-- root root 2100200 2013-02-01 01:52 Conversations.apk
-rw-r--r-- root root 182403 2013-02-01 01:52 CredentialManagerService.apk
-rw-r--r-- root root 12255 2013-02-01 01:52 CustomizationProvider.apk
-rw-r--r-- root root 18081 2013-02-01 01:52 CustomizedApplicationInstaller.apk
-rw-r--r-- root root 66178 2013-02-01 01:52 CustomizedSettings.apk
-rw-r--r-- root root 11816 2013-02-01 01:52 DefaultCapabilities.apk
-rw-r--r-- root root 10989 2013-02-01 01:52 DefaultContainerService.apk
-rw-r--r-- root root 731338 2013-02-01 01:52 DeskClockGoogle.apk
需要在设备上进行特殊复制保护的应用通常位于此文件夹下。没有足够权限的用户无法复制在此位置下安装的应用。但是，如果我们在设备上有根访问权限，仍然可以提取这些 APK。
现在，让我们看看如何从设备中提取我们选择的应用。这基本上是一个三步过程：
- 查找包名。
- 查找设备上 APK 文件的路径。
- 将其从设备中拔出。
让我们看看它的实际行动。以下示例显示在运行 Android 4.1.1 的真实 Android 设备上。
如果我们知道应用的名称，可以使用以下命令查找应用的包名称：
adb shell –d pm list packages | find "your app"
正如我们在前面的屏幕截图中所看到的，这将向我们显示包名。
现在，下一步是查找与此包关联的 APK 的路径。同样，我们可以使用以下命令来实现这一点：
adb –d shell pm path [package name]
正如所料，它位于/system/app/目录下，因为它是预安装的应用。最后一步是将其从设备中拔出。现在，我们可以使用以下命令将其拉出：
adb –d pull /system/app/[file.apk]
与预装应用的流程类似，如果我们知道应用的名称，我们可以使用以下命令查找用户安装的应用的包名称：
adb shell –d pm list packages | find "your app"
这一次，我正在寻找一个名为 heartrate 的应用，它是从 Play 商店安装的。如果要在设备上安装，可以从以下链接下载：
https://play.google.com/store/apps/details?id=si.modula.android.instantheartrate &hl=en
正如我们在上一个屏幕截图中看到的，我们已经得到了包名。我们可以使用以下命令查找其 APK 路径：
adb –d shell pm path [package name]
此 APK 位于/data/app/目录下，因为它是用户安装的应用。
最后，我们可以使用以下命令从设备中提取此应用，类似于我们以前使用预装应用所做的操作：
adb –d pull /data/app/[file.apk]
除了 APK 文件，如果您使用 adb shell 导航到/system/app/目录，您也可能会注意到.odex文件。这些.odex文件是优化的.dex文件，通常在应用首次运行时创建。使用名为dexopt的工具在内部创建这些.odex文件。这一过程提高了应用的性能，通常在 Android 操作系统的首次启动过程中完成。
当您在最新版本的 Android 设备上执行上述过程时，这些 APK 文件的位置与我们看到的略有不同。以下是用于测试此功能的仿真器的规范：
对于用户安装的应用和预安装的应用，每个 APK 在路径/data/app/和/system/app/中都有自己的目录。
预装应用的示例位置：
用户安装的应用的示例位置：
在这种情况下，如果您使用 adb 外壳浏览文件系统，则与应用关联的每个.odex文件都会放置在应用自己的目录中，如前一个屏幕截图所示，而不是/system/app/。
Android 应用通常由以下所列的四个不同组件组成：
- 活动
- 服务
- 广播接收者
- 内容提供商
活动提供一个屏幕，用户可以通过该屏幕进行交互，以完成某项任务。有时，它可能包含一些碎片。片段表示活动中的行为或用户界面的一部分。用户可以执行诸如拨打电话、发送短信等操作。一个很好的例子就是你的 Facebook 应用的登录屏幕。以下屏幕截图显示计算器应用的活动：
服务可以在后台执行长时间运行的操作，不提供用户界面。如果您使用音乐应用，您可以在选择所选歌曲后关闭其所有屏幕。音乐仍将在背景中播放。以下屏幕截图显示了在我的设备上运行的服务：
广播接收器是一个组件，用于响应系统范围内的广播通知，如电池电量不足、启动完成、耳机插头等。虽然大多数广播接收器都是由系统发起的，但应用也可以宣布广播。从利用人员的角度来看，当应用只需要在有特定的事件广播接收器时才需要执行某些操作。
内容提供商将数据作为一个或多个表呈现给外部应用。当应用希望与其他应用共享其数据时，内容提供商是一种方式，它充当应用之间共享数据的接口。内容提供商使用标准的insert()、query()、update()、delete()方法访问应用数据。向每个内容提供商分配一种以content://开头的特殊形式的 URI。任何知道此 URI 的应用，如果具有适当的权限，都可以从提供商应用的数据库中插入、更新、删除和查询数据。
示例：使用content://sms/inbox内容提供商，任何应用都可以从我们设备中内置的 SMS 应用存储库中读取 SMS。要访问 SMS 应用的数据，必须在应用的AndroidManifest.xml文件中声明 *READ_SMS权限。
在前面的所有章节中，我们只处理了 APK 文件。了解这些 APK 文件是如何在屏幕后面创建的是很重要的。当利用人员使用诸如 Android Studio 之类的 IDE 构建应用时，通常会在较高级别上执行以下操作。
正如我们前面看到的，Android 项目通常包含一个 Java 源代码，它被编译成classes.dex、一个二进制版本的AndroidManifest.xml和其他资源，这些资源在编译和打包过程中捆绑在一起。一旦完成，应用必须由利用者签名。最后，它已准备好在设备上安装和运行。
虽然从利用人员的角度来看，它看起来非常简单，但它包含屏幕后面的复杂过程。让我们看看整个构建系统是如何工作的。
根据谷歌的官方文档，以下是完整的构建系统过程：
-
The first step in the build process involves compiling the resource files such as
AndroidManifest.xmland other XML files used for designing the UI for the activities. This process is done using a tool known as aapt (short for Android Asset Packaging Tool). This tool generates a file calledR.javawith a couple of constants inside it enabling us to reference them from our Java code:
-
如果项目中使用了任何
.aidl（安卓接口定义语言文件），则 aidl 工具将其转换为.java文件。通常，当我们允许来自不同应用的客户端访问您的 IPC 服务并希望在您的服务中处理多线程时，会使用 AIDL 文件。 -
现在我们已经准备好了所有可以由 Java 编译器编译的 Java 文件。Javac 是用来编译这些 java 文件的编译器，它生成
.class文件。 -
所有的
.class文件都必须转换成.dex文件。这是由 dx 工具完成的。此过程生成一个名为classes.dex的 DEX 文件。 -
在上一步中生成的
classes.dex文件、未编译的资源（如图像）和已编译的资源被发送到 Apk Builder 工具，该工具将所有这些内容打包到 Apk 文件中。 -
要在 Android 设备或模拟器上安装此 APK 文件，必须使用调试或发布密钥对其进行签名。在利用阶段，IDE 使用调试键对应用进行签名以进行测试。可以使用 JavaKeytool和jarsigner从命令行手动完成签名过程。
-
当应用准备好进行最终发布时，必须使用发布密钥对其进行签名。当应用使用释放密钥签名时，必须使用zipalign工具对其进行对齐，以便在设备上运行时进行内存优化。
参考文献：http://developer.android.com/sdk/installing/studio-build.html 。
毫无疑问，DEX 文件是 Android 应用最重要的部分之一，通常对攻击者或渗透测试人员有用。在本书的反向工程部分，我们将不得不大量处理 DEX 文件。那么，让我们看看这些 DEX 文件是如何在应用构建过程中创建的。我们将从命令行执行此操作，以便更好地理解，因为我们可以仔细查看每个步骤。
下图显示了.dex文件生成的高级过程：
第一步是编写一个简单的 Java 程序来开始这个过程。下面的 Java 代码在输出控制台上简单地打印出单词Hacking Android：
public class HackingAndroid{
Public static void main(String[] args){
System.out.println("Hacking Android");
}
}
将此文件另存为HackingAndroid.java。
现在我们需要编译这个 Java 文件。为 Android 编写的 Java 代码的初始编译过程类似于传统的 Java 文件。我们将使用javac作为编译器。
运行以下命令编译 Java 文件：
javac [filename.java]
注意：使用 JDK1.6 编译 Java 文件，因为 JDK 的更高版本会生成一个不兼容的.class文件，在下一步中无法与 dx 工具一起使用。
前面的步骤生成一个.class文件。通常，此类文件包含标准 JVM 字节码。以下摘录显示了前一个类文件的反汇编的外观：
public class HackingAndroid extends java.lang.Object{
public HackingAndroid();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3; //String Hacking Android
5: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
}
我们可以使用以下命令运行这些类文件：
java [classname]
正如我们在前面的屏幕截图中所看到的，我们可以看到输出控制台上打印的输出Hacking Android。
然而，这个类文件不能直接在 Android 设备上运行，因为 Android 有自己的名为 Dalvik 的字节码格式。这些是 Android 的机器代码说明。
因此，下一步是将此类文件转换为 DEX 文件格式。我们可以用 dx 工具来做。目前，dx 刀具的路径在我的机器中设置。通常可以在 Android SDK 路径的build tools目录下找到。
运行以下命令从前面的类文件生成 DEX 文件：
dx –dex –output=[file.dex] [file.class]
我们现在应该已经生成了 DEX 文件。以下屏幕截图显示在十六进制编辑器中打开的 DEX 文件：
现在我们都准备好了在 Android 仿真器上执行这个文件。让我们将此文件推送到/data/local/tmp/目录并运行它。
运行以下命令将此文件上载到 emulator：
adb push HackingAndroid.dex /data/local/tmp
如我们所见，该文件已被推送到设备上。
可以从命令行使用dalvikvm运行此文件。我们可以从您的本地计算机运行以下命令来执行此操作。或者，我们可以在设备上获取 shell，导航到上载此文件的目录，然后运行它：
adb shell dalvikvm –cp [path to dex file] [class name]
当 Android 操作系统启动时，一个名为 Zygote 的进程启动，它会侦听新的应用启动请求。每当用户单击一个应用时，就会使用 Zygote 启动它。当 Zygote 收到启动新应用的请求时，它使用 fork 系统调用创建自身的副本。这种启动新应用的过程被认为更高效、更快。新启动的应用进程加载运行所需的所有代码。我们前面读到的是，classes.dex文件包含与 Dalvik 虚拟机兼容的所有字节码。在从 Android 5.0 开始的最新版本的 Android 设备中，默认的运行时环境是 ART。在这个新的运行时环境中，classes.dex文件将使用名为dex2oat的工具转换为 OAT。
安卓 4.4 首次引入了 ART，作为可选的运行时环境，终端用户可以从设备的利用者选项中选择。谷歌从安卓 5.0（棒棒糖）中默认了它。当安装在用户设备上时，ART 基本上将应用的字节码转换为本机代码。这就是所谓的提前编译。在引入 ART 之前，Dalvik 曾在应用运行时动态地将字节码转换为本机代码。这种方法称为 JIT（准时制）方法。ART 的好处在于，应用的字节码不需要在每次启动时都转换为机器码，因为它是在应用安装过程中完成的。这可能会在第一次运行时造成一些延迟，但从下一次运行起，性能和电池寿命都会得到显著改善。
在前面的所有章节中，我们已经详细讨论了应用是如何构建和运行的。一旦应用安装在设备上，它在文件系统上会是什么样子？谷歌实施了哪些安全控制，以确保我们的应用的数据不受设备上运行的其他应用的影响？本节将详细讨论所有这些概念。
Android 构建在 Linux 内核之上，Linux 的用户分离模型也适用于 Linux，但与传统 Linux 略有不同。首先，让我们看看 UID 是如何分配给在传统 Linux 机器上运行的进程的。
我已以用户root身份登录我的 Kali Linux 机器，并运行两个进程：
- 冰鼬
- 格迪特
现在，如果我们查看上述两个进程的用户 ID，它们使用相同的 UID 根运行。为了进行交叉检查，我通过编写以下命令来过滤使用UID root运行的进程：
ps -U root | grep 'iceweasel\|gedit'
ps -U root : Shows all the process running with UID root
grep 'iceweasel\|gedit' : filters the output and finds the specified strings.
正如您所注意到的，我们能够在相同的用户 ID 下看到这两个进程。
现在，Android 应用的情况并非如此。安装在您设备上的每个应用都将有一个单独的用户 ID（UID）。这可以确保每个应用及其资源都被沙盒封装，并且任何其他应用都无法访问。
注意：使用相同密钥签名的应用（如果两个应用由同一个利用人员利用，则可能）可以访问彼此的数据。
以下摘录显示了如何为每个应用提供单独的 UID：
C:\>adb shell ps |find "u0"
u0_a14 1366 968 642012 68560 sys_epoll_ b73ba1b5 S com.android.systemui
u0_a33 1494 968 606072 40104 sys_epoll_ b73ba1b5 S com.android.inputmethod
.latin
u0_a7 1518 968 721168 61816 sys_epoll_ b73ba1b5 S com.google.android.gms.
persistent
u0_a2 1666 968 601712 39908 sys_epoll_ b73ba1b5 S android.process.acore
u0_a5 1714 968 599604 37284 sys_epoll_ b73ba1b5 S android.process.media
u0_a7 1731 968 723464 67068 sys_epoll_ b73ba1b5 S com.google.process.gapps
u0_a7 1814 968 847820 70992 sys_epoll_ b73ba1b5 S com.google.android.gms
u0_a37 1843 968 664656 52688 sys_epoll_ b73ba1b5 S com.google.android.apps
.maps
u0_a7 1876 968 696996 40352 sys_epoll_ b73ba1b5 S com.google.android.gms.
wearable
u0_a24 1962 968 600340 33848 sys_epoll_ b73ba1b5 S com.android.deskclock
u0_a46 1976 968 594520 28616 sys_epoll_ b73ba1b5 S com.android.quicksearchbox
u0_a20 2011 968 602900 32724 sys_epoll_ b73ba1b5 S com.android.calendar
u0_a1 2034 968 596712 33300 sys_epoll_ b73ba1b5 S com.android.providers.calendar
u0_a4 2098 968 599872 29700 sys_epoll_ b73ba1b5 S com.android.dialer
u0_a9 2152 968 593236 27876 sys_epoll_ b73ba1b5 S com.android.managedprovisioning
u0_a28 2223 968 610040 37504 sys_epoll_ b73ba1b5 S com.android.email
u0_a7 2242 968 709932 55596 sys_epoll_ b73ba1b5 S com.google.android.gms.unstable
u0_a30 2265 968 601140 30540 sys_epoll_ b73ba1b5 S com.android.exchange
u0_a43 2289 968 620792 52824 sys_epoll_ b73ba1b5 S com.google.android.apps
.messaging
u0_a8 2441 968 621016 50200 sys_epoll_ b73ba1b5 S com.android.launcher3
C:\>
如果您注意到前面输出的第一列，则每个已安装的应用都以不同的用户名运行，其名称以u0_xx开头。对于示例，电子邮件应用是用户u0_a28。同样，我们可以观察其他应用的用户名。
这些用户中的每一个实际上都映射到各自的 UID，从10000开始。例如，用户u0_a28与 UID10028映射。这可以通过浏览位于/data/system/目录下的文件packages.xml在根设备上进行验证。
如以下摘录所示，本文件归system所有：
shell@android:/ $ ls -l /data/system/packages.xml
-rw-rw---- system system 160652 2015-11-14 16:34 packages.xml
shell@android:/ $
为了更好地理解这一点，让我们看看一些应用及其低级 UID 映射。我安装了心率应用，程序包名为si.modula.android.instantheartrate。
启动应用并运行和ps命令，观察应用流程的第一列：
u0_a132 6330 163 382404 77120 ffffffff 00000000 S si.modula.android.instantheartrate
正如我们在前面的摘录中所看到的，这个应用的用户是u0_a132。我们可以使用packages.xml文件检查其低级 UID 映射，如下所示：
<package name="si.modula.android.instantheartrate" codePath="/data/app/si.modula.android.instantheartrate-1.apk" nativeLibraryPath="/data/data/si.modula.android.instantheartrate/lib" flags="0" ft="151013a1f08" it="151013a2db1" ut="151013a2db1" version="2700" userId="10132">
<sigs count="1">
<cert index="10" key="308202153082017ea00302010202044bedb53a300d06092a864886f70d0101050500304f310b300906035504061302534931123010060355040713094c6a75626c6a616e6131163014060355040a130d4d6f64756c6120642e6f2e6f2e311430120603550403130b5065746572204b75686172301e170d3130303531343230343032365a170d3335303530383230343032365a304f310b300906035504061302534931123010060355040713094c6a75626c6a616e6131163014060355040a130d4d6f64756c6120642e6f2e6f2e311430120603550403130b5065746572204b7568617230819f300d06092a864886f70d010101050003818d003081890281810085bc0e5459c5d09bf94bddf5f599b3328d53fbdac876b7cf17288a44d9f8dfcf51d004c7dec353872940f101d83a53b1c050990a863db402249fe57349a2c1ba2ef49a11640755808e8b78593d81ab859aa3614eff02d4d38d2ea042101a8eccc166cd187d66be2075bf89d993c6e94080d1cb47d410b6f42931bc39fa4674f70203010001300d06092a864886f70d01010505000381810008a7be43861ebf10afc8918da2b9b63f5477a6ec4bcea8ab8b6b1d97bae4ee71969d692a3112f269b7ce2834984f6e30296bdc1be8beb1b5c369158240da1a915a324b6d69cea650e6754d95f3334fb9fab4e6c1715668560a3cf7faf159322a3b578e70579652b9b3f91a8e419d06e7e58bb16e4a2a77b6030c4b7a064a251c" />
</sigs>
<perms>
<item name="android.permission.CAMERA" />
<item name="android.permission.ACCESS_NETWORK_STATE" />
<item name="android.permission.FLASHLIGHT" />
<item name="android.permission.INTERNET" />
</perms>
</package>
如果您注意到字段userId="10132"，则表明用户为u0_a132的应用映射到了userid 10132。
我们也来检查一个这样的预装应用。以下app com.sonyericsson.notes为索尼设备预装。ps命令显示分配了u0_a77：
u0_a77 6544 163 308284 30916 ffffffff 00000000 S com.sonyericsson.notes
现在，让我们来探索packages.xml文件：
<package name="com.sonyericsson.notes" codePath="/system/app/SemcNotes.apk" nativeLibraryPath="/data/data/com.sonyericsson.notes/lib" flags="1" ft="13c933e4830" it="13c933e4830" ut="13c933e4830" version="1" userId="10077">
<sigs count="1">
<cert index="1" />
</sigs>
</package>
如你所见，它有userId 10077。
每个应用在/data/data/目录中都有自己的条目，用于存储其数据。如前一节所示，每个应用都有特定的所有权。
以下摘录显示了如何在/data/data/目录下的单独沙盒环境中隔离每个应用的数据。为了观察这一点，我们需要一个根设备或模拟器，因为有限的用户无法访问/data/data/目录：
-
使用 adb 在根设备上获取 shell。
-
使用以下命令导航到目录
/data/data：cd data/data/ -
输入
ls -l命令。
以下摘录是从/data/data/目录中的ls –l命令中获取的输出：
drwxr-x--x u0_a2 u0_a2 1981-07-11 12:36 com.android.backupconfirm
drwxr-x--x u0_a3 u0_a3 1981-07-11 12:36 com.android.bluetooth
drwxr-x--x u0_a5 u0_a5 2015-11-13 15:42 com.android.browser
drwxr-x--x u0_a6 u0_a6 2015-10-28 13:27 com.android.calculator2
drwxr-x--x u0_a72 u0_a72 1981-07-11 12:39 com.android.calendar
drwxr-x--x u0_a9 u0_a9 2015-11-14 02:14 com.android.certinstaller
drwxr-x--x u0_a11 u0_a11 2015-11-13 15:38 com.android.chrome
drwxr-x--x u0_a17 u0_a17 2015-10-29 04:33 com.android.defcontainer
drwxr-x--x u0_a75 u0_a75 1981-07-11 12:39 com.android.email
drwxr-x--x u0_a24 u0_a24 1981-07-11 12:38 com.android.exchange
drwxr-x--x u0_a31 u0_a31 1981-07-11 12:36 com.android.galaxy4
drwxr-x--x u0_a40 u0_a40 1981-07-11 12:36 com.android.htmlviewer
drwxr-x--x u0_a47 u0_a47 1981-07-11 12:36 com.android.magicsmoke
drwxr-x--x u0_a49 u0_a49 1981-07-11 12:39 com.android.musicfx
drwxr-x--x u0_a106 u0_a106 1981-07-11 12:36 com.android.musicvis
drwxr-x--x u0_a50 u0_a50 1981-07-11 12:36 com.android.noisefield
drwxr-x--x u0_a57 u0_a57 2015-10-31 03:40 com.android.packageinstaller
drwxr-x--x u0_a59 u0_a59 1981-07-11 12:36 com.android.phasebeam
drwxr-x--x radio radio 1981-07-11 12:39 com.android.phone
drwxr-x--x u0_a63 u0_a63 1981-07-11 12:36 com.android.protips
drwxr-x--x u0_a1 u0_a1 1981-07-11 12:36 com.android.providers.applications
drwxr-x--x u0_a7 u0_a7 1981-07-11 12:38 com.android.providers.calendar
drwxr-x--x u0_a1 u0_a1 1981-07-11 12:39 com.android.providers.contacts
drwxr-x--x u0_a37 u0_a37 1981-07-11 12:37 com.sonyericsson.music.youtubeplugin
drwxr-x--x u0_a77 u0_a77 2015-10-28 13:22 com.sonyericsson.notes
drwxr-x--x u0_a125 u0_a125 1981-07-11 12:37 com.sonyericsson.orangetheme
drwxr-x--x u0_a78 u0_a78 1981-07-11 12:36 com.sonyericsson.photoeditor
drwxr-x--x u0_a126 u0_a126 1981-07-11 12:37 com.sonyericsson.pinktheme
如果您注意到前面输出中的文件权限，则每个应用的目录都归自己所有，其他用户不可读写。
谷歌表示，“与所有安全功能一样，应用沙盒并非牢不可破。然而，要在正确配置的设备中突破应用沙盒，必须破坏 Linux 内核的安全性”。
在这里，我们可以轻松地讨论 Android root，它允许用户拥有 root 权限，在 Android 系统上完成他们想做的大部分事情。
在基于 Linux（和 UNIX）的机器中，“root”是具有执行任何任务的最高权限的最高用户级别。默认情况下，只有 Linux 内核和少量核心实用程序在 android 上作为“根”运行。但如果您以根用户身份访问设备，则该设备上运行的所有应用都可以使用根用户级别。现在，任何具有 root 权限的用户或应用都可以通过打破沙盒环境来修改 Android 操作系统的任何其他部分，包括内核、其他应用以及应用数据。
安卓Root概念已在第 2 章、安卓Root中详细讨论。
本章对 Android 应用的内部结构进行了更深入的了解。了解应用的内部实现细节是从 Android 安全开始的重要部分。本章试图向读者提供这些概念。在下一章中，我们将讨论攻击 android 应用的概述。