0% found this document useful (0 votes)
9 views16 pages

Adb Components: MPT Class

The document outlines the Android Debug Bridge (ADB) components, its functionalities, and essential commands for mobile application testing and debugging. It also describes the standard process for mobile penetration testing, including discovery, analysis, exploitation, and reporting, while emphasizing industry standards like OWASP and CVSS. Additionally, it provides insights into the Android boot process, history, and the significance of the AndroidManifest.xml file in app development.

Uploaded by

charlieoriri
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)
9 views16 pages

Adb Components: MPT Class

The document outlines the Android Debug Bridge (ADB) components, its functionalities, and essential commands for mobile application testing and debugging. It also describes the standard process for mobile penetration testing, including discovery, analysis, exploitation, and reporting, while emphasizing industry standards like OWASP and CVSS. Additionally, it provides insights into the Android boot process, history, and the significance of the AndroidManifest.xml file in app development.

Uploaded by

charlieoriri
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/ 16

● MPT CLASS

https://www.androidauthority.com/history-android-os-name-789433/

https://apilevels.com/

https://developer.android.com/tools/adb

https://devhints.io/adb

adb components
Based on the search results, the Android Debug Bridge (ADB) is a client-server
program comprising three components:

1. Client: Runs on the development machine (computer) and is invoked from the
command prompt using the adb command.
2. Daemon: Runs as a background process on either an emulator instance or the
Android device itself.
3. Server: Also runs on the development machine but in the background, managing
communication between the ADB client and daemon.

ADB provides various device actions, such as:

● Installing and debugging apps


● Running commands on the device using a Unix shell
● Interacting with the package manager (pm) tool to perform actions and queries
on app packages

Some useful ADB commands include:

● adb kill-server: Terminates the ADB server process and restarts it


● adb devices: Lists all connected devices
● adb install <package_name>: Installs an app package
● adb uninstall <package_name>: Uninstalls an app package
● adb pm list packages: Prints the list of packages, with options to filter by -d
(disabled), -e (enabled), or -s (system)

To use ADB, you need:


● A computer that meets the minimum system requirements for running the
Android SDK
● An Android device (optional, but necessary for testing and debugging)
● The ADB executable and other components from Google Platform Tools

https://www.appsealing.com/owasp-mobile-security-testing-guide/

https://www.pcloudy.com/types-of-mobile-apps/#The_architecture_of_Native_apps

https://www.geeksforgeeks.org/penetration-testing-execution-standard-ptes/

Standard process in mobile pentesting


Based on the provided search results, the standard process in mobile pentesting
involves the following stages:

● Discovery: Gathering information about the target mobile application, including its
architecture, components, and potential vulnerabilities.
● Setting up the testing environment: Configuring a virtual environment for the
Android device, including setting up a proxy (e.g., Burp Proxy) and installing a
CA certificate.
● Dynamic Analysis: Analyzing the mobile application’s behavior, network traffic,
and interactions with the device and server-side components using tools like
MobSF.
● Static Analysis: Examining the mobile application’s source code, binary files, and
configuration files for vulnerabilities and security flaws.
● Exploitation: Attempting to exploit identified vulnerabilities to demonstrate the
potential impact of a real-world attack.
● Reporting: Documenting findings, including vulnerability details, impact, and
recommendations for remediation.

Industry Standards and Best Practices

● OWASP Mobile Security Testing Guide: Provides a comprehensive framework for


mobile application security testing.
● Common Vulnerability Scoring System (CVSS): Used to score and prioritize
vulnerabilities.
● GIAC Penetration Tester (GPEN) certification: A recognized standard for
pen-testers, focusing on password hacks, digital programs intrusion, and
extensive pentest prep.
Triaxiom Security’s Mobile Application Penetration Testing Methodology

● Involves a brief meeting with the client to review and acknowledge the
penetration testing rules of engagement, confirm project scope and testing
timeline, identify specific testing objectives, document any testing limitations or
restrictions, and answer any questions related to the project.
● Requires a minimum of 5 years of experience in Information Security for the lead
engineer.
● Based on industry standards, including OWASP Testing Guide.

Key Takeaways

● Mobile pentesting involves a combination of dynamic and static analysis,


exploitation, and reporting.
● Industry standards and best practices, such as OWASP and CVSS, provide a
framework for mobile application security testing.
● A comprehensive pentesting methodology, like Triaxiom Security’s, ensures a
thorough and effective assessment of mobile applications.

https://www.interviewbit.com/blog/android-architecture/

https://www.geeksforgeeks.org/difference-between-dalvik-and-art-in-android/

https://www.geeksforgeeks.org/android-architecture/

https://developer.android.com/guide/platform

Android Activity Lifecycle - javatpoint

https://www.geeksforgeeks.org/activity-lifecycle-in-android-with-demo-app/
https://www.tutorialspoint.com/android/android_acitivities.htm
https://media.licdn.com/dms/image/D4D12AQFhWi2N1gxrUA/article-cover_image-shrink_720_1
280/0/1690178089040?e=2147483647&v=beta&t=s4_P7hUN06WVrUD-RNZS8Eef1Y-COeDFS
H4oIG5ohMg

https://medium.com/@vlad.iftimie88/some-points-on-android-apk-files-231a36cbc91c

https://payatu.com/blog/an-introduction-to-smali/#:~:text=Smali%20is%20a%20type%20of,the%20hb
ytecode%20of%20an%20app.

https://infosecwriteups.com/android-pentesting-101-part-1-8e31b8cd8b2b
Tools

How to push and pull apk through adb :-


adb shell
1. pm list packages
2. pm list packages | grep scroll.apk
3. package path finding
● Pm path package name
● exit
4. adb pull “ Package path ” Newsccroll.apk

● pm install: installs an APK file


● pm uninstall: uninstalls an application
● pm list: lists installed packages or features
● pm path: prints the path to an APK file
● pm dump: prints system state associated with a package
● pm grant/pm revoke: grants or revokes permissions to applications
● pm get-install-location/pm set-install-location: manages install locations

Drozer
apt install Docker.io
Drozer installation link https://hub.docker.com/r/withsecurelabs/drozer

Drozer agent link https://github.com/WithSecureLabs/drozer-agent


Download apk
Install in emulator

Activity exported=True
Adb ke through
am start -n Packagesname /.pmlist

Frida
Pip3 install frida-tools
16.2.1
Then frida sever 16.2.1
Same version
https://github.com/frida/frida/releases

unzip
adb Push frida-server-16.2.1-android-x86_64 /data/local/tmp/
Frida-ps -Uai

adb shell
vbox86p:/ # cd data/local/tmp
vbox86p:/data/local/tmp # ls
frida-server-16.2.1-android-x86_64
vbox86p:/data/local/tmp # chmod +x frida-server-16.2.1-android-x86_64
vbox86p:/data/local/tmp # ./frida-server-16.2.1-android-x86_64

Tools for static analysis


JAVA = apt install default-jdk
Jadx-gui = apt install jadx
Jd- gui = apt install jd-gui
Apktool = apt install apktool
Apktool Fix on github any error occur apk tool

Bytecode-viewer its use the different decomplier

Objection
Pip3 install objection
https://book.hacktricks.xyz/mobile-pentesting/android-app-pentesting/frida-tutorial/objection-tutorial

https://github.com/sensepost/objection/

https://github.com/sensepost/objection/wiki/Patching-Android-Applications
https://www.hackingarticles.in/android-hooking-and-sslpinning-using-objection-framework/

https://hacktricks.boitatech.com.br/mobile-apps-pentesting/android-app-pentesting/frida-tutorial/obje
ction-tutorial

ReVanced
https://github.com/sensepost/objection/wiki/Patching-Android-Applications#next-steps
https://book.hacktricks.xyz/mobile-pentesting/android-app-pentesting/frida-tutorial/objection-tutorial

https://mas.owasp.org/MASTG/tools/android/MASTG-TOOL-0029/

Mobesf

https://github.com/MobSF/Mobile-Security-Framework-MobSF?tab=readme-ov-file
docker pull opensecurity/mobile-security-framework-mobsf:latest
docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Keytool for signature apk signature :-

Create pvt key

Keytool -genkey -v -keystore mysec.keystore -alias mpt -keyalg RSA -keysize 2048 -validity 1000

Sign the apk


apksigner sign - -ks mysec.keystore (apkname)

Git clone insecurebankv2.apk {https://github.com/dineshshetty/Android-InsecureBankv2}


Cd Android-InsecureBankv2
Chmod +x InsecureBankv2.apk
Drag n drop insecurebankv2.apk in phone
Adb install Insecurebank.apk

Turn on Drozer Server in phone

adb connect {phone ip}


sudo docker run --net host -it withsecurelabs/drozer console connect --server {phone ip}
Run app.package.list -f insecurebankv2
run app.package.info -a com.android.insecurebankv2
run app.package.attacksurface com.android.insecurebankv2
run app.activity.info -a com.android.insecurebankv2
run app.activity.start --component com.android.insecurebankv2[## package name]
com.android.insecurebankv2.PostLogin[## activity name , it show the device is rooted]
file:////etc/hosts

adb shell am start -n jakhar.aseem.diva/.APICredsActivity

adb shell am start -n jakhar.aseem.diva/.APICreds2Activity -a


jakhar.aseem.diva.action.View_CREDS2 --ez check_pin false

adb shell content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes/

Android boot process step by step

When switching on an Android device, the boot process begins with the power-on
sequence. Here’s a step-by-step explanation of the Android boot process:
Step 1: Power-On Sequence The power-on sequence starts when you press the power
button on your Android device. This triggers the Boot ROM code to execute from a
pre-defined location in the ROM.

Step 2: Boot ROM Execution The Boot ROM code loads the BootLoader into RAM and
starts executing. The BootLoader is a small program that is responsible for initializing
the hardware components and loading the operating system.
Step 3: BootLoader Execution The BootLoader initializes the hardware components,
such as the CPU, memory, and peripherals. It also loads the kernel and device drivers
into RAM.

Step 4: Zygote Initialization The Zygote is a virtual machine process that starts at
system boot. It preloads and initializes core library classes, which enables code sharing
across the Dalvik VM and achieves a lower memory footprint and minimal startup time.

Step 5: System Server Initialization The System Server is a critical component of the
Android operating system. It initializes the system services, such as the activity
manager, window manager, and package manager.
Step 6: Boot Animation and Lockscreen The boot animation and lockscreen are
displayed, indicating that the device is booting up.

Step 7: System Startup The system startup process continues, and the device becomes
ready for use. The home screen and other system apps are launched, and the device is
ready for user interaction.

In summary, the Android boot process involves the power-on sequence, Boot ROM
execution, BootLoader execution, Zygote initialization, System Server initialization, boot
animation and lockscreen, and system startup.
https://medium.com/android-news/android-boot-process-8f7d94ff9889

https://medium.com/make-android/android-boot-process-introduction-54bf4020141
Android history full explanation
Android is one of the most widely used operating systems in the world, powering
millions of devices globally. Its history dates back to 2003, when Android Inc. was
founded by Andy Rubin, Rich Miner, Nick Sears, and Chris White. Here’s a detailed
explanation of the evolution of Android:

Early Days (2003-2005)


Android Inc. was founded in Palo Alto, California, with the goal of developing an
operating system for digital cameras. In 2004, the company shifted its focus to
developing an operating system for smartphones. Google acquired Android Inc. in 2005,
and the company’s founders became part of Google’s Android team.
First Beta Release (2007)
The first beta version of Android was released in November 2007. This was a significant
milestone, as it marked the beginning of Android’s journey as a mobile operating
system. The beta release was followed by several public betas, which allowed
developers to test and provide feedback on the operating system.
First Commercial Release (2008)
The first commercial version of Android, Android 1.0, was released in September 2008.
This version was based on the Linux kernel and was designed to run on a variety of
devices. The first Android device, the T-Mobile G1, was released in October 2008.
Early Success (2009-2010)
Android 1.5, released in April 2009, introduced several new features, including a virtual
keyboard and improved performance. Android 2.0, released in October 2009,
introduced a new user interface and improved multitasking capabilities. Android 2.2,
released in May 2010, added support for Adobe Flash and improved the operating
system’s performance.
Jelly Bean Era (2012-2013)
The Jelly Bean era in Android history began in June 2012 with the release of Android
4.1. Google quickly released versions 4.2 and 4.3 under the Jelly Bean label in October
2012 and July 2013, respectively. Some of the new additions in these software updates
included new notification features, full support for the Android version of Google’s
Chrome web browser, and improved performance.
KitKat and Lollipop (2013-2015)
Android 4.4, released in October 2013, introduced a new design language and
improved performance. Android 5.0, released in November 2014, introduced a new
material design and improved security features. Android 6.0, released in September
2015, introduced a new permission system and improved performance.
Marshmallow and Nougat (2015-2016)
Android 6.0, released in September 2015, introduced a new permission system and
improved performance. Android 7.0, released in August 2016, introduced a new design
language and improved performance.
Oreo and Pie (2017-2018)
Android 8.0, released in August 2017, introduced a new design language and improved
performance. Android 9.0, released in August 2018, introduced a new design language
and improved performance.
Android 10 and Beyond (2019-Present)
Android 10, released in September 2019, introduced a new design language and
improved performance. Android 11, released in September 2020, introduced a new
design language and improved performance. Android 12, released in October 2021,
introduced a new design language and improved performance.
Conclusion
Android has come a long way since its inception in 2003. From its early days as a beta
release to its current status as one of the most widely used operating systems in the
world, Android has evolved significantly over the years. Its commitment to innovation,
security, and user experience has made it a popular choice among consumers and
developers alike.

https://apilevels.com/

The AndroidManifest.xml file is a crucial file in an Android application that contains


essential information about the app. It is an XML file that provides metadata about the
app, such as its name, version, permissions, and components like activities, services,
and broadcast receivers. Here are some of the key elements that the
AndroidManifest.xml file can contain:

● Manifest: The root element of the AndroidManifest.xml file, which contains all the
other elements.
● package: The package attribute specifies the name of the package, which is a
unique identifier for the app.
● application: The application element specifies the name, version, and other
attributes of the app.
● activity: The activity element declares an activity, which is a single screen or
screenlet in the app.
● service: The service element declares a service, which is a component that runs
in the background to perform a specific task.
● receiver: The receiver element declares a broadcast receiver, which is a
component that receives and responds to system-wide broadcast intents.
● permission: The permission element declares a permission that the app requires
to function properly.
● intent-filter: The intent-filter element specifies the types of intents that the app
can handle.
● meta-data: The meta-data element provides additional metadata about the app,
such as its icon, label, and version.
● uses-permission: The uses-permission element specifies the permissions that
the app requires to function properly.

Difference between dex or odex

The main difference between Dex and Odex is how the Android application package
(APK) is stored and processed.
Dex (Dalvik Executable) is a compiled bytecode version of an app that has been built for
the Dalvik VM, which is the virtual machine that Android’s apps run on. The
“classes.dex” file is a part of the APK and contains the compiled code of the app.

Odex (Optimized Dex) is an optimized version of the Dex file. When an APK is installed,
the “classes.dex” file is automatically converted to an “oat” (Object File Archive) file,
which is then compiled into a “classes.odex” file. This process is called “odexing”. The
“classes.odex” file is stored separately from the APK and is used by the Dalvik VM to
run the app.
In summary, Dex is the original compiled bytecode of the app, while Odex is an
optimized version of that bytecode.
ADB Forwarding Explained
ADB forwarding allows you to redirect network connections between your computer and an
Android device or emulator. This enables communication between your development machine
and the mobile device, facilitating debugging, testing, and development.
Local Forwarding
Local forwarding, denoted by adb forward <local_port> <remote_device_port>, redirects
incoming connections from your computer’s <local_port> to the Android device’s
<remote_device_port>. This allows your computer to initiate connections to the device, which is
useful for:
● Debugging: Your computer can send requests to the device, and the device can
respond, enabling you to inspect and debug your application.
● Testing: You can test your application’s network communication by sending requests
from your computer and verifying the responses on the device.
Reverse Forwarding
Reverse forwarding, denoted by adb reverse <remote_device_port> <local_port>, redirects
outgoing connections from the Android device to your computer’s <local_port>. This allows the
device to initiate connections to your computer, which is useful for:
● Server-based applications: Your Android application can connect to a server running on
your computer, and you can inspect and debug the communication.
● Device-initiated connections: The device can initiate connections to your computer for
tasks like file transfer or data synchronization.
Key Considerations
● Only one side (either the device or your computer) needs to run a ServerSocket.
● Make sure the ports you specify are available and not in use by other applications.
● ADB forwarding is useful for debugging and testing, but it may not be suitable for
production environments due to security concerns.
By understanding and utilizing ADB forwarding, you can streamline your mobile development
workflow, improve debugging efficiency, and enhance your overall development experience.
Activity: An Activity represents a single screen with a user interface. It’s like a window into your
app. When the user interacts with an Activity, it performs actions on the screen. For example, an
email app might have one Activity to show a list of new emails, another to compose an email,
and another to read emails.
Service: A Service is a component that runs in the background, performing tasks without
blocking the user’s interaction with other Activities. It’s like a worker bee that does tasks while
the user is doing something else. For example, a music app might have a Service that plays
music in the background while the user is browsing other apps.
Intent: An Intent is a message that describes an action to be performed. It’s like a request to do
something. Intents can be used to start Activities, Services, or Broadcast Receivers. For
example, an Intent might say “Start the email composer Activity” or “Play music in the
background.”
Content: Content refers to data stored in your app, such as text, images, or contacts. Content
Providers manage access to this data, allowing other apps to use it. For example, a contacts
app might provide a Content Provider to share contact information with other apps.
Developer: A Developer is the person or team creating an Android app. They write code to
define the app’s components, such as Activities, Services, and Broadcast Receivers.
Broadcaster: A Broadcaster is a component that sends Intents to multiple receivers, announcing
an event or action. For example, when the user connects to Wi-Fi, the system broadcasts an
Intent to notify apps that can use this connectivity.
Receiver: A Receiver is a component that listens for and responds to Intents broadcast by the
system or other apps. For example, an app might register a Receiver to listen for the Wi-Fi
connectivity Intent and update its UI accordingly.
Full Examples:
​ Activity: Imagine an email app with three Activities:
○ EmailListActivity shows a list of new emails
○ ComposeEmailActivity allows the user to write a new email
○ ReadEmailActivity displays a single email for reading
Each Activity performs actions on the screen, and the user navigates between them using the
app’s UI.
​ Service: Suppose a music app has a Service called MusicPlayerService that plays music
in the background. When the user starts the Service, it begins playing music and
continues running even when the user switches to another app.
​ Intent: The music app might use an Intent to start the MusicPlayerService, saying “Play
music in the background.” The Intent would contain information like the music file to play
and the volume level.
​ Content: A contacts app might provide a Content Provider called ContactsProvider that
allows other apps to access contact information. When another app requests contact
data, the ContactsProvider returns the relevant information.
​ Broadcaster: When the user connects to Wi-Fi, the system broadcasts an Intent saying
“Wi-Fi connectivity changed.” Apps that registered Receivers to listen for this Intent can
update their UI accordingly.
​ Receiver: An app might register a Receiver called WifiReceiver to listen for the Wi-Fi
connectivity Intent. When the Intent is broadcast, the WifiReceiver updates the app’s UI
to reflect the new connectivity status.
These examples illustrate how Activities, Services, Intents, Content, Developers, Broadcasters,
and Receivers work together in an Android app.

You might also like