Mobile and Malware Forensics practice questions

Manual acquisition

Why it fails: Manual acquisition involves an examiner physically operating the device through its touchscreen, screenshotting or photographing each screen that displays relevant data. This process is inherently slow, prone to human error such as missed content or screen transitions, and captures only data currently visible on the interface. It does not create a forensic image, accesses no underlying storage, and completely misses deleted messages, call logs, or artifacts hidden in app sandboxes.

Logical acquisition

Why it fails: Logical acquisition relies on the device's operating system to enumerate and copy files through APIs, often using ADB backup or MTP, yielding an organized set of allocated files and their timestamps. Because it operates above the storage driver, it can only see objects the OS considers accessible; unallocated blocks, deleted entries, and raw partition remnants are never presented to the extraction agent. The result is a clean but incomplete dataset that may satisfy simple requests but fails to reveal deleted database rows or freed blocks.

File system acquisition

Why it fails: File system acquisition reads the on-disk file system structures directly, such as ext4 inodes, APFS file records, or FAT directory entries, to reconstruct allocated files and their metadata (names, sizes, timestamps) without going through the operating system's user-level APIs. However, it operates at the logical file system layer rather than the raw block layer, so unallocated storage blocks and free-space remnants are not imaged; deleted data that has not been overwritten may remain invisible unless the tool conducts targeted carving. This distinguishes it from physical acquisition, which captures the medium itself, and from logical acquisition, which depends on the OS.

SELECT * FROM messages WHERE key_remote_jid = '%1234%'

Why it fails: The equality operator requires an exact, case-sensitive match of the entire key_remote_jid value to the literal string '%1234%'. Because the wildcard characters are not interpreted in an = comparison, this query will only return rows where the JID is literally the four-character sequence percent-1234-percent, which never occurs. Consequently, the result set is empty, making it functionally useless for forensic search.

SELECT * FROM messages WHERE data LIKE '%1234%'

Why it fails: The data column contains the actual message content—the body of the chat, such as 'Call me at 1234' or media captions—not the identity of the sender or recipient. Searching LIKE '%1234%' here would return every message whose text happens to include the digit string '1234', which may be a phone number inside a message, a time, or part of a URL. That result is unrelated to finding messages from a particular JID, so it fails to answer the investigative question about a specific contact.

SELECT * FROM messages WHERE timestamp LIKE '%1234%'

Why it fails: The timestamp column stores Unix epoch milliseconds as an integer (e.g., 1614556800000), and applying LIKE forces a type conversion of the numeric value to a string before pattern matching. Because the numeric representation has no thousands separators or characters, a pattern like '%1234%' can unintentionally match dates or times, but more importantly, it ignores the structured nature of the data—filters should use range comparisons like BETWEEN or >=/<. Even if a match occurs, timestamp is not a contact identifier, so the query does not locate messages by recipient.

Call history

Why it fails: Call history is stored in call_history.db with a different hash.

SMS and iMessage conversations

Why it fails: SMS.db is stored with a different hash (e.g., 3d0d7e5fb... is associated with Notes).

Keychain data

Why it fails: Keychain data is stored in a different format (keychain-2.db) with a different hash.

Filter for 'WriteFile' events in System32

Why it fails: Filtering WriteFile events in System32 captures file output operations but does not specifically indicate persistence. Persistence requires a mechanism that causes the executable to be launched automatically on startup or logon, such as a service, scheduled task, or Run key. While dropping a file into System32 may be part of an installer or a malware payload, it lacks the autorun trigger needed to conclude persistence. Additionally, many legitimate system processes routinely write to System32, leading to high false positives.

Filter for 'Process Create' events

Why it fails: Process Create events report when a new executable is started, including the malware sample itself and any child processes it spawns. However, creating a process is a one-time execution event and does not by itself establish persistence, which requires a configuration that re-launches the program after reboot or at logon. Malware may run without installing any persistence mechanism, and even benign software generates Process Create events continuously. Therefore this filter lacks the specificity to distinguish persistent mechanisms from ordinary program execution.

Filter for 'RegSetValue' events with path containing 'RunOnce'

Why it fails: RunOnce registry entries trigger a program only on the next logon or boot, after which the entry is automatically deleted, so they provide a one-shot execution rather than ongoing persistence. Although malware can use RunOnce for immediate execution, the standard and more durable persistence locations are under 'CurrentVersion\Run', which execute every logon. Since legitimate installers also commonly write RunOnce keys, this filter produces more noise and is less indicative of long-term persistence. The question asks for a persistence indicator, making RunOnce a weaker and less reliable choice.

Wi-Fi password

Why it fails: Although Wi-Fi network secrets do live in the iOS keychain, they are registered under the generic-password service identifier 'AirPort' (or with the network's SSID as the account), not under 'com.apple.sbd' with account 'iCloud'. A keychain item whose account is literally 'iCloud' cannot be a Wi-Fi passphrase, because the service/account pair determines the item's purpose. Therefore this extracted entry points to an iCloud authentication token rather than to a stored Wi-Fi password.

Device passcode

Why it fails: The device passcode is not a keychain item at all; it is held by the Secure Enclave and used to derive the keybag's protection keys. An iTunes backup and its keychain extraction contain software-accessible keychain records, but they never export the SEP-held passcode or the class keys that protect user data. The observed com.apple.sbd/iCloud entry is an account credential, not an authentication secret derived from the alphanumeric passcode, so it cannot be the device passcode.

SMS encryption key

Why it fails: SMS and iMessage encryption keys are associated with Apple's messaging services and are stored under identifiers such as 'com.apple.imessage' or 'com.apple.identityservices', often with account fields like 'Apple Account' or an address book ID, not under the 'com.apple.sbd' service. The sbd service is the iCloud/account data daemon, not the encryption-key store for SMS protocol. Consequently, this keychain item is not an SMS encryption key but the iCloud account token.

Encryption

Why it fails: Encryption renders data unreadable through cryptographic algorithms, but it does not delete, conceal, or alter the forensic artifacts themselves; the ciphertext remains on the storage medium, and with the right lawful-access mechanisms such as key extraction or cloud recovery, the data can be recovered. Because it protects confidentiality rather than erasing or manipulating evidence, it is not considered an anti-forensic tampering technique in the same way as data destruction or timestamp alteration.

Steganography

Why it fails: Steganography conceals the existence of hidden messages by embedding them within innocuous carrier files such as JPEGs or MP4s, leaving the file system structure, logs, and timestamps untouched. It is primarily a data-exfiltration or covert-communication technique, not a method for tampering with device evidence; forensic examiners can often detect anomalies through statistical analysis, hash comparisons, or extracted-file carving, and the original evidentiary artifacts remain intact.

Log wiping

Why it fails: Log wiping involves deleting or truncating audit and event logs, such as Android's event log, system log, or app-specific logs, to remove traces of user activity; however, on a non-rooted mobile device, access to these logs is usually restricted by the permission model, making it a less practical tampering method. It also leaves behind gaps in the log sequence or inconsistencies in the file system journal, and it is more commonly associated with server-side incident response or OS-level forensic countermeasures rather than consumer mobile devices.

ZCONTACT

Why it fails: ZCONTACT is a table in Apple's Contacts database (AddressBook.sqlite or Contacts.sqlite), not in the call history database. It stores contact records such as names, phone numbers, and metadata, but lacks call-specific fields like timestamp, duration, or direction. Querying ZCONTACT during a call-history examination would return contact information, not evidence of dialed or received calls.

ZOBJECT

Why it fails: ZOBJECT is the primary table in knowledgeC.db, Apple's CoreDuet knowledge database used to store app usage, battery level, and other behavioral and contextual events. It is not part of the iOS call history schema and does not contain telephony call metadata. The presence of knowledgeC.db in an iCloud backup often misleads analysts, but call records must be retrieved from the call table in call_history.db.

ZCALL

Why it fails: ZCALL is a Z-prefixed Core Data table name that may appear in some iOS versions or third-party databases, but it is not the standardized table in the canonical call_history.db artifact. The stable, documented table for iOS call records is simply call, whose schema is widely recognized by forensic tools. Relying on ZCALL as the primary evidence source can cause an examiner to overlook the standard call database and miss important call details.

File system extraction

Why it fails: File system extraction parses the mounted file system (e.g., ext4, F2FS) using the kernel's storage drivers to enumerate allocated files, directories, and metadata, and it may identify some logically deleted files by reading remnants in unallocated blocks or file system journal. However, it does not produce a raw block-level image, so it cannot recover data that is not referenced by a file system structure or that resides in slack space or entirely unallocated regions. Consequently, it is less complete than physical extraction and may miss significant deleted artifact.

Logical extraction via ADB

Why it fails: Logical extraction via ADB uses the Android Debug Bridge to issue commands like `adb pull` or to query content providers, operating at the Android application framework level rather than reading raw storage. It only retrieves files that are accessible to the running operating system and user space, so it cannot access unallocated clusters, deleted inodes, or other data hidden beneath the kernel's file system layer. ADB may also alter device state by changing access times or creating temporary files, undermining forensic integrity.

Manual extraction via device UI

Why it fails: Manual extraction through the device UI requires an examiner to scroll through applications and screens while photographing or screen-recording the display, which inherently captures only visible information. It is not forensically sound because it cannot provide a cryptographic hash of the original data, it modifies device state as the examiner interacts with the interface, and it offers no way to recover deleted data or bypass application-level restrictions. At best it produces a non-reproducible record and is only usable as a last resort when no other method is possible.

Code injection via Reflective DLL

Why it fails: Reflective DLL injection is a sophisticated technique that loads a DLL entirely from memory into a process without relying on the Windows loader, mapping the PE headers and sections manually and resolving imports via a crafted stub. However, this method is fundamentally independent of the TLS directory: it does not require parsing the TLS callback table or executing any TLS callbacks for its unpacking or initialization. The presence of a .tls section would therefore not be an indicator of reflective DLL injection, which instead typically leaves traces such as a manually mapped module with no corresponding file on disk.

Packing with UPX

Why it fails: UPX is one of the most widely recognized packers and it typically compresses the original code into sections named UPX0, UPX1, and UPX2, with the decompressor stub at the entry point, but it does not use a .tls section for its unpacking logic. While UPX can theoretically preserve a TLS section if the original binary had one, the packer itself does not add or rely on TLS callbacks to decompress code; instead, the stub manually unpacks the sections in memory before jumping to the original entry point. Therefore, seeing .tls would not be a hallmark of UPX packing, and a malware analyst would look for the familiar UPX section names rather than a TLS directory.

Anti-debugging via NtGlobalFlag

Why it fails: NtGlobalFlag is a process environment variable located in the Process Environment Block (PEB) at offset 0x68 on 32-bit systems and 0xBC on 64-bit systems, which can be queried by malware to detect a debugger by checking for flags such as FLG_HEAP_ENABLE_TAIL_CHECK. This anti-debugging technique is entirely unrelated to the TLS section, as it relies on reading a specific PEB field and does not define any callbacks or executable code prior to the entry point. The presence of a .tls section would not indicate NtGlobalFlag-based anti-debugging, which is instead typically identified by code that accesses the PEB directly.

Oxygen Forensic Detective

Why it fails: Oxygen Forensic Detective is a commercial mobile forensics tool that offers logical, file-system, and cloud extraction together with app-data analysis across various platforms. Its acquisition methods depend on Android Debug Bridge, iOS backups, and vendor-specific APIs, but it does not leverage low-level BootROM exploits such as checkm8, so it is not the tool specifically tied to that vulnerability.

Magnet AXIOM

Why it fails: Magnet AXIAM is a digital forensic examination platform that ingests and analyzes evidence from mobile devices, cloud sources, and computer images, typically relying on other acquisition tools for physical extractions. It does not perform BootROM-level attacks; instead, it focuses on artifact parsing, decryption, and reporting, making it an analysis layer rather than the exploit-based acquisition tool referenced in the question.

GrayKey

Why it fails: GrayKey, developed by Grayshift, is a dedicated mobile forensic acquisition device that exploits the checkm8 BootROM vulnerability present in Apple SoCs from the A7 through A11 (iPhone 4s through iPhone X). By taking advantage of this unpatchable vulnerability, GrayKey bypasses code signing and secure-enclave protections to perform physical extraction of the file system and keychain, even from locked iOS devices.

Packing

Why it fails: Packing compresses or encrypts the malware's executable code and resources so static analysis tools and signature-based detection see only a loader stub. It changes the binary's on-disk representation but does not create, modify, or delete any autostart registry keys, scheduled tasks, or services. The dynamic run may show the process unpacking itself in memory, yet that unpacking activity has nothing to do with hiding the persistence entry that was already placed. In short, packing is an anti-static-analysis measure, not a mechanism for wiping traces of a Run key.

Encryption

Why it fails: Encryption protects data confidentiality by transforming plaintext into ciphertext, so malware often encrypts its configuration, payloads, or C2 communication. However, persistence actions such as creating a scheduled task or setting the 'Run' registry value operate at the system's API level; the existence of that autostart entry is not the kind of content that encryption conceals. Even if the malware's data blobs are encrypted, the log entries generated by the task scheduler or service manager remain intact and readable. Encryption therefore cannot remove or obscure the forensic artifact that the malware created, whereas wiping the log would.

Timestomping

Why it fails: Timestomping deliberately changes a file's modification, access, creation, and entry-change times to mislead investigators about when the file was placed or last used. It can make a persistence binary appear legitimate, but it does not delete or clear records of the persistence entry itself, such as an event log entry showing a service installation or a task registration. In a dynamic analysis, the key observation is that the sample cleaned up the evidence of its autostart action; that cleanup is a log-wiping behavior, not a timestamp alteration. Timestomping addresses the 'when', not the 'that' or 'how' of persistence.

Deleted applications' data

Why it fails: Deleted applications' data is stored in the /data partition under directories like /data/data/<package>, which a factory reset wipes by formatting or reallocating the filesystem. On modern Android devices, this partition is encrypted (FBE/FDE), and the reset destroys the encryption keys or filesystem metadata, making recovery extremely difficult. Additionally, TRIM and garbage collection may physically erase blocks, so application-specific remnants are rarely recoverable without a pre-reset image.

Call logs

Why it fails: Call logs are maintained in the call log provider database, typically /data/data/com.android.providers.contacts/databases/call_log.db, on the /data partition. A factory reset deletes this database along with its journal and WAL files, and call log entries are frequently overwritten as new calls occur, leaving little persistent data. Unlike SMS databases, call logs do not benefit from long-lived journal files or frequent page fragmentation, so their recovery from unallocated space after a factory reset is unlikely.

Photos stored in internal storage

Why it fails: Photos stored in internal storage are kept under /data/media/0/DCIM on the emulated /sdcard, which is part of the userdata partition. A factory reset often formats the internal storage or deletes the media directory, leaving only sparse remnants that depend on the device's wipe routine. Because photos are large contiguous files, some can be carved from raw blocks, but the wipe typically destroys the filesystem metadata, making systematic recovery unreliable and therefore not a guaranteed source.

Process hollowing

Why it fails: Process hollowing is a code injection technique in which a legitimate process is created in a suspended state and its memory is replaced with malicious code to evade detection. It does not establish persistence because the injected process only runs while the system is active and must be re-launched manually or via a separate persistence mechanism on reboot.

WMI event subscription

Why it fails: WMI event subscriptions can monitor system events such as startup, shutdown, or user logon and automatically execute scripts or code in response, which makes them a viable persistence mechanism. However, they are far less common than scheduled tasks, Run keys, or services because they require more complex setup and leave distinctive artifacts in the WMI repository that are often scrutinized by forensic tools.

It recovers the file system but not deleted files

Why it fails: This description actually matches a file system acquisition, which operates at the logical volume level and preserves directory trees and active files while leaving unallocated and slack space unread. Physical acquisition, however, images the entire flash memory chip at an absolute byte level, recovering deleted files, remnants from prior file system operations, and unallocated pages. Therefore, the claim that deleted files cannot be recovered is false for physical acquisition.

It extracts data via the user interface by manually interacting with the device

Why it fails: This describes manual acquisition, where an examiner uses the device's touchscreen and UI to navigate, take screenshots, or record screen content under forensic control. Manual acquisition is a logical, user-interactive method that cannot capture data hidden below the OS abstraction layer. Physical acquisition instead issues low-level commands to the storage controller or uses JTAG/chip-off techniques to read raw NAND flash, never interacting with the user interface.

It recovers only logical files visible to the operating system

Why it fails: A logical acquisition enumerates files through file system APIs, retrieving only those items visible to the operating system and not deleted or otherwise obscured. Physical acquisition bypasses the OS entirely, reading NAND flash directly to recover not just active logical files but also deleted entries, file system journal artifacts, and data residing in unallocated blocks. Thus the limited scope described here is the antithesis of physical acquisition.

AddressBook.db

Why it fails: AddressBook.db is the iOS contacts SQLite database, containing tables like ABPerson and ABMultiValue that store contact names, phone numbers, email addresses, and related metadata. It is unrelated to call activity, as it merely acts as a directory of contacts and does not log or maintain any history of dialed, received, or missed calls. During a backup, its content is fully populated by address book records, but no call timestamps, durations, or handset statuses are present, making it useless for call log reconstruction.

Calendar.sqlitedb

Why it fails: Calendar.sqlitedb is the SQLite store for the Calendar and Reminders apps, residing in Library/Calendar. It holds tables such as CalendarItem, CalendarItemChanges, and Alarm, which describe event titles, start/end times, locations, and alarm triggers. None of these tables contain telephony data such as phone numbers, call durations, or call flags, so it is irrelevant to call-log analysis; it only reveals a user’s scheduled appointments, not their actual phone communications.

SMS.db

Why it fails: SMS.db is the database that stores SMS text messages and iMessage conversations, located at Library/SMS/sms.db. Its core tables—message, handle, chat, and chat_message_join—capture message bodies, sender/recipient addresses, and send/receive timestamps for text-based exchanges. While these records can establish communication patterns and timelines, they do not include voicemail, call durations, or telephony flags; call logs are maintained separately in call_history.db, so SMS.db cannot serve as the source for voice call history.

Cellebrite UFED

Why it fails: Cellebrite UFED is a multi-platform forensic acquisition system that supports iOS, Android, and other mobile operating systems through logical, file system, and physical extractions. While certain UFED models can leverage bootrom exploits (e.g., checkm8 on older iPhones) to bypass passcodes, that capability is one of many features and is not the product's sole purpose. In contrast, GrayKey is a dedicated appliance engineered specifically around iOS lock screen bypass, which is why UFED is not the best answer.

Magnet AXIOM

Why it fails: Magnet AXIOM is a comprehensive digital investigation platform that ingests evidence from mobile devices, computers, and cloud services and provides powerful artifact decoding and timeline analysis. It is fundamentally an analysis and processing suite rather than a purpose-built extraction device; for locked iPhones it typically relies on images and data already extracted by specialized hardware such as GrayKey or Cellebrite. Therefore, AXIOM's role is post-extraction forensic examination, not iOS lock screen bypass.

Oxygen Forensic Detective

Why it fails: Oxygen Forensic Detective is an all-in-one mobile forensic suite that supports iOS, Android, Windows Phone, and feature phones with logical extraction, file system extraction, and cloud data acquisition. However, its iOS passcode bypass capability is limited to exploiting jailbroken environments or using available device backups; it does not feature a dedicated hardware attack chain for locked iPhones the way GrayKey does. Thus, it lacks the specialized, hardware-level lock screen bypass focus described in the question.

/data/data/com.android.providers.contacts/databases/

Why it fails: The /data/data/com.android.providers.contacts/databases/ directory houses the ContactsProvider's databases, including contacts2.db, which stores aggregated contact information such as names, phone numbers, and email addresses. While SMS/MMS messages can reference contact IDs, the actual message content, threads, and attachments are never persisted here. A forensic examiner seeking text message artifacts must look to the telephony provider, not the contacts provider, because this path only yields the address book and associated metadata.

/data/data/com.android.providers.calendar/databases/

Why it fails: The /data/data/com.android.providers.calendar/databases/ directory contains the CalendarProvider's databases, typically calendar.db, which stores calendar events, reminders, and attendee data. Although a calendar app might sync or display information derived from messages (e.g., a flight confirmation), it does not contain raw SMS/MMS content or the mmssms.db file. Therefore, this path is not where an examiner would locate text message databases; it is specific to scheduling and event management.

/data/data/com.android.providers.downloads/databases/

Why it fails: The /data/data/com.android.providers.downloads/databases/ directory stores the DownloadProvider's database, usually downloads.db, which tracks files downloaded via the Android Download Manager (e.g., APK files, images, or documents). This database records download URIs, file paths, and status, but it does not contain SMS/MMS messages or the telephony provider's mmssms.db schema. While a forensic examiner might find a downloaded MMS attachment file elsewhere (e.g., in /data/media) or a reference here, the actual message database is maintained exclusively by the telephony provider, not by the download manager.

Logical acquisition via iTunes backup

Why it fails: A logical iTunes backup only extracts user-domain files that iOS exposes through the backup API, such as contacts, messages, and app sandbox containers. It does not capture deleted records, unallocated blocks, or system partitions, and protected or exclusion-marked files may be absent. Because encryption keys for certain classes are not available to the backup process, artifacts like Health or keyboard cache can be incomplete.

Manual acquisition by browsing the device

Why it fails: Manual acquisition involves an examiner physically operating the device's UI to view and capture on-screen information, so it is limited to information the examiner can find and record. It cannot access deleted content, application databases behind normal user interfaces, or system-level artifacts, and it introduces significant risk of altering timestamp metadata through navigation. More critically, it lacks a hash-verified forensic image, making it unsuitable for defense-grade evidence.

File system acquisition via AFC (Apple File Conduit)

Why it fails: File system acquisition via Apple File Conduit (AFC) uses the AFC protocol to copy files from the device's user-accessible media partitions, sometimes including more data than a backup but still constrained to what the kernel exposes. It bypasses the backup API and may recover files that have been marked for deletion but not yet purged; however, it does not access unallocated space or deleted file slack. On un-jailbroken iOS, AFC access is normally limited to media folders, and broader access requires an exploit, still not reaching the full NAND.

MD5 hash of the malware file

Why it fails: An MD5 hash identifies only one exact byte sequence. Polymorphic and metamorphic malware deliberately alter their code with each infection, changing the hash even though the malicious behavior remains identical. This makes the MD5 hash useful for matching a specific quarantined sample but inadequate as a persistent indicator of compromise across a campaign or family.

File name of the malware

Why it fails: The on-disk filename is an extremely volatile attribute. Attackers routinely rename malware to mimic legitimate utilities, use random strings, or rely on user-downloaded filenames, meaning the same binary can appear under hundreds of names. Since it is trivially changed with no impact on execution, it cannot serve as a reliable indicator of compromise, especially when hunting for unknown or evolving variants.

Import hash (IMPHASH)

Why it fails: IMPHASH is a computed hash of the import functions in a PE file's import table, used for clustering related samples. However, the import table can vary when a malware author uses different Windows API calls, links against a different library version, or rebuilds with a different compiler or packer, producing a different IMPHASH even for functionally identical malware. It may help group samples in threat intelligence, but it is not a persistent indicator of compromise in the same way a behavioral artifact such as a registry key is.

Google account authentication tokens and sync settings

Why it fails: Google account authentication tokens and sync settings are stored in Android's /data partition, specifically within databases such as accounts.db and settings providers. A factory reset logically erases these files, but physical extraction from the raw flash memory can recover residual data from unallocated blocks, often yielding viable tokens and sync timestamps. These artifacts are critically important because they link the device to a specific Google account and reveal cloud synchronization activity, making them a high-value target for forensic analysis.

Deleted SMS messages from the mmssms.db WAL file

Why it fails: Deleted SMS messages in the mmssms.db WAL file are an unreliable source because the Write-Ahead Log (WAL) is subject to automatic checkpointing and truncation during normal operation and factory reset. Even if remnants persist in the WAL, they are typically overwritten or pruned, and recovery depends heavily on device usage after deletion. Unlike account tokens, which leave broader traces in multiple databases, SMS remnants in a truncated WAL are sparse and rarely yield complete, admissible message content.

The user's pattern lock hash stored in gatekeeper.password.key

Why it fails: The pattern lock hash stored in gatekeeper.password.key is invalidated and deleted during a factory reset, as the lock credential database is explicitly cleared to ensure the device is unlocked. Forensic tools cannot simply read this file from a reset device because the gatekeeper service no longer references it, and any residual flash data would be overwritten or rendered obsolete. Therefore, this option is incorrect as a reliable recoverable artifact, especially when compared to account tokens that persist in multiple system databases.