When shifting from general cybersecurity to mobile environments, the operating system's architecture is the battleground. Android and iOS, while both based on Unix-like kernels, take fundamentally different approaches to security. Understanding these differences is the first step in learning how to test their defenses.

Android is built on a layered architecture, with each layer relying on the security of the one below it. This structure provides a clear separation of concerns, but also creates distinct areas for potential vulnerabilities.

At the bottom is the Linux Kernel. This is the core of the OS, managing processes, memory, and device drivers. Android's security model is built directly on Linux features. For instance, every app is assigned a unique Linux user ID (UID) upon installation. This isn't just a label; it's a fundamental security boundary. The kernel enforces permissions between apps based on these UIDs, effectively isolating them from each other and from the system itself. This process is known as sandboxing.

Just above the kernel is the Hardware Abstraction Layer (HAL). The HAL provides a standard interface for hardware vendors to create drivers without revealing their proprietary source code. It allows the higher-level Android framework to communicate with hardware like the camera or Bluetooth radio, acting as a critical bridge.

The Android Runtime (ART) is where app code is executed. It compiles app bytecode into native instructions, managing the app's execution and memory. Above this sits the Application Framework, which provides the high-level services apps use, like the activity manager and notification system.

Apple's approach to iOS security is famously restrictive, often described as a "walled garden." The goal is to control the entire ecosystem, from hardware to software, to create a tightly integrated and secure user experience. This philosophy is enforced through several key mechanisms.

First is the secure boot chain. When an iOS device powers on, it begins a sequence where each component cryptographically verifies the next. The process starts with immutable code in the processor's Boot ROM, which checks the signature of the next-stage bootloader, which in turn checks the OS kernel, and so on. Any failure in this chain of trust halts the boot process, preventing tampered software from running.

Next, every application that runs on iOS must have a valid digital signature from Apple. This mandatory code signing ensures that only approved apps from the App Store (or registered developers) can be installed. It prevents the installation of unvetted, potentially malicious software.

Finally, iOS enforces a strict sandbox on every app. Unlike Android's UID system, the iOS sandbox is defined by a complex set of rules and profiles that limit what an app can do. An app has no access to data from other apps or most of the operating system. Critical user data is further protected by a dedicated security chip called the Secure Enclave, which handles cryptographic operations for things like Face ID, Touch ID, and Apple Pay.

The philosophical differences between Android's relative openness and iOS's locked-down control lead to distinct security trade-offs. An ethical hacker must adapt their methodology depending on the target platform.

Despite their differences, mobile apps on both platforms face similar threats. Security researchers and developers rely on frameworks to categorize and address these risks. The most widely recognized is the OWASP Mobile Top 10, which outlines the most critical security risks for mobile applications.

Understanding how Android's UID isolation or iOS's code signing works provides the context for how these vulnerabilities are exploited. A flaw in how an app stores its credentials, for example, has different implications depending on the underlying OS protections.

Grasping these foundational architectures is non-negotiable. It dictates the tools you'll use and the attack vectors you'll look for. In later sections, we'll build on this knowledge to start probing these security boundaries.