How to zip repair for data recovery and forensics
- Step 1Hash the source first — Before touching the corrupt file, generate a baseline hash. Run /archive-tools/checksum-generator on the original to record its SHA-256 for the case file.
- Step 2Open the repair tool on the workstation — Go to /archive-tools/corrupted-zip-repair. A Pro plan or higher is required. The file is read locally; nothing transits the network during the scan.
- Step 3Drop the carved or recovered ZIP — Drag the single corrupt ZIP in. The tool scans the whole file for local headers, decompressing each recoverable entry into a fresh archive.
- Step 4Record the recovery report — Capture the Attempts, Recovered, and Recovery-rate metrics. These document what was salvageable versus skipped (encrypted, truncated, or damaged entries).
- Step 5Download and hash the output — Save
<name>-repaired.zip, then run the Checksum Generator again to record the output hash and a per-entry manifest. - Step 6Verify and hand off — Confirm structural soundness with Archive Integrity Tester, then feed the verified ZIP into your case management or analysis pipeline.
Forensic recovery outcomes by damage source
What the local-header scan can salvage from common forensic inputs.
| Source of corruption | Typical outcome | Notes |
|---|---|---|
| Carved from disk image (partial) | Partial recovery | Entries before the carve boundary recover; the final cut-off entry is skipped |
| Failing drive — bad sectors in the index | High recovery | Index is bypassed entirely; payload entries usually survive |
| Interrupted download / capture | Partial recovery | Truncated tail entry skipped, all earlier entries recovered |
| Bit rot scattered in payloads | Partial recovery | Entries whose data fails to inflate are skipped and counted |
| Encrypted evidence archive | Skipped entries | Encrypted entries are skipped — no password support in this tool |
| Renamed non-ZIP (RAR/7z mislabeled) | No recovery | No PK headers; identify with Auto Format Detector |
Chain-of-custody pairing
Tools to bracket the repair step for an auditable record.
| Stage | Tool | Output for the record |
|---|---|---|
| Before | /archive-tools/checksum-generator | SHA-256 of the original corrupt file |
| Repair | /archive-tools/corrupted-zip-repair | Recovery report: Attempts / Recovered / rate |
| After (hash) | /archive-tools/checksum-generator | SHA-256 + per-entry manifest of the repaired ZIP |
| After (verify) | /archive-tools/archive-integrity-tester | Per-entry CRC pass/fail on the repaired ZIP |
| Metadata | /archive-tools/archive-metadata-extractor | Timestamps and structure for the salvaged entries |
Cookbook
Forensic recovery walkthroughs with the recovery report numbers the tool emits, framed for chain-of-custody documentation.
Carved ZIP from a disk image
A ZIP recovered with file-carving has a clean head but a truncated tail where the carve ended.
Pre-hash: sha256(carved.zip) = 9f3a...e1 Process: /archive-tools/corrupted-zip-repair Attempts: 512 Recovered: 509 Recovery rate: 99% (3 tail entries ran past EOF -> skipped) Post-hash: sha256(carved-repaired.zip) = 4c77...b9 Record both hashes + report in the case file.
Failing drive — destroyed index
The archive's central directory sat on bad sectors. The payloads are clean.
Process: Attempts: 1,180 Recovered: 1,180 Recovery rate: 100% Every file recovered; the broken index was never read. Verify: /archive-tools/archive-integrity-tester -> all CRCs pass.
Encrypted evidence archive
Some entries are encrypted. The tool documents exactly which were skipped.
Process: Attempts: 96 Recovered: 71 Recovery rate: 74% (25 encrypted entries skipped) Confirm scope: /archive-tools/encrypted-archive-detector Document the 25 encrypted entries as requiring credentials.
Mislabeled container
An exhibit named .zip is actually a 7z. The tool flags it cleanly.
Process:
Error: "No recoverable local file headers found —
the file may not be a ZIP at all."
Triage: /archive-tools/auto-format-detector -> reports 7-Zip
Re-route to the correct extractor; note the format mismatch.Full bracketed recovery record
The complete auditable sequence from corrupt input to verified output.
1. checksum-generator (original) -> baseline SHA-256 2. corrupted-zip-repair -> report + repaired ZIP 3. checksum-generator (repaired) -> output SHA-256 + manifest 4. archive-integrity-tester (repaired) -> CRC verification 5. archive-metadata-extractor -> timestamps/structure All steps in-browser; nothing uploaded.
Edge cases and what actually happens
Evidence privacy
PreservedThe corrupt file is read from disk and processed in the browser tab — it never uploads. The regulated boundary does not move when an analyst runs the tool, equivalent to running a local CLI.
Encrypted evidence entries
Skipped by designEntries with the encryption flag set are skipped and counted in the report but not recovered. Document them as requiring credentials; confirm scope with Encrypted Archive Detector.
Carve / truncation boundary
Partial recoveryAn entry whose compressed data runs past end-of-file is skipped; all complete entries before it recover. The recovery rate quantifies how much was lost at the boundary.
Mislabeled container
Error: no headersA non-ZIP exhibit (RAR/7z/TAR renamed to .zip) yields no local headers and errors. Identify the true format with Auto Format Detector before proceeding.
Reproducibility across analysts
DeterministicThe recovery has no configurable options, so the same input produces the same salvaged entry set on any analyst's machine — important for repeatable forensic procedure.
Output is rebuilt
By designThe repaired ZIP is rebuilt with fflate (deflate 6) and byte-scan entry order. Extracted contents are bit-identical; the container is fresh, so hash the repaired output separately for the record.
Damaged payload entries
SkippedEntries whose data fails to inflate are skipped and continue to count toward Attempts, so the report distinguishes recovered from unrecoverable.
Free account
Locked: Pro requiredThe tool's minimum tier is Pro. Provision analyst seats at Pro or higher so the repair workstation can run it.
Concurrent analysts
SupportedEach browser tab is an independent instance with no shared state, so multiple analysts can run recoveries in parallel on their own machines.
Frequently asked questions
Is this safe for sensitive evidence?
Yes — the corrupt file is read locally with the File API and processed in the browser via fflate. Nothing uploads, so evidence stays on the workstation. Confirm with your compliance team that local browser processing matches policy; it is equivalent to a local CLI.
How do I maintain chain of custody?
Hash the original with the Checksum Generator before repair, capture the recovery report, then hash and verify the repaired output afterward. Record all three artifacts in the case file.
What can it salvage from a carved ZIP?
Every entry whose local header and compressed data survived the carve. The truncated entry at the carve boundary is skipped; the recovery rate quantifies what was lost.
Can it recover encrypted evidence?
No. Encrypted entries are skipped because the tool has no password input. Document which entries are encrypted using the Encrypted Archive Detector and handle them with credentials separately.
Is the recovery reproducible?
Yes. There are no options, so the salvaged entry set is deterministic for a given input — the same on any analyst's machine and across re-runs.
Does the repaired ZIP match the original hash?
No — the container is rebuilt fresh, so its hash differs even when contents are identical. Hash the repaired output as its own artifact and rely on per-entry verification for content equivalence.
How do I verify the salvaged files?
Run Archive Integrity Tester to confirm per-entry CRCs pass, and Archive Metadata Extractor to record timestamps and structure for the salvaged entries.
What about regulated environments (HIPAA, PCI, FedRAMP)?
Because nothing transits a network, using the tool does not move data outside the regulated boundary. Most teams treat it like a local utility, but confirm with your compliance team.
What is the maximum file size?
Pro processes up to 500 MB; Pro-Media and Developer up to 2 GB. Very large carved images may need a CLI that streams from disk.
Can multiple analysts use it at once?
Yes. Each tab is an independent instance with no shared state, so concurrent recoveries on separate machines do not interfere.
What if the exhibit is not actually a ZIP?
You will get "No recoverable local file headers found." Run Auto Format Detector to identify the real format and route the file to the correct tool.
Does it preserve timestamps?
Recovered entries keep readable per-entry metadata where present. To inspect or document timestamps on the salvaged set, use the Archive Metadata Extractor.
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.