Android Basic Static Analysis — Advanced Study GuideThis episode demonstrates how to perform basic static analysis of Android applications, moving from initial malware triage to manifest analysis, code decompilation, and identification of suspicious functionality.1. Android Malware Analysis MethodologyAlthough Android and iOS have very different architectures, the fundamental malware-analysis methodology remains similar:Sample ↓ Identification ↓ Hashing ↓ Threat Intelligence ↓ Manifest Analysis ↓ Code Analysis ↓ Behavioral Hypothesis ↓ Dynamic Analysis The objective of static analysis is to understand as much as possible without executing the malware.2. Initial APK IdentificationThe first stage is to establish basic information about the APK.Useful checks include:
- File type
- File size
- Cryptographic hashes
- Existing antivirus detections
- Known threat intelligence
For example:file "malware 2.apk" Hashing provides a stable identifier for the sample:md5sum "malware 2.apk" sha256sum "malware 2.apk" The resulting hashes can then be searched in authorized malware-intelligence services such as VirusTotal.Important principleA clean scan does not establish that an APK is safe. Static analysis should continue even when existing security engines report no detection.3. AndroidManifest.xml AnalysisThe AndroidManifest.xml is one of the most important artifacts in an Android investigation.An APK's manifest is normally stored in a compiled/binary representation, so tools such as apktool can be used to decode it into a human-readable form.For example:apktool d "malware 2.apk" -o malware_analysis The decoded project may contain:malware_analysis/ ├── AndroidManifest.xml ├── smali/ ├── res/ ├── assets/ └── ... The manifest can reveal:
- Application components
- Activities
- Services
- Broadcast receivers
- Content providers
- Intent filters
- Requested permissions
- Exported components
4. Permission AnalysisPermissions can provide an early indication of an application's intended capabilities.In this lab, the APK requests permissions associated with:
- Reading SMS
- Writing SMS
- Receiving/intercepting SMS
- Installing packages
- Removing packages
This combination is particularly interesting for a purported banking application.However, permissions alone do not prove malicious behavior.A better analytical question is:Which parts of the code actually use these permissions, and for what purpose?That connects manifest analysis with code analysis.5. Identifying the Application's TargetThe investigation decodes the application's string resources and discovers that its name translates from Korean to "smart banking."This provides an important contextual clue.Combined with the SMS-related permissions, the analyst can begin developing a hypothesis:Korean Banking Theme + SMS Access + Device Information ↓ Potential Banking-Focused Malware The hypothesis should then be tested against the application's actual code and behavior.6. DEX AnalysisAndroid applications typically contain compiled code in DEX (Dalvik Executable) format.The primary file is often:classes.dex Static analysis can involve converting DEX bytecode into a more readable representation.A traditional workflow demonstrated in the episode is:classes.dex ↓ dex2jar ↓ JAR / Java representation ↓ JD-GUI / JEB / Procyon ↓ Pseudo-source code The resulting code is not necessarily identical to the original source code, but it can provide a useful approximation of the application's logic.7. Why Decompilation MattersManifest analysis tells you what the application declares.Decompilation helps determine what the application actually does.For example:Manifest: READ_SMS RECEIVE_SMS ↓ Code: SMSReceiver ↓ Extract SMS information ↓ Process information ↓ Potential network communication This correlation is much stronger evidence than simply observing a suspicious permission.8. SMSReceiver InvestigationOne of the most significant findings in the lab is the SMSReceiver class.A broadcast receiver associated with SMS functionality deserves particular attention because SMS can contain:
- Authentication codes
- Banking notifications
- Account alerts
- Password-reset messages
- Two-factor authentication codes
The analyst therefore investigates what the receiver actually does with incoming messages.9. Device ProfilingThe SMSReceiver analysis also reveals functionality for collecting information about the device, including:
- SIM-related information
- Telephone information
- Device characteristics
This creates a stronger behavioral picture:SMSReceiver │ ├── Access SMS │ ├── Gather SIM information │ ├── Gather telephone information │ └── Network communication This behavior is considerably more suspicious when combined with the application's banking theme.10. Suspicious Network InfrastructureThe analysis identifies a connection to:banking1.catcat.net This domain becomes an important indicator of compromise (IOC) and a potential focus for further investigation.At this stage, the analyst should avoid immediately concluding that the domain is definitively a C2 server.Instead, the appropriate hypothesis is:The application contains functionality that may communicate with external infrastructure associated with its banking-related behavior.Dynamic analysis can subsequently determine:
- When the connection occurs
- What data is transmitted
- What responses are received
- Whether SMS information is exfiltrated
- Whether additional commands or configuration are retrieved
11. Building the Behavioral HypothesisThe evidence collected so far can be combined:EvidenceObservationApplication identity"Smart banking"TargetingKorean usersSMS permissionsRead/write/receive SMSComponentSMSReceiverDevice profilingSIM and telephone informationNetwork indicatorbanking1.catcat.netCode analysisSuspicious functionalityTogether, these findings support a strong hypothesis that the application may be banking-oriented malware capable of collecting sensitive device/SMS information and communicating with remote infrastructure.12. Static Analysis WorkflowThe complete workflow from this episode can be summarized as: APK │ ▼ File Identification │ ▼ Hashing │ ▼ Threat Intelligence │ ▼ apktool │ ┌───────┴────────┐ ▼ ▼ Manifest Resources │ │ ▼ ▼ Permissions App Identity │ ▼ classes.dex │ ▼ Decompile │ ▼ Java/Pseudo-code │ ▼ Interesting Classes │ ▼ SMSReceiver │ ┌────┼─────┐ ▼ ▼ ▼ SMS Device Network Data IOC │ │ └───┬───┘ ▼ Behavioral Hypothesis │ ▼ Dynamic Analysis Key Takeaways
- APK analysis begins with identification and preservation, not execution.
- Hashes provide useful sample identifiers for threat-intelligence searches.
- AndroidManifest.xml provides an excellent overview of the application's declared capabilities.
- Permissions should be correlated with actual code behavior rather than treated as proof of maliciousness.
- apktool is useful for decoding APK resources and the manifest.
- DEX decompilation provides visibility into application logic.
- SMSReceiver is particularly important when investigating malware that may target banking or authentication workflows.
- Device profiling combined with SMS access and suspicious network communication can provide strong evidence of malicious intent.
- Static analysis ultimately produces a behavioral hypothesis, which should be validated through controlled dynamic analysis.
Golden ConceptThe strongest malware-analysis conclusions come from correlating multiple independent artifacts: what the application claims to need, what its code actually does, what data it accesses, and where it communicates.
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
