Android Application Pentest Checklist

Obtain the APK either directly from the client, by downloading it from the Play Store with a tool that extracts the installed package, or by pulling it from a provisioned test device. Confirm you have the exact build intended for the assessment, including version code, before proceeding so that findings map to a specific release.

Use the package manager to locate the installed app's path on device and copy the base APK and any split APKs to your workstation. This is useful when the app is only distributed through a private channel or dynamically delivered via Play Feature Delivery.

Compute a SHA-256 hash of every APK file collected and store it alongside the assessment notes. This gives you a durable reference for exactly which binary a finding applies to, which matters when the client ships multiple builds during the engagement.

Run the APK through a Dex-to-Java decompiler to get readable, searchable pseudo-source for the app's classes. This is normally the fastest way to understand business logic, find hardcoded values, and trace how data flows between components.

Unpack the APK with apktool to recover an editable resource tree and smali bytecode, which is needed when jadx fails to produce clean Java for certain classes or when you plan to patch and repack the app for later testing. Keep the unpacked project under version control so patches are reproducible.

Unzip the APK and walk through classes.dex, resources.arsc, the assets and lib directories, and META-INF to understand what the package actually ships, separate from what the decompiler renders. Native libraries, bundled config files, and embedded certificates are often easiest to spot at this raw file level.

Convert the binary XML manifest packaged inside the APK into readable XML so you can review declared components, permissions, and application-level flags in one place. Treat this file as the starting point for most of the static analysis stage.

Check the lib directory for bundled .so files and note which CPU architectures are supported, since native code often hides logic that decompiled Java or Kotlin will not show. This also determines which architecture your test device or emulator needs to run the app correctly for dynamic testing.

Note the minSdkVersion and targetSdkVersion values from the manifest or build metadata, since they determine which platform security defaults and mitigations actually apply to the running app. An app targeting an old API level may silently lose protections that are on by default for newer targets.

Set up a rooted physical device or a rooted emulator image so you have the filesystem and process access dynamic analysis requires. Keep a clean snapshot so you can reset state between test cases without reinstalling everything.

Push a frida-server binary that matches both your installed Frida client version and the device's CPU architecture, then run it with sufficient privileges. Version mismatches between client and server are the most common cause of instrumentation failing silently.

Point the device's Wi-Fi proxy settings at your workstation running Burp Suite or mitmproxy, then install the proxy's CA certificate on the device so HTTPS traffic can be decrypted for inspection. This groundwork is a prerequisite for most of the network communication testing later in the assessment.

Read through the entire AndroidManifest.xml line by line, cataloguing every declared component, permission, and application attribute rather than jumping straight to a tool's summary output. Many high-impact issues, such as an unintentionally exported component or a stray debug flag, are only obvious when the manifest is read in full context.

Search the manifest's application element for android:debuggable set to true in a release build, which allows any user to attach a debugger to the running process and inspect or alter it. Confirm this is not a leftover from a CI build configuration that was accidentally shipped to production.

Look at whether android:allowBackup is left at its default enabled state, which permits the app's private data directory to be extracted through the standard backup mechanism on many devices. Where backup is required for legitimate reasons, confirm sensitive files are excluded via a backup rules configuration instead of relying on the flag alone.

Locate any backup rules or data extraction rules XML referenced from the manifest and check exactly which paths are included or excluded from cloud and device-to-device backup. A rules file that includes shared preferences or database directories by default can leak sensitive data even when the developer believed backup was locked down.

Build a table of every activity, service, broadcast receiver, and content provider that is exported, either explicitly or by implication because it declares an intent filter without an explicit exported flag on newer targets. This inventory becomes the working list for the deeper IPC-focused testing done later in the assessment.

Compare the permission list in the manifest against what the decompiled code actually uses, flagging any dangerous or sensitive permission that appears unused or disproportionate to the app's stated purpose. Over-broad permission requests widen the impact of any other bug found in the app and raise privacy concerns even absent a technical vulnerability.

For any custom permission the app defines, verify its protectionLevel is set to signature rather than normal or dangerous when it is meant to restrict access to the app's own components. A custom permission left at the default level can be requested and held by any other app on the device, defeating its purpose.

Determine which platform security defaults, such as export flag defaults, cleartext traffic blocking, or scoped storage, are active given the app's declared min and target SDK versions. An app that targets an old API level deliberately or accidentally forgoes protections that would otherwise apply automatically.

Inspect whether android:usesCleartextTraffic is set to true, or whether a network security config overrides the platform default to permit plaintext HTTP for some or all domains. Flag this even before dynamic testing confirms actual traffic, since the manifest setting alone indicates intent to allow unencrypted communication.

Find the XML file referenced by android:networkSecurityConfig in the manifest and confirm it exists and is well-formed. Its detailed contents, such as pinned certificates and per-domain cleartext exceptions, are examined thoroughly in the network communication stage.

Grep through decompiled source, string resources, and configuration files for API keys, private keys, hardcoded credentials, and internal URLs. Manual review catches secrets that pattern-matching tools miss because of unusual variable names or string concatenation used to obscure a value.

Use a dedicated secret-scanning tool against the decompiled source and resource files to catch common key formats, such as cloud provider access keys or JWT signing secrets, that manual review might overlook. Automated scans are fast but should be treated as a supplement to, not a replacement for, manual review.

Determine whether the release build was processed with a code shrinker and obfuscator, and if so, how thoroughly class, method, and field names were renamed. Weak or absent obfuscation makes reverse engineering meaningfully faster and can also hint at whether the developer applied other release hardening consistently.

Check res/values and other resource files for embedded URLs, feature flags, comments left by developers, or default credentials that were placed in resources rather than code. Resource files are sometimes overlooked during a secrets sweep because reviewers focus on Java or Kotlin source.

Check each activity's taskAffinity and launchMode values for settings that place the activity into a shared or attacker-predictable task stack. Combinations that deviate from the default without a clear reason are worth flagging for deeper task-hijacking testing in the IPC stage.

Verify that screens performing sensitive actions, such as confirming a payment or granting a permission, set filterTouchesWhenObscured or an equivalent overlay-aware check. Without it, a malicious overlay app can intercept or redirect taps intended for the legitimate UI underneath.

Inspect the APK's signing block to see whether it relies solely on the older JAR signing scheme or also uses the newer whole-file signature schemes, which close gaps that allowed certain APK tampering techniques against v1-only signed packages. Relying only on the oldest scheme is a sign the build pipeline has not been revisited in some time.

Check the signing certificate's subject and validity period to make sure a release build was not accidentally signed with the auto-generated debug keystore. A debug-signed release usually indicates a broken or misconfigured build pipeline and may also mean the signing key is shared across many developer machines.

Search decompiled code for logging calls that print tokens, PII, request or response bodies, or stack traces containing sensitive values. Even when a log statement looks like it is only for debugging, it usually ships to production because logging code is rarely stripped automatically.

Disassemble bundled .so files to check for security-relevant logic implemented natively, such as license checks, crypto routines, or hardcoded keys, since these will not appear in the Java or Kotlin decompilation at all. Native code is harder to read but often holds exactly the checks an attacker most wants to bypass.

List every advertising, analytics, crash-reporting, and payment SDK bundled in the app, and note what data each one is configured to collect or transmit. Third-party code runs with the same permissions as the host app, so a poorly configured SDK can leak data the developer never intended to share.

Review whether activities handling http or https intent filters declare android:autoVerify and whether the corresponding assetlinks.json is actually reachable on the claimed domain. A domain that is not properly verified allows the same link to be captured by another app that also declares a matching intent filter.

Install the target APK on the prepared test device and watch logcat output during first launch, login, and a few core workflows. Initial monitoring often surfaces stack traces, third-party SDK initialization details, or debug output that hints at where to focus deeper testing.

Attach Objection to the running process to inspect loaded classes, active activities, and stored data without writing a custom Frida script for every basic check. Objection wraps common Frida operations into a shell-like interface that speeds up initial reconnaissance of the runtime.

Use a Frida script or Objection's built-in bypass to hook the app's certificate validation logic, forcing it to accept the proxy's certificate so HTTPS traffic can be inspected. Confirm the bypass actually works by checking that decrypted requests appear in the proxy rather than assuming success from a lack of errors.

Identify and hook the methods the app uses to detect root, such as checks for su binaries, Magisk artifacts, or suspicious build properties, and force them to return a non-rooted result. Testing on a rooted device without bypassing detection first will hide functionality that only appears once the app believes it is running on an unmodified device.

Where the app attempts to detect the presence of Frida, such as by scanning for named pipes, suspicious loaded libraries, or unusual ports, apply known evasion techniques or a custom script to hide the instrumentation. This is often required before other hooks in the app will work at all.

Hook calls into the platform's cipher, key generation, and MAC classes to log the algorithm, key material, and plaintext or ciphertext passed at runtime. This is often the fastest way to confirm whether crypto findings identified statically are actually reachable and to recover the real key values used in practice.

Use frida-trace to generate stub hooks for a class or method pattern and watch the sequence and arguments of calls as you exercise the app. This is especially useful for quickly mapping how a specific feature, such as login or payment, moves data through the app's internal classes.

Connect Drozer to the installed app and run its enumeration modules to list exported activities, services, receivers, and providers along with their permission requirements. Drozer's output gives a practical, tool-verified cross-check against the manifest-based inventory built during static analysis.

Use Drozer's app.activity.start module to launch each exported activity directly with attacker-controlled extras, bypassing whatever navigation flow the app normally enforces. This confirms whether sensitive screens can be reached or manipulated without going through required authentication or state checks.

Use Drozer's provider modules to enumerate accessible URIs and issue read, insert, update, and delete operations against exported content providers. Confirm the provider correctly denies operations it should not allow to an arbitrary calling app rather than assuming the manifest's exported flag alone tells the full story.

Capture a memory dump of the running app process during a sensitive operation, such as login or payment, and search it for plaintext credentials, tokens, or encryption keys. Data that only ever appears encrypted at rest and in transit can still leak if it sits unprotected in memory longer than necessary.

Hook specific methods, such as license checks, feature entitlement flags, or validation routines, and force them to return attacker-chosen values to test how the app behaves when those checks are subverted. This technique frequently reveals broken client-side trust assumptions that a server should have enforced instead.

Enable WebView debugging on the test build and connect Chrome DevTools over USB to inspect the DOM, console output, and network activity of any in-app WebView. This gives visibility into hybrid app content that would otherwise be opaque to standard mobile testing tools.

Send intents with missing, malformed, or unexpectedly typed extras to exported activities, services, and receivers to look for crashes, unhandled exceptions, or logic bypasses. A component that assumes its extras will always be well-formed is a common source of denial-of-service or unexpected-state bugs.

Monitor the system clipboard while interacting with fields that display one-time codes, passwords, or payment details to see whether the app allows this data to be copied. On platform versions without clipboard access restrictions, any other installed app may be able to read what was copied.

Navigate to screens showing sensitive data, background the app, and check whether the recent-apps switcher shows a thumbnail of that content, then attempt a screenshot directly. Sensitive screens should set the secure window flag so the system refuses to capture their contents.

Type into fields carrying sensitive data and confirm the field is marked appropriately so the input method editor does not learn and later suggest that value, and that autofill frameworks do not offer to save it inappropriately. Sensitive input fields should opt out of personalized learning and autofill where the data should never persist.

With pinning bypassed and the proxy configured, exercise every feature of the app while capturing traffic, then review the full request and response history for sensitive data exposure, weak authentication, and interesting parameters. This traffic capture feeds directly into the network communication testing stage.

Where the app checks build properties, sensor availability, or other emulator fingerprints to refuse running, patch or hook those checks so testing can proceed on an emulator, which is often faster to snapshot and reset than a physical device. Confirm any bypassed behavior does not itself mask a bug that would only appear in that code path.

Hook the callback methods invoked after a successful or failed biometric prompt to see whether the app trusts a locally reported success without any additional server-side or cryptographic verification. An app that only checks a boolean callback result can be tricked into believing authentication succeeded when it did not.

Capture logcat output across an entire realistic user session, from install through logout, and review it afterward for anything that leaked during normal operation rather than only during a single targeted action. Issues found this way often would not surface from a narrow, feature-by-feature test pass.

Where the app implements several runtime self-protection checks together, such as root, Frida, and debugger detection combined with integrity verification, use or build a combined bypass script that defeats them together rather than one at a time. This mirrors how a motivated real-world attacker would approach a hardened app and reveals whether the layers are actually independent or share a single weak point.

Pull the app's shared preferences XML files from the data directory and search them for tokens, passwords, or personal data stored without encryption. SharedPreferences is a convenient key-value store but provides no confidentiality of its own beyond normal file permissions.

For preference values that genuinely need confidentiality at rest, confirm the app uses an encrypted preferences wrapper backed by the Android Keystore rather than a custom or absent encryption scheme. Simply Base64-encoding a value before storing it does not provide meaningful protection.

Pull the app's database files and open them with a SQLite browser to check whether tables store credentials, personal data, or session tokens in plaintext columns. Databases are one of the most common places sensitive application state ends up persisted without anyone deliberately deciding it should be.

Determine whether the app uses a database encryption layer such as SQLCipher for databases holding sensitive data, or whether the raw SQLite file can simply be opened by any standard database browser. Encryption at the database layer is especially important for offline-first apps that cache large amounts of user data locally.

Review file-writing code for legacy world-readable or world-writable mode flags, and confirm on-device file permissions on the app's private directory are restricted to the app's own user ID. A file inadvertently created with permissive access can be read by any other app on devices where those older mode flags are still honored.

Search external storage and shared media directories for files the app wrote containing sensitive data, such as exported reports, cached attachments, or debug dumps. Files placed outside the app's private sandbox generally lose Android's per-app isolation guarantees.

Look for the legacy external storage manifest flag that opts an app out of scoped storage protections introduced on newer platform versions. Apps that request broad legacy access to external storage widen their own exposure and that of other apps sharing the same storage volume.

With allowBackup enabled and debugging accessible, use the backup mechanism to pull a full copy of the app's private data directory to a workstation without root. Treat a successful extraction as proof of concept for exactly what an attacker with brief physical device access could obtain.

Determine whether the app's data is eligible for the platform's automatic cloud backup service and, if so, whether sensitive files are properly excluded through backup rules. Data backed up to a personal cloud account persists outside the device and outside the app's own security controls entirely.

Check whether cryptographic keys used to protect sensitive local data are generated inside and used only via the Android Keystore, rather than being generated in software and merely stored somewhere on disk. Keys that never leave hardware-backed or OS-backed storage are far harder to extract than keys the app itself can read as raw bytes.

Where the device supports it, confirm the app requests hardware-backed key storage, such as a StrongBox module or trusted execution environment, for its most sensitive keys. Hardware-backed keys remain protected even against an attacker who has fully compromised the operating system, unlike keys that only rely on software-level protection.

For apps using Realm as a local database, confirm the database is opened with an encryption key rather than left in its unencrypted default mode when it stores sensitive records. An unencrypted Realm file can be copied off the device and browsed offline just as easily as an unencrypted SQLite file.

Check the app's private storage for any log files it writes itself, separate from the system logcat, and review them for tokens, request payloads, or crash data containing personal information. Self-managed log files are easy to forget about during a security review because they are not part of the standard Android logging path.

Inspect the app's cache directory and any temporary files created during operations like document export or image processing to confirm they are deleted promptly and do not persist sensitive content longer than necessary. Cache directories are sometimes assumed to be safe simply because the OS may clear them under storage pressure, which is not a security guarantee.

If the app registers an account authenticator, check how it stores the associated auth token and password, since AccountManager data is shared platform infrastructure rather than data fully isolated to a single app. Confirm sensitive values are not stored as unencrypted account user data.

Confirm password and other sensitive input fields are marked so the input method editor's personalized dictionary does not learn from them and so autofill services are not offered inappropriate save prompts for that data. Failing to mark these fields can leave sensitive text fragments cached by system components outside the app's own storage.

On a non-rooted device, verify that another unprivileged app or the shell user cannot read the target app's private data directory contents, confirming the sandbox boundary holds as expected. This acts as a baseline sanity check before drawing conclusions from any rooted-device findings.

Where the app requests broad external storage access via a legacy compatibility flag or an all-files access permission, confirm this access is actually necessary for its functionality and is not simply a convenient way to avoid adopting scoped storage. Unnecessary broad storage access increases the blast radius of any other vulnerability that lets an attacker act as the app.

With the proxy configured, exercise the app and check whether any request is sent over plain HTTP rather than HTTPS, including background requests from third-party SDKs. Manifest-level flags only indicate intent; observing real traffic confirms what the app does in practice.

Read through every domain-config entry in the network security config file, checking for cleartext exceptions, custom trust anchors, and pin sets scoped to specific domains. Pay particular attention to a debug-overrides block that might unintentionally trust a user-installed CA in a release build.

Check both the network security config and the app's networking code for any form of certificate or public key pinning. Its absence is not automatically a finding on its own, but it does mean the app relies entirely on the device's trusted certificate store for transport security.

Where pinning exists, check whether it pins to a leaf certificate, an intermediate, or a public key, whether backup pins are configured for key rotation, and whether the pin set actually matches the server currently in production. A pinning implementation with no backup pin risks bricking connectivity on the next certificate rotation, which often leads teams to remove it entirely.

Test the app's connection behavior against a server configured to offer only older TLS versions to see whether the app's networking stack or custom SSL context permits a downgrade. An app that explicitly configures an outdated minimum protocol version is deliberately weakening the platform's own defaults.

Review any custom SSL context or OkHttp connection spec configuration for cipher suites that use weak key exchange, no forward secrecy, or deprecated symmetric algorithms. A custom configuration that is more permissive than the platform default usually exists for compatibility with an outdated backend rather than for a good security reason.

Search for any custom HostnameVerifier that overrides the default check and confirm it does not simply return true unconditionally. A hostname verifier that accepts every hostname defeats the purpose of certificate validation even when the certificate chain itself is checked correctly.

Search decompiled networking code for a custom TrustManager whose certificate validation methods are empty or unconditionally succeed, a pattern sometimes left in from development-time convenience. This single class effectively disables all certificate validation for any connection that uses it.

With whatever bypasses are necessary in place, run a complete interception session across the app's core flows to build a comprehensive picture of backend endpoints, headers, and payload structures. This traffic dataset underpins most of the remaining network and API testing in this stage.

Combine endpoints observed in captured traffic with URL patterns and path fragments found in decompiled strings to build a complete map of the backend API surface the app talks to. Endpoints referenced in code but never triggered during normal use are worth testing directly since they receive less real-world scrutiny.

Review captured requests for tokens, session identifiers, or personal data placed in the URL rather than in the request body or headers. URLs are far more likely than bodies to be logged by proxies, web servers, browser history, and analytics tools along the way.

Catalogue every third-party domain seen in captured traffic, such as analytics, advertising, or crash-reporting endpoints, and check what data is sent to each. Data shared with third parties falls outside the primary backend's own security and privacy controls entirely.

Trace how access tokens and refresh tokens are issued, transmitted, and refreshed, checking that tokens are sent only over encrypted channels, scoped appropriately, and not embedded in places like redirect URLs where they could leak to a referrer or log. Also confirm expired or revoked tokens are actually rejected by the backend rather than only by client-side logic.

Where the app actively detects a configured proxy or active VPN and refuses to function, hook or patch the detection logic so testing traffic can still be captured. Document this control separately, since blocking known interception setups is itself a legitimate, if limited, defensive measure worth noting in the report.

Modify request parameters and intercepted response bodies to see whether the app enforces any integrity checks, such as signatures or checksums, on data received from the backend, or whether it blindly trusts and acts on whatever is returned. An app that trusts backend responses without validation can be manipulated by anyone able to intercept traffic, even without breaking transport encryption directly.

Using the endpoint map built from app traffic, test the underlying API directly for broken object-level or function-level authorization, such as accessing another user's records by changing an identifier. Mobile apps frequently expose more of the true API surface than the corresponding web client, since mobile UIs are less likely to hide unused endpoints.

Find every class registered with addJavascriptInterface and review which native methods it exposes to loaded web content. Any exposed method becomes callable by JavaScript running in the WebView, so the review should assume that JavaScript could originate from an untrusted source even if the developer only intended trusted content to load there.

Confirm that setJavaScriptEnabled is only turned on for WebViews that genuinely need to run script, rather than being enabled by default across the app. Every WebView with script execution enabled is meaningfully more exposed to injected or malicious content than one that only renders static markup.

Check the settings for file access and file access from file URLs to ensure the WebView cannot be tricked into reading arbitrary local files when it is not required to for legitimate functionality. These settings are frequently left at insecure defaults inherited from example code found online.

Specifically check whether universal access from file URLs is enabled, since this setting allows content loaded from a file URL to make cross-origin requests to any origin, including the app's own remote backend content. This is a stronger version of the general file access risk and should be treated with correspondingly higher severity.

Check the mixed content mode configured on the WebView to confirm it does not permit a page loaded over HTTPS to load subresources over plain HTTP. Allowing mixed content undermines the confidentiality guarantee of the outer page even when the main document itself was delivered securely.

Check how the app decides what URL to load into a WebView, particularly when the URL originates from a deep link, intent extra, or other externally controlled input. A WebView that loads whatever URL it is handed without validating scheme or origin can be redirected to load attacker-hosted content inside the app's own WebView context.

Check what the WebView's local cache and cookie store retain after a session ends, particularly for authentication cookies or cached pages containing sensitive data. Confirm the app clears this state appropriately on logout rather than leaving it available to the next person who picks up the device.

Search for an onReceivedSslError override that calls proceed unconditionally rather than surfacing the error or canceling the load. This pattern silently disables certificate validation for anything loaded in that WebView, similar in effect to a trust-all TrustManager in native networking code.

Check whether the WebView can be directed to load content provider URIs or local file paths supplied by an external caller, which could expose app-internal files or provider data through the rendering engine. Restrict which schemes a WebView will load based on the actual functionality required.

Confirm setWebContentsDebuggingEnabled is not left true in a release build, since it allows any locally connected debugger to inspect and interact with the WebView's content and execution context. This mirrors the risk of the general debuggable flag but applies specifically to web content rendered inside the app.

Where a WebView loads advertising, embedded widgets, or other third-party content, confirm the app's JavaScript interfaces and file access settings are not exposed to that context. Content the app does not fully control should be treated as untrusted regardless of how reputable the third party is assumed to be.

Check whether cookies set programmatically through CookieManager carry secure and appropriate same-site attributes, particularly for session cookies shared between native networking and WebView content. Cookies without the secure attribute can be sent over an unintended plaintext connection if any part of the flow ever falls back to HTTP.

For each exported activity, check whether it enforces a permission or otherwise validates the calling package before performing a sensitive action, and confirm it behaves safely when launched directly outside the app's intended navigation flow. An activity exported purely because it handles a deep link still needs to defend itself against being launched with unexpected extras.

For each exported service, check whether it validates the calling app before executing privileged operations and whether it enforces a signature-level permission where appropriate. A service exported without any check can be started or bound to by any other installed app, potentially triggering background functionality never meant to be publicly reachable.

For each exported broadcast receiver, determine whether it performs a sensitive action on receipt and whether it validates the broadcast's origin or requires a permission to send it. A receiver that reacts to an unauthenticated broadcast from any app can be triggered at will by malware installed alongside the target app.

For each exported content provider, test whether read and write permissions actually restrict access as the manifest declares, and check every exposed URI path rather than only the ones the app itself uses internally. Providers frequently expose more URI paths than the app's own UI ever queries, since the same provider class is reused across multiple features.

Check whether an exported component takes a nested Intent object from its own incoming extras and forwards or executes it without validation, allowing a malicious caller to smuggle a second, attacker-crafted intent through the vulnerable component's elevated trust or permissions. This pattern often lets an app with fewer permissions indirectly trigger actions that require permissions it does not itself hold.

Review how the app constructs PendingIntent objects, checking whether the wrapped intent is implicit or mutable in a way that lets another app fill in or alter its target component and extras before it is fired. A hijacked PendingIntent executes with the identity and permissions of whichever app originally created it, not the app that ultimately triggers it.

Check whether a custom URL scheme or web-based App Link declared by the app can also be registered by another installed app, and whether the target activity trusts parameters from the link without validating them. Where App Links are used, confirm domain verification is actually functioning rather than falling back to the less trustworthy custom-scheme-style resolution.

Register a listener for broadcasts the app sends without restricting the receiving package or requiring a permission, and check whether any of them carry sensitive data. Implicit broadcasts sent without protection can be observed by any other app on the device that registers a matching receiver.

Look for any use of sticky broadcasts, which remain available to be read by any component that registers for them later, even after the original send event, and confirm they do not carry sensitive state. Sticky broadcasts have been deprecated on the platform for good reason, and any lingering use is worth flagging even independent of a specific data leak.

Send crafted values through the selection, projection, and sort-order parameters of query calls against an exported content provider backed by a SQL database, looking for improperly parameterized query construction. A provider that concatenates caller-supplied strings directly into a SQL statement is vulnerable regardless of how well the rest of the app validates input.

Where a content provider serves files based on a caller-supplied path or identifier, try directory traversal sequences in that input to see whether the provider can be tricked into returning a file outside its intended directory. A provider meant to expose only a specific app folder can inadvertently expose the entire private data directory if it does not canonicalize and validate the resolved path.

Craft a malicious app that declares an activity with a matching taskAffinity and an appropriate launch mode, then install it alongside the target to see whether it can insert itself into the target's task stack or intercept the target's expected launch. A user who believes they are looking at the legitimate app's screen may actually be interacting with the attacker's activity layered into the same task.

Copy sensitive data within the app, then switch to another test app and check whether the clipboard content is readable from there. This complements the earlier dynamic clipboard check by specifically confirming cross-app readability rather than just whether the data was copied at all.

Attempt to invoke a component protected by a signature-level custom permission from a test app signed with a different key, confirming the platform actually denies the call. Also check for any conditional logic in the app itself that might bypass the platform's permission enforcement under certain states.

For services exposing an AIDL interface, check whether privileged methods verify the calling UID or package identity inside the method implementation itself, rather than assuming the manifest's permission declaration is the only gate. Binder calls carry the caller's identity, and a service that ignores it cannot distinguish a legitimate client from any other app that has bound to it.

Review calls that send broadcasts carrying sensitive data and confirm they specify a permission restricting which apps may receive them, rather than relying solely on the receiving component not being exported. An unrestricted broadcast is visible to any listening app regardless of what the receiving side's own export settings say.

Check calls that grant temporary read or write URI permissions to another app, such as when sharing a file, and confirm the grant is scoped to the minimum necessary URI and duration rather than a broad wildcard path. An overly broad grant can let the receiving app access far more provider data than the specific file the user intended to share.

Identify every technique the app uses to detect root, such as checking for su binaries, testing writability of system partitions, or looking for known root-management app packages, and assess how many independent techniques are combined. A root detection scheme relying on a single check is trivial to defeat by patching or hooking that one method.

Identify how the app attempts to detect that it is running on an emulator, such as checking build fingerprint values, sensor presence, or telephony properties, and note whether these checks are performed client-side only. Emulator detection primarily raises the cost of automated bulk analysis rather than stopping a targeted manual assessment.

Identify the specific artifacts the app checks for to detect instrumentation frameworks, such as named pipes, loaded library names, or open ports, and assess whether these checks run once at startup or continuously throughout the session. Detection that only runs once at launch can often be defeated simply by attaching Frida after that check has already passed.

Check for calls that detect an attached debugger, such as querying the debugger-connected flag or checking for tracing via a system call, and note whether the app takes a meaningful action, like terminating, when a debugger is found. Anti-debugging checks that only log the condition rather than responding to it provide effectively no protection.

Check whether the app verifies its own signing certificate or a checksum of its code at runtime, in addition to relying solely on the platform's installation-time signature verification. A runtime self-check can catch a resigned, repackaged copy of the app that a user installed from an untrusted source, which platform-level checks alone would not flag once installed.

For every self-protection check in the app, trace what actually happens when the check fails, distinguishing between a meaningful response, such as refusing to proceed or wiping sensitive local state, and a weak response, such as merely logging a warning or showing a dismissible dialog. Detection without a real consequence gives a false sense of protection during a design review.

Time how long it takes to recover the app's core logic using standard decompilation tools, and note whether identifiers were meaningfully renamed, control flow was flattened or otherwise transformed, and whether a commercial obfuscator was used versus the default shrinker configuration. Obfuscation strength should be judged by how much it actually slows down analysis, not by whether a tool was nominally applied.

Search the decompiled and disassembled output for sensitive constant strings, such as endpoint URLs or internal flags, that remain in plaintext despite obfuscation being applied elsewhere. Obfuscating identifiers while leaving meaningful strings untouched still gives an analyst most of what they need to understand the app's behavior quickly.

Determine whether the app's most security-critical logic, such as license validation or key derivation, lives in Java and Kotlin, where decompilation to readable pseudo-source is near-instant, or in native code, which requires disassembly and is meaningfully harder to analyze. Moving logic to native code raises analysis cost but does not make that logic unreadable to a sufficiently motivated reverse engineer.

Look for native code that inspects its own memory maps or loaded libraries for evidence of hooking frameworks operating at the native level, which is a harder target for generic bypass scripts than Java-layer detection. Assess whether these checks are specific enough to catch real instrumentation without also breaking on legitimate system configurations.

Determine whether the app relies on a platform-provided integrity attestation service to get a server-verifiable signal about device and app integrity, rather than trusting only client-side self-reported checks. Because attestation results are verified server-side against the platform vendor, this is meaningfully harder for a compromised client to forge than any purely local check.

Test whether the app detects being reinstalled under a modified package name or with a different signing certificate than expected, which would indicate a repackaged and resigned copy of the app. Repackaging detection protects the app's reputation and users from trojanized clones distributed outside official channels.

Determine whether the app uses any packing, encryption, or dynamic loading of its DEX bytecode intended to prevent straightforward static dumping of the full class list from the installed APK. Assess these protections realistically, since most packing schemes can still be defeated by dumping the bytecode from memory once the process is running.

Review whether root, emulator, Frida, and integrity checks are implemented as genuinely separate mechanisms scattered through the app, or whether they all funnel into one shared gatekeeping function that a single hook can neutralize. Layered defenses only provide real added cost to an attacker when defeating one layer does not automatically defeat the rest.

Search decompiled code for calls constructing ciphers, hashes, or MACs with algorithms known to be weak or broken by modern standards, such as outdated symmetric ciphers or collision-prone hash functions used for integrity purposes. Confirm the algorithm choice was intentional and appropriate for its actual purpose rather than copied from outdated example code.

Search for cipher instances configured with electronic codebook mode and flag any use of it for data with repeating structure or patterns, since this mode encrypts identical plaintext blocks into identical ciphertext blocks. Confirm the fix uses an authenticated mode with a unique nonce or IV per encryption rather than simply swapping in a different unauthenticated mode.

Check every symmetric encryption call site for how the initialization vector or nonce is generated, flagging any case where it is hardcoded, derived deterministically from non-secret data, or reused across multiple encryptions with the same key. Confirm a properly random or counter-based unique value is generated for each individual encryption operation.

Search the codebase and native libraries for byte arrays or strings used directly as encryption keys, separate from the broader hardcoded-secrets sweep done during static analysis, since crypto keys are sometimes generated through obfuscated derivation from a hardcoded seed rather than stored as an obvious constant. Trace key material back to its origin to confirm it is not ultimately derived from something baked into the app.

Where an encryption key is derived from a user-supplied password, check that a purpose-built key derivation function is used with a sufficiently high work factor and a unique, randomly generated salt per user, rather than a single fast hash function applied once. A weak derivation function lets an attacker who obtains the derived value or a related artifact test candidate passwords far faster than the legitimate flow would allow.

Search for the use of a general-purpose pseudorandom number generator to produce session tokens, password reset codes, encryption keys, or nonces, and confirm a cryptographically secure random source is used instead for anything security-relevant. A general-purpose generator is designed for statistical distribution properties, not unpredictability against an adversary trying to predict its output.

Search for hand-written implementations of encryption, hashing, or encoding schemes rather than calls into well-established, peer-reviewed cryptographic libraries. Even a conceptually sound custom scheme is far more likely to contain a subtle flaw than a standard library implementation that has been scrutinized by the broader security community.

For every long-lived cryptographic key the app generates, confirm it is created and used through the platform Keystore rather than generated in application code and then serialized to a file or preference value. A key that exists as extractable bytes anywhere in app-accessible storage can be pulled off the device far more easily than one that only ever exists inside protected key storage.

Check the parameters used when generating a Keystore-backed key, such as whether it requires user authentication before use, whether it is invalidated when biometrics change, and whether it is restricted to a specific purpose and mode. Overly permissive key attributes reduce the practical protection the Keystore provides even though the key material itself never leaves secure storage.

Check whether the app decrypts attacker-influenceable ciphertext using a padding scheme vulnerable to a padding oracle attack, and whether any observable behavior, such as a distinct error message or timing difference, reveals whether padding was valid after decryption. Prefer authenticated encryption modes that make padding oracle attacks structurally inapplicable rather than trying to suppress the oracle behavior after the fact.

Where the app itself hashes a password, such as for a local PIN or a custom authentication scheme, confirm it uses a slow, salted hashing function designed for credential storage rather than a fast general-purpose hash. This mirrors the key-derivation concern but applies specifically to credential verification rather than encryption key generation.

Check how the app parses and validates any JWT it receives, confirming it does not trust the token's claims without verifying the signature, and that it does not accept a token whose header specifies no signature algorithm at all. Client-side JWT handling bugs are less common than server-side ones but still worth checking wherever the app itself makes trust decisions based on token contents.

Where the app implements its own scheme for establishing a shared secret with the backend, separate from standard TLS, review whether the key exchange method provides real protection against an on-path attacker or merely provides obfuscation. Reinventing key exchange is a strong signal to look closely, since it usually indicates the standard transport security stack was judged insufficient for reasons worth questioning.

Step back from individual findings and assess whether the app has a coherent, consistently applied strategy for encrypting sensitive data at rest, or whether protection is applied inconsistently across different features and storage locations. A patchwork of protections, some strong and some absent, often indicates the encryption choices were made feature by feature rather than following a documented security requirement.

Confirm that when biometric authentication gates a sensitive operation, it does so by requiring biometric authorization to unlock a Keystore-backed key needed for that operation, rather than only gating a boolean flag checked separately in app logic. Binding authentication to the actual cryptographic operation closes the gap that a simple callback bypass would otherwise open.

Identify which cryptography libraries the app bundles and confirm they are actively maintained and receiving updates, since an abandoned crypto library will not receive fixes for weaknesses discovered in its algorithms or implementation over time. Prefer the platform's built-in cryptographic providers or a well-maintained, widely audited library over a bundled dependency that has not been updated in a long time.

For every finding, explain concretely what an attacker could actually achieve by exploiting it, in terms the client's stakeholders will care about, rather than only describing the technical mechanism. A finding described purely in technical terms is much easier for a reader to deprioritize than one tied to a specific consequence like account takeover or bulk data exposure.

Write reproduction steps precise enough that another tester could follow them without needing to ask a clarifying question, including exact adb commands, Frida script contents, and any required device state such as root or a specific app version. Vague reproduction steps are one of the most common reasons a client's engineering team reports being unable to confirm a finding.

Include the full, runnable script used to demonstrate each dynamic finding as an attachment or appendix entry, rather than only describing what the script did in prose. Providing the working script lets the client's team reproduce and later retest the issue without having to reverse-engineer your testing approach from a written description.

For each finding, save the specific screenshot, logcat excerpt, or proxy history entry that demonstrates it, and reference that evidence directly from the finding write-up. Evidence tied to a specific timestamp and device state also helps if a finding is later disputed or needs to be checked against a newer build.

Rate every finding using a consistent framework, noting the specific factors that drove the rating, such as required privilege level, user interaction, and the sensitivity of data or functionality affected. Consistent methodology lets the client compare severities across findings and across engagements over time rather than treating each rating as a subjective label.

For each finding, describe a concrete fix appropriate to the app's actual architecture rather than a generic best-practice statement, and where relevant point to the specific API or configuration change needed. Developers move much faster on a finding that tells them exactly what to change than on one that only says what went wrong.

For each finding, note exactly what should be re-checked after a fix is deployed, referencing the same reproduction steps used originally so the retest is a direct apples-to-apples comparison. A clear retest plan also helps the client understand which findings can be closed independently versus which depend on a shared underlying fix.

Summarize the overall security posture of the app, the most significant findings, and the general themes observed across the assessment in language a non-technical stakeholder can follow without reading the detailed findings. A good executive summary lets a decision-maker understand the state of the app and the urgency of remediation in a few minutes.