GASF Study Guide: Linking Claims to Mobile Artifacts

Study GASF by pairing every conclusion with its supporting artifact. When you learn an iOS or Android data store, write down what claim it supports, what it cannot prove, and which neighboring files (WAL, journal, plist, preferences XML) change that answer. Practice on lab-generated data, compare what different extraction levels expose, and check yourself with a rubric rather than a vague sense of familiarity.

Why artifact-to-claim pairing is the study skill GASF rewards

Learn each mobile artifact as a claim-support pair: the conclusion you could draw and the exact file, table, or key that supports it. Isolated memorization of artifact names collapses when a question asks what a value proves, or what a neighboring file changes.

A working examiner rarely gets asked 'where are text messages stored.' The harder version is 'given this table and this surrounding file set, what can you say about the user's activity, and what can you not say?' That requires knowing that a message row carries sender, direction, and delivery state in specific columns, that deletion behaves differently depending on database settings and journaling mode, and that your extraction level determines whether you ever see the underlying rows at all.

Build this habit deliberately. Every time you study an artifact — an iOS database, an Android XML preference file, a backup manifest — write two sentences: 'this supports a conclusion that...' and 'this does not distinguish between...'. When the pair is incomplete, you have found a gap to fill with hands-on work rather than another pass over notes. This converts passive review into the reasoning the exam objectives describe: file system analysis, application behavior, and event interpretation.

Choosing between logical, file system, and physical acquisition in scenarios

Decide the extraction level by what data you need and what access the device allows, then state the limitation that level imposes on your conclusions. Each level answers a different class of question.

Logical acquisition typically yields app-level data through the device's own backup or sync mechanisms, which means you see data the backup path exposes. File system acquisition yields the broader directory structure, including databases, plists, and preference files that a logical backup may omit. Physical acquisition captures raw storage, which is where deleted-data recovery possibilities live, but it is device- and OS-dependent and not always available. The exam scenarios ask you to reason about what each level contains, so study the boundaries, not just definitions.

A useful drill: for one practice device, run a logical pass and a file system pass, then diff the file inventories. List three artifacts present only in the file system set, such as application sandbox contents or system logs, and write one sentence each on what conclusion they could support that the logical set could not. This trains the scenario instinct — when a question describes a locked device, an unlocked device, or an available backup, you should immediately map it to which data is in play.

SQLite write-ahead logging: the WAL file changes what your report says

SQLite databases read differently with and without their -wal and -shm companion files. Transactions can be committed in the WAL but not yet checkpointed into the main database, so parsing the .db alone can omit recent committed data.

Scenario one. You image a lab iPhone, open a messaging database, and count twelve message rows. You then notice a -wal file alongside it. After copying the full file set — main database, -wal, and -shm — into one working folder and re-parsing, the combined view shows forty messages. A first mistake is reporting only twelve because you parsed the .db in isolation; a second mistake is the opposite overreach: declaring the extra twenty-eight 'deleted messages.' Neither is correct. Those transactions were committed by the app but not yet checkpointed into the main database file, which is a normal state for write-ahead-logging databases between checkpoints.

The defensible wording distinguishes committed-but-uncheckpointed data from deleted data, and it matters: an accurate report says recent activity was present in the write-ahead log, while deletion claims need their own evidence, such as freed pages or carved records. The same principle applies to rollback journals in the alternative journaling mode. Practice this on your own lab device: generate messages, pull the database trio, and parse each file separately and together. The observation — differing counts and which file holds them — is the learning outcome, not a tool screenshot.

Scenario two sharpens the reporting side. In an Android app's Shared Preferences XML you find a key holding a Unix-style timestamp. The tempting reading is 'user opened the app at this time.' The better decision is to identify the key's role before attributing it: trace the key name against the app's behavior on your lab instance, or compare how the value changes across controlled uses. If it updates on background sync rather than user interaction, your report must say synchronization marker, not user action. The lesson generalizes: a value's meaning lives in the code or corroborating artifacts, not in its format alone.

iOS structure you must navigate: plists, backup domains, and Manifest.db

iOS stores settings and state in property lists, and file system images organize content into domains. Know where each artifact class lives and what the domain structure tells you about an app's data.

Property lists come in XML and binary formats and hold configuration, state, and preferences for both system services and applications. Practically, you should be able to open a binary plist, convert or read it with standard tooling, and describe what a given key supports as a claim — for example, a settings key versus a last-connected timestamp. Alongside plists, iOS relies heavily on SQLite for structured app data, so the WAL reasoning from the previous section applies across the iOS artifact set.

For file system work, learn the domain layout used in iOS backups, where each application's data is grouped under a domain identifier and mapped through a manifest database that records original file paths. The exercise that cements this: take a lab backup, locate an app's domain via the manifest, and map three files in that domain — its database, its plists, and its library contents — writing one claim-support pair for each. Then compare with the same app's data on a second lab device. Consistency across devices tells you which values are stable indicators rather than device-specific noise.

• Plist formats: recognize XML versus binary plists and read both with tooling you have practiced
• Manifest mapping: use the manifest database to translate backup filenames back to original paths
• Domain grouping: identify which domain an app's data lives in before interpreting its files
• Claim-support pairs: for each plist key or table column, record what conclusion it supports and what it cannot distinguish

Android structure you must navigate: sandbox paths, preferences, and APK context

Android confines each app's private data to its sandbox under /data/data, with Shared Preferences in XML and structured data in SQLite. Interpret app data against the package name and the app's own code.

The sandbox layout is the anchor: an app's private databases, preference XML files, and cached content live under its package directory, while media and other shared content typically live in shared storage. Knowing which location a file came from already constrains your interpretation — private sandbox data belongs to that app's behavior, while shared storage may have many writers. ADB access on a lab device lets you walk these paths and observe them directly, which is far more durable than reading path lists.

Pair the file layout with the package identity. Decompile or inspect the app's APK on a lab machine to see the code that writes the keys and tables you found, because key names alone rarely reveal meaning — the scenario-two mistake in the SQLite section illustrates how a timestamp can be a sync marker rather than a user action. A compact drill: install a messaging app on a lab device, send test messages, pull its sandbox, then annotate each significant file with its role: database, preferences, cache, external media. Repeat with a second app and compare which artifact classes recur across apps.

Third-party app analysis and mobile malware handling without overclaiming

Third-party app analysis means identifying the app, understanding its stored data, and dating activity from its artifacts. Malware analysis means detecting and characterizing suspicious behavior with controlled tools, reporting observations rather than verdicts you cannot support.

For app analysis, the exam's objective language emphasizes reviewing and investigating third-party application activity. Method: identify the package, locate its data in the sandbox or backup domain, parse its databases and preferences, and correlate timestamps across artifacts — for instance, an install-time indicator, a settings change, and message records should tell a coherent story or the discrepancy becomes a finding in itself. Keep claim-support pairs attached to every correlation so a gap in support is visible in your own notes.

For malware, the objectives cover how mobile malware interacts with Android and iOS and the tools used to detect and analyze malicious activity. Keep the work contained: analyze samples and indicators on isolated lab machines, not on casework or personal devices, and treat detection results as observations to verify — a package name, a requested permission set, a callback domain, a persistence mechanism. Report what the artifact shows, such as the app's presence and the behaviors its code or configuration exhibits, and avoid definitive attribution language beyond what your evidence supports. Practicing with a known lab sample and writing a two-paragraph observation report is a realistic exercise here.

• Correlation targets: install indicators, settings changes, message records, and network-related artifacts should agree
• Malware hygiene: isolated analysis environments only; never examine samples on production or personal hardware
• Verdict discipline: report observed indicators and behaviors; distinguish detection from attribution

An adaptable preparation sequence and readiness checks

Sequence your preparation as build-lab, master-SQLite, then iOS set, then Android set, then apps and malware, then integrate. Check readiness with performance tests — can you produce the artifact and defend the claim — not with review comfort.

A realistic four-block sequence: Block one, set up an isolated lab with one Android and, where feasible, one iOS test device plus analysis tooling, and generate your own reference data. Block two, master SQLite internals — journaling modes, WAL behavior, schema reading — until you can run the WAL exercise above and predict its outcome. Block three, work the iOS artifact set and backup structure; block four, the Android set, then third-party apps and malware observation. Adjust the weighting toward whichever platform is less familiar to you; the sequence order, not the calendar, is what matters.

Readiness checks to finish with, all performance-based: you can write five iOS and five Android claim-support pairs from memory and defend them on lab data; you can explain what changes in your report when the -wal file is present versus absent; you can map a backup filename to its original path through the manifest; you can state what your extraction level excludes; and you can produce a one-page observation report for a lab app or sample. If any check stalls, return to that block's hands-on exercise rather than re-reading notes. For current administrative details about the credential and its exam, rely on GIAC's own certification page linked below.

• Check 1: produce ten claim-support pairs across both platforms from memory
• Check 2: run the WAL exercise and predict the count differences before parsing
• Check 3: map three backup files to original paths via the manifest
• Check 4: write a one-page malware observation report on an isolated lab sample
• Check 5: state, for each practice extraction, which conclusions that level cannot support

References and further reading

Use these references to explore the concepts and check the latest information from the relevant organizations.

• giac.org

Continue your preparation

• Giac Advanced Smartphone Forensics Gasf
• Study Guides