ZIP Metadata Extractor for Security & Compliance

Find every encrypted entry without a password

General-purpose bit 0 lives in the plaintext central directory, so encrypted entries are visible even though their payloads are not. This is how you confirm that an upload contains an encrypted blob a content scanner would have skipped.

$ jq '.entries[] | select(.flags.encrypted) | {name, compressionMethod}' \
     suspicious-metadata.json
{
  "name": "payload.bin",
  "compressionMethod": "AES"
}

→ One encrypted entry. To test a suspected password:
  /archive-tools/archive-password-tester
→ To classify ZipCrypto vs AES across the archive:
  /archive-tools/encrypted-archive-detector

Catch non-UTF-8 filenames hiding traversal characters

flags.utf8: false means the name was stored in a legacy code page. The tool decodes leniently, so suspicious bytes may surface as U+FFFD. Combined with path characters, this is a classic obfuscation for Zip Slip-style entry names.

$ jq '.entries[] | select(.flags.utf8 == false) | .name' meta.json
"..\\..\\windows\\system32\\evil.dll"
"\uFFFD\uFFFD config.json"

→ The first is a path-traversal attempt; the second has
  non-decodable bytes. Sanitise names on extraction with
  /archive-tools/filename-sanitizer .

Cross-check provenance via hostOS

An artifact a vendor claims was built on Windows but whose entries all report hostOS 3 (Unix) is worth a question. The host-OS byte is written by the creating tool and is a cheap provenance signal.

$ jq '[.entries[].hostOS] | unique' build-from-vendor-meta.json
[ 3 ]

→ Every entry hostOS 3 = Unix-built. If the SBOM claims a
  Windows build farm, that contradiction is a finding.
  (0 = DOS/FAT, 3 = Unix, 11 = NTFS/Windows.)

Tamper smell test on CRC-32 values

A zero CRC on a non-encrypted entry, or the same CRC across files that should differ, suggests the directory was edited without recomputing checksums. The report gives you the stored CRCs to compare; verification of the payload is a separate step.

$ jq '.entries[] | {name, crc32, encrypted: .flags.encrypted}' meta.json
{ "name": "a.txt", "crc32": "00000000", "encrypted": false }
{ "name": "b.txt", "crc32": "00000000", "encrypted": false }

→ Two plaintext entries with zero CRC is suspicious.
  Recompute and verify with
  /archive-tools/archive-integrity-tester .

Lock chain-of-custody with before/after hashes

Because everything is read-only and in-tab, the archive bytes are never modified. Prove it by hashing before and after analysis and storing both hashes with the metadata JSON.

Workflow:
  1. /archive-tools/checksum-generator → SHA-256 of evidence.zip
     e3b0c44298fc1c149afbf4c8996fb924...
  2. /archive-tools/archive-metadata-extractor → metadata.json
  3. /archive-tools/checksum-generator again → same SHA-256

Identical hashes prove the inspection did not alter the file.
Archive the two hashes + metadata.json in the case record.

Encryption never blocks this tool — the central directory is plaintext, so names, sizes, methods, timestamps and flags.encrypted all read normally. Only the payloads are encrypted, and the tool never reads payloads. This is precisely why it is useful for spotting encrypted blobs a scanner would skip.

The tool reads ZIP only and throws 'Not a valid ZIP archive (or unsupported format for metadata extraction)' on non-ZIP input. In a forensic context the mismatch (a .zip extension on a 7z payload) is itself a finding. Confirm with /archive-tools/auto-format-detector and record it.

Names are decoded with non-fatal UTF-8, so undecodable bytes become U+FFFD rather than throwing. With flags.utf8: false, a U+FFFD name signals a legacy code page — a common obfuscation vector. The original bytes are not preserved in the report; sanitise on extraction with /archive-tools/filename-sanitizer.

AES-encrypted entries (compressionMethod: 'AES', flags.encrypted: true) commonly store crc32: '00000000' because the real CRC is protected with the encrypted data. A zero CRC here is normal — only a zero CRC on a plaintext entry is suspicious.

The report flags hasComment/hasExtraField: true but does not dump their bytes — so it tells you data is present without showing what. To inspect comment contents use /archive-tools/comment-extractor; for signing-related extra fields use /archive-tools/archive-signing-info.

Parsing stops at the first record missing the 0x02014b50 signature, yielding a partial report; damage before the first entry yields zero entries and the standard error. A directory that parses fewer entries than totalEntries (the EOCD count) is itself a tamper indicator. For recovery, use /archive-tools/corrupted-zip-repair.

Each browser tab is an independent, stateless instance — there is no shared server session to contend over. Free-tier limits apply per session; a Pro seat removes them. Nothing about one analyst's run affects another's.

Because the file is read in-tab via the File API and nothing transits the network for archive tools (browserOnly: true), the regulated boundary does not move — the same posture as a local CLI. Confirm with your compliance team, but most treat in-browser local processing as equivalent to on-machine tooling.

The entry count is read from the 16-bit EOCD field and wraps past 65,535; the loop may stop early on a true ZIP64 directory. For very large evidence archives, corroborate the entry count with a ZIP64-aware tool. Tier entry caps keep typical artifacts well under this.