How to multi-format extractor for devops & incident response
- Step 1Open the extractor on the incident laptop — Load the page. For an air-gapped forensics workflow, load it while connected once, then disconnect — extraction runs entirely client-side afterwards.
- Step 2Drop the bundle — Drag the single support bundle / dump / log archive in. Do not rename it first — magic-byte detection identifies the real format even if the vendor mislabelled the extension.
- Step 3Enter the bundle password if encrypted — Many vendor ZIP bundles are password-protected. Paste the password into the optional field; zip.js decrypts AES-256 / ZipCrypto entries. Encrypted 7Z/RAR cannot be decrypted here — note that for your runbook.
- Step 4Extract and confirm the format and entry count — Run it. The result panel shows the detected
formatandEntries. Record both in the incident timeline so the artifact is reproducible later. - Step 5Download the repackaged ZIP — Download
<archive>-extracted.zip. The original paths (e.g.var/log/app/...) are preserved under a<archive>/folder, so directory-aware log tooling still works. - Step 6Hash the evidence for chain-of-custody — Generate a SHA-256 of the original archive and the extracted ZIP with the checksum-generator sibling, and log both hashes in the incident record before any further handling.
Common incident artifacts and how each extracts
Typical archive types arriving during DevOps incidents, the engine they take, and triage notes.
| Artifact | Format | Engine | Triage note |
|---|---|---|---|
| Vendor support bundle | tar.gz | fflate (gz) → re-run on .tar | Two-pass: gz first, then the inner .tar |
| Windows-captured logs | rar / zip | libarchive / fflate | RAR is read-only; encrypted ZIP needs the password field |
| Heap / core dump pack | 7z | libarchive WASM | Encrypted 7Z cannot be decrypted in-browser |
| Container layer / rootfs | tar.xz / tar.bz2 | libarchive WASM | Expanded transparently into all member files |
| Disk / forensic image | iso | libarchive WASM | Read entry-by-entry; large ISOs may need a paid tier |
| App log rotation | gz | fflate | Single-member; yields one decompressed log file |
Tier sizing for incident archives
Real per-archive limits. Incident bundles can be large — size your tier before the page is needed at 02:00.
| Tier | Max archive size | Max entries | Typical incident fit |
|---|---|---|---|
| Free | 50 MB | 500 | Small log bundles, single-service dumps |
| Pro | 500 MB | 50,000 | Multi-service support bundles |
| Pro-media | 2 GB | 500,000 | Full-host log captures, small disk images |
| Developer | 2 GB | 500,000 | Same caps, unlimited files per job |
Cookbook
Extraction recipes drawn from real incident triage, with the engine path and the chain-of-custody step for each.
Open a vendor support bundle (two-pass tar.gz)
Vendor sends support-2026-06-13.tar.gz. GZIP holds one member, so pass one yields the inner .tar; pass two unpacks the logs with paths intact.
Pass 1: support-2026-06-13.tar.gz → format: gz
Output contains: support-2026-06-13.tar
Pass 2: support-2026-06-13.tar → format: tar
Output:
support-2026-06-13/var/log/app/error.log
support-2026-06-13/etc/app/config.yamlDecrypt a password-protected ZIP bundle
An incident bundle arrives encrypted (the vendor emailed the password separately, per their security policy). Paste it into the optional field; zip.js decrypts.
Input: incident-bundle.zip (AES-256) Password: <from vendor's separate channel> Engine: @zip.js/zip.js format: zip Entries: 1,204 Download: incident-bundle-extracted.zip
Triage a heap dump packed as 7z
A plain (non-encrypted) heap.7z from the JVM. libarchive WASM reads it; the dump file lands in the output ZIP ready for the analyzer.
Input: heap.7z Engine: libarchive WASM format: 7z Entries: 1 Download: heap-extracted.zip → heap/heapdump.hprof
Hash before and after for chain-of-custody
Forensic discipline: record a SHA-256 of the original artifact and of the extracted ZIP in the incident timeline, using the checksum-generator sibling.
Original: support-bundle.tar.gz SHA-256: 9f2c...e41 (via /archive-tools/checksum-generator) Extracted: support-bundle-extracted.zip SHA-256: 3a77...b9d Log both hashes + timestamps in the incident record.
Open a mislabelled artifact
An engineer saved a capture as capture.dat. Magic bytes reveal it is GZIP — no need to guess or rename during triage.
Input: capture.dat (no real extension) First 2 bytes: 1F 8B → GZIP Engine: fflate format: gz Entries: 1 Download: capture-extracted.zip
Edge cases and what actually happens
Encrypted 7Z / RAR support bundle
UnsupportedIf a vendor encrypts a 7Z or RAR, this tool cannot decrypt it — libarchive opens read-only with no passphrase, and the password field feeds only the ZIP path. Ask the vendor for a ZIP, or decrypt on a sanctioned machine with native 7-Zip / WinRAR.
Bundle exceeds tier size cap
Limit exceededA full-host capture over your tier cap (Free 50 MB, Pro 500 MB, Pro-media / Developer 2 GB) is refused before processing. Upgrade ahead of an incident, or have the vendor split the bundle.
Air-gapped box, page not pre-loaded
Load requiredThe page (and the libarchive WASM module) must be loaded at least once with a connection. On a truly air-gapped host, pre-load on a connected machine in the same browser profile, or stage the assets first. After load, extraction is fully offline.
WASM blocked by endpoint security
Engine load failedHardened forensics laptops sometimes block WebAssembly via endpoint protection. 7Z/RAR/BZ2/XZ/ISO then fail to load the engine; ZIP/GZIP/TAR still work via pure-JS fflate. Whitelist the page or use an approved browser profile.
Wrong password on an encrypted ZIP
Decryption failedAn incorrect bundle password yields Failed to decrypt "<name>". The password may be incorrect. Re-check the vendor's out-of-band password — it is case-sensitive — before escalating.
Nested bundle (zip in tar.gz in zip)
Single levelIncident bundles are sometimes double-wrapped. This tool extracts one level per run, so re-run on the inner archive, or use the nested-archive-extractor at /archive-tools/nested-archive-extractor for bounded recursion.
Corrupt / truncated upload from the customer
Unknown formatA bundle that was truncated in transit fails magic-byte detection and the ZIP fallback, giving Could not detect or extract archive format. Re-request the file and verify its SHA-256 against the sender's hash.
Huge entry count in a log bundle
Limit exceededLog bundles can hold tens of thousands of rotated files. The per-archive entry ceiling is 500 (Free), 50,000 (Pro), 500,000 (Pro-media / Developer). Use a paid tier for large captures.
Paths preserved for log tooling
PreservedOriginal entry paths (e.g. var/log/app/error.log) are kept inside the output ZIP under the <archive>/ folder, so directory-aware log viewers and grep-by-path workflows keep working.
ISO disc image of a host snapshot
SupportedISO9660 images are read entry-by-entry via libarchive. Large images may exceed the Free 50 MB cap; size your tier accordingly before the incident.
Frequently asked questions
Is it safe for sensitive incident data?
Yes. Files are read with FileReader and decoded in-browser via fflate / @zip.js/zip.js / libarchive WASM. There is no server-side extraction and no upload, so tokens, PII, and internal hostnames in the archive never leave the device.
Can I use it on an air-gapped forensics laptop?
Load the page (and the WASM module) once with a connection, then disconnect — extraction runs fully offline. On a strictly air-gapped host, pre-load in a connected session with the same browser profile first.
Vendor sent an encrypted 7z — can I open it here?
No. Encrypted 7Z/RAR cannot be decrypted in-browser because libarchive opens read-only with no passphrase. The password field works for ZIP only. Ask for a ZIP or decrypt on a sanctioned machine with 7-Zip.
How do I keep chain-of-custody?
Hash both the original archive and the extracted ZIP with the checksum-generator at /archive-tools/checksum-generator, and log the SHA-256 values and timestamps in your incident record before further handling.
Will log directory structure survive extraction?
Yes. Original entry paths are preserved inside the output ZIP, nested under a <archive>/ folder, so var/log/... style structures stay intact for grep and log-viewer tooling.
What's the biggest bundle I can open?
Free 50 MB, Pro 500 MB, Pro-media and Developer 2 GB per archive, with entry ceilings of 500 / 50,000 / 500,000 respectively. Size your tier before the incident, not during it.
Why did the support bundle come out as one .tar file?
TAR.GZ is GZIP-wrapped, and GZIP holds a single member. The first pass yields the inner .tar; run the extractor again on it to get the individual logs.
Can I check what's inside before extracting?
Yes — archive-previewer at /archive-tools/archive-previewer lists entries, sizes, and timestamps without unpacking, useful when you want to scope a bundle before committing triage time.
Can I verify integrity of a possibly-corrupt bundle?
Use archive-integrity-tester at /archive-tools/archive-integrity-tester to confirm every entry decompresses, or encrypted-archive-detector at /archive-tools/encrypted-archive-detector to confirm whether a bundle is encrypted before you ask for a password.
Is there an API to wire this into our incident automation?
Not a public REST API — archive tools are browserOnly with apiAvailable: false. Pro+ tiers can route jobs to a local @jadapps/runner via a headless browser, which can fit into a controlled on-prem automation.
What if the bundle is double-wrapped?
This tool extracts one level per run. Re-run on the inner archive, or use the nested-archive-extractor at /archive-tools/nested-archive-extractor for bounded automatic recursion.
Does it leave any trace on the incident machine?
Only the file you download (<archive>-extracted.zip) and normal browser cache for the page assets. No archive content is sent anywhere; the only server-side write is an anonymous run counter for signed-in dashboard stats, which contains no file content.
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.