0% found this document useful (0 votes)
28 views

Unit 5 - Android

The document discusses Android forensics including Android basics, keycodes, ADB, rooting Android, file systems, security tools, and forensic procedures. It provides details on Android versions, features, ADB commands, and risks of rooting Android devices.

Uploaded by

ahamedamuhasin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views

Unit 5 - Android

The document discusses Android forensics including Android basics, keycodes, ADB, rooting Android, file systems, security tools, and forensic procedures. It provides details on Android versions, features, ADB commands, and risks of rooting Android devices.

Uploaded by

ahamedamuhasin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

UNIT V

ANDROID FORENSICS

Android basics – Key Codes – ADB – Rooting Android – Boot Process – File
Systems – Security –Tools – Android Forensics – Forensic Procedures – ADB –
Android Only Tools – Dual Use Tools –Oxygen Forensics – MobilEdit – Android
App Decompiling

Android basics

Android is the best-selling open-source Linux-based operating system among various mobile
platforms across the globe. Hundreds of millions of mobile devices are powered
by Android in more than 190 countries of the world. It conquered around 75% of the global
market share by the end of 2020, and this trend is growing bigger every other day.

Android was developed by the Open Handset Alliance, led by Google, and other
companies. The source code for Android is available under free and open source software
licenses. Google publishes most of the code under the Apache License version 2.0 and the rest,
Linux kernel changes, under the GNU General Public License version 2.
Why Android ?
Features of Android

Android is a powerful open-source operating system that open-source provides immense


features and some of these are listed below.
 Android Open Source Project so we can customize the OS based on our requirements.
 Android supports different types of connectivity for GSM, CDMA, Wi-Fi, Bluetooth, etc.
for telephonic conversation or data transfer.
 Using wifi technology we can pair with other devices while playing games or using other
applications.
 It contains multiple APIs to support location-tracking services such as GPS.
 We can manage all data storage-related activities by using the file manager.
 It contains a wide range of media supports like AVI, MKV, FLV, MPEG4, etc. to play or
record a variety of audio/video.
 It also supports different image formats like JPEG, PNG, GIF, BMP, MP3, etc.
 It supports multimedia hardware control to perform playback or recording using a camera
and microphone.
 Android has an integrated open-source WebKit layout-based web browser to support User
Interfaces like HTML5, and CSS3.
 Android supports multi-tasking means we can run multiple applications at a time and can
switch between them.
 It provides support for virtual reality or 2D/3D Graphics.
Android Versions

Google first publicly announced Android in November 2007 but was released on 23
SEPTEMBER 2008 to be exact. The first device to bring Android into the market was the
HTC Dream with the version Android 1.0. Since then, Google released a lot of android
versions such as Apple Pie, Banana Bread, Cupcake, Donut, Éclair, Froyo, Gingerbread,
Jellybeans, Kitkat, Lollipop, marshmallow, Nougat, Oreo, etc. with extra functionalities and
new features.
Keycodes

In Android development, keycodes are constants that represent the various keys on a keyboard
or input device. They are used to handle user input events such as key presses. Each key on a
keyboard has a unique keycode associated with it.

Android provides a set of constants in the KeyEvent class for commonly used keys. These
constants represent the physical keys on a keyboard as well as some additional keys specific to
Android devices, such as navigation keys and media control keys.

Here are some common keycodes in Android:

1. KEYCODE_BACK: Represents the Back key.


2. KEYCODE_HOME: Represents the Home key.
3. KEYCODE_MENU: Represents the Menu key.
4. KEYCODE_VOLUME_UP and KEYCODE_VOLUME_DOWN: Represent the
volume up and volume down keys, respectively.
5. KEYCODE_POWER: Represents the Power button.
6. KEYCODE_ENTER: Represents the Enter key.
7. KEYCODE_TAB: Represents the Tab key.
8. KEYCODE_DEL or KEYCODE_FORWARD_DEL: Represents the Delete or
Forward Delete key, depending on the keyboard.
9. KEYCODE_SPACE: Represents the Space key.
10. KEYCODE_SHIFT_LEFT and KEYCODE_SHIFT_RIGHT: Represent the left and
right Shift keys, respectively.
11. KEYCODE_ARROW_LEFT, KEYCODE_ARROW_UP,
KEYCODE_ARROW_RIGHT, and KEYCODE_ARROW_DOWN: Represent the
arrow keys.

These are just a few examples, and there are many more keycodes available in Android for
handling different types of key events. Developers can use these keycodes in conjunction with
event listeners to respond to user input in their Android applications.

Android Debug Bridge (adb)

Android Debug Bridge (adb) is a versatile command-line tool that lets you communicate with
a device. The adb command facilitates a variety of device actions, such as installing and
debugging apps.
The ADB is typical, used to communicate with a smartphone, tablet, smartwatch, set-top box,
or any other device that can run the Android operating system.

It is a client-server program that includes three components −

 A client, which sends commands. The client runs on your development machine. You
can invoke a client from a command-line terminal by issuing an adb command.
 A daemon, which runs commands on a device. The daemon runs as a background
process on each device.
 A server, which manages communication between the client and the daemon. The
server runs as a background process on your development machine.

How adb works

When you start an adb client, the client first checks whether there is an adb server process
already running. If there isn't, it starts the server process. When the server starts, it binds to
local TCP port 5037 and listens for commands sent from adb clients.

The server then sets up connections to all running devices. It locates emulators by scanning
odd-numbered ports in the range 5555 to 5585, which is the range used by the first 16
emulators. Where the server finds an adb daemon (adbd), it sets up a connection to that port.

Each emulator uses a pair of sequential ports — an even-numbered port for console connections
and an odd-numbered port for adb connections.

ADB Commands

The user can perform multiple types of operator once a connection is established to the android
device. Here, the list of commands to communicate with device as following

Command Comments

adb devices Print the connected


devices

Adb kill-server Kill the adb Server

adb root To get root access

adb wait-for-devices Wait for adb devices

adb shell stop thermal-engine Stopping system service


/system/bin/thermal-
engine

Adb install Install an application in


adb

adb shell Initiate a shell


Command Comments

Sadb shell dumpsys Shows memory


consumption details

adb shell echo performance > Put the cpu1 scaling


/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor governor to performance
mode

Adb pull Copy a file or directory


from the device

Adb push Copy a file or directory to


the device

Adb forwarding tcp:6100:7100 Port forwarding

Rooting in Anroid
Android, like any operating system (OS), has an advanced mode—usually called "root"—to
modify protected system files. Rooting can unlock many advanced features, but there are some
big trade-offs as well.
The highest permission level is usually called Administrator, Root, or Superuser. It unlocks
advanced features that require modifying system files. However, enabling it also creates
security risks, and this feature shouldn't be used recklessly.
What to Know Before Rooting an Android Device

Before rooting your Android phone or tablet, you need to understand a few things. This
includes risks—stuff that may or may not happen during the rooting process or after it—and
consequences that are inherent to rooting and, therefore, unavoidable.

1. Rooting Makes Your Android Phone Vulnerable

You shouldn't underestimate the risks of using Administrator privileges, be it on Android or


any computer system. Since rooting makes the system files modifiable, if your device
gets infected by malware, the damage has the potential to be even deeper than before.
Even if you're not infected, messing with the wrong file or configuration may render your
phone unusable. Enthusiasts call this "bricking" a device (as in turning it into a brick, a
paperweight), and it may or may not be a recoverable situation—but I wouldn't recommend
taking any chances.

2. Rooting Will (Likely) Void Your Warranty

Rooting an Android device requires doing a procedure called "bootloader unlocking." Simply
put, you'll disable a security check that prevents your phone from booting a system with
unauthorized modifications.

Save for a few companies, like Google and OnePlus, unlocking the phone's bootloader voids
its warranty, which means you won't be covered even if issues arise that are totally unrelated
to the system.

Most manufacturers will show a warning about the unlocked bootloader when you turn your
device on. Some have a physical fuse blown during the procedure, as explained on this
Samsung support page, so even if you re-lock the bootloader, the warning still shows.

This is not without reason: a phone with an unlocked bootloader can load any system that
runs on it, not just the ones created by the manufacturer. Because of that, the company can't
be liable for damage that these modifications may cause to the device.

3. Rooting May Disable Android Features

This one is usually a consequence of unlocking the bootloader, not of rooting. But since you
can't do the latter without doing the former, the warning still applies.

Using Samsung as an example again, you won't be able to use Knox or its enhanced
protection features, like Secure Folder. The physical fuse mentioned before, when blown,
disables Knox.

Many manufacturers also prevent you from receiving over-the-air (OTA) system updates (or
don't prevent it, but brick your phone if you install the new version) if the bootloader is
unlocked. This limitation may continue even if you re-lock the bootloader.

Rooting also triggers SafetyNet (and its replacement, "Play Integrity"). They're checks
included in Android by Google that ensure the system hasn't been tampered with. If a device
fails these checks, many games and banking apps—including Google Wallet—won't work.
There are ways to "hide" rooting and pass these checks, but they require even more effort on
top of rooting.

4. Rooting Deletes All of Your Phone’s Data

This is another consequence of unlocking the bootloader. When you do it, your phone's
whole internal storage is wiped, so all installed apps and saved files will be deleted.

Some devices, including all Samsung phones, actually delete your data twice. Your storage is
first wiped when unlocking the bootloader, and, in some cases, it gets erased again when
doing the rooting procedure itself.

That's not much of a concern if you make a backup of your Android phone before unlocking
the bootloader—and any experienced enthusiast in the modding community will tell you
to always make a backup before doing any important procedure.

Boot Process

In computing, booting is starting up a computer When switching off the power of the Android
device and switch on it again, this process is known as the Android Booting sequence.
5 stages of Booting process for an Android-powered device:

 1st Stage is Boot ROM and Boot Loader

 2nd Stage is Kernel

 3rd Stage is Init

 4th Stage is Zygote and DVM

 5th Stage is SystemServer and Managers

Boot ROM and Boot Loader

On pressing the POWER button, the Boot ROM code starts executing from a predefined location

which is hardwired in ROM. It loads the Bootloader into RAM. The bootloader is code that is

executed before any Operating System starts to run. The bootloader is a low-level code contains

the instructions that tell a device how to start up and find the system kernel. The bootloader

usually lives on the system board in non-volatile memory and is often specific to a device.

The bootloader is usually split into stages. Primary Boot Loader and Secondary Boot Loader.

The bootloader can be found at:

<android source>/bootable/bootloader/legacy/usbloader

This legacy loader contains 2 important files:

1- Init.s :: Initializes stacks, zeros the BSS segments and call_main() in main.c

2- Main.c:: Initializes hardware (clocks, board, keyboard, console) and creates Linux tags
Primary Boot Loader will load Secondary Boot Loader from a specific sector on the disk, then

Secondary Boot Loader will initialize the system and load the kernel from ‘boot’ flash partition

into RAM.

File System

Android's file system structure exhibits similarities with Linux due to its foundation on the

Linux kernel. Android, being one of the most popular mobile operating systems, offers various

options for storing and managing files.

In Android, the File System is a structured approach to storing, accessing, and managing data
and files on the device. The File System consists of two primary storage options: Internal
Storage and External Storage. Understanding the differences between these two storage types
is crucial for developing efficient and user-friendly Android applications.
1. Internal Storage

Understanding Internal Storage

Internal storage, as the name suggests, refers to the storage space that is private to the app itself.
The data stored in the internal storage is only accessible to the app that created it. This makes
it a secure option for storing sensitive user data that should not be accessible to other apps or
users.

The internal storage of an app is a part of the device’s built-in storage and is always available
to the app, regardless of whether the device has external storage (SD card) or not. However,
it’s essential to note that the internal storage has limited space, and using it excessively might
result in running out of storage, leading to potential crashes or data loss.

Accessing Internal Storage

To access the internal storage in an Android app, we use the Context object. The Context
provides methods to open and create files or directories in the internal storage.

Java
// Get the context of the app
Context context = getApplicationContext();

// Create or access a file in internal storage


String filename = “example.txt”;
File file = new File(context.getFilesDir(), filename);

Internal Storage Best Practices

When working with internal storage, consider the following best practices:

 Use Internal Storage for Sensitive Data: Since internal storage is private to the app, use
it to store sensitive data like user credentials, authentication tokens, etc.
 Manage Storage Space: Be mindful of the limited storage space. Remove unnecessary
files or offer options to the user to clear cache or old data.
 Backup and Restore: If the data is critical, provide backup and restore options to prevent
data loss when the user changes devices or reinstalls the app.

2. External Storage

Understanding External Storage

Unlike internal storage, external storage is accessible by all apps on the device, and the user
can also access it directly through a file manager. External storage usually refers to the SD card
or any other storage media mounted on the device. Since external storage is shared, it’s suitable
for storing files that can be shared between apps or files that the user may want to access
independently.
While external storage offers more space compared to internal storage, not all devices have
external storage, so it’s essential to handle scenarios where external storage might not be
available.

Accessing External Storage

To access the external storage in an Android app, you need to check if it’s available and request
the necessary permissions in the AndroidManifest.xml file.

xml
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Next, you can use the Environment.getExternalStorageDirectory() method to get the path to

the external storage directory:

java
// Get the path to the external storage directory
File externalDir = Environment.getExternalStorageDirectory();

Permissions for External Storage

Starting from Android 10 (API level 29), the approach to accessing external storage changed.
Instead of using WRITE_EXTERNAL_STORAGE permission, apps need to request a more
specific permission called MANAGE_EXTERNAL_STORAGE. This permission allows apps
to read and write from/to specific file paths on external storage.

Additionally, apps need to use the ACTION_OPEN_DOCUMENT_TREE intent to prompt the


user to select a directory for storing their files on external storage.

Choosing between Internal and External Storage

The choice between internal and external storage depends on the type of data your app needs
to store:

Use Internal Storage When:

 Storing sensitive data specific to the app.


 Avoiding the risk of data tampering from other apps or users.
 Ensuring data is available even if the device doesn’t have external storage.
Use External Storage When:

 Sharing data between multiple apps or making it accessible to the user.


 Storing large files that might exceed the internal storage limit.
 Providing an option to access files independently from other apps.
Security
Android is built with multiple layers of security and privacy protections to help keep you, your
devices, and your data safe. Most importantly, we are committed to transparency, so you can
see your device safety status and know how your data is being used.

Android uses the best of Google’s AI and machine learning expertise to proactively protect you
and help keep you out of harm’s way. We also empower you with tools that help you take
control of your privacy.

I/O is a great moment to show how we bring these features and protections all together to help
you stay safe from threats like phishing attacks and password theft, while remaining in charge
of your personal data.

Safe Browsing: faster more intelligent protection

Android uses Safe Browsing to protect billions of users from web-based threats, like deceptive
phishing sites. This happens in the Chrome default browser and also in Android WebView,
when you open web content from apps.

Passkeys helps move users beyond passwords

For many, passwords are the primary protection for their online life. In reality, they are
frustrating to create, remember and are easily hacked. But cybercriminals can’t phish a
password that doesn’t exist. Which is why we are excited to share another major step forward
in our passwordless journey: Passkeys.

Passkeys combine the advanced security of 2-Step Verification with the convenience of simply
unlocking your device — so signing in is as easy as glancing at your phone or scanning your
fingerprint. And because they use cutting-edge cryptography to create a “key” that is unique
between you and a specific app or website, passkeys can’t be stolen by hackers the way that
passwords can.

Better protections for apps

Accessibility services are helpful for people with disabilities but their broad powers can be
used by malware and bad apps to read screen content. In Android 14, we’re introducing a new
API that lets developers limit accessibility services from interacting with their apps. Now, with
a new app attribute, developers can limit access to only apps that have declared and have been
validated by Google Play Protect as accessibility tools. This adds more protection from side-
loaded apps that may get installed and are trying to access sensitive data.

In Android 14, we’re preventing apps that target an SDK level lower than 23 from being
installed. This is because malware often targets older levels to get around newer security and
privacy protections. This won’t affect existing apps on your device, but new installs will have
to meet this requirement.
More transparency around how your data is used

We launched the Data safety section in Google Play last year to help you see how developers
collect, share, and protect user data. Every day, millions of users use the Data Safety section
information to evaluate an app’s safety before installing it.

In Android 14, we’re extending this transparency to permission dialogs, starting with location
data usage. So every time an app asks for permission to use location data, you’ll be able to see
right away if the app shares the location data with third parties.

Better control and protection over your photos and videos

Last year, we announced the Android Photo Picker, a new tool that apps can use to request
access to specific photos and videos instead of requesting permission to a users' entire media
library. We’re updating Photo Picker through Google Play services to support older
devices going back to Android 4.4.

You might also like