Repairing a Corrupt PCAP File Starts with Evidence, Not Blind Conversion

A corrupt PCAP file can stop an investigation at the worst possible time. The capture may be the only evidence from a customer site, a lab reproduction, or a production incident. When a tool refuses to open it, the fastest impulse is to convert it, trim it, or run it through another parser.

That can work. It can also destroy the clues that explain what went wrong. Repair should begin with evidence.

Identify the Failure Boundary

Before changing the file, determine where it fails:

• global header cannot be read
• link type is unexpected
• packet header is incomplete
• captured length exceeds remaining file size
• original length and captured length are inconsistent
• timestamp fields look invalid
• packet data is truncated
• trailing bytes remain after the last valid packet

Each failure implies a different repair strategy. A bad global header is not the same as a truncated last packet. A wrong link type is not the same as checksum offload confusion.

Preserve the Original Capture

Never overwrite the original capture. A repair workflow should create a new file and record what changed. If the original file is evidence in a support case, legal review, or vendor escalation, the original bytes matter.

A disciplined workflow keeps:

• original file hash
• parser failure location
• count of valid packets before failure
• bytes trimmed or rewritten
• packet indexes affected
• output file hash
• notes explaining why the edit was safe

This is not bureaucracy. It is how engineers avoid making the capture less trustworthy.

Common Corruption Patterns

Many corrupt PCAP cases are simple:

• the capture process was interrupted mid-write
• the file was copied before the writer closed it
• disk space ran out
• a tool wrote an invalid packet length
• the wrong file type was renamed as .pcap
• link-layer expectations do not match the payload

The repair should match the pattern. If only the final packet is incomplete, trimming the final partial record may recover the useful prefix. If packet lengths are inconsistent throughout the file, the capture may need deeper validation before any rewrite.

Do Not Treat Repair as Normalization

Repair means preserving as much valid evidence as possible. Normalization means rewriting data into a preferred shape. Those are different jobs.

For example, changing timestamps, recalculating checksums, or rewriting link-layer headers may be useful later, but those operations should not be mixed into the first recovery step. First recover what can be trusted. Then decide whether controlled surgery is appropriate.

Where PCAP Surgery Fits

PCAP Surgery is built for careful capture evidence review and controlled rewrite workflows. It is not trying to become a broad packet player or a replacement for every analysis tool. Its role is to help engineers inspect capture metadata, identify where a file fails, and apply edits only when the evidence supports the operation.

For a corrupt file, the valuable output is:

• what part of the file is valid
• where parsing fails
• what repair action was applied
• which packets or bytes were affected
• whether the resulting file can be opened by downstream tools

That is the difference between "I ran a converter" and "I can explain the repair."