CyberCode Academy

CyberCode Academy

By CyberCode AcademyTechnologyEducationCourses
Download on the App Store

CyberCode Academy episodes

  • 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:
    1. Runtime instrumentation with Cycript
    2. Low-level debugging with LLDB
    3. Network monitoring with tcpdump + Wireshark
    2. 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 changes
    • Method execution
    • Object properties
    • Runtime state
    • Application responses to manipulated conditions
    3. 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:
    • Registers
    • Memory
    • Instructions
    • Breakpoints
    • Program execution
    • Function addresses
    This 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 addresses
    • DNS queries
    • Connection patterns
    • Protocols
    • HTTP traffic
    • Suspicious infrastructure
    If 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:
    • MobSF
    • Android Studio
    • Android Virtual Devices
    • ADB
    8. 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 permissions
    • Embedded URLs
    • Suspicious strings
    • Application components
    • Security weaknesses
    • Potential indicators of compromise
    This 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 devices
    • Production systems
    • Corporate networks
    • Sensitive accounts
    • Important files
    The 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 APKs
    • Removing applications
    • Accessing a shell
    • Transferring files
    • Collecting logs
    • Inspecting the device
    • Debugging applications
    For 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 data
    • System files
    • Processes
    • Runtime information
    • Protected directories
    However, 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:
    • Manifest
    • Permissions
    • Strings
    • Classes
    • Functions
    • URLs
    • Libraries
    • Configuration
    Dynamic AnalysisAnswers:What does the application actually do?You observe:
    • Runtime behavior
    • Process activity
    • Network traffic
    • File modifications
    • API/function execution
    • System changes
    13. 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 Takeaways
    • Cycript 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

    Get the books of the CyberCode Academy podcast:
    📚 The book series: 416 lessons, 12 books, hundreds of original diagrams: security, networking and programming.
    https://cybercodeacademy.gumroad.com/
    25 min
  • Course 42 - Mobile Malware Analysis Fundamentals | Episode 10: The Essentials of Dynamic Analysis
    Dynamic iOS Malware Analysis — Key Takeaways
    1. Application Entry Point
      • The 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.
    2. Method Swizzling
      • Method 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.
    3. Languages
      • Objective-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

    Get the books of the CyberCode Academy podcast:
    📚 The book series: 416 lessons, 12 books, hundreds of original diagrams: security, networking and programming.
    https://cybercodeacademy.gumroad.com/
    24 min
  • 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:
    • Classes
    • Methods
    • Interfaces
    • Application structure
    This 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:
    • Activities
    • Services
    • Broadcast receivers
    • Content providers
    • Permissions
    • Intent filters
    4. 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 detections
    • Malware family classifications
    • Existing research
    • Known indicators
    • Previous submissions
    However: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 hashes
    • Domains
    • IP addresses
    • URLs
    • Malware families
    • Known samples
    • Decompiled artifacts
    The 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 Takeaways
    • class-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

    Get the books of the CyberCode Academy podcast:
    📚 The book series: 416 lessons, 12 books, hundreds of original diagrams: security, networking and programming.
    https://cybercodeacademy.gumroad.com/
    22 min
  • 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 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

    Get the books of the CyberCode Academy podcast:
    📚 The book series: 416 lessons, 12 books, hundreds of original diagrams: security, networking and programming.
    https://cybercodeacademy.gumroad.com/
    22 min
  • 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:
    • Networking
    • Cryptography
    • User interfaces
    • System services
    • Other potentially interesting functionality
    2. nm — Examining SymbolsThe nm utility displays symbols contained within a binary.This can help analysts identify:
    • Functions
    • Global symbols
    • External references
    • Potentially interesting APIs
    Searching 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 names
    • Method names
    • Objective-C runtime metadata
    • Selector information
    SwiftSwift 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:
    • Swift
    • Objective-C
    • C/C++
    • Third-party frameworks
    4. 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 functions
    • Search strings
    • Follow cross-references
    • Visualize control flow
    • Examine assembly instructions
    • Generate higher-level pseudocode
    The 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 identifier
    • Application metadata
    • Executable name
    • Application configuration
    • Supported capabilities
    • Potentially suspicious settings
    9. 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:
    • Domains
    • URLs
    • IP addresses
    • File paths
    • Error messages
    • Configuration values
    • API endpoints
    • Debug information
    However, strings must be treated carefully because they can be:
    • Obfuscated
    • Encoded
    • Unused
    • Dynamically constructed
    Therefore, 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 components
    • Command-and-control communication
    • Retrieving configuration
    • Sending collected information
    • Connecting to remote services
    The 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 Takeaways
    • otool 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

    Get the books of the CyberCode Academy podcast:
    📚 The book series: 416 lessons, 12 books, hundreds of original diagrams: security, networking and programming.
    https://cybercodeacademy.gumroad.com/
    22 min
  • Course 42 - Mobile Malware Analysis Fundamentals | Episode 6: The Evolution and Methodology of iOS Malware Attacks
    iOS Malware Analysis — Key TakeawaysThis episode introduces the fundamentals of iOS malware analysis, combining the historical evolution of mobile threats with the methodology used by security researchers to investigate them.1. Understanding Mobile MalwareMobile malware is malicious software designed to disrupt devices, steal information, gain unauthorized access, or perform malicious actions. Common categories include:
    • Ransomware
    • Banking Trojans
    • SMS-based malware
    • Spyware
    • Backdoors
    2. Evolution of iOS MalwareThe episode examines major milestones in the history of iOS threats:
    • Ikee (2009): An early worm targeting jailbroken iPhones, demonstrating how removing Apple's security restrictions could increase exposure.
    • XcodeGhost (2015): A major supply-chain attack in which malicious versions of Apple's development environment were used to inject malicious code into otherwise legitimate applications.
    The broader lesson is that attackers do not necessarily need to compromise iOS directly; they can target developers, applications, distribution mechanisms, or users.3. Major iOS Attack VectorsiOS malware can reach victims through several mechanisms:
    • Social engineering: Tricking users into installing or executing malicious software.
    • Software vulnerabilities: Exploiting weaknesses in iOS or applications.
    • Enterprise certificates: Abusing legitimate enterprise distribution mechanisms.
    • Repackaged applications: Taking legitimate applications, inserting malicious code, and redistributing them.
    This demonstrates an important security principle: the security of the operating system is only one part of the overall attack surface.4. Malware Analysis MethodologyMalware analysis is presented as both a structured technical process and an investigative discipline.A researcher should first establish:
    1. What do I want to determine?
    2. What evidence do I need?
    3. What analysis techniques should I use?
    4. How can I perform the investigation safely?
    Safety is especially important when dealing with unknown malware. Analysis should take place inside isolated environments, with appropriate precautions for potentially malicious files.5. Static AnalysisThe episode introduces static analysis as an initial step before executing malware.The objective is to examine the application without running it and identify useful artifacts such as:
    • URLs
    • IP addresses
    • C2 infrastructure
    • File paths
    • Embedded strings
    • Configuration information
    • Suspicious code or components
    These artifacts help the analyst construct an initial hypothesis about the malware's behavior.Core TakeawayThe central idea is that iOS malware analysis starts with understanding the ecosystem and attack surface, then progresses toward evidence-driven investigation.The typical progression is:Malware discovery → Safe preservation → Static analysis → Artifact identification → Behavioral hypothesis → Dynamic analysisUnderstanding historical threats such as Ikee and XcodeGhost also demonstrates how attackers continually adapt when operating-system security mechanisms become stronger.

    You can listen and download our episodes for free on more than 10 different platforms:
    https://linktr.ee/cybercode_academy

    Get the books of the CyberCode Academy podcast:
    📚 The book series: 416 lessons, 12 books, hundreds of original diagrams: security, networking and programming.
    https://cybercodeacademy.gumroad.com/
    23 min
  • Course 42 - Mobile Malware Analysis Fundamentals | Episode 5: Fundamentals, App Structure, and Knowledge Review
    Android Security & APK Architecture — Advanced Study Template1. Android Security ModelAndroid security is built around several fundamental objectives:

    - Protecting user and application data
    - Isolating applications from one another
    - Controlling privileges
    - Providing secure inter-process communication
    - Restricting unauthorized access to system resources
    The architecture combines traditional Linux security mechanisms with Android-specific controls.2. Linux FoundationAndroid is built on the Linux kernel, which provides fundamental capabilities such as:

    - Process management
    - Memory management
    - Networking
    - Device drivers
    - Filesystem access
    - User and group permissions
    Android builds additional security mechanisms on top of these Linux primitives.3. Android Application SandboxOne of Android's most important security mechanisms is the application sandbox.Applications normally execute under distinct Linux identities, which limits their ability to interact with other applications.Conceptually:Android System │ ┌────┼────┐ │ │ │ App A App B App C │ │ │ UID A UID B UID C │ │ │ Sandbox Sandbox Sandbox This isolation helps prevent a compromised application from automatically accessing another application's private data.Security principleCompromise of one application should not automatically imply compromise of every application on the device.4. SELinuxAndroid also uses SELinux (Security-Enhanced Linux) to provide Mandatory Access Control (MAC).This adds another layer beyond traditional Linux discretionary permissions.Conceptually:Application Request ↓ Linux Permissions ↓ SELinux Policy ↓ Allow / Deny Even if a process has certain Linux-level permissions, SELinux policies can impose additional restrictions on what that process is allowed to do.5. Android Application Package — APKAndroid applications are distributed primarily as APK files.An APK is an archive containing the application's:

    - Compiled code
    - Resources
    - Manifest
    - Assets
    - Configuration
    - Supporting components
    A simplified structure looks like:Application.apk │ ├── AndroidManifest.xml ├── classes.dex ├── resources.arsc ├── res/ ├── assets/ ├── lib/ └── META-INF/ For malware analysts, understanding this structure is fundamental.6. AndroidManifest.xmlThe Android Manifest is one of the most important files during APK analysis.It can contain information about:

    - Package identity
    - Application components
    - Permissions
    - Services
    - Activities
    - Broadcast receivers
    - Content providers
    - Intent filters
    - Application configuration
    Malware-analysis perspectiveThe manifest is often an excellent first point of investigation.For example, suspicious permissions or unexpected exported components can provide early indicators worth investigating further.7. ActivitiesAn Activity generally represents a user-facing application component.Examples include:

    - Login screens
    - Settings screens
    - Main application interfaces
    - Forms
    Activities define how users interact with the application.Security relevanceAn analyst may examine:

    - Exported activities
    - Intent filters
    - Deep links
    - Input handling
    - Inter-component communication
    8. ServicesServices perform operations that may continue without a conventional foreground UI.They can be used for tasks such as:

    - Background processing
    - Network operations
    - Synchronization
    - Long-running application tasks
    Malware relevanceMalware may attempt to use background components to maintain functionality while minimizing visible user interaction.9. IntentsIntents are messaging objects used to request actions or communicate between Android components.They can facilitate communication between:

    - Activities
    - Services
    - Broadcast receivers
    - Other applications
    Conceptually:Component A │ │ Intent ▼ Component B Security relevancePoorly protected component interfaces can sometimes create security issues involving unauthorized interaction or data exposure.10. Broadcast ReceiversBroadcast Receivers respond to broadcast messages generated by the system or applications.They can be used to react to events such as:

    - System state changes
    - Application events
    - Connectivity-related events
    - Other broadcasts
    From a malware-analysis perspective, receivers can be interesting because they may reveal how an application responds to specific system events.11. DEX FilesAndroid applications contain compiled bytecode in DEX (Dalvik Executable) format.The primary file is commonly:classes.dex Additional DEX files may appear when an application contains enough code to require multiple files.The code is executed through Android's runtime environment.12. Dalvik vs. ARTHistorically, Android applications ran using the Dalvik Virtual Machine (DVM).Modern Android uses the Android Runtime (ART).Older Android ↓ Dalvik ↓ classes.dex Modern Android ↓ ART ↓ classes.dex Understanding this distinction is important when studying older Android malware samples versus modern applications.13. Content ProvidersContent Providers provide a standardized mechanism for managing and sharing structured data between applications and system components.Conceptually:Application A │ ▼ Content Provider │ ▼ Protected Data │ ▼ Application B Access is controlled through Android's permission and component security mechanisms.Security relevanceContent Providers can become important during security analysis because improperly exposed providers may unintentionally reveal sensitive information.14. Binder IPCBinder is one of the fundamental communication mechanisms in Android.It provides high-performance Inter-Process Communication (IPC) between processes.Conceptually:Process A │ │ Binder IPC ▼ Android System Service │ ▼ Process B Binder is heavily integrated into Android's architecture and is used by applications and system services to communicate.Why it mattersWithout a secure and efficient IPC mechanism, Android's application isolation model would be considerably more difficult to implement.15. APK Static Analysis WorkflowA basic APK investigation can begin by extracting the archive.For example:unzip application.apk -d application/ You can then examine the resulting structure:application/ ├── AndroidManifest.xml ├── classes.dex ├── resources.arsc ├── res/ ├── assets/ └── lib/ The analyst can then investigate the individual components.Typical initial workflowAPK ↓ Extract ↓ Manifest Analysis ↓ Identify Components ↓ Inspect Permissions ↓ Analyze DEX ↓ Inspect Resources ↓ Continue with Static/Dynamic Analysis 🔓 16. Android RootingRooting refers to obtaining elevated or superuser-level privileges on an Android device.Depending on the technique, this may involve exploiting vulnerabilities or modifying the software environment.Conceptually:Normal Application ↓ Restricted Privileges ↓ Android Security Boundaries X Rooted Research Device ↓ Elevated Privileges ↓ Expanded System Visibility 17. Why Root Access Matters for Malware AnalysisA controlled rooted research device can provide researchers with greater visibility into:

    - Application data
    - Filesystem contents
    - Running processes
    - System services
    - Runtime behavior
    - Network activity
    - Protected application directories
    This makes rooting particularly useful for dynamic malware analysis.However, rooting also reduces some of the protections normally provided by Android, so it should be performed only in an isolated research environment.18. Android Security ArchitectureThe major security mechanisms can be viewed together: Android │ ┌───────┴────────┐ │ │ Linux Android Kernel Security │ │ Permissions Sandbox │ │ └───────┬────────┘ │ SELinux │ ▼ Application Isolation │ ▼ Secure IPC / Binder 19. iOS vs. AndroidSecurity ConceptiOSAndroidApplication isolationSandboxSandboxLow-level foundationXNU / DarwinLinuxMandatory access controlsMultiple platform mechanismsSELinuxApplication packageIPAAPKRuntimeNative / platform runtimesARTIPCPlatform-specific mechanismsBinderPrivilege modificationJailbreakingRootingApplication codeNative binariesDEX + native codeSecurity researchOften requires jailbreakOften benefits from root20. Key Malware-Analysis ArtifactsWhen analyzing an Android APK, pay particular attention to:AndroidManifest.xmlLook for:

    - Permissions
    - Exported components
    - Services
    - Receivers
    - Providers
    - Intent filters
    classes.dexLook for:

    - Application logic
    - Suspicious APIs
    - Network functionality
    - Credential handling
    - Obfuscation
    - Embedded URLs or domains
    res/May contain:

    - UI resources
    - XML configuration
    - Images
    - Other application resources
    assets/May contain:

    - Configuration files
    - Embedded data
    - Scripts
    - Additional resources
    lib/May contain native libraries such as:.so These can require separate native-code analysis.🎯 Key Takeaways

    - Android is fundamentally built on the Linux kernel.

    You can listen and download our episodes for free on more than 10 different platforms:
    https://linktr.ee/cybercode_academy

    Get the books of the CyberCode Academy podcast:
    📚 The book series: 416 lessons, 12 books, hundreds of original diagrams: security, networking and programming.
    https://cybercodeacademy.gumroad.com/
    26 min
  • Course 42 - Mobile Malware Analysis Fundamentals | Episode 4: iOS Security and Android Frameworks
    A comprehensive technical exploration of the foundational architectures and security models of iOS and Android, providing the essential knowledge required for mobile security analysis and malware research.The journey begins with iOS security, examining its three major pillars: system security, data security, and application security. You will learn how iOS applications operate within the Cocoa Touch layer and how the sandbox model isolates applications to protect system resources and user data. The episode also explores jailbreaking, including tethered, semi-untethered, and untethered approaches, and explains how vulnerabilities in hardware, the boot chain, or the kernel can be leveraged to bypass Apple’s security restrictions.The focus then shifts to Android, tracing its evolution from its early development in Palo Alto through its acquisition by Google and the creation of the Open Handset Alliance. The episode breaks down Android's architecture from both a system and platform perspective.On the system architecture side, we examine the interaction between the Linux Kernel, Hardware Abstraction Layer (HAL), and Binder IPC, which enables efficient communication between Android processes and system components.On the platform architecture side, the episode explores the Android Runtime (ART) and its predecessor, the Dalvik Virtual Machine (DVM), which provide the execution environment for applications. We also examine the Java API Framework, which exposes essential system services and APIs that developers use to build Android applications.By the end of this episode, you will have a solid understanding of how iOS and Android implement isolation, privilege boundaries, application execution, and hardware interaction—providing a strong foundation for deeper mobile application security and malware analysis.

    You can listen and download our episodes for free on more than 10 different platforms:
    https://linktr.ee/cybercode_academy

    Get the books of the CyberCode Academy podcast:
    📚 The book series: 416 lessons, 12 books, hundreds of original diagrams: security, networking and programming.
    https://cybercodeacademy.gumroad.com/
    22 min
  • Course 42 - Mobile Malware Analysis Fundamentals | Episode 3: iOS Application Architecture and Jailbreaking Fundamentals
    iOS Application Architecture & Jailbreaking — Advanced Study Template1. iOS Application ArchitectureiOS applications are primarily developed using:
    • Swift
    • Objective-C
    • Xcode as the main development environment
    After compilation, an application is packaged into an IPA (iOS App Store Package).An IPA is essentially an archive containing the components required to install and execute the application.2. Anatomy of an IPAA typical IPA contains a structure similar to:Application.ipa │ └── Payload/ │ └── Application.app/ ├── Application ├── Info.plist ├── Frameworks/ ├── PlugIns/ ├── Resources └── Other application files Payload DirectoryThe Payload directory is particularly important during static analysis.It contains the application's .app bundle.Inside the bundle, analysts can locate:
    • Application executable
    • Info.plist
    • Frameworks
    • Resources
    • Embedded components
    • Configuration files
    3. Info.plistThe Info.plist file contains important application metadata and configuration information.Depending on the application, it may reveal things such as:
    • Bundle identifier
    • Application version
    • Display name
    • Supported platforms
    • Required capabilities
    • URL schemes
    • Permissions-related configuration
    Security relevanceDuring static analysis, Info.plist is often one of the first files worth examining because it can provide a quick overview of how the application is configured.4. Application BinaryThe .app bundle normally contains the application's executable binary.For example:Payload/ └── Example.app/ ├── Example ├── Info.plist └── ... The binary contains the compiled application logic.Static AnalysisA basic static-analysis workflow can therefore begin with:IPA ↓ Extract Archive ↓ Open Payload/ ↓ Identify .app Bundle ↓ Inspect Info.plist ↓ Identify Executable ↓ Analyze Binary 🔐 5. The iOS SandboxOne of the most important security mechanisms in iOS is application sandboxing.Each application operates within a restricted environment rather than having unrestricted access to the operating system.Conceptually: iOS │ ┌────────┴────────┐ │ │ App A App B │ │ Sandbox Sandbox │ │ Private Data Private Data The sandbox limits an application's ability to:
    • Access other applications' private data
    • Modify protected system files
    • Interact directly with restricted system resources
    • Escape its designated environment
    6. Application ContainersAn application generally has separate areas for different types of data.Conceptually:Application BundleContains the application itself:
    • Executable
    • Resources
    • Configuration
    Data ContainerContains application-generated data such as:
    • Databases
    • User preferences
    • Cached information
    • Application files
    Temporary StorageUsed for temporary data that does not need permanent storage.🧪 7. Static Analysis of an IPAA basic analysis begins by extracting the IPA.Conceptually:Application.ipa ↓ Extract ↓ Payload/ ↓ Application.app/ ↓ ┌───────────────┐ │ Info.plist │ │ Executable │ │ Frameworks │ │ Resources │ └───────────────┘ The objective at this stage is to understand:
    • What the application contains
    • What executable it uses
    • What configuration it declares
    • What frameworks and resources are bundled
    🔓 8. What Is Jailbreaking?Jailbreaking is the process of circumventing Apple's software restrictions to obtain greater control over an iOS device.A jailbroken device may allow researchers to:
    • Execute software outside normal restrictions
    • Access normally protected areas of the filesystem
    • Perform deeper application analysis
    • Instrument applications
    • Inject code or scripts
    • Access additional debugging capabilities
    Security perspectiveNormal iOS:Application ↓ Sandbox ↓ Restricted APIs ↓ Protected OS Jailbroken research environment:Research Tool ↓ Elevated Access ↓ System Components ↓ Filesystem / Processes 9. How Jailbreaks WorkJailbreak techniques depend on vulnerabilities in different layers of the platform.Potential targets include:
    • Boot ROM
    • Bootloader
    • Kernel
    • Other privileged system components
    The basic concept is:Vulnerability ↓ Security Boundary Bypass ↓ Code Execution / Privilege Escalation ↓ Expanded System Access Apple continuously patches vulnerabilities used by jailbreaks, so jailbreak compatibility is highly dependent on the specific device and iOS version.10. Types of JailbreaksTethered JailbreakA tethered jailbreak generally requires assistance from another computer after the device reboots.Without the required boot process, the device may not boot normally.Semi-Untethered JailbreakThe device can generally boot normally, but the jailbreak functionality must be reactivated after certain reboots.Untethered JailbreakThe jailbreak remains active across reboots without requiring external assistance.This is historically the most persistent form.11. Jailbreaking for Security ResearchFor mobile malware researchers, jailbreaking can provide capabilities unavailable on a standard device.It can make it possible to:Inspect protected filesystem areas/ ├── System ├── Applications ├── Library ├── Private data └── Other protected areas Inspect processesResearchers can investigate:
    • Running processes
    • Process relationships
    • Loaded components
    • Application behavior
    Instrument applicationsResearchers can use instrumentation techniques to observe or modify application behavior during execution.12. Cydia and Research ToolingHistorically, Cydia has been an important package-management environment within the jailbroken iOS ecosystem.It can provide access to packages and research utilities that are unavailable on a standard device.In the demonstrated environment, Cydia is used as part of establishing a research-oriented jailbroken setup.13. SSH AccessOnce an appropriate research environment is established, SSH can provide remote command-line access to the device.Conceptually:Analysis Computer │ │ SSH ▼ Jailbroken iOS Device │ ▼ Elevated Shell │ ▼ Filesystem / Processes This is particularly useful for security researchers because it allows them to perform analysis without relying exclusively on the normal iOS user interface.14. Why Jailbreaking Matters to Malware AnalysisWithout elevated access, researchers may encounter significant visibility limitations.A normal device enforces:
    • Sandboxing
    • Code-signing restrictions
    • Filesystem protections
    • Process isolation
    • Restricted system APIs
    A controlled jailbroken research device can provide considerably greater visibility.This enables techniques such as:
    • Runtime inspection
    • Filesystem examination
    • Process monitoring
    • Script injection
    • Application instrumentation
    • Deeper malware behavior analysis
    🔬 15. Static vs. Dynamic AnalysisThis episode establishes an important distinction.Static AnalysisDynamic AnalysisExamine IPA without executing itObserve application while runningInspect Info.plistMonitor runtime behaviorExamine executableInspect processesAnalyze frameworksObserve network activitySearch embedded resourcesInstrument applicationReverse engineer binaryMonitor filesystem changesA strong mobile malware investigation generally benefits from both approaches.🎯 Key Takeaways
    • iOS applications are commonly developed using Swift or Objective-C.
    • Applications are distributed in IPA packages.
    • The Payload directory contains the application bundle.
    • Info.plist provides valuable application metadata.
    • The application's executable contains its compiled logic.
    • Sandboxing isolates applications from protected system resources and other applications.
    • Jailbreaking removes or bypasses some of Apple's normal restrictions.
    • Jailbreaks may exploit vulnerabilities in the Boot ROM, bootloader, or kernel.
    • Different jailbreak types provide different levels of persistence.
    • A controlled jailbroken device can significantly improve visibility during mobile security research.
    • SSH can provide a useful command-line interface for authorized analysis.
    • Static + dynamic analysis provides a much more complete picture of an application's behavior.
    Golden ConceptIPA analysis tells you what an iOS application contains; a controlled jailbroken environment allows you to investigate what that application actually does at runtime.

    You can listen and download our episodes for free on more than 10 different platforms:
    https://linktr.ee/cybercode_academy

    Get the books of the CyberCode Academy podcast:
    📚 The book series: 416 lessons, 12 books, hundreds of original diagrams: security, networking and programming.
    https://cybercodeacademy.gumroad.com/
    16 min
  • Course 42 - Mobile Malware Analysis Fundamentals | Episode 2: iOS Architecture & Security
    iOS Architecture & Security — Study Template1. iOS Architecture OverviewThe iOS platform can be understood as a layered architecture in which higher-level frameworks rely on increasingly fundamental system services.┌─────────────────────────────┐ │ Cocoa Touch │ ├─────────────────────────────┤ │ Core Media │ ├─────────────────────────────┤ │ Core Services │ ├─────────────────────────────┤ │ Core OS │ └─────────────────────────────┘ ↓ Hardware 2. Cocoa TouchCocoa Touch represents the upper application-facing layer of the architecture.It provides functionality related to:
    • User interfaces
    • Touch and multi-touch interactions
    • Application controllers
    • System alerts
    • Application lifecycle management
    Security relevanceThis layer is where applications interact heavily with the operating system's higher-level APIs.For a security analyst, understanding this layer helps explain:
    • How applications interact with system services
    • How user input reaches applications
    • How applications request privileged functionality
    3. Core MediaCore Media provides multimedia-related capabilities.It handles functionality such as:
    • Audio
    • Video
    • Media playback
    • Graphics
    • Animation
    • 2D/3D rendering
    Historically, technologies such as OpenGL have been part of Apple's graphics stack.Security relevanceMedia processing creates a potentially important attack surface because applications may process:
    • Images
    • Videos
    • Audio
    • Complex media formats
    Malformed media can potentially expose vulnerabilities in parsers or processing components.4. Core ServicesCore Services provides essential system-level functionality used by applications.Examples include:
    • Networking
    • Location services
    • File access
    • Databases
    • System state information
    Security relevanceThis layer is particularly important because applications often interact with sensitive system resources through APIs exposed here.Security analysis may involve determining:What data can an application access, and through which system APIs?5. Core OSCore OS represents the lowest major software layer.It interacts closely with the underlying hardware and provides fundamental capabilities such as:
    • Kernel functionality
    • Device drivers
    • Low-level networking
    • Cryptographic services
    • System-level security mechanisms
    Security relevanceThis is where many of the platform's fundamental security boundaries are enforced.🔐 6. iOS Security ArchitectureiOS security can be divided into several interconnected areas:
    1. System Security
    2. Application Security
    3. Data Security
    4. Network Security
    These mechanisms work together rather than functioning as isolated controls.7. System Security🔒 Secure BootiOS uses a secure boot chain to verify that trusted software components are loaded during startup.Conceptually:Hardware Root of Trust ↓ Boot ROM ↓ Bootloader ↓ Operating System ↓ Trusted Runtime Each stage verifies the integrity/authenticity of the next stage.GoalPrevent unauthorized or modified system software from being loaded during boot.8. Secure EnclaveThe Secure Enclave is a dedicated security subsystem designed to protect sensitive cryptographic operations and secrets.It works alongside the main processor while maintaining a strong security boundary.The architecture uses hardware-backed cryptographic protections, including AES-based mechanisms.Security purposeThe Secure Enclave helps protect:
    • Cryptographic keys
    • Authentication-related secrets
    • Biometric authentication operations
    • Sensitive security operations
    Key conceptHardware-backed security makes extracting protected secrets significantly more difficult than storing them solely in ordinary application memory.📱 9. Application SecurityiOS applications operate under strict security controls.Code SigningApplications must be appropriately code signed before they can execute under normal iOS security policies.This helps establish:
    • Application authenticity
    • Code integrity
    • Developer identity
    10. Application SandboxingEach application operates within a restricted sandbox.The sandbox limits what an application can access outside its designated environment.For example, an application generally cannot freely access:
    • Another application's private files
    • System resources
    • Arbitrary protected data
    without going through authorized mechanisms.Security principleCompromise of one application should not automatically provide unrestricted access to the entire device.11. Controlled Data SharingiOS provides controlled mechanisms for applications to share information when permitted.Examples include:
    • Extensions
    • App Groups
    • Specific system APIs
    Rather than allowing unrestricted application-to-application access, iOS establishes defined communication boundaries.🔐 12. Data SecurityiOS protects sensitive information stored on the device through multiple layers.KeychainThe Keychain provides protected storage for sensitive information such as:
    • Credentials
    • Authentication tokens
    • Cryptographic secrets
    • Other sensitive application data
    Key BagsKey-management structures help organize and protect cryptographic keys associated with different protection states.File ProtectioniOS uses cryptographic protection for stored files.The general concept is:User Data ↓ File Encryption ↓ Encryption Keys ↓ Hardware / Key Management Protection This helps protect data even if an attacker obtains physical access to the device's storage.🌐 13. Network SecurityiOS also protects information while it travels across networks.TLSSecure communications commonly use TLS to protect data in transit.This provides:
    • Encryption
    • Integrity
    • Server authentication
    VPNiOS supports VPN technologies that allow network traffic to be routed through protected tunnels.This can provide additional security when communicating across untrusted networks.AirDrop & Wireless SharingFeatures such as AirDrop and Wi-Fi-based communication also rely on security mechanisms designed to control who can communicate with the device and what information can be exchanged.🧠 14. Security Architecture as a ChainThe most important conceptual takeaway is that iOS security isn't based on a single mechanism.Instead:Hardware Security ↓ Secure Boot ↓ Operating System Integrity ↓ Code Signing ↓ Application Sandboxing ↓ Data Protection ↓ Network Protection Each layer reinforces the others.🔬 15. Why This Matters for Malware AnalysisFor a mobile malware analyst, understanding the architecture is essential.When analyzing an iOS application, you need to understand:
    • Where the application executes
    • What APIs it can access
    • What data it can reach
    • How code signing works
    • How sandbox boundaries operate
    • Where cryptographic secrets are protected
    • How the application communicates externally
    This gives you the foundation for understanding what an attacker can and cannot realistically accomplish after compromising an iOS application.🎯 Key Takeaways
    • Cocoa Touch → application and UI functionality
    • Core Media → multimedia and graphics
    • Core Services → essential system services
    • Core OS → kernel, drivers, networking, and low-level security
    • Secure Boot → establishes a chain of trust during startup
    • Secure Enclave → hardware-backed protection for sensitive secrets and security operations
    • Code Signing → establishes application integrity and authorization
    • Sandboxing → isolates applications
    • Keychain → protects sensitive credentials and secrets
    • File Protection → protects stored user data
    • TLS/VPN → protect communications in transit
    Golden ConceptiOS security is a defense-in-depth architecture where hardware, operating-system, application, data, and network protections work together to establish multiple security boundaries.

    You can listen and download our episodes for free on more than 10 different platforms:
    https://linktr.ee/cybercode_academy

    Get the books of the CyberCode Academy podcast:
    📚 The book series: 416 lessons, 12 books, hundreds of original diagrams: security, networking and programming.
    https://cybercodeacademy.gumroad.com/
    25 min

About CyberCode Academy

From the publisher's feed

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…