How to zip comment editor for data recovery & forensics
- Step 1Record a baseline of the source archive — Before editing, capture the original whole-file hash and, ideally, per-entry hashes — use checksum-generator at /archive-tools/checksum-generator. This is your chain-of-custody record so you can later prove exactly what the edit changed.
- Step 2Confirm the file is a ZIP — The tool requires a valid EOCD record. Recovered .zip, .jar, .apk, .docx, and .xlsx all work; .7z/.rar/.tar do not (they have no EOCD). For damaged ZIPs missing their EOCD, repair first with corrupted-zip-repair.
- Step 3Drop the evidence ZIP locally — Processing is browser-side; nothing is uploaded. On an isolated examination machine this keeps the evidence on-host throughout.
- Step 4Type the annotation, or empty to strip — Use the single textarea to write a case note (
Case 2026-0412 / acq 2026-06-10 / examiner JD) — this replaces any existing comment. Leave it empty to remove a leaked comment. There is no append mode, so if you must preserve an existing comment, copy it first with comment-extractor. - Step 5Edit and download — The result downloads as
<name>-with-comment.zip. Result metrics show the new comment byte length and whether it was removed — note these in your case log. - Step 6Re-hash and document the delta — Run checksum-generator again. Per-entry hashes are identical to the baseline; the whole-file hash differs by exactly the comment change. Record both hashes and the comment text in your report.
What changes vs what is preserved
Forensic relevance of each part of the file after a comment edit. 'Preserved' means byte-for-byte identical to the source.
| File region | After edit | Forensic note |
|---|---|---|
| Compressed entry data | Preserved | Per-entry content hash is unchanged |
| Local file headers | Preserved | Names, sizes, CRCs, timestamps intact |
| Central directory | Preserved | Offsets and entry order unchanged |
| EOCD header (22 bytes) | Preserved except comment-length | Only the 2-byte comment-length field is rewritten |
| EOCD comment (trailing) | Replaced | Your annotation, or removed if left empty |
| Whole-file hash | Changes | Differs by exactly the comment-length + comment-byte delta |
Recovered-archive scenarios
How the tool behaves on the kinds of damaged or partial archives common in recovery work.
| Source condition | Outcome | Recommended order |
|---|---|---|
| Intact ZIP with EOCD | Editable | Baseline → annotate → re-hash |
| ZIP with truncated tail (EOCD lost) | Rejected | Repair with corrupted-zip-repair first |
| ZIP with junk appended after EOCD | Junk treated as comment, overwritten | Inspect tail bytes first; don't edit if junk is meaningful |
| Non-ZIP recovered blob (7z/tar/raw) | Rejected | Identify format with auto-format-detector |
| ZIP-container evidence (.docx/.apk) | Editable | Annotate, then rename extension back |
Tier limits (per-archive)
Forensic ZIPs can be large; choose a tier that covers the archive size and entry count.
| Tier | Max file size | Max entries | Files at once |
|---|---|---|---|
| Free | 50 MB | 500 | 1 |
| Pro | 500 MB | 50,000 | 20 |
| Pro-media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | unlimited |
Cookbook
Chain-of-custody-aware workflows for annotating or sanitising recovered ZIP evidence.
Annotate evidence with a case stamp
Add a case ID and acquisition metadata to the comment without altering the contents. The per-entry hashes recorded earlier still verify.
Baseline (checksum-generator): whole-file SHA-256: a91f...e3 per-entry hashes: recorded Comment edit: Case 2026-0412 | acq 2026-06-10T14:22Z | examiner JD Comment length: 49, Removed?: false After (checksum-generator): per-entry hashes: IDENTICAL whole-file SHA-256: 7c40...b1 (changed by comment only)
Strip a comment that leaked the owner's path
A recovered archive's comment exposed the suspect's username and source directory. Clear it for a redacted working copy while keeping contents intact.
Original comment: packed from C:\Users\suspect\Desktop\exfil by suspect Edit: leave textarea empty Comment length: 0, Removed?: true Result: redacted-copy-with-comment.zip contents byte-identical; comment removed
Repair-then-annotate a truncated archive
Carving recovered a ZIP whose tail (and EOCD) was lost. Rebuild the directory first, then annotate.
Step 1: corrupted-zip-repair recovers entries, writes a fresh EOCD Step 2: zip-comment-editor adds: Recovered via carving | sectors 0x... | examiner JD Note in report: repair already changed bytes vs raw carve; record both the carved and repaired hashes.
Document the exact binary delta
Prove to a reviewer that only the comment changed by diffing the two files.
$ cmp -l original.zip annotated-with-comment.zip (differences only at EOCD comment-length offset and in the trailing comment region) Everything before the EOCD comment field: identical.
Annotate an APK artifact
Android packages are ZIPs; annotate a recovered .apk the same way, then restore the extension.
Input: recovered.apk (ZIP container) Comment: Sample 0091 | malware triage | do-not-execute Download: recovered-with-comment.zip → rename to recovered.apk Signature blocks inside the APK are untouched.
Edge cases and what actually happens
Recovered file has no EOCD (truncated tail)
RejectedIf carving lost the end of the file, the PK\x05\x06 signature is gone and the comment cannot be located. The tool errors. Rebuild the central directory with corrupted-zip-repair first, documenting that the repair itself changes bytes.
Junk data appended after the EOCD
OverwrittenThe tool treats every byte after the 22-byte EOCD header as the comment region and overwrites it. If that trailing junk is itself evidence (e.g. hidden appended data), do NOT edit — extract and document the tail bytes first.
Need to preserve the original alongside the annotated copy
By designThe tool downloads a new file (-with-comment.zip) and never modifies the source in place. Keep the original untouched as the master evidence item and work on the downloaded copy.
Per-entry content hash must stay constant
PreservedBecause no entry is re-compressed, each extracted file's hash is identical before and after. Only the whole-file hash changes — by exactly the comment delta — which you should record explicitly.
Source is a 7z, tar, or raw recovered blob
RejectedThese have no EOCD. Identify the real format with auto-format-detector. Comments are ZIP-specific; if you need an annotation on a non-ZIP, record it in your case notes, not in the file.
Comment exceeds 65,535 bytes
TruncatedThe ZIP comment field caps at 65,535 bytes and the tool slices longer text to 65,535 characters. For long case narratives, store them in your report, not the archive comment.
Existing comment must be retained and extended
Manual stepThere is no append mode — the new text replaces the old. Read the existing comment with comment-extractor, then re-type it together with your addition so nothing is lost.
Evidence ZIP exceeds the tier size cap
RejectedLarge acquisition images may exceed 50 MB (Free) or even 500 MB (Pro). The whole file is loaded into memory, so the size cap is enforced before editing. Use a tier that covers the archive size.
Frequently asked questions
Does editing the comment alter the evidence?
It changes only the trailing EOCD comment and the 2-byte comment-length field. Every entry's compressed bytes — and therefore each extracted file's hash — are unchanged. The whole-file hash changes by exactly the comment delta, which you should document.
Will my per-entry content hashes still match after annotation?
Yes. The tool does not re-compress anything, so per-entry content hashes are byte-for-byte identical before and after. Record a baseline with checksum-generator to prove it.
Can I prove only the comment changed?
Yes. A binary diff (cmp -l original.zip annotated.zip) shows differences only at the comment-length offset and in the trailing comment bytes. Everything before the EOCD comment field is identical.
Is the evidence uploaded anywhere?
No. The edit runs entirely in your browser; the ZIP is read locally and the result is downloaded. This suits an isolated examination workstation.
What if the recovered ZIP is truncated and has no EOCD?
The tool cannot find the comment field and will error. Rebuild the central directory with corrupted-zip-repair first, and document that the repair changes bytes relative to the raw carve.
How do I strip a comment that leaked the owner's identity?
Leave the textarea empty and run the edit. The comment-length field is set to 0 and the leaked text is removed, with the result metric Removed? showing true. The contents stay intact.
Can I annotate a recovered .docx or .apk?
Yes — they are ZIP containers. Annotate, download <name>-with-comment.zip, and rename the extension back. Internal document or APK signature data is not touched.
Does it modify the original file in place?
No. It produces a new downloaded file and never alters the source. Keep the original as the master evidence item and work on the copy.
What if junk data sits after the EOCD?
The tool overwrites everything after the EOCD header as the comment. If that trailing data is itself relevant (hidden appended content), document and extract it before editing — otherwise it will be lost.
How big an archive can I process?
Free up to 50 MB / 500 entries, Pro up to 500 MB / 50,000 entries, Pro-media and Developer up to 2 GB / 500,000 entries. The whole file is loaded into memory, so the cap is checked first.
Can I read an existing comment first?
Yes — use comment-extractor at /archive-tools/comment-extractor to read it, and archive-metadata-extractor for deeper EOCD and directory details, then annotate here.
Is the change deterministic?
Yes. Given the same input and comment text, the output bytes are identical every time — only the comment-length field and trailing comment region change. That reproducibility is useful for documenting the operation.
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.