Packet Capture Preparation: Repair, Sanitization, and Evidence Workflow
Prepare a packet capture for support or QA without confusing focused scope, supported header rewrites, checksum repair, and partial privacy inventory with complete sanitization or corrupt-file recovery.
“Repair this PCAP” and “sanitize this capture” can mean very different things. A file might be structurally corrupt, too large to share, full of unrelated traffic, carrying stale checksum warnings, or exposing identifiers and payload that require policy review. Treating all of those jobs as one-click PCAP repair leads to unsafe claims and unusable support artifacts.
PCAP Surgery is a local preparation workbench for a narrower, controlled workflow: preserve a source capture, identify the evidence window with an analyzer, preview supported keep/drop and L2–L4 rewrite operations, inspect bounded exposure findings for the selected output, write a new classic PCAP, and independently validate it. It does not claim to recover every corrupt capture, decrypt traffic, reassemble every stream, redact arbitrary payload, or certify that a file is safe to share.
This page maps the terms “packet capture repair” and “PCAP sanitization” to the evidence you actually need, so a support, firmware, network, or QA team can prepare a useful artifact without losing the proof it was meant to preserve.
Identify the real preparation problem first
The first step is to replace a vague request with a concrete outcome. “Make this PCAP smaller” is not enough; a subset that removes the handshake or retry boundary may no longer explain the failure. “Remove private data” is not enough; header masking cannot promise that names, tokens, payload, or unknown protocols are gone.
| What someone asks for | Underlying job | Responsible approach |
|---|---|---|
| “Repair a corrupt PCAP” | Recover/open a damaged container or truncated file | Use a recovery-capable process and validate with a trusted parser; do not claim PCAP Surgery repairs arbitrary corruption |
| “Fix bad checksums” | Separate capture/offload artifact from a real packet problem, or apply supported rewrite checksums | Analyse first; use supported checksum repair only for supported L2–L4 edits |
| “Sanitize this file” | Reduce privacy exposure before sharing | Scope the flow, review visible exposure, apply supported transformations, then run independent privacy review |
| “Send only the failure” | Produce a minimal reproducible support/QA artifact | Preserve handshake/context and preview a focused subset |
| “Hide an IP address” | Rewrite selected addressing fields | Verify supported protocol/checksum scope and remember payload may still reveal identity |
| “Change timing for a fixture” | Create a controlled derived timeline | Preserve original timing and document transformation/validation |
The corrupt PCAP recovery boundary explains why a truthful product does not advertise universal file recovery. The checksum offload guide helps determine whether a checksum warning describes the wire or a capture artifact.
Preserve the source before any transformation
Never let the only copy of a capture become the working copy. Keep the original read-only and record where it came from, capture point/interface, file type, timestamps, and any existing parser warnings. Every output should be a separately named derived artifact with a known scope and review note.
| Source record | Why it matters later |
|---|---|
| Original filename/hash or controlled storage identity | Lets a reviewer identify the untouched evidence source |
| Capture interface/point | Sets the limit on what the trace can prove |
| File format and link/interface assumptions | Prevents unsupported metadata expectations on export |
| Collection time/timezone | Makes log and multi-capture correlation possible |
| Existing corruption/parser warnings | Separates source defects from later edits |
| Incident question | Keeps filtering aligned with the reason the file is retained |
| Owner/privacy classification | Determines who may view or receive any derivative |
PCAP Surgery writes a new artifact rather than overwriting the source. That is a workflow safeguard, not a complete chain-of-custody system; follow your own evidence retention and access policy where it applies.
Analyse before you edit
Use the strongest available analyzer to establish the conversation, endpoint, packet/time range, and protocol evidence that matters. Deep decoding, stream reassembly, expert diagnostics, and root-cause investigation may belong in Wireshark or another specialist tool. A preparation workbench should inherit an evidence contract, not guess it.
| Analysis finding | Context to keep when preparing an artifact |
|---|---|
| TCP retransmission/recovery | Handshake where available, data gap, ACK/SACK context, recovery, capture-point note |
| HTTP/TLS latency | DNS/connect/handshake/request/response timing around the symptom |
| DHCP or address failure | Offer/request/ack or timeout sequence and relevant interface context |
| QUIC/HTTP3 complaint | UDP attempt, DNS/ICMP/TCP comparison path and encryption limitation note |
| RTSP/RTP symptom | Control dialogue, SDP, negotiated transport, RTP/RTCP window near symptom |
| Regression fixture | The exact packet sequence and timing the test is expected to exercise |
The PCAP analyzer versus editor guide explains this bridge in detail. If you cannot state what must survive the edit, the capture is not ready for a meaningful subset.
Prepare a focused evidence artifact
Once the preservation contract is clear, reduce scope deliberately. PCAP Surgery can focus supported packet views by protocol, endpoint, direction, packet number, time range, and text, then preview keep/drop decisions before export. The goal is not the fewest packets at any cost; it is the smallest artifact that still proves the documented observation.
| Preparation action | What it preserves | Failure if used carelessly |
|---|---|---|
| Endpoint/protocol filtering | Relevant conversation identity | Excluding a related control/handshake flow |
| Packet-number range | Reproducible evidence reference | Cutting before the first causal packet |
| Time-window scope | Latency/retry boundary | Removing the gap that demonstrates the symptom |
| Direction filter | One side of a selected flow | Making an absence of response impossible to interpret |
| Text/field narrowing | Review focus for known evidence | Treating a search hit as complete protocol context |
| Keep/drop preview | Proposed output count/order | Assuming preview proves privacy or root cause |
For large recordings, use split a large PCAP and extract a conversation. Retain the original and a written scope note so a recipient can request more context without restarting from an unexplained tiny file.
Know exactly what supported rewrites can and cannot repair
Supported L2–L4 header rewrites can change selected fields while repairing corresponding supported IPv4, TCP, and UDP checksums. That is helpful for controlled test fixtures or selected-address transformations. It is not arbitrary packet repair and it is not semantic sanitization of everything carried in the capture.
| Transformation question | What to verify |
|---|---|
| Which packets are changed? | Previewed count, packet IDs, and selected scope |
| Which header fields are supported? | Product/version documentation and the planned rule/manual edit |
| Are checksums repaired for this supported rewrite? | Export preview and independent parser validation |
| Could payload retain old identity? | DNS, HTTP, TLS, application bytes, embedded addresses, and unknown protocol review |
| Could timing/order be affected? | Transformation plan and post-export comparison |
| Does another protocol reference the edited value? | Separate analysis; do not assume cross-protocol semantic repair |
Fixed-length raw-byte edits are not automatically checksum-safe, and arbitrary payload stripping/truncation is not a supported general solution. When a case needs stronger sanitization, use a process that matches that requirement and verify the actual output.
Treat privacy inventory as a review prompt, not a certificate
The selected full/subset artifact can be reviewed for visible IPv4, IPv6, MAC, DNS, HTTP Host, TLS SNI, printable payload, and unknown exposure. That inventory is intentionally bounded: it does not decrypt traffic, reassemble streams, or prove the absence of sensitive information.
| Exposure category | Why a separate decision is still needed |
|---|---|
| IP/MAC addresses | May identify systems, customers, or topology |
| DNS/HTTP Host/TLS SNI | May reveal internal hostnames, services, or organizations |
| Printable payload | May contain credentials, tokens, user content, or proprietary data |
| Encrypted/unknown payload | Can hide material the inventory cannot classify |
| IPv6 or non-target protocol data | May remain outside a chosen IPv4/header rewrite scope |
| Original and derived copies | Need access/retention control even if one output is shareable |
Read what PCAP Surgery can and cannot inventory before external handoff. “No finding in this bounded inventory” is not the same as “safe for public release.”
Validate after writing the derived PCAP
Export is a new technical event. Re-open an important derived artifact in a trusted parser and compare it with the preservation contract: packet count, ordering, key fields, checksum status for supported edits, timing, and the failure pattern. If it is a regression fixture, run the intended parser or test against the exported file where feasible.
| Post-export check | Why it matters |
|---|---|
| File opens in an independent parser | Detects format/write problems |
| Packet count/scope matches preview | Finds accidental extra removals or inclusions |
| Handshake/control context remains | Ensures the case is still interpretable |
| Target symptom remains visible | Confirms the artifact still proves its stated point |
| Supported checksums validate | Avoids creating an unrelated broken-packet issue |
| Timing still tells the same story | Protects latency/retry/recovery evidence |
| Privacy review is repeated on output | Derived bytes/scope can differ from source assumptions |
PCAP Surgery currently does not generate a cryptographic transformation manifest or automatic post-export validation certificate. Record the operator, purpose, scope, transformation, and verification result in the handoff note when the case matters.
A support and QA handoff template
Attach a concise explanation to every prepared capture:
- Question: What exact behaviour should the recipient verify?
- Capture point: Where was it observed, and what may be missing?
- Source: Which original capture/version is preserved?
- Evidence scope: Which packet/time range and surrounding context were retained?
- Changes: Which supported filters/rewrites/timing operations were applied?
- Validation: Which parser/test re-opened the output and what remained true?
- Privacy boundary: What was reviewed, and what cannot be guaranteed?
- Next owner: Which team can prove the remaining hypothesis?
This turns a PCAP from an opaque attachment into an evidence handoff. It also prevents an editor's bounded capabilities from being mistaken for total recovery or full sanitization.
Packet capture preparation QA checklist
Before sharing, check that the original remains preserved, the edited file has a different path, the evidence contract is documented, output count/timing/key packets were revalidated, and the privacy decision is appropriate for the recipient. Keep unsupported recovery and redaction claims out of customer or incident copy.
Use PCAP Surgery overview, capture scope help, the PCAP Surgery blog, or download PCAP Surgery for the local preparation workflow.
If the unresolved question is which preparation tool fits the case, compare the best PCAP editor workflows and then review PCAP Surgery versus Wireshark, editcap, and TraceWrangler. Those guides distinguish protocol analysis, command-line transformation, visual evidence preparation, and broader sanitization work instead of treating every packet tool as interchangeable.
Frequently asked questions
Can PCAP Surgery repair any corrupt capture file?
No. It is not a universal corrupt-PCAP recovery tool. Preserve the source, diagnose the container/parser problem with appropriate recovery tooling, and validate any recovered file independently.
Does header rewriting fully sanitize a PCAP?
No. Supported headers and checksums are a bounded operation. DNS, HTTP, TLS, payload, IPv6, unknown protocols, and embedded identifiers may still expose sensitive material.
Why not just send the complete original file?
The complete file may contain unrelated traffic, more privacy exposure, and too much noise for a recipient to reproduce the problem quickly. Preserve it securely, then prepare a focused derivative with enough context to retain the evidence.
A two-person release check for sensitive captures
When a derivative leaves the incident team, separate the transformation author from the release reviewer. The author documents the evidence contract and performs supported edits. The reviewer independently opens the output, checks retained protocol context, searches for known identifiers, and confirms that the recipient is authorized for the remaining exposure. This is a process control, not a guarantee that arbitrary payload has been sanitized.
| Review layer | Author checks | Independent reviewer checks |
|---|---|---|
| Evidence | handshake, failure, retries, recovery retained | stated conclusion can still be reproduced |
| Integrity | packet count and hashes recorded | output reopens in a separate parser |
| Transformation | every filter/rewrite listed | no undocumented scope or timing change |
| Privacy | known visible identifiers inventoried | recipient and residual exposure approved |
| Delivery | derivative has distinct name and path | original is not attached accidentally |
Use a stable case label rather than customer, host, or employee names in the derivative filename. Keep the original hash and derivative hash in a sidecar manifest. If the artifact is regenerated, create a new derivative hash and version instead of silently replacing the reviewed file.
Is truncating payload the same as sanitizing it?
No. Truncation can remove some content while also destroying protocol evidence, and identifiers may remain in headers or the retained payload prefix. Document exactly what was truncated and run an independent privacy review.
Should encrypted traffic be considered safe to share?
No. TLS still exposes addresses, ports, timing, sizes, certificate or handshake metadata, and traffic relationships. Session keys or adjacent plaintext logs may also exist elsewhere. Apply the recipient and minimization policy even when application content is encrypted.
What is the minimum useful support subset?
There is no universal packet count. Retain enough pre-failure context to establish the connection and protocol state, the complete failure boundary, relevant retry or timeout behavior, and recovery or final termination. The capture-scope guide helps define that window without confusing a small file with a sufficient file.
The final release note should say what the derivative is for, what was retained, what was changed, what privacy checks were performed, and what remains outside the guarantee. That language prevents “prepared for this support case” from being reinterpreted as “safe for any public distribution.”
Before sending, open the exact attachment from the outbound location rather than trusting a similarly named local file. Match its SHA-256 to the reviewed manifest, verify recipient and retention policy, and record the transfer. This catches the mundane but serious failure of attaching an unreviewed original instead of the approved derivative.
<!-- multilingual-related-reading:start -->Related guides
Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:
<!-- multilingual-related-reading:end -->