Beginner
Android Malware
SEND_SMS
READ_CONTACTS
INTERNET✓
◎ BEGINNER500 XPAudio:ES
Android Malware Beginner
Practical Android malware foundations with guided hands-on labs.
⬡ 1 guided lab◷ 10h of content
119 EUR
◈ Path Bundle
Android Malware
From APK unpacking and jadx-gui decompilation to Frida instrumentation, native library analysis, C2 configuration extraction and dynamic behaviour capture — reverse engineering real Android malware in isolated cloud labs, with nothing to install on your own machine.
Lab tools you will use
jadx-guiapktoolMobSFADBFridaAndroguarddex2jarBytecode Viewerjadx-guiapktoolMobSFADBFridaAndroguarddex2jarBytecode Viewer
JEB DecompilerdrozerObjectionBurp SuiteAPKiDAPKLeaksGhidraradare2JEB DecompilerdrozerObjectionBurp SuiteAPKiDAPKLeaksGhidraradare2
Courses Included
Intermediate
Android Malware
classes.dex obfuscated
libnative.so packed
▲ INTERMEDIATE750 XPAudio:ES
Android Malware Intermediate
Intermediate Android malware with complex real-world scenarios and professional workflow.
⬡ 2 guided labs◷ 12h of content
159 EUR
Why Choose the Full Pack?
Get the Beginner + Intermediate courses bundled together and unlock exclusive extras.
Beginner + Intermediate courses (22h of content)
All 4 guided labs with isolated VMs
2 HTK certificates (Beginner + Intermediate)
1 exclusive bonus consolidation lab
Direct instructor support
Access to the HTK community
Your Learning Roadmap
Each phase maps to a course module. Scroll to assemble your full progression — from beginner fundamentals to intermediate mastery.
Phase 1
BeginnerTaking the package apart
An APK is an archive with rules. You start by reading what the application declares about itself before trusting any of it.
- •Unpack resources and read the manifest as a statement of intent
- •Map the components that can be triggered from outside the app
- •Interpret permissions in terms of capability rather than labels
Phase 2
BeginnerReading the code it shipped
Android decompiles far better than native code, which makes reviewing what an application really implements realistic.
- •Recover readable code from Dalvik bytecode
- •Follow entry points through to where the interesting logic lives
- •Identify the API calls that indicate surveillance or theft
Phase 3
BeginnerRunning it where it can do no harm
Standing up an instrumented device and watching the application behave rather than inferring behaviour from source.
- •Build an emulated device you can reset between samples
- •Drive installation and interaction from the command line
- •Observe what it writes, starts and contacts at runtime
Phase 4
BeginnerIntercepting what it sends
Mobile malware exists to move data off the device, so the traffic is where its purpose becomes undeniable.
- •Route device traffic through a proxy you control
- •Read the exfiltration channel and what it carries
- •Recover server addresses the app only reveals in use
Phase 5
IntermediateWhen the code is deliberately unreadable
Commercial samples are obfuscated and often packed. This phase is about recognising the protection before fighting it.
- •Identify the packer or obfuscator in use before wasting hours
- •Recover payloads that only appear once the app is running
- •Work through renamed classes and string encryption
Phase 6
IntermediateRewriting behaviour as it runs
Runtime instrumentation is the mobile analyst's sharpest tool: it makes an application tell you what it is doing while it does it.
- •Hook methods to read arguments obfuscation was meant to hide
- •Bypass root, emulator and certificate pinning checks
- •Force execution down branches the sample tries to avoid
Phase 7
IntermediateFollowing it into native code
Serious families move their secrets out of Java and into compiled libraries, so the analysis has to follow.
- •Trace calls across the boundary into native libraries
- •Reverse compiled code to recover decryption routines
- •Extract configuration hidden below the readable layer
Phase 8
IntermediateSaying what it can actually do
The deliverable is a capability assessment, not a permission list — what the application does, evidenced.
- •Extract indicators that identify the family, not one build
- •Separate demonstrated capability from theoretical permission
- •Write the assessment for a reader who will act on it
What this path is
The Android Malware path covers reverse engineering mobile applications: taking an APK apart, reading what it really does versus what it claims in its manifest, and observing its behaviour on an instrumented device. Mobile is where a very large share of personal data now lives, which is exactly why it is targeted.
The technical shape of the work differs from Windows analysis in ways worth knowing up front. Android applications are usually Dalvik bytecode, which decompiles to something close to readable Java — a substantially easier starting point than native disassembly. The difficulty moves elsewhere: aggressive obfuscation, native libraries invoked through JNI, encrypted payloads loaded at runtime, and permission models that hide malicious intent inside legitimate-looking requests.
There is also a distribution problem worth understanding, because it shapes what you will actually meet. Desktop malware mostly arrives through email or compromised downloads. Mobile malware frequently arrives through an app store, having passed automated review, or through sideloading that the user was socially engineered into enabling. Families in this space commonly ship a benign first version, build an install base and a review history, then deliver the malicious capability in a later update or fetch it at runtime — which is precisely why static review of a single version is not enough, and why the dynamic phase of this path carries so much weight.
This path is in development. It is being built to the same standard as the rest of the catalogue, with isolated labs and flag-validated exercises on real samples rather than purpose-written demos.
Who it's for
- Malware analysts extending their coverage from desktop to mobile
- Mobile developers who want to understand how their applications are attacked
- Application security testers moving toward malware analysis
- Threat researchers tracking mobile banking trojans and stalkerware
Who it's not for
- ·Anyone with no programming background — you need to read Java-like code to make progress
- ·People looking for mobile penetration testing; the focus is malware analysis, not app pentesting
What you need before starting
- Able to read Java or Kotlin — you need to understand decompiled code, not write apps
- Understanding of how Android applications are structured: activities, services, permissions
- Comfortable with the command line and with ADB
- Malware analysis fundamentals help, though the path does not assume them
The tools, and what each one is for
The path uses more tools than fit here. These are the ones that define the work.
| Tool | Category | What for |
|---|---|---|
| jadx-gui | Decompilation | Turning Dalvik bytecode back into readable Java — the usual first step |
| apktool | Unpacking | Decoding resources and the manifest to see declared permissions and components |
| MobSF | Automated analysis | Fast triage across static and dynamic checks before manual work begins |
| Frida | Instrumentation | Hooking functions at runtime to defeat obfuscation and observe real arguments |
| ADB | Device control | Installing, extracting and interacting with applications on the test device |
| Androguard | Static analysis | Scripting analysis across many samples instead of clicking through each |
| APKiD | Fingerprinting | Identifying packers, obfuscators and compilers before wasting time on manual analysis |
| Ghidra | Native analysis | Reversing the native libraries that obfuscated applications hide their logic in |
What you finish with
APK analysis reports
Covering permissions, components, network behaviour and capability
Frida hook scripts
Written to bypass obfuscation and reveal what the application really passes around
Extracted C2 indicators
Recovered from applications that decrypt their configuration only at runtime
A capability assessment
What the application can actually do, versus what its permission list implies
Where it leads
Mobile analysis is a narrower specialisation than desktop malware analysis, which is precisely what makes it valuable — the supply of analysts who can do it well is much smaller than the demand.
Mobile Malware Analyst
Reverses mobile threats and extracts indicators from them
Threat Researcher
Tracks mobile banking trojans, stalkerware and spyware families
Application Security Analyst
Assesses mobile applications for weaknesses and malicious behaviour
DFIR Analyst
Investigates compromised mobile devices during incidents
Frequently Asked Questions
Complete answers about this path, labs, certificates, and refunds
It is in development, being built to the same standard as the rest of the catalogue with isolated labs and flag-validated exercises. The Windows Malware, Phishing with OSINT and Threat Hunting paths are available now.
No. The labs use emulated devices, which are safer for malware and easier to reset between analyses. A physical device is useful for a few specific cases and the material notes where.
The starting point is easier, because Dalvik bytecode decompiles to something close to readable Java rather than assembly. The difficulty shifts to obfuscation, native libraries reached through JNI, and payloads that only appear at runtime.
No, but you need to read Java or Kotlin and understand how an application is put together — activities, services, permissions. You are reading other people's code, not writing your own.
No. iOS analysis is a different discipline with its own tooling and a much more restrictive research environment. This path is Android only, and says so rather than implying broader coverage.
They share the analytical method — triage, static, dynamic, reporting — and differ entirely in tooling. Doing Windows first is helpful but not required; the mobile path is self-contained.