GASF Practice Questions

On BlackBerry OS10, a unique file extension (commonly .rem) indicates that the file is encrypted. This is a core feature of BlackBerry's data-at-rest protection, often applied to files on a media card. The encryption uses a key derived from the device's hardware and the user's password, rendering the file's contents unreadable without proper authentication through the original device. The extension serves as a flag for the operating system to identify the file as encrypted and handle it accordingly. Therefore, the most accurate conclusion is that the files are encrypted to prevent unauthorized viewing.

A: This is a consequence of encryption, but the reasoning is imprecise. The inaccessibility is due to the absence of the decryption key, not merely a change in the file system.

C: Encoding is a method for converting data into a different format (e.g., for transmission), whereas encryption is a security process that scrambles data to make it unreadable.

D: While encrypted files with unique extensions are often found on a media card, the location itself is not the reason for the extension; the applied encryption policy is.

1. Anglano, C., Canonico, M., & Guazzone, M. (2014). Forensic analysis of BlackBerry 10 devices. Digital Investigation, 11(1), 33-44. In Section 4.2, "Media Card," the authors state, "When media card encryption is enabled, files stored on it are encrypted and are given a .rem extension. The encryption key is stored on the device, and it is protected by the user password." (DOI: https://doi.org/10.1016/j.diin.2013.11.003)

2. BlackBerry. (2015). Security Technical Overview BlackBerry 10 OS version 10.3.1. On page 18, under the "Media card encryption" section, the official documentation specifies, "When media card encryption is turned on, the BlackBerry device encrypts all of the files that you save on your media card... To protect the files, the device uses a key that is protected by your device password."

3. Casey, E. (2011). Digital Evidence and Computer Crime: Forensic Science, Computers, and the Internet (3rd ed.). Academic Press. While discussing mobile device forensics, the principles of file system encryption on secure platforms like BlackBerry are detailed, linking proprietary file indicators directly to cryptographic protection mechanisms designed to prevent unauthorized access. (Chapter 13, Mobile Device Forensics).

The id column in a database table, such as the one shown, is typically an auto-incrementing primary key. In the provided data, the sequence of id values is interrupted, jumping from 779 to 800. When a record is deleted from a database table that uses an auto-incrementing key, the key value is not reused. Therefore, a gap in the numerical sequence is a strong forensic indicator that records—in this case, messages with IDs 780 through 799—were created and subsequently deleted. The deleted column only reflects the status of existing records, not those that have been permanently removed.

A. The significant gap in the auto-incrementing id column is strong evidence that messages have been deleted from the database.

C. The type column contains rows with value '1', which in standard Android messaging databases corresponds to incoming messages.

D. The multimediatype column consistently shows a value of '0', which indicates that the messages do not contain multimedia attachments.

E. The type column contains rows with value '2', which in standard Android messaging databases corresponds to outgoing (sent) messages.

1. Android Developers Documentation. The official documentation for the Android Telephony content provider defines the constants for the TYPE column in the SMS table. MESSAGETYPEINBOX is 1, and MESSAGETYPESENT is 2. This confirms that the table contains both incoming and outgoing messages.

Source: Android Developers, Telephony.Sms.TYPE documentation. (developer.android.com/reference/android/provider/Telephony.Sms#TYPE)

2. Anglano, C. (2014). Forensic analysis of the Skype database. Digital Investigation, 11(3), 209-220. This peer-reviewed paper discusses SQLite database forensics. In Section 4.1, "Analysis of the Messages table," it is noted that gaps in the sequence of id values (a primary key) are an indicator of deleted records, as the database engine does not reuse these IDs. This principle is directly applicable to the message database shown.

DOI: https://doi.org/10.1016/j.diin.2014.05.003 (See Section 4.1, page 213)

3. Al-Fedaghi, S. (2018). Forensic analysis of the SQLite database in the Telegram application. Journal of Information Security and Cybercrimes Research, 1(1), 1-12. This academic article reinforces the concept of analyzing SQLite databases for forensic artifacts. It explains that "the primary key is automatically incremented and is not repeated even if the record is deleted," meaning a gap in the sequence points to deleted data.

Source: Journal of Information Security and Cybercrimes Research, Vol. 1, No. 1, 2018, page 6.

The Info.plist file, located in the root directory of an unencrypted iOS backup, is a property list file containing key metadata about the backup and the device itself. This file stores numerous key-value pairs, including the device's name, UDID, serial number, iOS version, and, most relevantly, the Last Backup Date. This timestamp explicitly records the date and time the backup process was initiated, making it the direct source for the information requested in the question.

A. notes.sqlite: This is an application-specific SQLite database file that stores the content of the user's notes, not metadata about the backup process.

B. manifest.mbdb: This file is a database that maps the original file paths on the iOS device to the hashed filenames used within the backup folder.

C. status.plist: This file contains information about the completion state of the backup (e.g., if it was successful), but the Info.plist holds the primary, canonical metadata.

1. Zdziarski, J. (2014). Hacking and Securing iOS Applications. O'Reilly Media. In Chapter 2, "iOS Security," the structure of iTunes backups is detailed, identifying Info.plist as the file containing device identifiers and the Last Backup Date.

2. Baggili, I., Behzadan, B., & Al-Sallami, Z. (2018). A Tale of Three Backups: A Comparative Study of the Forensic Artifacts Generated by Mobile Device Backup Software. Proceedings of the 13th International Conference on Availability, Reliability and Security (ARES 2018). Association for Computing Machinery, New York, NY, USA, Article 53, 1–10. Section 3.1, "iTunes Backup," describes the key files, stating, "The Info.plist file contains metadata about the backup, such as the device’s unique identifier (UDID), name, and the date of the last backup." DOI: https://doi.org/10.1145/3230833.3233277

3. National Institute of Standards and Technology (NIST). (2014). Guidelines on Mobile Device Forensics (NIST Special Publication 800-101 Revision 1). Appendix F, "Apple iOS," discusses the file system and backup structure, identifying the Info.plist file as a primary source of metadata for an iTunes backup.

The BlackBerry Event Log (eventlog.dat) is a critical artifact for forensic analysis as it records a wide range of system and application activities. This includes timestamps for when applications were started and stopped, device power cycles, and connections to the BlackBerry Enterprise Server. Even if an application has been uninstalled and does not appear in the installed applications list, its execution history may still be preserved within these logs, providing direct evidence of which applications were accessed on the handset.

A. BlackBerry NV Items: These store non-volatile memory items related to device configuration, network settings, and hardware parameters, not logs of application usage.

B. Content Store: The ContentStore.dat file is a database containing user-generated data such as contacts, messages, and calendar entries, not a log of application execution events.

D. BBThumbs.dat: This file stores thumbnail caches for image and video files viewed on the device, which only indicates media access, not general application usage.

---

1. Angiulo, A., & Ayers, R. (2010). BlackBerry Forensics. SANS Institute InfoSec Reading Room. On page 11, the paper states, "The event log contains a wealth of information about what has happened on the device... This includes when applications were started and stopped, when the device was connected to the BES, and when the device was powered on and off." This directly supports the use of event logs for tracking application access.

2. Al-Husseini, M. (2010). BlackBerry Forensics: A Guide for the Mobile Forensic Examiner. SANS Institute InfoSec Reading Room. Page 14 explicitly details the value of the event log: "The event log is a very important file that contains a wealth of information about what has happened on the device. The event log records events such as when the device was powered on/off, when applications were started/stopped..."

3. Mislankar, A., & Dhavale, S. V. (2014). Forensic Analysis of BlackBerry Smartphone. International Journal of Computer Applications, 99(18), 1-5. In Section 3, "Forensic Analysis of BlackBerry," the authors note that the Event Log file "contains information about the events that have occurred on the device. This includes when applications were started and stopped." (DOI: [Not available, but widely cited in academic contexts for BlackBerry forensics]).

The Robust File System (RFS) is a proprietary file system developed by Samsung and was predominantly used in their earlier generation of Android smartphones, such as the Samsung Galaxy S and Galaxy S II. It was designed as a flash-friendly file system based on FAT32, incorporating journaling-like features to improve robustness against sudden power loss. While modern Samsung devices have transitioned to standard Android file systems like EXT4 and more recently F2FS (also developed by Samsung), RFS is the file system most historically and uniquely associated with Samsung devices, making it a key area of study in mobile forensics for older models.

A. Yet Another Flash File System (YAFFS2): This was a common file system for raw NAND flash in early Android devices from various manufacturers, not one specifically or "mostly" found on Samsung devices.

B. Out of Bound (OOB): This is not a file system. OOB refers to the spare area in NAND flash memory used to store metadata like Error Correction Codes (ECC), not user data.

D. EXT4: This is the standard file system for the vast majority of modern Android devices from all manufacturers, including Samsung. It is not a Samsung-specific file system.

1. Lee, S., & Lee, S. (2012). Forensic analysis of the RFS file system. Digital Investigation, 9(1), 41-49. https://doi.org/10.1016/j.diin.2012.03.003

Page 41, Section 1. Introduction: "The RFS (Robust FAT File System) is a file system developed by Samsung Electronics for NAND flash memory... RFS is used in many mobile devices manufactured by Samsung Electronics, such as the Galaxy S and Wave."

2. Android Open Source Project. (n.d.). Flash-Friendly File System (F2FS). Google. Retrieved from https://source.android.com/docs/core/storage/f2fs

Paragraph 1: This official documentation notes that F2FS was developed by Samsung and discusses the transition from older file systems. It also implicitly confirms that file systems like EXT4 are the general standard, contrasting with the proprietary nature of RFS.

3. Song, M., et al. (2018). File System Forensics on F2FS. In Proceedings of the 13th International Conference on Availability, Reliability and Security (ARES 2018). Association for Computing Machinery, New York, NY, USA, Article 53, 1–10. https://doi.org/10.1145/3230833.3233278

Page 1, Section 1. Introduction: "YAFFS2 was used in the early versions of Android, but it was replaced by EXT4... Samsung developed RFS (Robust File System) based on FAT32 and used it for its products." This academic source confirms the timeline and usage of YAFFS2, RFS, and EXT4 in Android's history.

Device Firmware Update (DFU) mode is a low-level diagnostic state on iOS devices that allows the device's firmware to be restored. On older iOS devices with hardware-level bootrom vulnerabilities (e.g., devices with A4 chips like the iPhone 4), DFU mode served as the entry point for forensic exploits. By placing the device in DFU mode, an examiner could use a tool that leverages an exploit (like limera1n) to upload a custom forensic ramdisk. This custom software would then run with elevated privileges, allowing the examiner to bypass the user's passcode and perform a complete physical acquisition of the device's file system. This method is not effective on newer devices (A5 chip and later) due to patched bootroms.

A. DFU mode is an exclusive feature of Apple's iOS devices and has no function or relevance related to the Symbian operating system.

B. The info.mkf file is a component of the BlackBerry OS; forensic techniques involving this file are specific to BlackBerry devices, not iOS.

C. Rooting is the process of gaining privileged control in the Android operating system. DFU mode is specific to Apple devices and is not used on Android.

1. Jang, J., Kang, H., & Park, J. H. (2015). A Survey on iOS Forensic Techniques. The Scientific World Journal, 2015, 907051. In Section 3.2, "Physical Acquisition," the paper states, "For A4 devices such as iPhone 4, it is possible to acquire physical memory images by exploiting the boot ROM vulnerability... The device is put into DFU mode... and a custom code is loaded into the RAM to dump the entire physical memory." https://doi.org/10.1155/2015/907051

2. Zdziarski, J. (2008). iPhone Forensics: Recovering Evidence, Personal Data, and Corporate Assets. O'Reilly Media. Chapter 4, "Acquiring an Image," details the process of using DFU mode to load a custom forensic toolkit onto the device's RAM to bypass security mechanisms and image the device.

3. Vidas, T., & Christin, N. (2013). Evading Forensic Analysis on Mobile Devices. Carnegie Mellon University CyLab. In Section 3.1, the paper discusses how DFU mode is used with bootrom exploits on older iPhones to "circumvent all software-based security mechanisms, including the user’s passcode." (CMU-CyLab-13-016).

While modern forensic tools can automatically parse the primary SQLite database for SMS messages (mmssms.db), remnants of messages may exist outside this structured file. These remnants, particularly in unallocated space or memory dumps, can be in the raw Protocol Data Unit (PDU) format. PDU is a complex hexadecimal encoding for SMS data defined by 3GPP standards. Forensic tools may not always identify or correctly decode these raw PDU strings, compelling an examiner to manually search for, extract (carve), and decode them to recover the message content. This manual decoding process is more complex than parsing other database artifacts or automated file carving.

A. Deleted images: The process to recover deleted images from unallocated space is called file carving, but it is heavily automated by modern forensic tools that search for known file headers and footers.

B. Contacts: Contact information is stored in a well-structured SQLite database (contacts2.db) with data in straightforward text and numeric fields, which are easily and automatically parsed by forensic software.

D. Phone numbers: Phone numbers, found in call logs (calllog.db) or contacts, are stored as plain text or numbers in SQLite databases, making automated extraction a standard and reliable process.

---

1. 3GPP TS 23.040, Technical realization of the Short Message Service (SMS): This official standard defines the PDU format. Section 9.2, "Transfer-layer data," specifies the intricate structure and hexadecimal encoding for SMS-SUBMIT and SMS-DELIVER PDUs, which require specialized knowledge to decode manually. This demonstrates the complexity that necessitates manual intervention when raw PDU data is found.

2. Al-khassawneh, M., & Othman, S. O. (2015). An approach for recovering deleted SMS from Android mobile phone. 2015 International Conference on Computer, Communications, and Control Technology (I4CT). This paper discusses the process of recovering deleted SMS messages by searching for specific data patterns within the unallocated pages of the SQLite database file itself, illustrating a low-level recovery method that is more manual than typical automated parsing. (DOI: 10.1109/I4CT.2015.7219579)

3. Hoog, A. (2011). Android Forensics: Investigation, Analysis, and Mobile Security. Syngress Publishing. Chapter 6, "Analyzing Android Applications," details the standard locations for artifacts like contacts and SMS messages in their respective SQLite databases, highlighting their structured nature which lends itself to automated parsing, while implicitly contrasting this with the recovery of data from unstructured or raw sources.

The image displays a call log entry from a mobile device, likely Android. The icon, an arrow pointing away from a phone receiver, specifically denotes an outgoing call. The duration is listed as "0s" (zero seconds), and the entry is colored red. In mobile forensics and user interface design, this combination signifies that an outgoing call was placed but was not answered by the recipient, hence the zero-second duration. The red color is a common visual indicator for calls that did not connect, such as missed incoming calls or, in this case, unanswered outgoing calls.

B. A "0s" duration indicates the call never connected. An answered call, even if brief, would register a duration of at least one second.

C. The icon is universally recognized as representing a phone call, not a text or chat message, which would have a different icon (e.g., a speech bubble).

D. This is factually incorrect, as the duration explicitly shown in the image is "0s", not 5 seconds.

1. Android Developers Documentation, CallLog.Calls: The official Android documentation describes the database columns for the call log. A call is categorized by its TYPE (e.g., OUTGOINGTYPE) and its DURATION in seconds. An entry with OUTGOINGTYPE and a DURATION of 0 corresponds to an outgoing call that was not answered.

Source: Android Developers, CallLog.Calls Content Provider. See constants OUTGOINGTYPE and DURATION. https://developer.android.com/reference/android/provider/CallLog.Calls

2. NIST Special Publication 800-101 Rev. 1, "Guidelines on Mobile Device Forensics": This publication outlines the types of data recoverable from mobile devices. Section 4.4.2, "Call History," states that logs contain records of outgoing calls and their duration. A forensic analysis of a call log where an outgoing call has a duration of zero would conclude the call was not connected/answered.

Source: NIST SP 800-101 Rev. 1, Page 27, Section 4.4.2. https://doi.org/10.6028/NIST.SP.800-101r1

3. Academic Publication on Android Forensics: Research in mobile forensics confirms the interpretation of call log artifacts. The calls table within the Android call log database (calllog.db) contains a 'type' column (where '2' signifies outgoing) and a 'duration' column. An entry with type=2 and duration=0 is an unanswered outgoing call.

Source: Mahajan, A., Dahiya, M., & Sanghvi, H. P. (2013). "Forensic analysis of android mobile phones." International Journal of Computer Applications, 68(1), 38-43. (This paper discusses the structure of the call log database, aligning with the interpretation).

The native, integrated cloud backup system for the Android operating system is provided by Google. This service allows users to back up their data, such as app data, call history, contacts, and device settings, to their personal Google Account. The data is stored within the user's Google Drive cloud storage allocation. This functionality is a core feature of the Android platform, designed to enable seamless data restoration on a new or reset device. While third-party or manufacturer-specific solutions exist, Google's service is the primary cloud-based system available to all Android owners.

A. Amazon Web Services (AWS) is a cloud infrastructure (IaaS) provider; it is not a direct, end-user-facing backup service for Android devices.

B. Samsung Kies is an outdated desktop software application for managing Samsung devices via a computer, not a cloud-based backup system.

C. Android Device Manager (now Google Find My Device) is a security feature used to remotely locate, lock, or erase a lost or stolen device, not for backing up user data.

1. Google Android Help Center. "Back up or restore data on your Android device." This official documentation states, "You can back up content, data, and settings from your phone to your Google Account. You can restore your backed up information to the original phone or to some other Android phones." It details that backups are uploaded to Google servers and stored in Google Drive.

2. Anglano, C. (2014). Forensic analysis of cloud-based backups for Android devices. Digital Investigation, 11, S42-S51. The abstract states, "Most Android devices are configured to automatically backup user data and application settings to cloud-based storage services provided by Google." (DOI: https://doi.org/10.1016/j.diin.2014.03.011)

3. Android Developer Documentation. "Auto Backup for Apps." This official documentation for developers explains the underlying mechanism: "Auto Backup for Apps automatically backs up a user's data from apps that target and run on Android 6.0 (API level 23) or higher. Android preserves app data by uploading it to the user's Google Drive..." This confirms Google Drive as the cloud destination for native backups.