Organize your CMFE preparation around the evidence chain: acquisition method, storage location, and interpretation. Learn what logical, file system, physical, and cloud acquisitions each reach; trace Android and iOS artifacts to their actual databases and property lists; practice decoding with a control device loaded with known data; and treat legal topics as documentation habits. Work through the two scenarios and the self-check rubric below, and confirm current administrative requirements directly with IACIS.
Anchor your CMFE notes to the evidence chain, not tool menus
Mobile forensic findings are meaningful only when you can name the acquisition method, the storage source, and the interpretation applied. Build every study note as that three-part chain so tool features connect to evidence origins you can explain.
IACIS's mobile device forensics training explicitly aims to take students behind the automation of popular tools, and its broader catalog emphasizes validation and defensible method. Mirror that philosophy in your notes: for each artifact you study, record which file, database, or partition it lives in, which acquisition level reaches it, and how parsers convert it into readable form. A report entry you can trace end to end is knowledge; one you cannot is a button you once pressed.
Convert this into a study format immediately. Use a three-column layout for every artifact: what the examiner sees in the report, where it originates on the device, and what acquisition path retrieves it. When you review iOS or Android topics, fill columns from memory first, then check references. Gaps in the middle column are the signal that you know a tool feature but not the evidence beneath it, and those gaps are exactly what a certification process for examiners is designed to probe.
Logical, file system, and physical extraction recover different evidence
Each acquisition level reaches a different slice of a device. Treating them as interchangeable leads to wrong conclusions about what data exists. Learn what each method typically reaches and what structurally limits it.
Logical acquisition works through device interfaces and protocols, retrieving data the operating system chooses to expose, such as synchronized app data, media, and device identifiers. File system acquisition reaches further into app sandboxes and system databases. Physical acquisition images partitions or the whole storage, which is what makes unallocated space and carved deleted data possible, but secure hardware and full-disk encryption can limit or block it. Cloud acquisition is different again: it reflects an account's synced and backed-up content, which may overlap only partially with the device in hand.
Study each level with two questions: what does this method structurally include, and what does it structurally exclude? For example, a logical extraction that shows no deleted photos does not establish that no deleted photos exist; it establishes that this method did not surface them. Practice articulating those boundaries in one sentence per method, because examiners must scope their conclusions to their acquisition, and a certification that tests mobile fundamentals will expect the same discipline from you.
| Acquisition method | What it typically reaches | Key structural limitation |
|---|---|---|
| Logical | Data exposed through device interfaces: supported app data, media, device information | Limited to what interfaces expose; deleted content is rarely included |
| File system | App sandboxes and system databases beyond what logical protocols expose | Often requires elevated access; some protected containers remain out of reach |
| Physical | Partition or full-storage image, including unallocated space where recoverable | Most technically demanding; encryption and secure hardware may constrain results |
| Cloud | Account-linked backups and synchronized content tied to the account, not only the handset | Scope depends on the account, the authorization obtained, and the provider's data model |
Android: trace app messages to the database before trusting a report
Android application data lives mainly in per-app private directories as SQLite databases and related files. Learn to locate those sources and account for write-ahead logs before accepting a tool's empty result as proof of absence.
Worked scenario: a logical extraction of a seized Android phone shows no messages from a particular chat application, and the examiner drafts a report stating the app contains no relevant messages. The mistake is treating an empty result from one acquisition level as a fact about the device. A chat app that stores conversations in a private SQLite database may not expose that database through the logical protocols used, or recent writes may sit in a write-ahead log (WAL) file that the tool's parser did not merge into its output.
The better decision is to state the finding precisely: the logical extraction of this method surfaced no messages from that application, and then to pursue a file system acquisition where authorized, locate the app's database and its -wal and -journal companions, and examine the raw tables directly. This matters because the two drafts are different documents. One asserts the app held nothing; the other accurately reports what was recovered, at what level, and what a deeper method might still address. Treat this as a simplified teaching case: real behavior varies by application, device state, and tooling, which is exactly why the trace-to-source habit matters.
iOS: separate device facts from backup-container facts and verify timestamps
iOS evidence can come from the device or from backup containers, and timestamps appear in several encodings. Reporting a container artifact as a device fact, or converting a timestamp with the wrong assumption, produces unsupported conclusions.
Worked scenario: an examiner analyzing an iTunes-style computer backup quotes a backup metadata property as the date the phone was last used. The mistake is provenance confusion: that property describes the backup container, not the device. The better decision is to label every finding with its provenance and support any device-use timeline with on-device artifacts corroborated at an appropriate acquisition level. This matters because a report sentence that reads as a device fact but rests on a container property overstates the evidence, and that overstatement is discoverable the moment another examiner looks at the source file.
Second, make timestamp encodings a drilled skill rather than a passing acquaintance. Mobile artifacts commonly store time as Unix epoch values, Mac absolute time, or WebKit-style timestamps, and confusion between seconds and milliseconds shifts dates by orders of magnitude while time zones shift them by hours. Build a personal conversion check: take one known event on a test device, find its stored value, identify the encoding, convert it, and confirm it matches your recorded wall-clock time. Repeat until you can classify an unfamiliar value's plausible encoding from its magnitude alone.
Decoding app data: practice with a control device and known answers
Application analysis is best learned against data whose true values you already know. Load a device you control with recorded test content, extract it, and compare tool output, raw databases, and your ground truth at every layer.
Exercise: take a spare or secondary Android device you own and record everything you load into two or three apps: exact message texts, contact entries, and the wall-clock times you created them. Perform a logical extraction with whatever authorized tooling is available to you, then locate the underlying SQLite database for one app and compare it against both the tool's report and your ground truth. Work through the self-check rubric below and note where the three views differ.
Expected observations: timestamps may be stored in UTC and differ from your wall-clock time by your zone offset; the app's interface data may be spread across several tables with the report grouping them differently; and a write-ahead log or journal file may contain rows not yet merged into the main database file. A workable rubric: (1) you located the database file; (2) you identified the table holding the test content; (3) you explained what the WAL or journal contributed; (4) you converted a timestamp and matched it to your known entry; (5) you wrote a one-sentence provenance statement for each finding. These are learning milestones, not pass predictions.
Legal and ethical topics: study them as documentation habits
Legal and ethical exam content is best mastered as habits: know your authority's scope, document each step repeatably, validate tools and methods, and report only what the evidence at hand supports at its acquisition level.
Scope of authority comes first. Whatever authorizes an examination, such as consent, an order, or an organizational policy, defines which devices, accounts, and data categories are fair game, and cloud content in particular can raise scope questions that a device search does not. Practice describing, in neutral language, how you would confirm that a planned examination stays within the authorization obtained, and what you would do when data outside that scope appears, such as isolating it and seeking guidance rather than analyzing further.
Then treat documentation and validation as a paired discipline. IACIS's own catalog stresses validated methods and quality documentation across its training, and the habit generalizes: record acquisition method and version, hash evidence, log every processing step, and distinguish in your writing between what a parser decoded, what you verified in raw data, and what you inferred. Write three practice findings, one of each type, using deliberately different certainty language. The skill being built is precision under scrutiny: any qualified examiner should be able to retrace your path from device to conclusion using your notes alone.
A six-week adaptable sequence with concrete readiness checks
Sequence your preparation from acquisition fundamentals through platform artifacts, hands-on decoding, and documentation, finishing with mixed review. Finish only when you pass the readiness checks below without notes.
A realistic sequence: weeks one and two, master the acquisition-level table and rebuild it from memory, adding one paragraph per method on structural limits; week three, Android artifacts, tracing at least five artifact types to their sources and completing the scenario in the Android section; week four, iOS artifacts and timestamp encodings, completing the provenance scenario and the conversion drill; week five, run the full control-device exercise against the rubric; week six, documentation habits, legal scope reasoning, and mixed practice questions using the free practice set. Compress or stretch the weeks to fit your schedule; the order, which always moves from sources to tools to documentation, is the part worth keeping.
Readiness checks: explain each acquisition level and its limits without notes; map five common artifacts per platform to their storage locations; correctly convert one example each of epoch, Mac absolute time, and WebKit timestamps; explain in two sentences what a WAL file is and why it matters; articulate how you would confirm examination scope; and complete the control-device exercise with all five rubric items met. Treat a miss on any check as a signal to revisit that section rather than as a prediction about the exam. For current administrative requirements, formats, and eligibility details for the CMFE, rely on the issuer directly at iacis.com rather than on secondary summaries.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.