SANS Institute’s six-step framework is a useful starting point. The harder task is proving what an acquired record actually means—and showing another examiner how you checked it.
Viktor (Dante) BurcevskiWildfire Data Recovery · IACIS CFCE 12 October 2026 · 15 min read · 32 primary references
Mobile forensics on the Wildfire bench. An acquisition supplies material to examine; validation tests the findings drawn from it.
A message appears in a forensic report. Its text is readable, its timestamp looks precise and an account name sits beside it. How much of the resulting story has actually been tested?
That question is the centre of mobile forensic validation. A successful extraction, a plausible parser result and a defensible interpretation answer different questions. Treating them as one result makes it easy to be confident about a claim that the data only partly supports.
SANS’s 2021 collaboration explains why examiners must check significant findings beyond a single tool’s output. NIST’s scientific foundation review reaches a compatible conclusion: digital methods have established foundations, while incomplete discovery, recovered extraneous material and changing software behaviour still require care. [2][6]
Three questions behind every important finding
Wildfire’s explanatory model for this article. These are overlapping checks, not a separate SANS standard.
01 · ACQUISITION
What did we obtain?
Identify the source, capture method, coverage and changes made during collection.
02 · DECODING
Did we read it correctly?
Check the source records, relationships, time conversion and parser behaviour.
03 · INTERPRETATION
Does it support the claim?
Test event meaning, alternative explanations, attribution and the limits of the conclusion.
This article develops that distinction using the SANS framework and 30 additional primary references. The examples are original teaching scenarios, not client evidence or a claim that a particular tool has failed.
The starting point · May 2021
SANS’s six steps, in plain language.
The original paper is Six Steps to Successful Mobile Validation. This short summary follows its sequence; the practical analysis that follows is Wildfire’s own. [1]
01
Choose the extraction methods
Determine the authorised options, consider their risks and start with the safest suitable approach.
What to document
Record the method, device state, coverage and any acquisition changes.
02
Compare tools
Process essential evidence with more than one tool and investigate differences in parsing, filtering and time display.
What to document
Keep the tool versions, settings and discrepancies that affect the finding.
03
Examine the underlying data
Go beyond automation when needed. Check surviving records and their context directly.
What to document
Identify the source file, relevant record and any acquired companion files.
04
Validate the findings
Trace important results to their source, check timestamps and use corroboration or controlled tests.
What to document
Keep the raw values, reproduced conversions and controlled-test results.
05
Report what is supported
Present relevant, checked findings and distinguish observations from opinions.
What to document
State the supported conclusion, remaining limits and basis for opinions.
06
Keep learning
Revisit assumptions as devices, apps, methods and forensic tools change.
What to document
Identify changes that require targeted retesting or revised limitations.
The paper is methodological guidance from 2021, not a current device-support list. The appropriate depth of examination depends on the question, available material and authorised scope.
Question 01
Validate the acquisition before counting the records.
An extraction description should establish what was acquired: a backup, supported files, a broader file-system extraction or another method. It should also identify failures, excluded areas and the device state. NIST separates collection and examination from later analysis; mobile guidance makes the acquisition method part of understanding the result. [3][4]
Preservation is a recorded process. The examiner needs the device identity, custody history, power and lock state, relevant interactions, acquisition settings and resulting files. Mobile devices continue to change while active, and network-isolation methods have limitations. A generic instruction to reboot every phone or remove every SIM ignores those differences. [5][11]
On Apple devices
Data Protection applies different access conditions to files. Keybags manage class keys, and the Secure Enclave is part of the security architecture. An accessible screen does not establish that every protected file is available to an acquisition method. [17][18][19][20]
On Android devices
Device-encrypted and credential-encrypted storage are distinct. Direct Boot documentation explains that credential-encrypted storage becomes available after the user’s first successful unlock and remains available until restart. Supported forensic access still depends on the particular device and method. [22][23]
Backups also have their own boundaries. Apple documents differences between computer and iCloud backups, including content affected by encryption and cloud synchronisation. Android Auto Backup applies app rules, exclusions and per-app limits. Neither backup label, by itself, establishes a complete record of handset activity. [21][24]
Practical consequence: define the finding against the acquired material. “No matching record was located in this extraction” is a narrower statement than “that event never occurred.” Preserve the distinction when writing the report.
Question 02
Validate the decoding at the source.
A second tool is useful because it can expose disagreements. Our interpretation of that check is deliberately modest: agreement increases confidence, but is not automatically independent proof. Two exports of the same parser result have not added a new test. The stronger check connects the material, the method used to read it and the expected behaviour. [10][12][14]
Acquired materialDatabase, log or file
→
Source recordField, row or byte location
→
Decoded resultMeaning and conversion
SQLite provides a concrete example. In write-ahead logging mode, committed changes can sit in the WAL before they are checkpointed into the main database. Reviewing only a copied .db file may therefore produce an incomplete view. Preserve acquired companion files and examine working copies using a method that accounts for them. [25]
Interactive graph · Synthetic dataset
One database. Three different views.
In this teaching example, six message rows are checkpointed into the main database. Two newer inserts are committed in its WAL. Change the view to see why an isolated database copy can omit recent records.
Message rows visible in this example6 / 8
6 main
Main databaseCommitted WAL insertsStriped area: omitted from this view
M01M02M03M04M05M06M07*M08*
Main database only: M07 and M08 are absent from this isolated view. That does not establish that the events never occurred.
*The two newer row identifiers are known from the teaching dataset. This model contains inserts only. Real WAL pages can update or delete records too: file counts must not simply be added. Checkpointing is illustrated here, not an instruction to alter original evidence.
The database format also distinguishes structured records from free space and freelist pages. A carved fragment needs its own explanation: where it survived, which fields were reconstructed and which relationships are missing. SQLite’s deletion settings can overwrite deleted content, while some virtual-table shadow data may behave differently. The presence or absence of a fragment needs investigation, not a blanket recovery promise. [26][27]
For an important message, a useful validation note identifies the source path, table or record location, relevant identifiers, raw values and the steps used to interpret them. It also explains differences between tools rather than quietly selecting the output that best fits the expected story.
What a matching hash answers
A cryptographic digest helps detect changes to the bytes hashed. A matching hash between an acquired file and its working copy supports copy integrity. It does not establish acquisition completeness, correct parsing, the meaning of a timestamp or the identity of the person who acted. [30]
Question 03
Validate the claim, not just the date on the screen.
A timestamp has at least three layers to resolve: its storage representation, the event it describes and the way the tool displays it. A date attached to a row could describe creation, receipt, editing, import or synchronisation. The app’s behaviour and surrounding records determine which interpretation is supported.
Epochs and units matter. Apple’s CFAbsoluteTime uses a reference date of 1 January 2001. SQLite’s date functions accept several representations, including ISO text, Julian values and Unix timestamps. A number that converts neatly into a recent date is not, on that basis alone, a validated event time. [31][32]
Interactive timestamp lab
A stored number needs a decoding rule.
Change the epoch, unit or display offset. Watch how the same number can produce a different date—and how two offset displays can represent the same instant.
UTC representation
=
Selected offset representation
02:30UTC clock
↔
12:30Selected offset clock
Each preset describes the article’s hypothetical 12:30 example. Changing the display offset preserves the instant; changing the epoch or unit changes the decoding. The tool does not establish what event a field describes. Offsets here are fixed, without regional daylight-saving rules. CFAbsoluteTime is defined in seconds; the milliseconds option illustrates an explicitly scaled storage representation, not its native unit.
RFC 3339 supports explicit offsets. Regional time-zone rules introduce another consideration: the relevant historical rule and database version may matter, especially where daylight-saving or political changes are involved. Preserve the raw value and record the conversion instead of relying on a screen label alone. [28][29]
Attribution needs its own argument. A record associated with an account or device is an observation about that record. Saying a particular person performed the action adds a further inference. A useful report describes what connects the person to the event, what other explanation was considered and what remains unresolved.
These cautions are consistent with NIST’s discussion of changing artefact meaning and SWGDE’s approach to identifying possible errors. Our practical extension is to write the proposed conclusion first, then ask which parts of it the available records actually test. [6][14]
Original teaching example
A message at 12:30. What can we say?
A hypothetical acquired app database contains a message row. It is not a Wildfire client case.
Observation
A row contains message text, an account identifier and a raw time value. The reported source and record location allow another examiner to locate it.
Decoding check
A separate check reproduces the time conversion. The examiner verifies which field was converted and checks associated records, including any acquired WAL data.
Meaning check
A controlled test on separate material explores whether the field changes on sending, receipt, import or editing. Differences in app version are recorded.
Supported wording
“The acquired database contains this record. The identified time field converts to 12:30 at +10:00. The tests described support its interpretation as [event].” Name the event only after the test supports it.
Remaining limit
Those checks alone do not identify the human operator or establish that the message was read. Additional evidence would be needed for either claim.
Interactive reasoning exercise
Which parts of the finding were checked?
Use the hypothetical message above. Mark the checks as documented and see which parts of the proposed wording still need support.
SourceDOCUMENTED
Time conversionNOT DOCUMENTED
Event meaningNOT DOCUMENTED
Source observation only
“The acquired database contains the identified message row.” The displayed time and event meaning still need validation.
Attribution remains a separate question. These checks alone do not identify the human operator or establish that the message was read.
This is a visual record of selected checks, not a confidence score or a forensic certification. A checked box represents a documented examination step in the example; it does not perform that step or guarantee its result.
Make the test answer a question
Build validation around known actions.
A practical test starts with an expected result that was established independently of the tool being assessed. Record the actions on a separate test device or dataset, acquire the resulting material and compare the result with that record. NIST’s mobile test-device guidance and CFReDS resources support documented reference data; CFTT supplies test specifications rather than a universal promise about every tool, version or case. [7][8][9]
Fix the questionDoes this field distinguish sending from receiving, or does it record another event?
Record the environmentIdentify the model, OS, app build, tool version and relevant settings.
Vary one relevant conditionFor example, compare an original message with an imported copy on separate test material.
Keep the discrepancyRecord unexpected results and the effect on the proposed finding.
Tool dependency cuts the other way as well. When a supplier’s future is uncertain, the ability to return to the evidence matters more than the licence, which is the question we examined in The Demise of Oxygen Forensic Detective?
Interactive comparison · Synthetic test
Agreement is visible. Accuracy needs a reference.
A controlled message-send action was independently recorded at 12:30. These invented parser displays show how two tools can agree while sharing the same five-minute error.
Displayed time · local clock · one controlled send action
Known action
12:30
Parser A
12:35
Parser B
12:35
12:3012:3512:40
Agreement, with a shared error. Both displays are five minutes later than the independently recorded action. A second matching export has not validated the event time.
Original Wildfire teaching graph. Parser A and Parser B are fictional; the five-minute offsets are chosen for illustration. This is not a product benchmark. Even a matching time validates only the function and scenario tested, not every capability or the identity of a person.
A test of one behaviour does not validate every capability of a product. A successful message-time test says little about location parsing, deleted-data reconstruction or another app build. SWGDE’s tool-testing guidance ties testing to function and limitations. NIST’s 2025 validation guidance reinforces the need for organised collection and use of validation data. [10][16]
The useful question after an update is therefore specific: has a change affected an operation, format or interpretation that this matter relies on? The answer may call for targeted testing, revised limitations or a different method. It should be documented rather than hidden behind the software’s release number.
From examination to explanation
A report should let someone check the reasoning.
SWGDE distinguishes the examiner’s report from tool-generated supporting material. Its reporting guidance calls for clear results, an overview of the processes, the basis for opinions and documented amendments when needed. A large automated export can be useful, but it does not itself explain why a selected record answers the question. [13]
For a contested finding, we recommend a compact chain of reasoning: identify the question, locate the material, describe the check, state the conclusion and name the remaining limit. This is a suggested presentation approach for the reader, not a claim that SANS prescribes a particular report template.
Source and scopeWhat material was examined, and what was outside the acquisition or instruction?
Method and resultWhich checks support the reported observation and interpretation?
Limits and alternativesWhat could not be tested, and which other explanations remain?
Review and correctionWho checked the work, and how will any necessary amendment be identified?
Quality assurance gives those habits an organisational home: documented procedures, competent personnel and appropriate review. The separation between acquisition, examination, analysis and reporting also helps a reader distinguish a technical observation from its interpretation. [15][4]
For a client, the most useful opening instruction is a question that can be investigated: “What surviving records show contact between these accounts during this period?” That creates a clearer examination scope than an instruction to prove a conclusion in advance.
32 primary references · All visible
The sources behind the analysis.
Two SANS resources establish the starting framework. Thirty additional references support the technical analysis. Older publications are identified by their dates or document numbers; they are not device-support guarantees. Links checked 12 October 2026.
ISO text, Julian dates and Unix timestamps need explicit interpretation.
This is independent Wildfire commentary. Reference to SANS, NIST, SWGDE, Apple, Android, SQLite, IETF or IANA does not imply endorsement, affiliation or certification by those organisations. Read the original documents for their full scope and qualifications.
Viktor (Dante) Burcevski
Executive Data Engineer/Owner, Wildfire Data Recovery. IACIS Certified Forensic Computer Examiner (CFCE). Wildfire’s Brisbane laboratory accepts matters from across Australia.
Tell us what you need to establish, which device or extraction is available and any deadline. We can discuss an authorised examination scope, the available methods and the limits to address in the report.
TESTER