Mobile Platform Security MCQ 60 Tests With Answers (2026)

Incorrect·D: By utilizing the "Binder" framework, which facilitates message passing and inherently identifies the PID and UID of the calling process

Binder (/dev/binder) is Android's kernel IPC driver. Every Binder transaction automatically tags the calling process's UID and PID in the kernel, which the receiving process can read via Binder.getCallingUid(). This allows system services to perform fine-grained access control — e.g., only the package with a matching UID can bind to a specific Service.

Incorrect·B: NSFileProtectionComplete

NSFileProtectionComplete (Class A) wraps the file's per-file key with a key derived from both the hardware UID and the user's passcode. When the device locks, this derived key is purged from memory, making the file cryptographically inaccessible until the passcode is re-entered — the strongest iOS Data Protection level.

Incorrect·A: If an Intent is "Exported" without strict permission checks, malicious third-party apps can invoke sensitive components or intercept data payloads

Setting android:exported="true" on an Activity, Service, or BroadcastReceiver without declaring a custom permission allows any app to invoke it. Attackers can fire implicit Intents to trigger sensitive actions (e.g., launch a payment screen) or register BroadcastReceivers to intercept system events not properly protected with android:permission.

Incorrect·C: Seatbelt

iOS uses a macOS-derived sandbox engine called "Seatbelt" (also referred to as the Sandboxd / MACF kernel framework). Each app's sandbox profile is a compiled binary policy file that defines exactly which file paths, IPC endpoints, and syscalls the process is permitted to use — violations are blocked at the kernel level.

Incorrect·B: The device has booted an alternative operating system signed with a custom, user-provided key

Android Verified Boot defines four states: GREEN (locked, verified), YELLOW (locked, but signed with a user-enrolled custom key — shown as a warning on boot), ORANGE (bootloader unlocked, no verification), and RED (verification failed, device will not proceed). YELLOW allows developers to flash custom ROMs while still providing integrity.

Incorrect·D: Through an isolated, interrupt-driven shared memory "mailbox" system

The AP and SEP share a small hardware mailbox — a ring buffer in a restricted memory region only SEP can write sensitive outputs to. The AP posts requests (e.g., "verify biometric") and the SEP responds with results. This asymmetric communication channel ensures the AP can request operations without ever reading SEP's internal state or key material.

Incorrect·B: SELinux

SELinux (Security-Enhanced Linux), running in Enforcing mode on Android since 4.4, assigns security labels (contexts) to every process and file. Even if an attacker obtains root (UID 0), SELinux policy prevents unlabeled or improperly labeled processes from accessing files outside their defined domain — significantly containing post-exploitation impact.

Incorrect·A: A highly privileged permission only granted if the requesting app is signed with the exact same developer certificate as the app declaring the permission

signatureOrSystem permissions are used by Android system components to restrict inter-app communication to trusted partners. For example, only an app signed with the same certificate as the one declaring a custom permission can use it — no user prompt ever appears, and no third-party app can spoof eligibility.

Incorrect·B: To encrypt the application binary at rest, requiring the OS to decrypt pages on the fly during execution, hindering static reverse engineering

When you download an app from the App Store, Apple's FairPlay DRM wraps the compiled Mach-O binary in a symmetric encryption layer tied to your Apple ID and device. The OS decrypts individual code pages only as they are paged into RAM for execution, which prevents straightforward static analysis of the binary stored on disk.

Incorrect·C: The Network Security Configuration XML file

Network Security Configuration (res/xml/network_security_config.xml) lets developers declaratively disable cleartext HTTP for specific or all domains, pin certificates, and define custom CA trust anchors for debug builds. This separates transport security configuration from application code, making it auditable and adjustable without re-compiling.

Incorrect·B: It randomizes the memory locations of application executables, libraries, and the heap, making buffer overflow and ROP exploits drastically harder

ASLR loads the executable, stack, heap, and shared libraries at random virtual addresses each time a process starts. This defeats exploit techniques that rely on hardcoded memory addresses — attackers must first leak an address via an information disclosure bug before building a reliable exploit, adding enormous complexity.

Incorrect·A: To restrict apps to only reading and writing files within their own isolated app-specific directories, heavily limiting broad read access to the entire external shared storage

Introduced in Android 10 and fully enforced in Android 11+, Scoped Storage removes the broad READ_EXTERNAL_STORAGE permission for most use cases. Apps can only directly access their own external app-specific directories and files they created via MediaStore — they must use the Storage Access Framework to access arbitrary user files.

Incorrect·C: The Provisioning Profile

A Provisioning Profile is a signed plist (by Apple) that binds together a set of device UDIDs (or wildcard), an App ID, an entitlements set, and a developer or distribution certificate. The device checks this profile at launch — if the UDID or certificate chain isn't listed, the app refuses to run.

Incorrect·B: The cryptographic keys are generated and used entirely within the isolated TEE/SE, meaning even a compromised kernel cannot extract the raw key material

In a software keystore, keys reside in process or kernel memory and are vulnerable to extraction via memory dumps if root is obtained. Hardware-backed keys are generated inside the TEE (or StrongBox SE), and all cryptographic operations happen inside the secure hardware — the key material's bits never cross into the normal world as plaintext.

Incorrect·C: A hardware-enforced mechanism that prevents an attacker from downgrading the OS to an older, vulnerable version to exploit patched flaws

Both Android (via anti-rollback counters in the TEE) and iOS (via fusing non-volatile counters in hardware) record the minimum OS version that may be booted. If an attacker attempts to restore a signed-but-older firmware containing a patched vulnerability, the bootloader consults the hardware counter and refuses to proceed.

Incorrect·D: Entirely inside the isolated Secure Enclave Processor (SEP)

The TrueDepth camera sends infrared dot-pattern data to the SEP via a direct, isolated interface — not through the AP. The SEP converts this into a mathematical representation and compares it against the enrolled template, also stored in SEP-encrypted memory. The AP only learns the binary pass/fail result.

Incorrect·A: Dangerous permissions (like Camera or Location) require explicit runtime consent from the user, while Normal permissions (like Internet access) are granted at install time

Android groups permissions by protection level. 'Normal' permissions (e.g., INTERNET, VIBRATE) are auto-granted at install — they offer low privacy risk. 'Dangerous' permissions (e.g., READ_CONTACTS, ACCESS_FINE_LOCATION, CAMERA) require an explicit runtime dialog (Android 6.0+) where the user grants or denies the request in-context.

Incorrect·B: It physically divides the processor into a "Secure World" for trusted operations and a "Normal World" for the rich operating system

ARM TrustZone introduces a hardware security bit (NS bit) on the CPU bus. When clear, the CPU runs in "Secure World" — accessible to the TEE OS and Trusted Applications (TAs). When set, it's in "Normal World" (Android/iOS). The Secure Monitor, running at EL3, manages context switches between worlds via Secure Monitor Calls (SMC).

Incorrect·C: It aggressively strips or ignores these variables for signed binaries to prevent malicious code hooking

When DYLD (the iOS dynamic linker) loads a process that is restricted (has a code signature and no get-task-allow entitlement), it ignores DYLD_INSERT_LIBRARIES and all other DYLD_ environment variables. This prevents the classic LD_PRELOAD-style attack. On jailbroken devices, this restriction is patched, enabling tools like Cydia Substrate and Frida.

Incorrect·B: Content Providers utilizing temporary URI permissions

Content Providers expose structured data via content:// URIs. Using grantUriPermission() or FLAG_GRANT_READ_URI_PERMISSION, an app can share a specific URI with another app for the duration of a task (e.g., allowing a photo editor to access one image from a gallery app) without granting broad file-system read access.

Incorrect·C: By signing code pointers with a cryptographic hash before placing them in memory, validating the signature before execution to thwart Return-Oriented Programming (ROP)

ARM v8.3-A PAC uses spare bits in 64-bit pointers to embed a HMAC-like signature (PAC) derived from the pointer value, its context, and a secret hardware key. A blr x0 instruction first validates the PAC — if the pointer was forged or corrupted (as in a ROP chain), the validation faults, aborting the exploit before gaining control.

Incorrect·B: By applying seccomp-bpf filters that restrict the specific syscalls a sandboxed application is permitted to invoke

Android's Zygote-spawned app processes have a seccomp-bpf filter installed that creates an allowlist of permitted Linux syscalls. If a sandboxed process attempts any syscall outside its allowlist — which an exploit might need (e.g., ptrace, keyctl) — the kernel delivers a SIGSYS signal, terminating the process before exploitation proceeds.

Incorrect·C: To use hardware features to lock the kernel's executable code pages, preventing attackers from modifying the kernel even if they achieve arbitrary write primitives

KTRR, introduced on Apple's A10 chip, uses MMU region registers to hardware-lock the kernel's __TEXT and __CONST segments as read-only after boot. Even an attacker with kernel write primitives (from a tfp0 exploit) cannot patch the kernel text — a write attempt causes a hardware exception, impeding persistent kernel modifications.

Incorrect·D: It embeds checks into compiled binaries to ensure the execution path follows a predetermined, valid control-flow graph, mitigating code-reuse attacks

LLVM CFI, enforced in Android system components (since Android 9) and the kernel (since Android 10), inserts runtime checks before indirect calls and virtual dispatch. The check validates that the target address is within the set of legal call destinations. ROP/JOP gadget chains that redirect control flow to arbitrary addresses fail this check and trap.

Incorrect·D: The ability to arbitrarily read and write to the kernel memory space, completely compromising the operating system

In macOS/iOS Mach, pid 0 is the kernel task. Obtaining a send right to the kernel task port (task_for_pid(0)) grants the holder mach_vm_read() and mach_vm_write() primitives over the entire kernel address space. This is the crown jewel of iOS kernel exploits and is the building block of virtually every modern jailbreak.

Incorrect·B: It heavily isolated the vendor-specific Hardware Abstraction Layers (HALs) from the Android OS framework, preventing bugs in proprietary drivers from directly compromising the core OS

Pre-Treble, OEM HALs ran as monolithic libraries inside the mediaserver/system_server processes, meaning a camera HAL bug could compromise the entire system. Post-Treble (Android 8+), each HAL runs as an isolated process in its own SELinux domain with minimal permissions — a vulnerability in a vendor HAL is now contained to that narrow domain.

Incorrect·A: By executing a Secure Monitor Call (SMC) instruction, triggering a context switch managed by the Secure Monitor

The SMC (Secure Monitor Call) instruction drops the CPU to EL3 (Secure Monitor), which saves Normal World state, switches the NS bit to 0 (Secure World), and transfers execution to the TEE OS. The TEE processes the request (e.g., key unwrapping) and returns results to the Normal World without exposing secure memory directly.

Incorrect·C: Apple Mobile File Integrity (AMFI)

AMFI (amfi.kext) is the in-kernel component of iOS code signing enforcement. It works alongside a userland daemon (amfid) to validate the Code Directory hash chain for every binary before pages are made executable. AMFI is the first target that jailbreaks must patch or bypass to allow unsigned code to run.

Incorrect·D: It is backed by a physically separate, tamper-resistant secure element (SE) with its own CPU, memory, and secure storage, distinct from the main SoC's TEE

StrongBox (Android 9+, KeyProperties.SECURITY_LEVEL_STRONGBOX) requires a discrete, tamper-resistant Secure Element chip — not just a TrustZone TEE, which shares silicon with the main SoC. The SE has its own CPU and flash storage and is physically separate, meaning key material is isolated from even a fully-compromised TEE.

Incorrect·B: An immutable, read-only Boot ROM fabricated directly into the SEP silicon during manufacturing

Like the main AP's Boot ROM, the SEP has its own on-chip ROM that cannot be altered post-fabrication. This Boot ROM verifies the sepOS firmware signature before executing it, forming an independent trust anchor. If sepOS is compromised, the Boot ROM will halt — it cannot be patched by software running on the main processor.

Incorrect·A: Just-In-Time (JIT) code reuse attacks, by preventing attackers from reading memory pages to find ROP gadgets

XOM marks executable memory pages as non-readable. ROP/JOP attacks require the attacker to first read .text segments to discover gadget addresses and byte patterns. With XOM, any attempt to read an execute-only page causes a segmentation fault, forcing attackers to rely on information disclosure side-channels — greatly increasing exploit complexity.

Incorrect·C: Attackers modifying userland page tables to bypass code signing, even if they have already achieved kernel read/write capabilities

PPL (introduced with A12 on iOS 12) runs at a higher privilege level than the XNU kernel (ppl_handler routines run in PPL mode, not kernel mode). It is the sole component allowed to modify page table entries controlling execute permissions. Even an attacker with full kernel r/w cannot directly re-map pages as executable — they must compromise PPL itself, a much harder target.

Incorrect·B: They provide a secure mechanism to update lower-level, unprivileged system libraries and components natively, bypassing the need for full OEM firmware updates

APEX (Android Pony EXpress), introduced in Android 10 via Project Mainline, packages low-level system components (e.g., libcrypto, DNS resolver, Media codecs) as signed, updatable modules. Google can push security patches to these components via the Play Store without requiring a full OEM/carrier firmware update cycle, drastically reducing patch propagation time.

Incorrect·C: BlastDoor

BlastDoor (introduced in iOS 14 following Project Zero's FORCEDENTRY research) is a sandboxed service that pre-processes all incoming iMessage content — parsing attachments, decoding data structures — before any results reach the main SpringBoard process. It runs with extremely limited syscalls (seccomp) and no network access, neutralizing parsing-based zero-click exploits.

Incorrect·C: CE storage requires the user's passcode to decrypt; DE storage is unlocked during Direct Boot before the user enters their passcode

DE (Device Encrypted) keys are derived from hardware secrets alone, making DE files accessible immediately after a reboot in Direct Boot mode (e.g., alarm clock data). CE (Credential Encrypted) keys are derived from both hardware secrets and the user's passcode — CE files remain locked until first unlock (AFU), holding more sensitive user data like emails and photos.

Incorrect·D: Through the XPC (XNU Inter-Process Communication) framework, which enforces strict entitlement checks on the caller

XPC is Apple's IPC framework built on Mach messages and libdispatch. System daemons validate the calling process's entitlements (e.g., com.apple.security.network.client) before servicing requests. XPC connections are brokered by launchd with privilege separation — apps cannot directly call privileged APIs and must ask daemons with appropriate entitlements to act on their behalf.

Incorrect·B: By looking up the target domains mapped in the file_contexts and service_contexts policies

The init process reads compiled policy files (file_contexts, service_contexts, property_contexts) built into the vendor and system partitions. When forking a service, init calls setcon() to transition the new process into its declared SELinux domain, ensuring each service starts with least-privilege MAC labels — never inheriting init's own context.

Incorrect·B: A boolean true/false indicating whether the biometric evaluation was successful, entirely abstracting the underlying biometric data

LAContext.evaluatePolicy() is a deliberately thin API. It returns only a success/failure boolean (and an NSError on failure). The actual biometric template, match score, and hardware operations all occur inside the SEP — completely opaque to the calling application and the iOS kernel. This abstraction is why local biometric bypass via Frida hooks the boolean return value.

Incorrect·A: Memory Tagging Extension (MTE)

ARM MTE (ARMv8.5-A) assigns a 4-bit color tag to every 16-byte granule of memory at allocation. Pointers to that allocation store the matching tag in their upper bits. On every load/store, the CPU hardware checks that the pointer tag matches the memory granule tag — a mismatch (indicating OOB access) triggers a fault, detecting heap overflows and use-after-free with near-zero overhead.

Incorrect·D: It uses a Code Directory (CD) structure embedded in the signature, which contains an array of cryptographic hashes for every page of the executable

A Mach-O code signature contains a Code Directory — a list of SHA-256 hashes, one per 4 KB page of the binary. When the VM system pages in a code page, XNU's pager calls AMFI to verify the page's hash against the pre-validated Code Directory. Any tampered or injected page fails the hash check and the process is killed, providing continuous, lazy integrity verification.