How to timestamp normaliser for data recovery & forensics
- Step 1Work on a copy, never the original — Standard forensic practice: this tool rewrites timestamps, so always operate on a working copy of the carved archive and preserve the original evidence file with its hash recorded beforehand.
- Step 2Hash the input first — Before normalising, record a baseline hash of the working copy — use checksum-generator. This documents the pre-normalisation state and lets you prove what changed (only metadata).
- Step 3Open the normaliser and load the working copy — Go to /archive-tools/timestamp-normalizer. It reads ZIP/TAR via fflate and 7z/RAR/bz2/xz/ISO via libarchive WASM, all in-browser. Confirm the entry count it detects matches the carve's expected count.
- Step 4Choose a documented Target date — Pick a single canonical date you will record in your notes (the
1980-01-01default is conventional). Every entry will be stamped to 00:00:00 UTC of that date — the picker is date-only, so the time component is fixed and reproducible. - Step 5Normalise and capture the metrics — Run it, then record the reported Timestamp (e.g.
1980-01-01T00:00:00.000Z) and Entries count. These two values plus the chosen date fully describe the transformation for your report. - Step 6Hash the output and compare carves — Hash the
-normalized.zipand compare it across your carves. Identical hashes mean the underlying file set is identical once timestamp noise is removed. Use archive-diff to enumerate any real content differences.
Forensic concerns mapped to tool behaviour
What an analyst needs vs what the normaliser actually does. Read the 'caveat' column — this is a canonicalisation tool, not an authentication or recovery tool.
| Analyst need | Tool behaviour | Caveat |
|---|---|---|
| Keep evidence off the network | All processing in-browser (WASM) | Only an anonymous usage counter is recorded |
| Compare two carves of one archive | Uniform timestamp removes time noise | Content differences still show — that's intended |
| Read carved 7z / RAR / ISO | libarchive WASM reads them | Read-only; output is always ZIP |
| Recover the original mtimes | Not possible | Tool overwrites all times with your chosen date |
| Authenticate provenance | Not provided | Use signing/metadata siblings; this only canonicalises |
| Repair a damaged carve | Not provided | Use corrupted-zip-repair first if it won't open |
What changes vs what is preserved
Only timestamp metadata and the container/compression change. File bytes are preserved verbatim.
| Aspect | Result |
|---|---|
| Entry modification times | Overwritten to one chosen date |
| File contents (bytes) | Preserved exactly |
| Paths / filenames | Preserved (empty dirs dropped) |
| Container | Always ZIP, re-compressed (DEFLATE 6) |
| Original timestamps | Lost — not recoverable from output |
| Encryption | Cannot be read (no password field) |
Tier capacity for evidence sizes
Carved archives can be large. Plan tier accordingly — both size and entry count are capped.
| Tier | Max archive | Max entries |
|---|---|---|
| Free | 50 MB | 500 |
| Pro | 500 MB | 50,000 |
| Pro + Media | 2 GB | 500,000 |
| Developer | 2 GB | 500,000 |
Cookbook
Workflows from recovery and forensic analysis. File names are illustrative; treat all timestamps as canonicalised, not original.
De-duplicate two carves of the same archive
A carving tool produced two copies of what should be one archive, each stamped with a different carve time. After normalisation they hash identically, confirming they are the same file set.
carve-A.zip sha256: 11aa... (entries mtime 2026-06-09 03:11) carve-B.zip sha256: 88ff... (entries mtime 2026-06-09 09:44) Normalise both, Target date 1980-01-01: carve-A-normalized.zip sha256: 5c20... carve-B-normalized.zip sha256: 5c20... <-- duplicate confirmed
Read a carved 7z without external tools
A 7z fragment recovered from unallocated space needs to be opened on an air-gapped workstation with no 7-Zip installed. The browser tool reads it via libarchive WASM.
Input: recovered-block.7z (read via libarchive WASM) Target date: 1980-01-01 Output: recovered-block-normalized.zip Timestamp: 1980-01-01T00:00:00.000Z Entries: 23
Document the transformation for a report
Forensic reports require recording every transformation. Capture the before-hash, the parameters, and the after-hash.
Pre: exhibit-7.zip SHA-256 a1b2... (97 entries) Param: timestamp-normalizer, Target date = 1980-01-01 Post: exhibit-7-normalized.zip SHA-256 c3d4... Reported metrics: Timestamp 1980-01-01T00:00:00.000Z, Entries 97 Note: only metadata + container changed; file bytes preserved.
Compare a carve against a known-good baseline
You have a clean reference archive and a recovered one. Normalise both, then diff to surface genuine content differences without timestamp noise getting in the way.
1. Normalise reference.zip -> reference-normalized.zip 2. Normalise recovered.zip -> recovered-normalized.zip 3. /archive-tools/archive-diff on the two normalised ZIPs -> 2 files added, 1 removed, 0 changed (timestamps no longer flagged as differences)
Repair-then-normalise a barely-readable carve
A carve won't open because its central directory is damaged. Repair it first, then canonicalise timestamps.
Step 1 - /archive-tools/corrupted-zip-repair: damaged-carve.zip -> recovered entries -> repaired.zip Step 2 - timestamp-normalizer: repaired.zip -> repaired-normalized.zip (uniform date) Now the salvaged set is in canonical, comparable form.
Edge cases and what actually happens
It rewrites timestamps — original times are lost
Destructive to metadataThis is the most important caveat for forensics: the tool overwrites every entry's modification time with your chosen date. Original (or carve-assigned) times do not survive in the output and cannot be recovered from it. Record the input's state before normalising and always keep the original evidence file.
It does not authenticate provenance
Out of scopeNormalising timestamps says nothing about whether an archive is genuine. For signature / metadata inspection use archive-signing-info and archive-metadata-extractor. This tool only produces a canonical comparison form.
Damaged carve won't open
FailIf the archive structure is too corrupt to read, normalisation fails with a format/extract error. Run corrupted-zip-repair first, then normalise the recovered output.
Encrypted recovered archive
FailNo password field is offered, so an encrypted carve cannot be read. If you have lawful access and the password, extract it with multi-format-extractor, then normalise the plaintext.
Output container differs from the carve
ExpectedA carved 7z, RAR, or tar.gz comes back as a ZIP. This is fine for comparison/hashing but means the output is not a faithful container copy of the original — note this in your report if container fidelity matters.
Empty-directory markers dropped
Not preservedExtraction keeps only file entries, so empty-folder records present in the carve are not carried into the output. If the presence of an empty directory is itself significant, document it from the original before normalising.
Re-compression alters the byte size
ExpectedBecause the tool re-compresses to DEFLATE level 6, the output's size differs from the input. File contents are byte-identical; only the container/compression changed. Hash the contents (or use archive-diff) rather than comparing raw file sizes.
Evidence over the tier cap
Tier limitLarge disc images or bundles can exceed 50 MB / 500 entries on Free. Pro reaches 500 MB / 50,000; Pro + Media / Developer reach 2 GB / 500,000. For evidence beyond 2 GB, segment the analysis or use native tooling on the workstation.
All entries get the same date — ordering, not sequence
By designBecause every entry shares one timestamp, you cannot infer creation order from the normalised output. If temporal sequence matters to your analysis, derive it from the original archive before normalising.
Frequently asked questions
Does any evidence leave my machine?
No file content leaves your machine. The archive is read and re-packed in the browser via fflate and libarchive WASM. Only an anonymous usage counter (no content) is recorded. This makes it suitable for confidential or air-gapped forensic work once the page is loaded.
Can it recover the original timestamps of recovered files?
No — it does the opposite. It overwrites every entry's time with the single date you choose, to create a canonical comparison form. Original or carve-assigned timestamps are not recoverable from the output, so preserve the original file first.
Why normalise timestamps in a forensic workflow at all?
Carving tools often stamp recovery/carve times onto reconstructed entries, so two carves of the same logical archive won't hash alike. Flattening all times to one value removes that noise, letting you confirm duplicates and diff genuine content differences.
Which carved formats can it read?
ZIP, TAR, GZIP, tar.gz, tar.bz2, tar.xz, bz2, xz, 7z, RAR, and ISO. ZIP/TAR/GZIP go through fflate; 7z/RAR/bz2/xz/ISO are read via the libarchive WASM bridge. All read-only — the output is always a ZIP.
Will my carved disc image (ISO) work?
Yes for reading — libarchive WASM reads ISO 9660 images, and the files inside are re-packed into a normalised ZIP. Mind the tier size cap, since disc images are often large (Free is 50 MB).
Does it repair a corrupt carve?
No. It expects a readable archive. For structural damage, run corrupted-zip-repair first, then normalise the salvaged output.
What should I record in my report?
The pre-normalisation hash of the working copy, the chosen Target date, and the tool's reported Timestamp (ISO) and Entries count, plus the post-normalisation hash. That fully documents a reproducible, metadata-only transformation.
Are the original file contents altered?
No. Only modification-time metadata changes; file bytes are extracted and re-packed verbatim. The output ZIP's overall size differs because it is re-compressed, but each file's content is byte-identical to the source.
Can it process an encrypted recovered archive?
Not directly — there is no password field. With lawful access and the password, decrypt via multi-format-extractor first, then normalise the extracted, re-zipped output.
How do I confirm two carves are the same file set?
Normalise both to the same date and hash the outputs with checksum-generator. Identical hashes mean the underlying files match once timestamp noise is removed. Use archive-diff to enumerate any real differences.
Does it work offline on an isolated workstation?
Yes, once the page has loaded. Processing is fully client-side with no server round-trip, so it suits an air-gapped analysis machine. Load the page while connected, then it runs locally.
Can I set an exact time, not just a date?
No — the picker is date-only and applies 00:00:00 UTC. For a defensible record this is actually an advantage: the time component is fixed and reproducible, with no ambiguity to document.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.