Thursday, February 6, 2025
HomeAndroidAndroid Application Penetration Testing Part 3

Android Application Penetration Testing Part 3

Published on

SIEM as a Service

Follow Us on Google News

In my last article( Android Application Penetration Testing Part 1 ), ( Android Application Penetration Testing Part 2 )we had look at basic architecture and penetration testing tools. Now Let’s dig deeper with ADB.

Android Debug Bridge

Android Debug Bridge (ADB) is a versatile command-line tool that lets you communicate with a device

Adb install – It is used to install an apk file into an Emulated/Connected Device

Adb pull – It is used to fetch some data from an Emulated device (remote) to a local host (local).

Adb push – It is used to push some data from localhost (local) to Emulated Device (remote).

Adb forward – Forwards socket connections from a specified local port to a specified remote port on the emulator/device instance.

Adb shell – Adb provides a UNIX shell that you can use to run a variety of commands on an emulator or connected device. In the terminal, you can use all adb commands

  • We can install applications via ADB shell or directly by using the app use dashboard

Some Important notes

  • UID– Every time a new application is initiated in the Android device, it is assigned a unique User ID
  • PID– As every application has its own process id
  • GID– group IDs of the application that owns that process

Dumpsys meminfo – All process details

Android Application Penetration testing Part 3

Dumpsys meminfo name of .apk

Android Application Penetration testing Part 3

Android Package (APK) is the default extension for Android applications, which is just an archive file that contains all the necessary files and folders of the application.

All data of the application in the device can be found in /data/data directory.

All applications (apk files) in the device can be found in /data/app directory

Android Application Penetration testing Part 3

Standard permissions granted to the shell can be found in /system/etc/permissions # cat platform.xml

Android Application Penetration testing Part 3
Android Application Penetration testing Part 3

Hacks via ADB:

We usually open our Android device by unlocking various gesture patterns or password key

Android Application Penetration testing Part 3

If you remove the gesture. Key or password. The key which located in data/system, you can bypass that lock.

Android Application Penetration testing Part 3

Another method

Try with ADB shell

Cd /data/data/com.android.providers.settings/databases

sqlite3 settings.db

Update system set value=0 where name='lock_pattern_autolock';

Update system set value=0 where name='lockscreen.lockedoutpermanently'; .quit

Reset your phone. Don’t worry try a random pattern or pin or Password, you will bypass it.

  Android Application Penetration Testing Part – 4

Also, read

You can follow us on Linkedin, Twitter, and Facebook for daily Cybersecurity updates also you can take the Android Hacking and Penetration Testing Course to keep yourself self-updated.

Gurubaran
Gurubaran
Gurubaran is a co-founder of Cyber Security News and GBHackers On Security. He has 10+ years of experience as a Security Consultant, Editor, and Analyst in cybersecurity, technology, and communications.

Latest articles

Paragon Spyware Allegedly Ends Spyware Contract with Italy

Paragon Solutions, an Israeli cybersecurity firm, has reportedly ended its spyware contract with Italy.The...

Authorities Arrested Hacker Who Compromised 40+ Organizations

Spanish authorities have arrested a hacker believed to be responsible for cyberattacks targeting over...

OpenAI Data Breach – Threat Actor Allegedly Claims 20 Million Logins for Sale

OpenAI may have become the latest high-profile target of a significant data breach.A...

Lumma Stealer Attacking Windows Users In India With Fake Captcha Pages

Cybersecurity experts are raising alarms over a new wave of attacks targeting Windows users...

Supply Chain Attack Prevention

Free Webinar - Supply Chain Attack Prevention

Recent attacks like Polyfill[.]io show how compromised third-party components become backdoors for hackers. PCI DSS 4.0’s Requirement 6.4.3 mandates stricter browser script controls, while Requirement 12.8 focuses on securing third-party providers.

Join Vivekanand Gopalan (VP of Products – Indusface) and Phani Deepak Akella (VP of Marketing – Indusface) as they break down these compliance requirements and share strategies to protect your applications from supply chain attacks.

Discussion points

Meeting PCI DSS 4.0 mandates.
Blocking malicious components and unauthorized JavaScript execution.
PIdentifying attack surfaces from third-party dependencies.
Preventing man-in-the-browser attacks with proactive monitoring.

More like this

BADBOX Botnet Surges: Over 190,000 Android Devices Infected, Including LED TVs

The BADBOX botnet, a sophisticated malware operation targeting Android-based devices, has now infected over...

Malicious Android & iOS Apps Downloaded Over 242,000 Times, Stealing Crypto Recovery Keys

A sophisticated malware campaign, dubbed SparkCat, has infiltrated Google Play and Apple’s App Store,...

Android Security Update Fixes Linux Kernel RCE Flaw Allow Read/Write Access

On February 3, 2025, Google published its February Android Security Bulletin, which addresses a...