How to nested extractor for devops & incident response
- Step 1Confirm tier and stay offline-capable — Open /archive-tools/nested-archive-extractor on a Pro (or higher) account. The tool runs in your tab; once loaded it does not need to phone home to process, which suits an air-gapped or restricted incident bridge.
- Step 2Drop the support bundle — Drag the single outer archive in. One file at a time — for several independent bundles, do them one by one or pre-merge with batch-extraction-manager.
- Step 3Set depth for the bundle shape — A two-level dump (outer ZIP → node ZIPs → logs) needs depth 3; a must-gather of tarballs-in-tarballs may need 4-5. Default 3 covers most. Keep it as low as the bundle requires to limit memory use.
- Step 4Process and read the metrics — Click Process. Note Archives unpacked (did every node ZIP open?) and Entries (total logs flattened) — a lower-than-expected unpack count flags an encrypted or corrupt member.
- Step 5Download and triage — Save
<bundle>-flattened.zip. Every log keeps its host/path lineage. Grep across it, or load into your log viewer; the path prefix tells you exactly which node and inner archive each line came from. - Step 6Build the evidence manifest — Run the flattened ZIP through checksum-generator (SHA-256 default) to record hashes for chain-of-custody, and file-listing-generator for a CSV/JSON inventory.
Common incident bundle shapes
How real diagnostic dumps nest, and the depth that flattens them. Output is one ZIP with full per-host paths.
| Bundle type | Typical nesting | maxDepth | After flattening |
|---|---|---|---|
| Vendor support dump | support.zip → node-N.zip → logs.tar.gz | 3 | node-N.zip/logs.tar.gz/var/log/*.log |
| K8s must-gather | must-gather.tar.gz → per-ns tarballs | 3-4 | <ns>.tar/.../pod.log |
| Crash bundle | crash.zip → core.7z + logs.zip | 3 | core.7z/* and logs.zip/* |
| Rotated log rollup | archive.zip → app-*.tar.gz | 2-3 | app-2026-06-12.tar.gz/app.log |
| Multi-layer forensic image carve | evidence.zip → set.zip → set.7z | 4 | deep members; raise depth as needed |
Tier limits that matter during triage
Free cannot run this tool. Watch the entry cap on large must-gathers — flattening multiplies entry counts.
| Tier | Per-job size | Entry cap | Runs this tool? |
|---|---|---|---|
| Free | 50 MB | 500 | No (Pro overlay) |
| Pro | 500 MB | 50,000 | Yes |
| Pro-media | 2 GB | 500,000 | Yes |
| Developer | 2 GB | 500,000 | Yes |
Cookbook
Real incident-bundle shapes and the flattened paths you triage against. Hostnames anonymised.
Per-node support dump
An outer ZIP of per-node ZIPs, each with a compressed log bundle. Depth 3 flattens all of it while keeping the node name in the path.
Input: support-2026-06-12.zip node-1.zip -> logs.tar.gz -> var/log/app.log, var/log/sys.log node-2.zip -> logs.tar.gz -> var/log/app.log maxDepth: 3 Output: support-2026-06-12-flattened.zip node-1.zip/logs.tar.gz/var/log/app.log node-1.zip/logs.tar.gz/var/log/sys.log node-2.zip/logs.tar.gz/var/log/app.log Then: grep -r 'ERROR' across the flattened ZIP, host visible in path.
Crash bundle with a 7z core
Vendor crash bundles often ship the core dump as 7z. libarchive WASM reads it so the core lands beside the logs.
Input: crash.zip logs.zip -> service.log core.7z -> core.bin, threads.txt maxDepth: 3 Output: crash-flattened.zip logs.zip/service.log core.7z/core.bin core.7z/threads.txt
One node's archive is encrypted
An encrypted node bundle cannot be opened (no password field). It is preserved raw; the rest still triage. Decrypt that one separately.
Input: support.zip node-1.zip -> logs/* node-2-secure.zip -> (AES encrypted) Output: support-flattened.zip node-1.zip/logs/* node-2-secure.zip <- raw, not unpacked Fix: multi-format-extractor with the password, then re-nest.
Depth-limit a huge must-gather
Cap depth to keep memory bounded and pull only the top layers first, then go deeper on the node you care about.
Input: must-gather.tar.gz (tarballs of tarballs, 5 levels) maxDepth: 2 -> outer + one layer, inner tarballs preserved -> identify the failing namespace maxDepth: 4 on just that node's tarball -> full leaf logs
Manifest the evidence after flattening
Chain-of-custody: hash every extracted file. Run the flattened ZIP through the checksum tool.
support-flattened.zip -> checksum-generator (SHA-256) node-1.zip/logs.tar.gz/var/log/app.log 9f86d0818... node-2.zip/logs.tar.gz/var/log/app.log 60303ae22... (record alongside the case file)
Edge cases and what actually happens
Analyst is on the free tier
Pro requiredThis tool requires Pro. A free-tier analyst sees a Pro upgrade overlay, not the dropzone. Provision analyst seats at Pro or above before an incident, not during one.
Encrypted node bundle
Preserved (raw)There is no password field on this tool, so an encrypted member is preserved as raw bytes rather than unpacked. Triage the rest immediately and decrypt the secured bundle with multi-format-extractor (password supported), then re-run nesting.
Truncated log file in a rotated bundle
Preserved (raw)A partially-written rotation archive that fails to open is caught and kept as raw bytes; every other log still extracts. The Archives-unpacked metric will be one short — a useful signal that a member was bad.
Must-gather exceeds the entry cap
Limit reachedLarge Kubernetes must-gathers can flatten to hundreds of thousands of files. Pro caps at 50,000 entries; Pro-media/Developer at 500,000. If you hit it, lower maxDepth, or unpack the outer layer and process the relevant node separately.
Bundle over 2 GB
Rejected (limit)Even Developer rejects inputs over 2 GB per job with a tier-limit error before decompression. For oversized forensic images, carve or split externally first, then flatten the parts.
Inner archive saved without an archive extension
Not recursedSome tools name a tar dump data or payload.bin. The recursion keys on archive extensions, so such a member is copied through as a leaf, not unpacked. Rename to .tar/.zip or extract that layer with a sibling tool first.
Memory pressure on a deep tree
By designEach layer is fully decompressed in memory before the next opens; the schema flags depths past 5 as memory-heavy. On a constrained jump box, keep maxDepth as low as the bundle requires.
Hardened browser blocks WASM
Fails to loadA locked-down enterprise browser or strict CSP can block the libarchive WASM module, disabling the 7z/rar/bz2/xz path (ZIP/GZIP/TAR via fflate still work). Allow WebAssembly for the tool's origin.
Two nodes produce identically-named files
Preserved (path-distinct)Because each member is stored under its <archive>/... prefix, node-1.zip/app.log and node-2.zip/app.log stay separate. Only identically-named siblings inside the same inner archive could collide.
Frequently asked questions
Is this safe for sensitive incident evidence?
The processing is in-browser — files are not uploaded, so a memory dump or PII-laden log never leaves the analyst's machine. That said, do your own due diligence for formal chain-of-custody; the tool's privacy property is that nothing is transmitted, verifiable via DevTools → Network.
Does it work on a locked-down corporate laptop?
It needs no install — just a WASM-capable browser and a Pro login. If the browser or CSP blocks WebAssembly, the libarchive (7z/rar/bz2/xz) path is disabled but ZIP/GZIP/TAR still work. Confirm WASM is allowed for the origin.
Can several analysts use it at once?
Yes — each runs independently in their own browser. There is no shared server-side queue because there is no server-side processing; concurrency is bounded only by each analyst's own machine.
How deep should I set the depth for a must-gather?
Start at 3. Tarballs-of-tarballs may need 4-5. Keep it as low as the bundle requires — every extra layer multiplies memory use and entry count. You can run shallow first to map the structure, then deeper on one node.
What about regulated environments (HIPAA, PCI, FedRAMP)?
Because data is never transmitted off-device, the usual upload-exposure concern does not apply. Compliance also depends on your endpoint, browser, and organisational controls — evaluate against your own framework. The tool itself adds no network egress for your files.
It says a node bundle is encrypted — now what?
This tool cannot take a password, so it preserves the encrypted member as raw bytes. Extract that one with multi-format-extractor, which accepts a password, then re-run nesting on the decrypted output to fold it into the tree.
Will one corrupt log abort the whole triage?
No. A member that fails to open is caught and kept as raw bytes, and the rest extract normally. Watch the Archives-unpacked metric — if it is lower than the number of nested archives, a member was bad or encrypted.
Can I get an inventory of what was in the bundle?
Yes — feed the flattened ZIP into file-listing-generator for a CSV/JSON/TXT listing of every leaf and its path. For host-level provenance, the path prefix already encodes which node ZIP each file came from.
How do I record hashes for chain-of-custody?
Run the flattened output through checksum-generator (SHA-256 by default, SHA-1/MD5 also available) and store the manifest with your case notes.
Does it handle Kubernetes must-gather tarballs?
Yes — they are tar/tar.gz nesting, which fflate reads. Set maxDepth to match the layers (often 3-4). Large clusters can hit the entry cap; process per-namespace if so.
Can I automate this across many incidents?
Not via an API — archive tools have no public endpoint (Pro+ runs them through a headless-browser runner). For batch/automated triage pipelines, a scripted 7z/tar/unzip loop on a triage host is the practical equivalent.
What is the largest bundle it will take?
500 MB per job on Pro, 2 GB on Pro-media/Developer. Above that, split or carve externally first. Also mind the entry cap (50k Pro / 500k higher), which deep flattening can exhaust before the size cap.
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.