The Android architecture

Many a time, Android is referred to as Java on Linux. As a developer or security researcher, it is very important to understand the architecture behind any platform. Android's architecture is based on the Linux 2.x and 3.x kernels and acts as the hardware abstraction layer.

It consists of:

• Key applications
• An operating system (which is the abstraction between the software and hardware components)
• Middleware
• The runtime environment
• Different services
• Native and custom libraries

It can be represented as five different layers, as shown in the following architecture diagram:

All the components are tuned and integrated to provide the optimal application development and execution environment for mobile contrivances.

Now, let's take a bottom-up approach toward understanding the different layers of the Android stack.

The Linux kernel

The Linux kernel is the heart of the Android OS. Linux has extensible portability features, that is, it enables easy compilation of programs on different hardware platforms, and was therefore chosen as the best candidate to start with.

The Linux kernel, which is in the bottom part of the software stack, supports basic OS functionalities such as process management/scheduling, memory management, and device management. It also forms an important abstraction layer by providing access to various device drivers so that the app can interact with hardware devices.

A simple example for this is the automatic tilt/rotation adjustment of the screen to match the orientation of the mobile device. The following questions arise:

• How does this happen?
• What triggers the device to perform this operation?
• How does the OS come to know that the device orientation has changed?

Let's have a look.

Hardware sensors in the device, such as the accelerometer and gyroscope, detect minute movements and changes in orientation and relay this hardware data to the kernel. The device drivers convert this information into software instructions and these are picked up by the apps; if the app is programmed to respond to these instructions, it does so accordingly. As shown in the following diagram, the Linux kernel contains all the drivers that are required for the hardware to function appropriately and it also performs power management.

In a nutshell, the Linux kernel is responsible for the management of memory, resources, power, and drivers.

Confusion between Linux and the Linux kernel

The term Linux is customarily used for the entire operating system and the term kernel designates the core of the operating system. Saying Android is predicated on the Linux kernel does not denote that it is another Linux distribution; it is just that the core operating system is Linux, and not all Linux packages can be installed on Android.

Note

Why does Android use the Linux kernel?

The reason is that the Linux kernel has a proven driver model along with its extensive collection of drivers. It additionally provides a well-defined security model and an abundance of core operating system capabilities, which have been working very well for a very long period of time.

Android runtime

Although Android is developed in Java, the runtime layer of the Android architecture consists of the Dalvik virtual machine (DVM), core Java libraries, and recently, a new virtual machine called Android runtime (ART).

The following figure is from Android 4.4 KitKat, which allows developers to build applications for ART:

The DVM runs Java-programmed apps. The DVM does not claim to be a Java virtual machine (JVM) due to licensing reasons, but fulfills the same purpose. The reason for this is that Dalvik is optimized to run on small-sized devices with limited memory. Due to performance reasons, the DVM is started only once. Each new instance of it is cloned by a system service called Zygote. The following diagram provides the structure of Android runtime:

The java virtual machine

When any Java program is compiled, we get bytecode. The JVM is a virtual machine (a virtual machine is an application that acts as an operating system) that can execute this bytecode. The following diagram illustrates how a Java program is compiled:

The Dalvik virtual machine

In Android, the bytecode generated by the JVM is taken as the input to the DVM, which will then produce a lightweight format called .dex.

Why do we need to convert Java bytecode to .dex?

The answer is that in the case of mobile devices, we don't have the amount of power, memory, and RAM as compared to PC. This gives us the reason why we need more lightweight applications. Java bytecode is suitable for heavyweight applications on PCs. The DVM employs compression techniques and reduces redundant information in the classes and then produces the .dex file. For example, if you have 1,000 classes written in your Java source code, all these 1,000 classes will be available as one single file in a format called the Dalvik executable format (.dex).

The following flowchart shows the conversion of Java source code (.java) to Dalvik byte code (.dex):

Zygote

When an Android device boots, one of the first processes to be started is Zygote, which is responsible for:

• Starting up a virtual machine
• Preloading the core libraries
• Initializing various shared structures

Note

A Google versus Oracle court case centers on the use of Java in Android, particularly in relation to API calls (https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.)

Core Java libraries

These are different from the Java SE and Java ME libraries within the core Java libraries. They are often referred to as Dalvik libraries. These include:

• DVM-specific libraries: These libraries are specifically used to interact directly with a DVM instance. It is unlikely that the development community will use them.
• Java interoperability libraries: These are nothing but a list of classes that hold in the core Java run time libraries; typically, the libraries provide support in file operations, handling strings and other networking.

ART

When Google introduced Android Lollipop, the DVM was completely replaced by ART. ART has many advantages over the DVM, such as:

• Ahead-of-time (AOT) versus old just-in-time (JIT) compilation
• Improved garbage collection
• Better application performance

The following diagram illustrates how ART code is compiled:

Native libraries

When programming in Java, it is not possible to interact with some low-level components. For example, if you have to display graphics on the device screen, it is not possible to directly write code in Java; instead, one can write a function or method to call other native programs that are non-Java programs.

These non-Java programs are the native libraries in Android. All the libraries are written in C, C++, and other languages. This native code is installed using the Android Native Development Kit (NDK), which provides a wide range of libraries and headers that allow developers to code and build different activities.

The following diagram shows the different native libraries available on the current Android platform:

Every original equipment manufacturer (OEM) can customize it accordingly. Typically, the libraries module includes the following:

• The media framework: This framework is based on PacketVideo OpenCore platforms, and it supports standard audio, video, still-frame formats and codec plugins. The StageFright vulnerability was uncovered using a media framework (libStageFright) weakness that allowed full remote access to attackers using the feature that automatically allowed video files to play on an Android device when received through an MMS or other means.
• The surface manager: This supports the display subsystem and renders 2D and 3D graphics layers from multiple applications.
• Freetype: This is used to render bitmap and text.
• OpenGL ES: OpenGL is a cross-platform graphics API that specifies a standard software interface for 3D graphics-processing hardware.
• SSL (short for Secure Socket Layer): This is based on OpenSSL (www.openssl.org).
• SQLite: This is a lightweight relational database engine available to all applications through the application framework API.
• WebKit: This is a browser engine based on the open source WebKit browser (www.webkit.org) and it supports the rendering of pages, full CSS, JavaScript, DOM, and AJAX as well as single-column and adaptive view rendering.
• SGL (short for Scalable Graphics Library): This is used for 2D graphics libraries.
• libc: A BSD-derived implementation of standard C system libraries for embedded Linux-based devices.

The application framework

The application framework provides the infrastructure for developers to build much more complex applications or tools. The entire development lifecycle of the application is managed using this framework.

For example, a developer who is building an app that requires the use of the notification feature need not write a huge line of code—he or she can simply call the Notification Manager API. This framework provides a majority of the APIs that are required to use an Android device.

The following diagram provides a list of the frameworks that are currently available on the Android platform:

The key services in this framework are:

• Activity Manager: The entire lifecycle of an app is provided by the Activity Manager, and, it is also responsible for managing the different states of an activity to ensure that apps using different processes are running smoothly, which we will discuss in detail in a following section.
• Content Providers: This component allows applications to publish and share data with other applications. Encapsulating data, defining data security, and managing the structure of data is taken care of by Content Provider. One such example is when all the input provided by the user to an app is structured and stored in an SQLite database.
• Resource Manager: Access to all embedded resources that are not coded in the app, for example, graphics, localized strings, and other layout files, are taken care of by the Resource Manager.
• Notifications Manager: This provides mobile user notifications and display alerts.
• View System: Different sets of view, event dispatching, and other important buttons and lists are handled by the View System.
• Package Manager: This controls all the application packages that are installed on the device.
• Telephony Manager: This supplies telephone services available on the device, such as status and subscriber information
• Location Manager: This provides location services about location changes, which allow an application to receive updates.
• Window Manager: It is responsible for organizing the screen that is displayed to the user, and it also provides the decision-making capabilities of the surface when the application is to be rendered and layered accordingly on the display window.

The applications layer

This is the first layer in the Android stack, where a majority of users interact with the mobile through applications. There are two kinds of applications that are normally available on the device, as displayed in the following figure:

Now let's explore the differences.

Native Android or system apps

System apps are applications that are preinstalled on the phone by the OEM and shipped along with the phone. The applications loaded by default include the e-mail client, SMS program, Phone, Calendar, Maps, phone dialer, Browser, Contacts, and others. These apps normally cannot be uninstalled from the device and are present in the /system folder.

User-installed or custom apps

These apps are downloaded and installed by the user from various distribution platforms, such as Google Play and Amazon Store. These apps are present in the /data/data/ folder within the Android filesystem. We will discuss the details of the security features in the coming sections.

The Android software development kit

In simple terms, the Android software development kit is a repository of tools that help developers create apps on Android; it can be downloaded from https://developer.android.com/sdk/index.html.

The kit includes all the tools, documentation, platforms (which include data, skins, images, and sample OS images), and add-ons (such as Google maps). A majority of developers now use Android Studio, which is based on IntelliJ, and some use Eclipse as the IDE for Java programming (https://eclipse.org/downloads/).

We will discuss in detail how to install and configure the Android SDK to perform security assessment in Chapter 3, Building a Test Environment.

Android application packages (APK)

Installable files in Android are called Android application package (APK) files. This is the file format used by Google to distribute applications for the Android operating system and is similar to .exe files in Windows.

Note

APK files are nothing but ZIP files that are based on the JAR file format.

Let's take an example. For demonstration purposes, we have downloaded the Gmail application from the app store, renamed the .apk file to .zip and extracted it into a folder. Typically, this file includes the items shown in this screen capture:

• assets: This folder is similar to the res folder; the majority of the resources that are in it require less memory. Asset manager classes support these files. Many a time, you can find some interesting references left behind by the developers, which can be beneficial for security researchers.
• META-INF: This folder typically includes the .MF (manifest file) and certificates that are used to sign the app.
• res: This folder contains all the resources required by the application that are not compiled into resources.arsc.
• AndroidManifest.xml: This is the file that contains all the details about the application and its functionality, permissions, and so on. When you unzip an .apk file, this file won't be readable due to the .jar format; you may need tools such as ApkTool or Androguard to make it plaintext.
• classes.dex: This is the compiled Dalvik executable file.
• resources.arsc: This file contains all the precompiled resources that are required by the app, for example, all the XML files that support the UI component of an app.
• lib: This folder is not visible in the previous screen capture, but it contains the compiled code that is specific to a processor, such as armeabi, arm64-v8a, x86, and MIPS.

AndroidManifest.xml

What is in the application = AndroidManifest.xml

The AndroidManifest.xml file provides complete information about an Android application. In simple terms, the Android platform is going to read this particular file before as well as after installation in order to start the app. The manifest file is responsible for the following:

• It names the Java package for the application
• It describes the Android application's components; we will discuss this in detail in the next section.
• It determines which process will present which application components
• It declares permissions
• It lists the libraries packaged and linked against the app
• It contains a declaration of the minimum level of the API that the application requires

The structure of the Android manifest file

The following screen capture shows the general structure of any AndroidManifest.xml file:

All the elements in this file have to be legal elements; no custom or personal elements or attributes are supported in general.

The following table summarizes all the elements that appear in a manifest file:

Understanding the AndroidManifest.xml file is the first and foremost element of Android application penetration testing. Some of the fantastic features that the application provides to users can be translated into a risky feature if there is a mismatch in using the right elements.

Android application components

Android applications are made using application components. Each component is equipped with a different means of working with the operating system. The overall behavior of the application vitally depends on these components. Understanding these components in detail will be crucial during the penetration testing activity because any app will have at least one of these components. There are four different types of Android components, as shown in the following diagram:

All Android components are closely connected using intents.

Intent

Intents are the key part of inter-app communication; these are objects that contain message information about the operation that needs to be performed. Intents comes in two forms:

• Explicit: These intents have components specified through classes, which provide the exact component to be run
• Implicit: These intents do not have any specific components defined; instead, they allow the Android system to evaluate and register a component based on the data produced by the intent

Three of four types of Android application components being launched by an asynchronous call is called an intent. It associates the base between the components in an app.

Activity

An activity is nothing but the representation of single screen with a user interface (UI) in which users can view and interact. For example, a phone application displays a dialer, a different activity provides an interface for typing the contact name, and another activity provides an interface to dial the number.

An activity is created by the system by calling a set of lifecycle methods, which act as the core, similar to the base level of a wedding cake. Subsequently, different stages of the activity lifecycle correspond to different levels of the cake. The system moves the activity state step by step to the top as and when newer activities invoke their callback methods. The top level of the cake represents the foreground location at which the activity is accessible to the user for interaction. Similarly, when the user starts moving away from the activity, the system moves the activity state step by step from the top to the bottom. The activity is paused and waits to be resumed or is stopped and waits to be restarted. The base is again where the activity is concluded and destroyed.

It is important to understand how the activity lifecycle works; let's now walk through what happens when a mobile application is launched through a step pyramid, with a simple illustration of the activity lifecycle from Google's Android developer community website (https://developers.google.com):

The Android system launches the application by initiating code in an activity instance instead of utilizing the main() method used in traditional programming constructs. It does so by summoning the callback methods in a specific way corresponding to the stages of its lifecycle. There are specific sequences of callback methods to start up an activity and also tear it down. The preceding diagram shows how every callback takes the activity a step toward the Resumed state at the top. To step down from an activity, there is a callback method. The activity can also be returned to the Resumed state from the Paused and Stopped states.

The typical activities include:

• The launch activity: The launch activity is invoked by the onCreate() method. This method is called when a user clicks on the application from the home screen of the device.
• The create activity: New instances of activities are invoked by calling the onCreate() method. This method is called only once for each activity. At the end of the activity, the onStart() and onResume() methods are called by the system. The user will be able to see an activity when the onStart() method is called. Once the activity is started, the onResume() method is called and the activity is in the Resumed state.
• The pause activity: An activity is paused by invoking by the onPause() method. When one activity is overtaken by another activity, the new activity comes to the foreground but the first activity is still visible in the background and is paused. Information that is required to be persisted is saved in case the user moves on to another activity.
• The resume activity: An activity is resumed by invoking the onResume() method. This method is used to resume an activity from the Paused state. When an activity comes into the foreground, the onResume() method is called by the system. The activity resumes its tasks and continues to perform considering the user to be focused on the activity.
• The stop activity: An activity is stopped by invoking the onStop() method. This method is used to stop an activity when it is no longer visible, and it releases all the resources that were used by the activity.
• The restart activity: An activity is restarted by invoking the onRestart() method. This method is used when the activity comes to the foreground from the Stopped state. The onStart() method is also invoked by default along with the onRestart() method.
• The destroy activity: An activity is destroyed by invoking the onDestroy() method. This method is used to completely end an activity. All the information and resources are released and this method usually cleans up any resources that were not released by the onStop() method.

Services

A service is an Android application component that can be started and stopped without the UI. These are typically used in long-running tasks in the background. Some examples of common services include the SMS receiver and Wi-Fi network alerts/status. Although each of these services runs outside of the user's view, these components take advantage of IPC facilities by sending and receiving intents.

Services are further pided into two categories: unbound and bound.

Unbound or start services

An unbound service is an application component that starts the service and will continue to run in the background even when the original component that initiated it is destroyed. For example, on turning on Bluetooth, a service would be available and ready to discover other devices in the background.

Bound service

A bound service can bind from one application activity or component to another using bindservice(). This service would run as long as the activities or components are bound to it. It is destroyed only when they are unbound.

A simple flowchart from Google's Android developer community website illustrates the two types of service lifecycles (http://developer.android.com/guide/components/services.html):

The important methods in a service lifecycle are:

• onStartCommand(): This method is called when startService() is called
• onBind(): This method is used when another component wants to bind with the service calling bindService()
• onCreate(): All the service initiation is done by calling this method; it is never called again
• onDestroy(): This method is called or used to destroy the service in order to clean up the created threads, receivers, and so on

Broadcast receivers

A broadcast receiver is an Android component used to answer system announcements and register for system or application events.

For example, when you plug in a headset, charger, or USB cable to a device, the alerts you see on the screen are broadcast receivers. The following screenshot shows that the volume button has been pressed and the notification is shown to the user:

The permission set on a broadcast receiver limits the apps that can send intents to that or any declared endpoint.

Content providers

In Android, you cannot share one application's data with another due to the restrictions imposed by the operating system. A content provider is used to share data between multiple applications, for example, a social networking application such as WhatsApp accessing the contacts, calls logs, and photo gallery. Unlike other application components, the ability to read from or write to content providers can be restricted with permissions.

Consider the following code snippet from an example AndroidManifest.xml file:

<provider android:name="NotePadProvider" android:authorities="com.google.provider.NotePad" android:exported="false">
        <grant-uri-permission android:pathPattern=".*" />
</provider>

The application declares a provider named NotePadProvider. The com.google.provider.NotePad class implements the ContentProvider. The android:authorities is the list of one or more URI authorities that identify the data offered by the content provider.

Android Debug Bridge

Before we begin to understand the process of building an Android application, it is very important that you have good understanding of Android Debug Bridge (adb), which is a simple command-line tool from which you can communicate with an Android device or emulator.

adb communication happens between a client, server, and daemon (adbd). This is one tool that we will be using throughout the Android application penetration testing process, especially to identify potential vulnerabilities in the file structure or the storage of an application on the device, permission details at the OS level, shared information, and so on.

The following screen capture shows two sample commands to display devices using the adb command and also to access the shell of the device. We will take a wider look at how to use this powerful tool for attacking an Android application in Chapter 6, Full Steam Ahead – Attacking Android Applications.

Application sandboxing

Android utilizes the well-established Linux protection ring model to isolate applications from each other. In Linux, assigning a unique ID segregates every user. This ensures that there is no cross-account data access. Similarly, in Android, every app is assigned its own unique ID and run as a separate process. As a result, an application sandbox is formed at the kernel level and the application will only be able to access the resources it is permitted to access. This subsequently ensures that the app does not breach its work boundaries and initiate any malicious activity.

The following diagram provides an illustration of the Android sandbox mechanism:

From this diagram, we can see how the unique Linux UID created per application is validated every time a resource mapped to the app is accessed, thus ensuring a form of access control.

Application signing

Android apps bank on digital certificates to achieve entity and data origin authentication with the app developer. Usually, self-signed certificates (certificates signed by a certificate authority are valid as well) are used to digitally sign an app before its installation. As this is a form of asymmetric cryptography, the app developer holds a private key that can be used for pushing updates to the app. This diagram provides the list of steps performed post the application development:

Secure inter-process communication

As discussed in the previous sections, apps are run as separate processes with discrete Linux identities in order to achieve sandboxing. System services also follow the same method by running as separate processes but with a caveat, that is, they have more privileges. Therefore, in order to manage and synchronize data and signals between these processes, an inter-process communication (IPC) framework is needed. The IPC framework enables us to share information between components and helps in privilege separation as well as data isolation.

In Android, this is achieved with the use of the Binder framework. Binder comes from OpenBinder (https://en.wikipedia.org/wiki/OpenBinder).

The Binder framework enables us to run communication between separate processes. Android application components such as intents and content providers are also built on top of this Binder framework. Using Binder, it is possible to perform a wide range of actions, such as invoking methods on remote objects by considering them as local objects, invoking methods synchronously and asynchronously, and sending file descriptors across processes.

Let's consider that an application in process A wants to utilize the service exposed by another process, B. So, process A becomes the client requesting the service from process B, which eventually becomes the server. The communication model using Binder is shown in the next screenshot, in the following subsection.

The Binder process

All the IPC using Binder is enabled through Android's modified kernel through the driver found at /dev/binder. By default, these device drivers have read and write permissions that are set globally, which means any application can read from or write to them. Each Binder service has a unique 32-bit token value, which is assigned using the Binder mechanism. This token remains unique across all the processes in the system. The client can interact with the service after determining the token value using Binder's context feature.

A client and a server cannot communicate directly in Binder; all the client-side interfaces are over proxies and server-side interfaces over stubs. These proxies and stubs hold the responsibility of data exchange and the commands that are sent over the Binder Driver.

If Process A requests to utilize a service used by Process B, the Binder driver adds the UID and PID values of Process B for each transaction. Ultimately, Process A can check the values obtained and decide whether the transaction should be completed or not. This enforces security and also the Binder token acts as a security token for the communication.

Note

An interesting presentation was demonstrated at the Black Hat conference of 2014 about the Man in the Binder attack. Its paper, Man in the Binder: He who Controls IPC, Controls the Droid, can be downloaded from https://www.blackhat.com/docs/eu-14/materials/eu-14-Artenstein-Man-In-The-Binder-He-Who-Controls-IPC-Controls-The-Droid.pdf.

The Android permission model

It is very beneficial to understand the Android permission model, which is implemented for every single app while assessing it for privacy concerns. The manifest file includes all the permissions that the application will require. The following screenshot shows the application requesting access to multiple resources. This is presented to the user so that he or she can make a decision whether to install or not.

This provides the full information to the user before the application is installed to the device about what type of permissions the application is seeking. A majority of users who are want to install the app on their device fail to read the permissions that they are granting the app, which means they are exposing the device to malicious activities or making it more vulnerable.

Note

Until Android 5.0 Lollipop, it was not possible to install an application with custom permission selection. You could either cancel the installation or accept all the requested permissions from the application. Android 6.0 Marshmallow allows users to customize the permission model.

Android permissions are categorized into the following levels:

The Android application build process

This section provides an overview of how an Android application is compiled and executed and what the stages of its execution process are. This process is very useful while reverse-engineering the application.

The following diagram illustrates the application build development stages:

Now, let's pide this build process into the following steps:

1. Generating the resource code:

   All the application resource files, such as XML files, AndroidManifest.xml, libraries, and source files are compiled using the aapt tool, as a result of which the R.java file is produced, so that all the resources from the Java code are referenced correctly.

2. Generating the interface code:

   The next step is to create the interfaces for communication between a client and service; this is achieved using the aidl tool, which converts all the .aidl files into Java interfaces.

3. Compiling the Java code:

   Here, the Java compiler (JVM) is introduced, which will then convert R.java and the .aidl files into .class files (Java bytecode).

4. Converting the bytecode:

   Now that we have compiled all the files into bytecode, it is then passed on to dextool, which converts the .class files into Dalvik bytecode. All the other code utilized from third-party libraries and .class files is used to produce the .dex file.

5. Prebuild packaging:

   The typical files and folders available in Android that we discussed in the previous section, such as resources.arsc, assets, lib, and .dex, are compiled into a .apk file using the ApkBuilder tool.

6. Signing the package:

   Finally, once the packaging is done, it is then signed with a release/debug key using JarSigner or a similar tool.

7. Optimizing the package:

   Some developers use the Zipalign tool post the .apk file build in order to optimize memory usage while the application runs on a device.

An excellent understanding of the application build process will enhance your skill in reverse engineering.

The Dalvik VM has been completely replaced by ART now. The following diagram illustrates the architectural differences between ART and the Dalvik VM:

The main difference is that the JIT compiler has been replaced with AOT; AOT could be the next-generation JIT. ART essentially compiles the DEX file into completely native code that will be in the .oat file format.

Some of the key tools in this section are:

• aapt (short for Android Asset Packaging Tool): It allows developers to create, view, and update compatible archives such as ZIP, JAR, and APK. This tool is also used to compile resource files into a binary asset.
• AIDL (short for Android Interface Definition Language): Helps developers define the interface through programming at the client and service level in order to provide communication between each other through inter-process communication.
• Dexopt: Dexopt is a tool that is used to optimize DEX files within Dalvik. It helps by optimizing the loading of classes and ensuring proper resource allocation. It initializes a VM, loads the DEX files, and checks for instructions, which can be optimized so that they do not require additional resources during the execution. Dexopt provides .odex files as output.
• JIT: JIT (short for just-in-time) is the execution engine within some JVM implementations; it is known to require more memory but execute faster. When the method is called for the first time, the JIT compiler will compile the bytecode of the method to native machine-level code.
• Dex2oat: Dex2oat compiles the DEX files. Instead of interpretation by a virtual machine, it allows the execution of native code by the processor. It works on the concept of AOT compilation, which is different from DVM in that uses JIT compilation. Dex2oat provides ELF (short for Executable and Linkable Format) files as output.
• ODEX files: ODEX files are created as a result of the optimization performed on application packages. These files will be present within the .apk file and indicate that the application package has been optimized to save resources.
• ELF files: ELF files are the replacement for ODEX files in ART. The .dex files supply the same bytecode to ART as they do in Dalvik. The dex2oat utility on ART compiles the application on the device and the compiled ELF executable is called for application execution.

The following diagram is the ELF header file format:

The header contains the following parts:

• ELF Header: This header holds the full details of the file in different sections that hold all the code, instructions, and data.
• Program header table: This table holds the information required to create a process image. It is basically an array of structures describing information required from a segment or other system for program execution.
• Section header table: This table contains information about linking program code, relocation, and other details.
• Segments: This file contains one or more sections that could be loadable, dynamic, and so on.

Android rooting

The method of using various means of exploitation in firmware to remove restrictions imposed by the operating system is termed as rooting in Android and jailbreaking in iOS. Some OEMs provide devices with root enabled.

There are plenty of reasons to root Android, not limited to:

• Sideloading applications, which is the term used for installing applications from non-traditional app stores (other than Play Store)
• Customizing the CPU and kernel
• The ability to have full application access to move it around in the storage, to back it up, and so on
• The ability to install custom firmware, normally referred to as CustomROM

Here are some rooting tools:

• Wondershare
• Kingo
• SRSroot
• Root Genius
• iRoot

There are also tools that can be used without connecting to the computer, such as SuperSU Pro, Superuser, and framearoot.

Note

Rooting or jailbreaking phones might void your phone's warranty and will be your own risk. It is recommended not to use your personal phone for penetration testing purposes.