How to file listing generator for devops & incident response
- Step 1Pull the bundle locally — Stage the archive on the analyst's machine from your evidence store or pipeline. The tool reads from disk via the File API — nothing transits the network at any point.
- Step 2Open the tool — Go to /archive-tools/file-listing-generator. No login is needed for free-tier triage up to 50 MB / 500 entries; use Pro for 500 MB / 50,000-entry bundles.
- Step 3Choose json for ingestion — Pick listFormat: json so the inventory loads directly into your SIEM or a script; choose csv if it is going into a spreadsheet for the incident review.
- Step 4List without extracting — Click Process. For a ZIP, entries are read from the central directory with no decompression, so no file content is touched or written — just the manifest.
- Step 5Record the CRCs — The crc32 column is a per-entry checksum you can capture before extraction. For an archive-level SHA-256 of the whole bundle, run /archive-tools/checksum-generator alongside.
- Step 6Attach to the ticket — Download the listing and attach it to the incident record. The filename is derived from the bundle name, so it self-documents which archive it describes.
Triage columns and what they tell you
Every column is populated for ZIP bundles; non-ZIP bundles populate fewer (see the next table). All produced without extracting file content.
| Column | Incident-response use |
|---|---|
name / isDirectory | Confirm the bundle structure matches the expected manifest; spot unexpected paths |
size / compressedSize / ratio | Flag anomalies — e.g. a log entry far larger than its peers, or already-compressed payloads |
lastModified | Timeline reconstruction from per-entry dates (ZIP only) |
crc32 | Per-entry fingerprint to record pre-extraction and compare against a known-good copy |
isEncrypted / compressionMethod | Identify protected entries (AES) before you attempt extraction |
Bundle format and metadata available
Prefer ZIP evidence bundles when timeline and integrity columns matter — only ZIP exposes per-entry dates and CRCs.
| Bundle format | Per-entry dates | crc32 / encryption flag | Listing cost |
|---|---|---|---|
| ZIP | Real (DOS date/time) | Yes | Cheap — central directory only, no decompress |
| TAR / GZ | Archive file's date only | None | Moderate — enumerated via fflate |
| 7z / RAR / BZ2 / XZ | Archive file's date only | None | Higher — extracted in memory to enumerate |
Tier limits for incident-sized bundles
Both file size and entry count are enforced before processing — a log bundle with many tiny files can hit the entry cap first.
| Tier | Max bundle size | Max entries | Bundles per run |
|---|---|---|---|
| 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
Triage-flavoured examples. Filenames and CRCs are illustrative; the column shapes are exactly what the tool emits.
Inventory a log bundle before extraction
List a ZIP log bundle as JSON without unpacking it to the triage host. Every entry's CRC and date is captured in the manifest first.
[
{
"name": "var/log/auth.log",
"size": 1048576,
"compressedSize": 81920,
"ratio": "92.2%",
"lastModified": "2026-06-09T02:14:11.000Z",
"isDirectory": false,
"compressionMethod": "Deflate",
"crc32": 305419896,
"isEncrypted": false,
"comment": null
}
]Spot an encrypted entry up front
The isEncrypted column and an AES compressionMethod tell you which entries need a password before you waste time on a failed extraction.
name,size,compressedSize,ratio,lastModified,isDirectory,compressionMethod,crc32,isEncrypted evidence/disk.img,2097152,2090000,0.3%,2026-06-09T02:14:11.000Z,false,AES,,true evidence/notes.txt,512,310,39.5%,2026-06-09T02:14:11.000Z,false,Deflate,9f00aa12,false
Flag a size anomaly in a CSV review
Loaded into a spreadsheet, the size and ratio columns make an outlier obvious — here one log is two orders of magnitude larger than its peers.
name,size,compressedSize,ratio,... logs/app-01.log,40960,3500,91.5%,... logs/app-02.log,41200,3550,91.4%,... logs/app-99.log,5242880,4980000,5.0%,... <-- outlier: 5 MB, barely compresses
Capture CRCs, then verify the whole bundle
Record per-entry CRCs from the listing, then take an archive-level SHA-256 with the sibling checksum tool to anchor chain-of-custody.
# Step 1: File Listing Generator -> evidence-listing.json (per-entry crc32) # Step 2: /archive-tools/checksum-generator -> SHA-256 of evidence.zip # SHA-256: 3b1f...e9 evidence.zip # Attach both to the incident ticket.
Confirm a CI artifact's contents in code review
Reviewing a deploy artifact ZIP? List it to confirm only expected paths are present before approving — no checkout, no extraction.
Result panel: Format: zip Entries: 38 listing shows: dist/**, package.json, LICENSE -> no unexpected node_modules/, no .env, no *.pem => approve
Edge cases and what actually happens
Listing never writes file content to disk
By designFor a ZIP the tool reads the central directory and produces a manifest — no entry payload is decompressed or written. This is exactly what you want on a possibly-compromised triage host: you learn the contents without touching them.
Encrypted evidence ZIP lists without a password
SupportedBecause listing is metadata-only, an encrypted bundle lists fine and flags protected entries via isEncrypted: true (often with an AES compressionMethod). You only need the password later, if and when you extract.
Non-ZIP bundle gets extracted in memory to list
By designOnly ZIP exposes a central directory. A 7z or RAR evidence bundle is extracted in memory to enumerate it, so it uses more RAM and is not a pure metadata-only read. Prefer ZIP for the most contained triage.
Per-entry timestamps unavailable for non-ZIP
ExpectedTimeline reconstruction relies on per-entry dates, which only ZIP provides. For tar.gz/7z bundles every lastModified is the archive file's own date, so do not treat those as evidence timestamps.
crc32 blank on non-ZIP listings
ExpectedThe crc32 fingerprint column is populated only for ZIP. For non-ZIP bundles take an archive-level checksum with /archive-tools/checksum-generator instead of relying on per-entry CRCs.
Bundle exceeds the size cap mid-incident
Rejected (tier limit)Free stops at 50 MB; a large evidence bundle needs Pro (500 MB) or higher (2 GB). The cap is checked before processing, so an oversized bundle never starts — plan tier ahead of an incident.
Bundle has more entries than the tier allows
Rejected (tier limit)A log archive of hundreds of thousands of tiny files can pass the size check but fail the entry cap (Free 500, Pro 50,000, top tiers 500,000). Upgrade or split the bundle.
Bundle's central directory is corrupt
Empty (parse fail)A truncated transfer of an evidence ZIP yields an empty listing. Recover what you can with /archive-tools/corrupted-zip-repair, then re-list — and note the corruption in the incident record.
Concurrent analysts, no shared state
SupportedEach browser tab is an independent instance, so several responders can list bundles in parallel without contending over shared state. Tier limits apply per session.
Regulated data never crosses a network boundary
By designBecause the file is read locally and never uploaded, using the tool does not move data across your regulated boundary — equivalent to running a local CLI. Confirm with compliance, but most treat local browser processing the same as a local tool.
Frequently asked questions
Can I inventory an evidence bundle without extracting it?
Yes, for ZIP. The listing reads the central directory and produces a manifest with no decompression and nothing written to disk — ideal on a triage host you do not want to write to.
Does anything get uploaded?
No. The bundle is read locally via the browser File API and processed in-tab. Network shows no outbound transfer of the file, which keeps sensitive data inside your boundary.
Can I list an encrypted bundle without the password?
Yes. Listing is metadata-only, so encrypted entries appear with isEncrypted: true (often AES as the method) without needing the password. You only need it to extract.
Does the CRC column help with chain of custody?
It gives a per-entry fingerprint you can record pre-extraction (ZIP only). For an archive-level SHA-256 of the whole bundle, pair with /archive-tools/checksum-generator.
Why are the dates wrong on my tar.gz evidence?
Per-entry timestamps are only available for ZIP. For tar.gz/7z/RAR every entry's lastModified is the archive file's own date, so do not use them as evidence timestamps — use a ZIP bundle if timeline matters.
What size and entry limits apply?
Free 50 MB / 500 entries, Pro 500 MB / 50,000, Pro-media and Developer 2 GB / 500,000. Both checks run before processing.
Can multiple responders use it at once?
Yes. Each tab is independent with no shared state, so analysts can triage bundles in parallel. Limits are per session.
Which format should an evidence bundle be?
ZIP, if you can choose. Only ZIP gives per-entry dates, CRCs, and an encryption flag, and it lists cheaply without unpacking. 7z/RAR are extracted in memory to list.
How do I detect encryption across many bundles first?
Use /archive-tools/encrypted-archive-detector to flag protected archives, then list the ones you need. The File Listing Generator itself flags encryption per ZIP entry.
What if the bundle is corrupt?
A ZIP with a damaged central directory lists 0 entries. Try /archive-tools/corrupted-zip-repair and re-list the repaired copy, recording the corruption in the incident notes.
Does this meet HIPAA/PCI/FedRAMP needs?
Because nothing transits a network, the regulated boundary does not move — this is equivalent to a local CLI. Confirm with your compliance team; most accept local browser processing.
How do I inventory many bundles at once?
This tool is single-archive. For many archives, extract with /archive-tools/batch-extraction-manager or get a rollup with /archive-tools/batch-compression-report.
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.