An APK can request familiar permissions, display a polished icon, and still hide behavior that deserves scrutiny. Android malware analysis starts by treating the application as evidence, not something to install and try.
The decompiler lets you inspect an APK’s structure and reconstructed source code without running it. A careful Android malware analysis workflow uses a safe lab and clear notes. A polished trojanized application may behave like spyware or adware, so treat it as potentially malicious software until evidence supports a conclusion.
Key Takeaways
- Treat every suspicious APK as evidence: preserve the original, record its SHA-256 hash, and avoid installing it on personal or production devices.
- Begin with static analysis in JADX by reviewing the manifest, permissions, components, embedded assets, native libraries, and reconstructed code.
- Follow suspicious references and call paths instead of treating isolated permissions, strings, domains, or certificates as proof of malware.
- Look for patterns such as persistence, concealment, sensitive-data collection, command handling, and unexplained network uploads, while separating observations from conclusions.
- Use dynamic analysis only in an authorized, isolated lab to test a documented hypothesis, and report uncertainty when obfuscation, reflection, encryption, or native code limits visibility.
Android malware analysis with JADX starts before decompilation
Static analysis examines an app’s files, configuration, code, and embedded data without executing it. That makes it the right first step for suspicious APKs, especially when the sample’s origin or behavior is unknown.
Static analysis and dynamic analysis answer different questions
The decompiler can reveal declared permissions, exported components, hard-coded domains, suspicious services, and hidden code paths. It also lets you compare an app’s claimed purpose with what its code appears able to do. Even adware can warrant this review when its advertising SDKs request excessive access.
Dynamic analysis observes behavior while an app runs in a controlled environment. It can expose network traffic, runtime-decrypted strings, downloaded modules, and abuse that isn’t obvious in code. However, running an unknown APK raises the risk level.
A permission tells you what an app can request. A call path, receiver, service, or network routine shows what it may try to do with that access.
Start with static work. Move to a separate runtime setup only when you have authorization, isolation, and a defined question to answer.
Build a lab that protects your accounts and devices
Use a dedicated virtual machine or analysis workstation. Keep it separate from personal accounts, work credentials, synced cloud storage, and shared folders. Take a clean snapshot before each case so you can revert after handling a suspicious file.
If you later need runtime evidence, use a disposable Android emulator or a dedicated test handset. Disable access to real contacts, personal photos, payment methods, and corporate networks. Never execute a suspicious APK on a daily-use phone.
The OWASP mobile testing knowledge base offers useful context for reviewing mobile apps with a repeatable mobile security mindset. Keep a case folder for each sample and write down every action you take. When authorized, a Pithus record can provide optional supporting intelligence, but it never replaces your own review.
Read the APK structure before reading the code
An Android application package is a ZIP-based container. It holds bytecode, resources, metadata, and sometimes native libraries. A quick inventory prevents you from getting lost in the app’s classes.
The files that usually matter first
AndroidManifest.xml is the best opening document. It identifies the package name, requested permissions, activities, services, broadcast receivers, content providers, and app-level settings.
classes.dex contains Android’s compiled bytecode. Its contents represent reconstructed application logic, not the developer’s original project.
Also inspect these locations:
res/andresources.arscmay reveal app labels, notification text, layouts, and configuration tied to advertising behavior, adware, or unexpected SDKs.assets/can contain web content, configuration files, encrypted blobs, or additional payloads.lib/holds native.solibraries for CPU architectures such as ARM64. Those files need a native-code tool when the package structure doesn’t explain them.META-INF/and APK signing information can assist with clustering. Use an authorized corroborating source such as Pithus for sample comparison, but a certificate or intelligence-platform result alone doesn’t prove authorship.
Components reveal an app’s reachable surface
The manifest tells Android which components can start under certain conditions. A boot receiver may launch after a device restart. A foreground service can keep a process active. An exported activity, receiver, or provider may accept requests from other apps. Excessive or mismatched access can indicate permission abuse.
Android documents that sensitive access must be declared with <uses-permission> entries in the manifest. Review the official permission declaration reference while checking each request.
A weather app requesting network access is ordinary. A polished trojanized application may request unrelated capabilities, including accessibility access, microphone recording, SMS functions, boot startup, and device-admin controls.
Install JADX and preserve the sample’s identity
The official project provides command-line and graphical tools that turn DEX and APK files into readable source. Its release page is the safest place to check current builds, rather than downloading repackaged archives from unknown sites.
Acquire samples legally and record hashes
Use a sanctioned training sample, an incident-response case you’re authorized to assess, or a reputable malware-intelligence service such as Pithus, when its access terms permit it. Don’t fetch APKs from random file hosts, chat groups, or anonymous links.
Before unpacking anything, calculate a SHA-256 hash. You can optionally check that hash on Pithus for context, but a match doesn’t authorize downloading or executing the sample. On macOS or Linux, use sha256sum incoming/sample.apk. On PowerShell, use Get-FileHash .\incoming\sample.apk -Algorithm SHA256.
Store the full hash with the original filename, acquisition date, source, and your case identifier. A hash lets other analysts confirm they are discussing the same byte-for-byte file. The PTS guide to handling a potentially malicious mobile app also recommends computing and recording hashes before deeper investigation.
Open files without treating them as trustworthy
Keep the original APK read-only in an incoming folder. Extract or decompile into a separate working directory. A basic command-line pass can use jadx -d cases/sample_001/decompiled incoming/sample.apk, while jadx-gui incoming/sample.apk opens the graphical browser.
The tool doesn’t run an APK’s Android code. Still, update the tool and your operating system because any parser can contain flaws. Avoid opening unknown files with Android Studio, an emulator, or a physical device merely to see what happens.
For a second perspective, APKTool can decode resources and expose smali when the tool produces incomplete output. That contrast is useful during reverse engineering, but it doesn’t change the rule: inspect first, execute only in an approved lab.
Use a repeatable decompiler triage order
A reliable first pass is faster than hunting through thousands of classes at random. In static analysis, start with broad facts, then trace only code connecting those facts to possible behavior.
Triage the manifest and permission set
Begin your manifest analysis in the decompiler by recording the package name, version details, minimum SDK, target SDK, application label, and each declared component. Then identify permissions that clash with the app’s visible function.
Pay attention to permissions or special access related to SMS, contacts, call logs, microphone, camera, notifications, accessibility, package visibility, overlays, device administration, and boot completion. Android’s permission overview explains that Android 6.0, API level 23, introduced runtime permissions, but a manifest declaration remains important evidence.
A permission alone is not proof of harmful behavior. A password manager, parental-control app, or communication tool may need sensitive access. A mismatch can suggest permission abuse, but it isn’t proof by itself.
Search code for behavior, then follow references
Use the decompiler’s global search for http, https, WebSocket, Socket, URLConnection, OkHttp, Runtime, ProcessBuilder, AccessibilityService, MediaProjection, and BOOT_COMPLETED. Search also for permission names, manifest components, and routines that may handle command-and-control traffic.
When you find a suspicious string or method, use “Find Usage” and cross-references. Trace who calls it, what conditions enable it, and what data enters or leaves the method. This is more useful than treating a lone string as evidence of compromise.
For context, compare hashes, domains, or package identifiers with Pithus when appropriate. External intelligence can enrich the code review, but it doesn’t replace tracing relevant paths.
OWASP’s app-permissions guidance reinforces a helpful review principle: assess declared access and how the application uses it. A large permission set becomes meaningful only when code paths make it actionable.
Mobile malware indicators that deserve closer review
Malware families differ, but each malware family can show recurring implementation choices during APK review. Map recurring behavior to tactics techniques and procedures (TTPs). Treat each finding as a lead in a pattern, not automatic proof or a verdict.
Persistence, concealment, and unwanted control
Look for receivers registered for device boot, package replacement, connectivity changes, or screen events. A receiver that starts a service after BOOT_COMPLETED may support normal reminders or security software. It can also keep unwanted code active after a reboot.
Review services that use long-running work, foreground notifications, alarms, or scheduled jobs. Check whether the application hides its launcher icon, changes its label, or prompts users to enable accessibility access or device-admin privileges. An apparently ordinary adware app may remain visible, but spyware can combine concealment with hidden collection.
A product advertised as a Phone monitoring tool may claim legitimate family or enterprise use, but the label alone isn’t decisive. A hidden trojanized application may start at boot, capture screens, and send private data off-device. That pattern needs a clear lawful purpose and informed user consent.
Exfiltration routines and common RAT patterns
Search for routines that collect contacts, SMS messages, call history, location, installed-app lists, clipboard data, media files, or device identifiers. Also look for keystroke capture through a keylogger. Then trace those results to JSON construction, encryption, HTTP requests, sockets, cloud-storage SDKs, or custom upload methods.
Remote-access trojans often combine collection routines with a command handler. Static clues include command names, polling loops, WebSocket clients, Firebase Cloud Messaging handlers, or services parsing actions from command-and-control infrastructure. A backdoor or botnet role is possible, but legitimate remote-support apps can use similar architecture, so context matters.
A banking trojan may misuse overlays or accessibility services to imitate financial-app screens and observe interaction. Apps associated with billing fraud may focus on SMS-related behavior or payment flows, while phishing malware may use deceptive screens or messages to capture credentials. Ransomware can target files or device access, and rooting malware may bundle native libraries and references to device-specific vulnerabilities. Do not attempt to trigger any of these functions during beginner analysis.
A review of Android static-analysis research describes why permissions, API calls, and other static features can help classify suspicious apps. Authorized Pithus data can help compare artifacts, but it shouldn’t assign a family automatically. These signals are leads, not final proof.
A fictional sample investigation, step by step
Consider WeatherPulse.apk, a fictional sample labeled as a local forecast app. The file is never installed. Its SHA-256 value and source are recorded, then it is opened in the decompiler from the isolated workstation.
Connect the evidence instead of chasing every class
The manifest shows INTERNET, ACCESS_FINE_LOCATION, RECEIVE_BOOT_COMPLETED, and notification access. Location access fits a weather function, while boot startup and notification access require explanation.
A search for BOOT_COMPLETED points to a receiver that starts SyncService. Cross-references show that the service calls collectInstalledPackages, adds location data to JSON, and posts it to a hard-coded HTTPS domain. That domain could support command-and-control, but static evidence cannot confirm live control; the visible forecast screen never explains the collection.
None of those details proves a known malware family by itself. Together, the hidden collection and upload behavior can resemble spyware. The evidence supports a narrower finding: the sample appears to collect more data than its stated function requires and sends it to an external endpoint.
Turn observations into an IOC record
Record exact values from the sample, not guesses or shortened copies. Each indicator of compromise (IOC) should retain its full value and context. The table below shows the evidence a case file should hold.
| Artifact | Example observation in WeatherPulse.apk | Analyst action |
|---|---|---|
| SHA-256 | Full 64-character digest recorded before review | Search internal records and authorized intelligence portals |
| Package name | A package name unrelated to its weather branding | Compare with signing and distribution context |
| Boot receiver | Receiver handles BOOT_COMPLETED and starts a service | Trace the service’s call chain |
| Network indicator | Hard-coded HTTPS host in the upload routine | Preserve the full domain and path as an IOC |
| Data collection | Installed-app list and location added to JSON | Document source methods and permission linkage |
If an authorized portal supports hash lookups, check the SHA-256 in Pithus before interpreting the sample or downloading variants. Pithus can also help analysts compare known Android samples, but its results should guide review rather than replace it.
Know where the decompiler stops being enough
The decompiler is excellent for first-pass visibility, but reconstructed source can contain gaps. Treat it as a map, not a court transcript.
Obfuscation, encrypted strings, and native code
Modern code obfuscation can replace helpful class names with single letters, flatten control flow, and hide strings or activation logic for detection evasion. An empty-looking method may call code by name through reflection. A suspicious URL may stay encrypted or assemble only after the app starts.
The decompiler can also show decompilation errors or code that doesn’t compile cleanly. Inspect surrounding instructions, review the DEX or smali with another tool, and note uncertainty in your report. Native .so files need separate analysis because the decompiler focuses on DEX bytecode.
For authorized comparison, Pithus can provide sample metadata and known indicators, but it can’t compensate for encrypted or native behavior.
A clean search for URLs does not clear an APK when it includes encrypted assets, reflection, or native libraries.
Use dynamic analysis only to test a documented hypothesis
Earlier findings should lead to focused runtime questions, not open-ended experimentation. A documented hypothesis might ask whether a service uploads contacts after boot or transmits other data.
It might also ask whether suspected ransomware changes files, whether rooting malware hides a critical action in native code, or whether a botnet contacts a remote coordinator. Test only the documented question, without trying to activate additional behavior.
Use an isolated emulator, controlled network monitoring, snapshots, and a written scope. Keep personal accounts, SIM cards, and production Wi-Fi out of the test. Don’t interact with command-and-control infrastructure, submit credentials, or try to activate suspected surveillance features.
Report and remove suspicious Android apps safely
A useful report separates facts from conclusions. Include the sample hash, package name, app label, permissions, component names, suspicious methods, domains, URLs, certificate details, relevant code screenshots, and a confidence level.
When authorized, use Pithus to correlate a hash or indicator. Don’t upload sensitive evidence without approval.
Escalate with clear evidence
For a workplace device, send the APK, hash, and notes to the security team or incident-response provider. Rapid support may be warranted when findings suggest phishing malware or ransomware. Preserve the original file and avoid forwarding it through ordinary email. If the app came from an official store, use its reporting route and include the package name.
An outside review should have written authorization, a defined device scope, and a clear handling process. A provider branded Pro Ethical Hackers For Hire should meet those standards before anyone shares devices, credentials, or evidence. Don’t contact a threat actor or send them investigative material.
Remove the app without destroying evidence
If the device is safe to handle, capture the app name, package name, permissions, and visible behavior first. Then revoke unusual permissions, uninstall the app, and check for unknown device-admin, accessibility, notification-listener, or VPN entries.
Change passwords from a separate trusted device if the app accessed messages, accessibility controls, or screen content. Signs of spyware or adware warrant specialist review. Suspected rooting malware also calls for additional device checks.
Update Android and installed apps, then monitor for billing fraud and unusual account activity when the sample accessed sensitive data.
Treat invitations to Download Pathfinder Rat software as a reason for defensive review, never as a source of test applications. Similarly, Verified Tor Onion Links should not be used to acquire samples or contact anyone connected to an investigation.
Frequently Asked Questions
Is JADX safe for analyzing a suspicious APK?
JADX decompiles APK and DEX files without running the app’s Android code, making it suitable for a cautious first pass. Keep the sample isolated, use updated software, and remember that any parser can contain vulnerabilities.
What should I inspect first in an APK?
Start with AndroidManifest.xml, the package and version details, declared permissions, and exported activities, services, receivers, and providers. Then review classes.dex, resources, assets, native libraries, and signing information for clues that connect the app’s claimed purpose to its capabilities.
Do suspicious permissions prove that an app is malware?
No. A permission is evidence of potential access, not proof that the application uses it maliciously. Confidence increases when a permission connects to code that collects sensitive data, maintains persistence, or sends information to an unexplained endpoint.
When should dynamic analysis be used?
Use it only when static analysis leaves a specific question unanswered and you have authorization, isolation, controlled networking, and a written scope. Runtime testing should examine a documented hypothesis rather than attempting to activate every suspected behavior.
What are JADX’s main limitations?
Obfuscation, encrypted strings, reflection, dynamic loading, and native .so libraries can hide important behavior or produce incomplete decompilation. Use smali or native-code tools for additional context, and record uncertainty instead of treating a clean search as proof that the APK is safe.
Final thoughts
A defensible review is built on evidence, not dramatic assumptions. Preserve the APK, record its hash, read the manifest, trace code paths in the decompiler, and connect each finding to the app’s claimed purpose.
The tool won’t reveal every behavior, especially when code is obfuscated or activated at runtime. Still, a careful review gives you safe, actionable evidence before any higher-risk testing begins.
