CyberCode Academy

CyberCode Academy
  • 5.0 (1)
  • Courses
  • Updated daily

Welcome to CyberCode Academy — your audio classroom for Programming and Cybersecurity. 🎧 Each course is divided into a series of short, focused episodes that take you from beginner to advanced level — one lesson at a time. From Python and web development to ethical hacking and digital defense, our content transforms complex concepts into simple, engaging audio learning. Study anywhere, anytime — and level up your skills with CyberCode Academy. 🚀 Learn. Code. Secure. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy

  1. 11 hr ago

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 14: Architecture and Essential Toolkits

    This episode provides a comprehensive guide to designing and equipping a professional mobile malware analysis lab, with a focus on building a secure, repeatable, and well-instrumented environment for both iOS and Android research.1. Lab Design and InfrastructureThe episode begins by emphasizing that a professional malware lab requires more than simply running a few virtual machines. Researchers must carefully plan the environment around security, isolation, performance, and repeatability.Key considerations include:Network Architecture: Building isolated networks that prevent malware from reaching corporate or personal systems while still allowing controlled observation of malicious network traffic.Hardware Requirements: Allocating sufficient CPU, RAM, and storage to support multiple virtual machines, analysis tools, memory captures, and large malware samples.Operating Systems: Selecting appropriate host and guest operating systems for the platforms being investigated.Physical Devices: Maintaining real iOS and Android devices when necessary, since certain behaviors cannot be accurately reproduced through virtualization alone.Snapshots and Gold Images: Creating clean baseline environments that can quickly be restored after malware execution.Documentation: Recording network configurations, hardware specifications, installed tools, and experimental changes to make investigations reproducible.2. iOS Analysis ToolkitThe episode then introduces the major tools used throughout an iOS malware-analysis workflow.For static analysis, researchers can use:Hopper for disassembly and reverse engineering.MobSF for automated mobile application security analysis.Additional utilities for inspecting application packages, binaries, metadata, and embedded resources.For dynamic analysis, the toolkit includes:LLDB for debugging and inspecting running processes.Needle for iOS security assessment and runtime analysis.Cydia Impactor and AppSync for application installation and sideloading in appropriate research environments.Together, these tools allow analysts to progress from examining an application's structure and binary code to observing its behavior during execution.3. Android Analysis ToolkitThe Android toolkit follows a similar static-to-dynamic methodology.Static analysis includes tools such as:Android Guard for examining and transforming Android applications.JEB for advanced reverse engineering and decompilation.MobSF for automated security analysis.For dynamic analysis, the episode highlights:Droser for interacting with Android application components at runtime.FSmon for monitoring filesystem activity.Volatility for memory-forensics investigations when memory artifacts are relevant.This combination allows researchers to correlate application code with its actual runtime behavior.4. Network Analysis and Cross-Platform ToolsBecause mobile malware frequently communicates with external infrastructure, network visibility is another fundamental part of the laboratory.The episode highlights:Burp Suite for intercepting and analyzing HTTP/HTTPS traffic.Wireshark for packet-level network analysis.Charles Proxy for monitoring and debugging application traffic.These tools help researchers identify C2 infrastructure, suspicious domains, unusual requests, transmitted data, and network-based indicators of compromise.5. The Complete Analysis WorkflowThe most important takeaway is that the laboratory should function as an integrated ecosystem rather than a collection of unrelated tools:Sample → Static Analysis → Dynamic Execution → Runtime Monitoring → Network Analysis → Memory Analysis → IOC Extraction → ReportingThe goal is to correlate evidence from multiple sources. For example, a suspicious domain discovered during static analysis can later be confirmed through network captures, while a suspicious function identified in a binary can be correlated with the process and filesystem activity observed during execution.Ultimately, the episode provides a practical roadmap for building a secure, scalable, and professional mobile malware-analysis environment capable of supporting repeatable investigations across both iOS and Android. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 14: Architecture and Essential Toolkits

  2. 1 day ago

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 13: Designing and Architecting a Scalable Mobile Malware Analysis Lab

    This episode focuses on designing a professional, scalable, and repeatable mobile malware analysis laboratory, moving beyond a simple virtual-machine setup toward an environment suitable for long-term security research.1. Strategic Lab PlanningBefore building the lab, analysts should define its purpose and scope:Determine whether the environment will be air-gapped, isolated, or internet-connected.Identify the platforms that will be analyzed, such as Android, iOS, Windows, or macOS.Design the environment around the types of malware and investigations it will support.2. Network Architecture and IsolationA major focus is creating a dedicated “dirty network” that is completely separated from corporate or personal resources.The lab should provide:Trusted and untrusted network segments to control malware traffic.Strong isolation to prevent malware from reaching production systems.Controlled internet access when required for behavioral analysis.Consideration for mobile-specific behavior, since some malware behaves differently over Wi-Fi, cellular networks, or specific SIM configurations.Fake or controlled internet services when direct internet access is unnecessary or dangerous.The fundamental principle is simple: assume the malware will attempt to escape the laboratory.3. Hardware and Operating System SelectionThe lab must have sufficient resources to run multiple virtual machines and analysis tools efficiently.Important considerations include:Adequate CPU and RAM allocation.Physical Android and iOS devices when authentic device behavior is required.Using an operating system that reduces the risk associated with the malware being analyzed—for example, analyzing malware targeting one platform from a different platform when practical.Maintaining dedicated hardware that is not connected to sensitive networks.4. Tooling and AutomationThe course recommends beginning with security-focused distributions such as Kali Linux or REMnux, which provide many forensic and malware-analysis tools out of the box.A professional lab should combine:Static analysis tools.Dynamic analysis frameworks.Network-monitoring tools.Debuggers and reverse-engineering utilities.Mobile-specific analysis frameworks.Automated installation and configuration processes.New tools should first be tested in an isolated environment before being introduced into the primary research infrastructure.5. Documentation and RepeatabilityOne of the strongest operational lessons is the “3Ds” principle: Document, Document, Document.Analysts should maintain detailed records of:Network topology and IP ranges.Virtual-machine configurations.Hardware specifications.Installed tools and versions.Device configurations.Analysis procedures.Changes made to the environment.This documentation makes the laboratory repeatable, troubleshootable, and easier to rebuild after a failure.6. Snapshots and Gold ImagesVirtualization provides another important advantage: the ability to return systems to a known-clean state.Analysts should maintain a gold image containing a properly configured analysis environment and use VM snapshots before executing suspicious samples.If malware compromises the VM, the analyst can discard the infected state and restore the clean snapshot rather than rebuilding the environment from scratch.7. Core TakeawayThe episode's central lesson is that a malware lab should not simply be a collection of tools and virtual machines. It should be an engineered security environment designed around:Isolation → Control → Repeatability → Documentation → AutomationA professional malware-analysis laboratory allows researchers to safely reproduce malicious behavior, capture network and system artifacts, compare results across experiments, and rapidly return to a trusted baseline after infection. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 13: Designing and Architecting a Scalable Mobile Malware Analysis Lab

  3. 2 days ago

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 12: Dynamic Analysis Tools, Techniques, and Assessment

    This episode covers dynamic analysis of Android applications, with a strong emphasis on runtime interaction, monitoring, and debugging.1. Android Dynamic Analysis with DrozerThe episode introduces Drozer, an Android security assessment framework that allows researchers to interact with application components while they are running.Key capabilities include:Establishing communication between the analysis machine and Android device using ADB port forwarding.Enumerating installed packages and examining metadata such as permissions, UIDs, and package information.Identifying potentially exposed attack surfaces, including:Exported ActivitiesBroadcast ReceiversContent ProvidersInteracting directly with application components to observe their runtime behavior.This makes Drozer particularly useful for discovering insecurely exposed Android components that may not be obvious through static analysis alone.2. Runtime File-System MonitoringThe episode introduces FSmon for monitoring file-system activity in real time.Researchers can observe:Files being created or modified.Files being deleted.Changes occurring while an application executes.System-level activity associated with suspicious behavior.The collected information can then be analyzed to determine how an application interacts with the underlying operating system.3. Network MonitoringNetwork behavior is investigated using TCPDump.The general workflow is:Android Device → TCPDump → PCAP → WiresharkCapturing traffic allows analysts to investigate:Remote connections.Destination IP addresses.DNS activity.HTTP/HTTPS communications.Potential command-and-control infrastructure.Data transmitted by the application.Network analysis is particularly valuable when static analysis reveals suspicious URLs or networking functions but does not establish exactly when or why those connections occur.4. Debugging and InstrumentationThe episode also introduces several debugging approaches:GDB for remote debugging sessions.Android Studio for Java-level debugging.Anbug as an additional Android debugging tool.Debugging provides a deeper level of visibility than simple behavioral monitoring because analysts can inspect program execution and investigate what happens at specific points during runtime.5. Connecting Android and iOS AnalysisThe knowledge check reinforces that the same fundamental methodology applies across both platforms:Static Analysis → Hypothesis → Dynamic Analysis → Observation → ConfirmationFor iOS, important concepts include:UIApplicationMainThe five application lifecycle states.Method swizzling for modifying or intercepting method behavior during runtime analysis.For Android, the focus is on ADB, particularly commands used to:Install applications.Communicate with devices.Forward ports for remote analysis and debugging.Overall TakeawayThe major lesson is that static and dynamic analysis are complementary rather than competing approaches.Static analysis tells you:“What could this application do?”Dynamic analysis tells you:“What does this application actually do?”By combining component enumeration, filesystem monitoring, network capture, debugging, and static inspection, an analyst can move from an initial suspicion to a much stronger, evidence-based understanding of a mobile application's behavior. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 12: Dynamic Analysis Tools, Techniques, and Assessment

  4. 3 days ago

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 11: Dynamic Analysis for iOS and Android

    Dynamic Mobile Malware Analysis — iOS and AndroidThis episode expands dynamic malware analysis beyond basic runtime observation and introduces process instrumentation, debugging, network capture, and automated mobile-security frameworks across both iOS and Android.The central idea is:Static analysis tells you what a sample may be capable of; dynamic analysis shows what it actually does when executed.1. iOS Dynamic AnalysisThe iOS portion focuses on three major capabilities:Runtime instrumentation with CycriptLow-level debugging with LLDBNetwork monitoring with tcpdump + Wireshark2. Process Injection with CycriptCycript allows researchers to interact with a running iOS process and inspect or manipulate Objective-C objects at runtime.Conceptually:Running Application ↓ Cycript ↓ Attach / Inject ↓ Inspect Runtime Objects ↓ Modify Properties / Invoke Methods ↓ Observe Application Response For example, an analyst can investigate UI objects and modify properties while the application is running.This is useful because it allows researchers to test hypotheses without modifying the original application binary.Possible observations include:UI changesMethod executionObject propertiesRuntime stateApplication responses to manipulated conditions3. Runtime InstrumentationThe important concept is instrumentation.Instead of simply watching the application externally, the analyst gains visibility into the application's internal runtime environment.This can help answer questions such as:Which method is being called?What arguments are being passed?Which objects are created?What happens after a specific condition is satisfied?Does the application execute hidden functionality?This makes runtime instrumentation particularly useful when static analysis identifies an interesting function but its actual behavior remains unclear.4. LLDB and Remote DebuggingThe episode then introduces LLDB, a powerful debugger used for low-level inspection.In a controlled research environment, LLDB can allow an analyst to examine:RegistersMemoryInstructionsBreakpointsProgram executionFunction addressesThis provides a significantly deeper level of visibility than high-level instrumentation.5. ASLR and Address CalculationA major challenge during binary debugging is Address Space Layout Randomization (ASLR).ASLR changes where executable components are loaded into memory.Conceptually:Static Binary Address + Runtime ASLR Slide ↓ Actual Runtime Address Therefore, an analyst may need to determine the ASLR slide before translating an address observed during static analysis into the corresponding address in the running process.This is particularly important when setting breakpoints on specific functions.6. Network Monitoring with tcpdumpDynamic analysis isn't limited to the application's process.Network behavior is often one of the strongest sources of evidence.On a controlled research device, tcpdump can capture network traffic into a PCAP file.Conceptually:iOS Malware ↓ Network Activity ↓ tcpdump ↓ PCAP ↓ Wireshark ↓ Traffic Analysis Wireshark can then help identify:Destination IP addressesDNS queriesConnection patternsProtocolsHTTP trafficSuspicious infrastructureIf traffic is unencrypted, analysts may also be able to inspect transmitted content directly.7. Android Dynamic AnalysisThe Android portion focuses heavily on creating a controlled laboratory environment.The primary components are:MobSFAndroid StudioAndroid Virtual DevicesADB8. MobSF — Automated Mobile AnalysisMobile Security Framework (MobSF) provides automated analysis capabilities for mobile applications.For an APK, it can quickly identify artifacts such as:Dangerous permissionsEmbedded URLsSuspicious stringsApplication componentsSecurity weaknessesPotential indicators of compromiseThis makes MobSF useful for initial triage.However, automated findings should be treated as leads rather than definitive conclusions.A useful workflow is:APK ↓ MobSF ↓ Automated Findings ↓ Interesting Indicators ↓ Manual Static Analysis ↓ Dynamic Analysis 9. Android Virtual DevicesAndroid Studio's Android Virtual Device (AVD) system allows researchers to create isolated Android environments for testing.A malware-analysis environment should be separated from:Personal devicesProduction systemsCorporate networksSensitive accountsImportant filesThe purpose is to reduce the consequences of accidental malware execution.10. Android Debug Bridge — ADBADB is one of the most important tools in Android security research.It provides a command-line interface for communicating with an Android device or emulator.Conceptually:Analyst ↓ ADB ↓ Android Device / Emulator ↓ Application / Files / Processes ADB can be used for tasks such as:Installing APKsRemoving applicationsAccessing a shellTransferring filesCollecting logsInspecting the deviceDebugging applicationsFor example:adb devices can verify that an Android device or emulator is available.An APK can be installed in a controlled lab with:adb install sample.apk 11. Root AccessThe episode also discusses obtaining elevated privileges in an Android research environment.Root access can provide significantly greater visibility into:Application dataSystem filesProcessesRuntime informationProtected directoriesHowever, root should be treated as a research capability, not something that should automatically be enabled on production devices.12. Combining Static and Dynamic AnalysisThe most important lesson from the episode is that static and dynamic analysis complement each other.Static AnalysisAnswers:What can this application potentially do?You investigate:ManifestPermissionsStringsClassesFunctionsURLsLibrariesConfigurationDynamic AnalysisAnswers:What does the application actually do?You observe:Runtime behaviorProcess activityNetwork trafficFile modificationsAPI/function executionSystem changes13. Complete Mobile Malware WorkflowThe techniques from the entire module can be combined into one investigation pipeline: Malware Sample │ ▼ Initial Triage │ ┌────────┴────────┐ ▼ ▼ iOS Android │ │ ▼ ▼ IPA / Mach-O APK / DEX │ │ ▼ ▼ Static Analysis Static Analysis │ │ └────────┬────────┘ ▼ Behavioral Hypothesis │ ▼ Isolated Lab │ ┌────────┴────────┐ ▼ ▼ iOS Android │ │ Cycript / LLDB ADB / MobSF │ │ tcpdump / PCAP Runtime Logs │ │ └────────┬────────┘ ▼ Network Analysis │ ▼ Behavioral Evidence │ ▼ Final Assessment Key TakeawaysCycript provides runtime interaction and instrumentation capabilities on jailbroken iOS devices.LLDB enables low-level debugging and memory/instruction inspection.ASLR must be considered when translating static addresses into runtime addresses.tcpdump can capture network traffic for subsequent PCAP analysis.Wireshark helps investigate captured communications and identify suspicious infrastructure.MobSF provides valuable automated Android security triage.AVDs provide controlled Android environments for research.ADB is the fundamental command-line interface for interacting with Android devices and emulators.Root access can provide deeper visibility during controlled Android research.Dynamic analysis becomes much more powerful when guided by observations from static analysis.Golden ConceptThe strongest mobile malware investigations use a feedback loop: static analysis generates hypotheses, dynamic analysis tests those hypotheses, and the resulting runtime evidence guides the next round of static investigation. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 11: Dynamic Analysis for iOS and Android

  5. 4 days ago

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 10: The Essentials of Dynamic Analysis

    Dynamic iOS Malware Analysis — Key TakeawaysApplication Entry PointThe standard entry point for an iOS application is UIApplicationMain.It initializes the application runtime and connects the application to its App Delegate, which manages important lifecycle events.Method SwizzlingMethod swizzling allows an analyst to intercept or replace a class method at runtime.In a controlled malware-analysis environment, you can hook a method responsible for a network/environment check and alter its behavior so the application follows a different execution path.This can help determine what the malware would do if the expected condition were satisfied.LanguagesObjective-C is particularly important because iOS runtime behavior and method dispatch are heavily based on Objective-C's runtime.JavaScript is useful when working with Cycript to interact with and manipulate the running process.Overall WorkflowStatic Analysis → Identify Interesting Method → Run in Isolated/Jailbroken Lab → Attach with Cycript → Hook/Swizzle Method → Observe Behavior → Document Network/File/System ChangesThe important conceptual transition here is that static analysis tells you what the application appears capable of doing, while dynamic analysis lets you observe what it actually does at runtime. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 10: The Essentials of Dynamic Analysis

  6. 5 days ago

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 9: Mastering Basic Static Analysis for Mobile Malware

    Mobile Malware Static Analysis — Module ConclusionThis episode serves as a knowledge check and consolidation of the basic static-analysis methodology covered across both iOS and Android. The emphasis is not on learning one particular tool, but on developing a repeatable investigation process.1. iOS Static AnalysisSeveral important tools and artifacts are reinforced.class-dumpUsed primarily to extract and inspect Objective-C class information from compiled iOS binaries.It can help reveal:ClassesMethodsInterfacesApplication structureThis gives the analyst an initial picture of how an application is organized.otoolA versatile Mach-O inspection utility.For example:otool -L application can display the application's linked dynamic libraries.Other otool options can provide additional information about the Mach-O binary, making it an important first-stage reverse-engineering tool.2. Finding the iOS ExecutableThe Info.plist contains important application metadata.One useful investigation task is determining the executable associated with the application.Conceptually:IPA ↓ Payload/ ↓ Application.app/ ↓ Info.plist ↓ CFBundleExecutable ↓ Executable Name The CFBundleExecutable value identifies the main executable associated with the application bundle.3. Android Static AnalysisOn Android, the equivalent early-stage artifact is the AndroidManifest.xml.apktool is commonly used to decode an APK so that its manifest and resources can be examined.For example:apktool d application.apk -o decoded_app The resulting manifest can reveal:ActivitiesServicesBroadcast receiversContent providersPermissionsIntent filters4. Intent FiltersA particularly important Android concept is the intent-filter.Intent filters describe the types of intents that an Android component can respond to.For example, a receiver may declare an intent associated with a particular system event.This makes intent filters useful during malware analysis because they help answer:What events is this application designed to react to?For example:Intent ↓ Matching Intent Filter ↓ Android Component ↓ Application Logic This is especially important when investigating applications that react automatically to events such as incoming messages, boot events, connectivity changes, or other system broadcasts.5. The Structured Malware-Analysis MethodologyOne of the most important lessons from the entire module is that malware analysis should follow a structured methodology rather than randomly examining files and tools.A strong workflow is:1. Define the objective ↓ 2. Preserve the sample ↓ 3. Calculate hashes ↓ 4. Search online intelligence resources ↓ 5. Identify platform and file type ↓ 6. Examine metadata ↓ 7. Analyze permissions / capabilities ↓ 8. Inspect code and binaries ↓ 9. Identify suspicious artifacts ↓ 10. Build a behavioral hypothesis ↓ 11. Validate through deeper analysis Why define the objective first?Without a specific objective, malware analysis can become extremely inefficient.For example, different questions require different investigations:What does this application do?Does it communicate with a C2 server?Does it steal SMS messages?What persistence mechanism does it use?What information does it collect?The objective determines which artifacts deserve priority.6. Hashing as an Early Triage TechniqueHashing provides a convenient way to identify a malware sample.Common hashes include:md5sum sample.apk sha256sum sample.apk The hash can then be searched in authorized threat-intelligence databases.This can potentially reveal:Previous detectionsMalware family classificationsExisting researchKnown indicatorsPrevious submissionsHowever:No detection does not equal no malware.A previously unseen sample may have no reputation whatsoever.7. Using Online ResourcesOnline intelligence sources can significantly accelerate analysis.Instead of spending hours investigating an artifact that has already been studied, researchers can search existing intelligence for:File hashesDomainsIP addressesURLsMalware familiesKnown samplesDecompiled artifactsThe important skill is knowing when to leverage existing intelligence and when to perform your own analysis.8. iOS vs. Android — Quick ComparisonAreaiOSAndroidApplication packageIPAAPKMain metadataInfo.plistAndroidManifest.xmlExecutableMach-ODEX/native librariesKey toolotoolapktoolClass inspectionclass-dumpDEX decompilersComponent analysisApp metadata/runtimeActivities, Services, Receivers, ProvidersEvent handlingiOS frameworksIntent / Intent FilterPrimary static-analysis goalUnderstand binary structureUnderstand package structure and application logic9. The Bigger PictureThe module has essentially established a complete basic static-analysis foundation for both mobile platforms.iOSIPA ↓ Info.plist ↓ Executable ↓ Mach-O Analysis ↓ class-dump / otool ↓ Strings / Symbols / Libraries ↓ Behavioral Hypothesis AndroidAPK ↓ AndroidManifest.xml ↓ Permissions / Components ↓ Intent Filters ↓ DEX ↓ Decompilation ↓ Application Logic ↓ Behavioral Hypothesis The two platforms use different technologies, but the investigative mindset remains the same.Key Takeawaysclass-dump → useful for examining Objective-C class information in iOS binaries.otool → useful for inspecting Mach-O binaries and linked libraries.Info.plist → contains important iOS application metadata, including the executable name.apktool → decodes Android APK resources and manifests for analysis.AndroidManifest.xml → reveals permissions and application components.intent-filter → identifies the types of intents to which Android components can respond.Hashing → provides an efficient method for sample identification and threat-intelligence searches.Online intelligence → can accelerate investigations by providing existing knowledge about samples and indicators.Clearly defined objectives → keep malware investigations focused and efficient.Golden ConceptGood malware analysis is not simply knowing how to use forensic and reverse-engineering tools. It is knowing what question you are trying to answer, which evidence can answer it, and how to systematically connect that evidence into a defensible behavioral hypothesis. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 9: Mastering Basic Static Analysis for Mobile Malware

  7. 6 days ago

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 8: Static Analysis of Android Banking Trojans

    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 typeFile sizeCryptographic hashesExisting antivirus detectionsKnown threat intelligenceFor 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 componentsActivitiesServicesBroadcast receiversContent providersIntent filtersRequested permissionsExported components4. Permission AnalysisPermissions can provide an early indication of an application's intended capabilities.In this lab, the APK requests permissions associated with:Reading SMSWriting SMSReceiving/intercepting SMSInstalling packagesRemoving packagesThis 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 codesBanking notificationsAccount alertsPassword-reset messagesTwo-factor authentication codesThe 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 informationTelephone informationDevice characteristicsThis 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 occursWhat data is transmittedWhat responses are receivedWhether SMS information is exfiltratedWhether additional commands or configuration are retrieved11. 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 TakeawaysAPK 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

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 8: Static Analysis of Android Banking Trojans

  8. 3 Sept

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 7: Malware Tools and Practical Lab Walkthrough

    iOS Basic Static Analysis — Advanced Study GuideThis episode moves from the fundamentals of iOS malware analysis into hands-on static binary analysis, demonstrating how command-line utilities and reverse-engineering tools can reveal valuable information without executing the malware.1. otool — Inspecting Mach-O Binariesotool is one of the most useful command-line utilities for examining Apple Mach-O binaries.A particularly important option is:otool -L application This displays the dynamic libraries linked by the executable.Analyzing these libraries can provide early clues about the application's functionality and dependencies.For example, an analyst may investigate whether an application relies on libraries associated with:NetworkingCryptographyUser interfacesSystem servicesOther potentially interesting functionality2. nm — Examining SymbolsThe nm utility displays symbols contained within a binary.This can help analysts identify:FunctionsGlobal symbolsExternal referencesPotentially interesting APIsSearching symbols for security-sensitive functions can provide useful leads for further investigation.The important principle is:Symbols don't prove malicious behavior, but they can help identify where to investigate.3. Identifying Objective-C vs. SwiftThe language used to develop an iOS application can sometimes be inferred from characteristics of its compiled binary.Objective-CObjective-C applications commonly expose recognizable:Class namesMethod namesObjective-C runtime metadataSelector informationSwiftSwift uses name mangling, meaning function and symbol names may appear in encoded or transformed forms.Older Swift binaries can contain recognizable mangling patterns such as _T.However, analysts should avoid relying on a single indicator because modern binaries can contain a mixture of:SwiftObjective-CC/C++Third-party frameworks4. Class DumpingClass-dumping tools can help reconstruct information about Objective-C classes from compiled binaries.Conceptually:Mach-O Binary ↓ Objective-C Metadata ↓ Classes / Methods ↓ Potential Application Logic This can give an analyst an initial understanding of the application's internal architecture without immediately performing full reverse engineering.5. Disassembly and Reverse EngineeringFor deeper analysis, tools such as Hopper and IDA Pro can be used to examine the binary at the assembly level.A typical workflow is:IPA ↓ Mach-O Executable ↓ Disassembly ↓ Functions ↓ Control-Flow Analysis ↓ Decompilation ↓ Behavioral Understanding These tools can help researchers:Locate functionsSearch stringsFollow cross-referencesVisualize control flowExamine assembly instructionsGenerate higher-level pseudocodeThe goal isn't simply to read assembly—it is to reconstruct the program's logic.6. Initial Malware TriageBefore performing extensive analysis, the episode demonstrates basic malware triage.A useful first step is generating a cryptographic hash of the sample.For example:md5 malware.ipa The resulting hash can be used as a sample identifier when checking authorized malware-intelligence resources.The general workflow is:Sample ↓ Hash ↓ Threat Intelligence Lookup ↓ Existing Detections / Reputation ↓ Initial Context A hash lookup can provide useful context, but a lack of detections does not mean that the file is safe.7. Extracting the IPAAn IPA can be extracted to expose its internal application structure.Conceptually:malware.ipa ↓ Payload/ ↓ malware.app/ ├── executable ├── Info.plist ├── Frameworks/ └── Resources/ The executable and Info.plist are particularly valuable during initial triage.8. Analyzing Info.plistThe episode uses plutil to inspect the application's property-list information.For example:plutil -p Info.plist The analyst can use this information to investigate:Bundle identifierApplication metadataExecutable nameApplication configurationSupported capabilitiesPotentially suspicious settings9. Hidden Application BehaviorOne particularly interesting discovery in the lab is the discrepancy between the executable's internal identity and how the application presents itself to the user.The executable is associated with "no icon", while the application presents itself as "passbook" and contains configuration indicating a hidden icon.This type of inconsistency is valuable during malware triage because it raises questions about the application's intended behavior.An analyst should ask:Why is the application attempting to hide?Why does its internal naming differ from its apparent identity?What functionality is being concealed?Does the application attempt to maintain persistence?What happens when it executes?These questions form the basis of the behavioral hypothesis.10. String AnalysisExtracting strings from a binary is another useful early-stage technique.Conceptually:Binary ↓ Strings ↓ URLs IPs File Paths Commands Configuration Identifiers ↓ Behavioral Hypothesis Strings can reveal:DomainsURLsIP addressesFile pathsError messagesConfiguration valuesAPI endpointsDebug informationHowever, strings must be treated carefully because they can be:ObfuscatedEncodedUnusedDynamically constructedTherefore, discovering a suspicious domain is an indicator, not automatically proof of malicious communication.11. HTTP Artifact DiscoveryThe episode searches the binary for HTTP-related artifacts and discovers numerous suspicious domains.This provides an important investigative lead.For example:Application │ ├── Domain A ├── Domain B ├── Domain C └── Domain D The analyst can then investigate how those domains are referenced by the application.Possible hypotheses include:Downloading additional componentsCommand-and-control communicationRetrieving configurationSending collected informationConnecting to remote servicesThe next step would be determining which functions reference those strings.12. From Indicators to HypothesesThe episode emphasizes an important malware-analysis principle:Static artifacts should be used to construct hypotheses rather than immediately declaring conclusions.For example:Hidden Application + Suspicious Domains + HTTP References + Interesting Functions ↓ Potential Network-Based Malware ↓ Dynamic Analysis Required Static analysis might suggest that an application communicates with external infrastructure, but dynamic analysis can help establish whether those connections actually occur.13. Recommended Investigation FlowThe techniques from this episode fit into a broader iOS malware-analysis workflow:1. Preserve Sample ↓ 2. Calculate Hash ↓ 3. Threat Intelligence Lookup ↓ 4. Extract IPA ↓ 5. Analyze Info.plist ↓ 6. Identify Executable ↓ 7. Determine Language / Architecture ↓ 8. Inspect Linked Libraries ↓ 9. Examine Symbols ↓ 10. Extract Strings ↓ 11. Identify URLs / Domains / IPs ↓ 12. Disassemble Interesting Functions ↓ 13. Build Behavioral Hypothesis ↓ 14. Perform Controlled Dynamic Analysis Key Takeawaysotool is valuable for inspecting Mach-O binaries and linked libraries.nm provides insight into available symbols and function references.Objective-C and Swift can often be distinguished through binary metadata and naming conventions.Hopper and IDA Pro provide deeper disassembly and reverse-engineering capabilities.Hashing is an important first step in malware triage and sample identification.Info.plist can expose important application metadata and suspicious configuration.String analysis can reveal domains, URLs, paths, and other behavioral indicators.Suspicious network artifacts can help formulate hypotheses about C2 or remote-resource activity.Static analysis should establish hypotheses that can later be validated through controlled dynamic analysis.Golden ConceptThe objective of basic static analysis isn't to completely understand the malware immediately. It is to rapidly collect enough reliable evidence to build a behavioral hypothesis and determine where deeper reverse engineering should focus. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy

    Course 42 - Mobile Malware Analysis Fundamentals | Episode 7: Malware Tools and Practical Lab Walkthrough
See All (355)

About

Welcome to CyberCode Academy — your audio classroom for Programming and Cybersecurity. 🎧 Each course is divided into a series of short, focused episodes that take you from beginner to advanced level — one lesson at a time. From Python and web development to ethical hacking and digital defense, our content transforms complex concepts into simple, engaging audio learning. Study anywhere, anytime — and level up your skills with CyberCode Academy. 🚀 Learn. Code. Secure. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cybercode_academy

Information

  • Creator
    CyberCode Academy
  • Years Active
    2025 - 2026
  • Episodes
    355
  • Rating
    Clean
  • Copyright
    © Copyright CyberCode Academy
  • Show Website
    CyberCode Academy

You Might Also Like