Corrupt PCAP Triage: Preserve Evidence Before You Rewrite
How to distinguish a damaged capture container from bad packet checksums, and where PCAP Surgery's repair scope stops.
“Corrupt PCAP” can mean several different things: a truncated file record, invalid capture container metadata, a packet whose checksum looks wrong because of NIC offload, or a structurally valid capture with timestamps that are inconvenient for a lab fixture.
Separate container damage from packet edits
First open the file in a mature parser and preserve the original. If records are truncated or the container is structurally invalid, use specialized recovery tooling. PCAP Surgery does not claim general corrupt-container recovery and may reject data it cannot index safely.
If the container is valid, inspect why a checksum appears wrong before changing it. Host captures often contain checksum-offload artifacts that never appeared on the wire.
PCAP Surgery's actual repair scope
The product can prepare a new classic PCAP from an indexed source, change timestamps, keep or drop packets, perform selected L2-L4 rewrites, and repair IPv4/TCP/UDP checksums on supported rewrite paths. Fixed-length raw byte edits do not receive automatic checksum repair.
That is controlled artifact preparation, not arbitrary recovery. Re-open the output in a trusted parser before using it as evidence or a regression fixture.
Establish whether the capture container is readable
Make a copy of the received file, calculate an identifier or hash under the case policy, and record its source, time range, link type, and byte length before opening it in a repair tool. A viewer that shows “malformed” can be reporting a truncated record, an unsupported encapsulation, a damaged pcapng block, or a perfectly valid host-side checksum artifact. Those cases need different owners and different preservation rules.
| Observation | What it can mean | Safe next action |
|---|---|---|
| Parser stops at one record offset | Truncation or invalid container length | Preserve original and record offset/remaining bytes |
| File opens; only selected packets look bad | Capture/offload or packet-level issue | Inspect capture host and checksum evidence |
| Different tools disagree on packet count | Parser support or format interpretation difference | Retain tool versions and compare container metadata |
| Timestamp order is awkward but records parse | Analysis/fixture timing issue, not corruption | Use a documented derived export, keep original |
| Output cannot be reopened | Transformation or export failed | Do not share it; compare source/output validation logs |
Use capture scope guidance before collecting a replacement. A new capture is sometimes safer than attempting to recover a partial artifact, but it is not a substitute for retaining the original evidence and its failure symptoms.
Avoid confusing checksum-offload with corruption
Host captures may record outbound packets before the network adapter calculates final IPv4, TCP, or UDP checksums. A packet decoder then labels the checksum “incorrect,” while the wire packet was valid. Compare direction, capture interface, offload setting, and a capture from another observation point before modifying checksums. A blanket checksum rewrite can turn a useful offload observation into misleading evidence.
| Checksum pattern | Evidence to preserve | Likely interpretation |
|---|---|---|
| Outbound packets only; same host capture | Direction, NIC/offload context | Possible offload artifact |
| Inbound and outbound failures at same boundary | Packet bytes and independent capture | Real transport or capture corruption needs review |
| Bad checksum after a deliberate address/port rewrite | Transformation manifest and affected packets | Derived packet needs supported checksum repair |
| Fixed-length raw byte edit | Exact offset/value change | Automatic repair may not apply |
| Parser reports checksum but transport is healthy | Time, retransmission, peer capture | Do not equate decoder label with on-wire proof |
For the detailed distinction, read checksum offload false errors. The right conclusion is bounded: a capture can be structurally valid even when a checksum display needs host-context interpretation.
Create a reproducible derived artifact
If the source parses and the investigation requires a smaller or normalized file, define the purpose first: a minimal failure window, a timestamp-normalized lab fixture, a subset by conversation, or a supported L2–L4 rewrite. Keep the original immutable and make every derived output traceable to it. Never call a derived file “repaired original evidence.”
| Derived-artifact step | Record in the case | Validation before sharing |
|---|---|---|
| Select packets/window | Filter or packet-number rule, timezone, reason | Confirm expected first/last packets remain |
| Apply supported transformation | Tool version and explicit options | Reopen in independent parser |
| Recalculate supported checksums | Affected protocol/packets | Inspect checksum and packet count changes |
| Export classic PCAP if required | Source format and unavoidable format loss | Confirm receiver can open it |
| Create evidence manifest | Source identity, output identity, transformations | Review by case owner |
PCAP timestamp rewrite evidence explains why time edits require an audit trail. For tool boundaries and packet-editing choices, use the PCAP editing FAQ rather than assuming that all malformed input is recoverable.
FAQ: repair corrupt PCAP files
Can PCAP Surgery repair any damaged PCAP or pcapng file?
No. It does not claim general corrupt-container recovery. It prepares controlled derived PCAP artifacts from sources it can index safely and rejects cases outside that scope.
Should I edit a checksum that Wireshark marks invalid?
Not before checking capture location and NIC offload. An invalid-looking checksum in a host capture may never have existed on the wire.
Is a timestamp rewrite evidence tampering?
It is a transformation. It can be appropriate for a lab fixture when documented, but the original must remain preserved and the derived output must state what changed.
Handoff checklist
Send the original file identity, parser/tool versions, exact failure offset or error, capture location, link type, packet count, checksum/offload context, intended derived-artifact purpose, transformation manifest, and independent reopen result. Open PCAP Surgery only for its documented preparation scope; for a broad editor comparison, see best PCAP editing tools. The useful statement is “the source container truncates at record X” or “the source is valid and only outbound checksum labels reflect offload,” not simply “the pcap is corrupt.”
Decide whether recovery is worth the risk
Not every unreadable capture should be repaired. If the incident question depends on packets after a truncation point, a replacement capture from an approved observation point can be more defensible than guessed recovery. If the question is limited to packets that parse before the defect, export only that known-readable window and label the omission. If a vendor requires a file, provide the original separately under the correct access controls and describe exactly what the derived file excludes.
| Case goal | Prefer | Avoid |
|---|---|---|
| Explain a parser failure | Original plus offset/error report | Rewriting records until a viewer stops complaining |
| Create a regression fixture | Minimal readable subset with manifest | Treating a rewritten file as source evidence |
| Diagnose checksum warning | Independent capture/offload context | Globally recalculating checksums without context |
| Share a narrow failure | Reviewed packet/time window | Sending a whole production capture |
| Prove a missing event | Replacement capture plan and limitation note | Inferring packets beyond a truncation boundary |
This choice should be recorded before transformations begin. A technically readable output is not necessarily fit for the investigative or compliance purpose that motivated the capture.
Validate at three levels
First validate the file container: does an independent parser open it and report the expected link type and packet count? Then validate the protocol result: do the selected conversation, flags, timestamps, and decoded fields still support the stated conclusion? Finally validate the chain of custody: can a reviewer connect the output to the source and reproduce every intentional change? A file can pass one level and fail another.
| Validation level | Question | Evidence |
|---|---|---|
| Container | Can another parser traverse the output? | Tool/version and reopen result |
| Packet meaning | Did the relevant failure window survive? | Packet-number/time comparison |
| Transformation | Are changes explained and bounded? | Options, before/after counts, manifest |
| Evidence ownership | Is the original retained and protected? | Case reference and access owner |
When validation disagrees, stop at the last known-good artifact rather than adding another rewrite. That preserves the ability to explain the uncertainty to an incident lead, vendor, or future reviewer.
Practical triage worksheet
Write a one-page record while inspecting the capture: source identity, how it was transferred, first parser error, first readable and unreadable offsets, capture host/interface, known offload state, relevant conversation window, intended recipient, and chosen action. Include a “not proven” line for any data beyond a truncation boundary or encrypted protocol layer. This small worksheet prevents a later repair attempt from losing the facts that made the file suspicious in the first place.
The goal of corrupt PCAP triage is not a prettier file. It is an evidence-preserving decision: retain the original, identify whether the container or observed packets are at fault, produce only a documented derivative when it answers a defined question, and state the limits plainly.
Before closing the case, have a second reviewer reopen both source and derivative, confirm the stated packet window, and read the limitation note without relying on the analyst's memory. If that reviewer cannot tell what failed, what changed, and what remains unknown, the triage record is not ready for a vendor handoff or regression repository.
Keep the review result with the artifact so a later investigation can distinguish original capture facts from decisions made during preparation.
Parser-error decision table
Capture the exact parser message and the byte or record boundary where reading stops. Different tools may tolerate different damage, so “opens in one application” does not prove a healthy container. Compare at least two independent readers and avoid exporting through a tolerant reader until the missing or altered scope is understood.
| Observation | Safe interpretation | Next action |
|---|---|---|
| Both parsers stop at same record | Structural truncation or malformed record is likely | Preserve source and use recovery-capable tooling |
| One parser opens, another fails | Parser tolerance differs | Compare packet counts and last readable offset |
| File opens, many checksum warnings | Container may be healthy | Investigate NIC offload and capture point |
| Timestamps jump but records parse | Timing evidence is suspect | Follow timestamp-evidence workflow |
| Link type or interface metadata is unknown | Decode context may be incomplete | Recover metadata before protocol claims |
Can changing the extension repair a PCAP?
No. Renaming .pcapng to .pcap or vice versa does not convert container structures. Identify the actual magic bytes and format, then use a trusted conversion only after the source parses sufficiently.
Should a truncated final packet be dropped?
Only in a documented derivative and only if the remaining scope still answers the question. Record the original last readable offset, packet count difference, and the fact that evidence beyond truncation is unavailable. Never replace the original with the shortened file.
What if the file was damaged during transfer?
Compare source and received hashes. If they differ, repeat the transfer through a verified path before attempting recovery. A clean retransmission is stronger than reconstructing a file that was altered in transit.
Recovery handoff record
Give the specialist original hash, file size, true container type, transfer history, parser/tool versions, exact first error, last successfully decoded record, expected capture duration, and intended investigation question. Those facts help choose whether block recovery, record salvage, or a replacement capture is appropriate.
When a readable derivative is produced, validate it with the complete evidence workflow and document its limits through the packet preparation process. Recovery does not automatically make timestamps, missing packets, or privacy exposure trustworthy.
Replacement-capture plan when recovery is insufficient
If the damaged range includes the event needed for diagnosis, stop polishing the derivative and design a replacement capture. Record the endpoint, interface, direction, snap length, capture filter, expected traffic volume, clock source, storage budget, and trigger that ends collection. Confirm that the capture process reports dropped packets and that disk rotation cannot overwrite the failure window.
Run a short authorized test before the incident window. Open the resulting file in two parsers, confirm both traffic directions, verify timestamps against a known log event, and check that the required protocol headers and payload length are present. A validated five-minute test is better than discovering after a day that only one direction or the wrong interface was captured.
| Replacement check | Acceptance condition |
|---|---|
| Capture point | Sees the endpoint and direction needed for the claim |
| Snap length | Retains required headers or payload evidence |
| Clock | Correlates within documented uncertainty |
| Drop monitoring | Tool and host counters are recorded |
| Rotation | Failure context cannot be overwritten before retrieval |
Store the replacement separately from the corrupt source. The old artifact remains part of the case history and may explain what was originally observed, even when it cannot support the final packet-level conclusion.
<!-- 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 -->