ZEKASTRA / FORENSIC / METHODS

Four methods. Every assumption visible.

Work through a source-defined representation, an exact synthetic example and the checks needed before interpretation. Each method leads to an existing tool or lab.

Educational examples only. No evidence file is read on this page; the methods do not claim a validated acquisition or live investigation.

METHOD · time-normalization

01 · From source timestamp to defensible UTC

Identify the source field, representation and unit before conversion. UTC is a common comparison scale, not proof that separate source clocks agreed.

Investigation question

When a FILETIME, FAT last-write and ISO +03:00 entry refer to an event, when do they become comparable?

Repeatable procedure

Record the exact producer and field (for example FILETIME DWORD pair or named application column). Never infer seconds versus milliseconds by digit count.
Match epoch, unit, signedness and null/sentinel policy to the documented representation. FILETIME uses 100 ns units from 1601 UTC, POSIX seconds from 1970 UTC.
Convert using exact integers. Subtract 116444736000000000 FILETIME ticks for Unix-relative 100 ns ticks; preserve the fractional ticks and reject out-of-range inputs.
FAT last-write is local wall time. State the offset assumption and examine historic daylight-saving settings or corroborating clock records.
Order normalized UTC instants while retaining the original values. Matching values do not by themselves prove physically simultaneous actions.

Synthetic raw input

FILETIME: 116444736000000001 (100 ns)
ISO: 1970-01-01T03:00:00+03:00

Expected interpretation / check

ISO is 1970-01-01T00:00:00Z; FILETIME is 100 ns later. A millisecond-only display conceals the difference.

Errors to avoid

Appending Z to FAT without an offset; rounding FILETIME in a floating-point number; attributing a person or activity from time alone.

Primary technical references

METHOD · sqlite-types

02 · SQLite storage classes and explicit time conversion

SQLite has no dedicated date/time storage class. TEXT, REAL and INTEGER do not reveal event meaning without producer schema and writing rules.

Investigation question

Why might numeric zero render as the Unix epoch or a Julian date?

Repeatable procedure

Record the database path, acquisition context and any WAL/SHM sidecars. These examples operate on synthetic data, not uploaded case databases.
Record sqlite_version() and CREATE TABLE schema. Use PRAGMA table_info for declarations and typeof(event_time) for actual stored value types.
Only apply datetime(event_time,'unixepoch') where producer evidence establishes seconds. Otherwise mark the candidate interpretation rather than asserting it.
Avoid assuming 'auto' is always safe: early 1970 Unix values may be treated as Julian days. Declare UTC/localtime modifier order.
Preserve source table/column/row key, raw value, typeof, modifier, result and assumptions together. Without schema evidence, do not label a specific app event.

Synthetic raw input

-- Synthetic only
SELECT typeof(1704067200);
SELECT datetime(1704067200,'unixepoch');
SELECT datetime(0,'unixepoch');
SELECT datetime(0,'auto');

Expected interpretation / check

typeof(1704067200) → integer; Unix seconds → 2024-01-01 00:00:00; zero+unixepoch → 1970-01-01. Zero+'auto' is interpreted as a Julian date.

Errors to avoid

Confusing declared column type with storage class, inferring units from length, or labelling unrestricted SQL execution read-only.

Primary technical references

METHOD · timeline-provenance

03 · Reproducible chronology with source provenance

A timeline needs a trace back to source material, acquisition circumstances, transformation, version and known clock assumptions—not just sorted dates.

Investigation question

What can be inferred when a report revision timestamp follows a source log entry?

Repeatable procedure

State the question and time window. Do not invent a before/during/after classification without an established incident date.
Create a source matrix: record ID, source file/DB/table, raw time, representation, declared offset and acquisition/copy version.
Sort normalized UTC with raw values and transform rules retained. Mark equal instants and clock uncertainty independently; do not infer causality from sequence.
Cross-check thread continuity, duplicates, file copies and cache effects. Record concrete alternative explanations that can be tested against the source.
Keep observed records under findings, relationships under assessment, and the answer under conclusions. Avoid actor attribution absent corroborating source evidence.

Synthetic raw input

E: 2026-10-09T23:55:00+03:00
C: 2026-10-09T21:01:00Z
A: 2026-10-10T00:03:00+03:00

Expected interpretation / check

E = 20:55Z, C = 21:01Z, A = 21:03Z; order E → C → A. A's next local calendar date does not change UTC ordering.

Errors to avoid

Assigning a single source to unrelated rows, inferring causation without clock checks, or presenting synthetic exercises as real case verification.

Primary technical references

METHOD · hash-report

04 · File digests, provenance and report traceability

A digest describes a precise byte sequence. It does not establish acquisition authority, incident relevance or authorship.

Investigation question

When SHA-256 values agree, what matches and what still needs its own report field?

Repeatable procedure

Declare the exact hashing scope: a TXT file, extracted content, an image or an archive. Do not compare different scopes as if they were the same bytes.
Select an authorized synthetic sample; declare SHA-256 and hash the exact bytes, including UTF-8 encoding and terminal newline.
Compare digests only with matching algorithms and byte scope. Matching names or visible text do not substitute for byte-level agreement.
Separate findings, assessment and conclusion. Record source path, method/version, raw values, time basis, transforms, digest and any real procedure log as distinct fields.
Review technical identifiers, Unicode and missing values across TXT/JSON/DOCX. Do not invent acquisition, custody or reviewer metadata.

Synthetic raw input

SHA-256('abc', UTF-8 üç bayt)
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Expected interpretation / check

This known test vector is for the exact three bytes 'abc'; a newline or any byte change yields a different digest.

Errors to avoid

Confusing evidence-byte and exported-report digests, claiming acquisition verification based on a test vector, or citing notes in place of source paths.