Anoncap in PacketSafari

PacketSafari uses anoncap as a managed background workflow around the original uploaded capture. The product keeps the source file, creates an anonymized sibling capture, and exposes a compact mapping artifact for follow-up review.

This page explains the PacketSafari product integration: where anoncap runs, how it creates sibling captures, and how mapping lookup and AI policy connect to the analyzer. For the downloadable CLI, see the anoncap reference.

In the upload dialog

Enable Protect capture with Anoncap in the upload Review step.

PacketSafari then:

• stores the original upload first
• queues anoncap as a background follow-up task
• creates the anonymized result as a separate sibling capture
• shows progress in the upload task UI
• exposes Open anonymized copy when the sibling is ready

Product controls

Today the main productized anoncap decisions are intentionally separate:

• Privacy treatment: No anonymization investigates the original capture; Network evidence is the recommended P1 path and cuts payload bytes after a supported decoded boundary; Application evidence · DeepAnon retains complete L7 payload with an explicit warning that unsupported values may remain.
• Topology and device-vendor privacy: Hide topology and device-vendor details keeps the Network-evidence packet boundary while hiding subnet/prefix relationships and MAC vendor information. It does not change metadata handling, run an assurance scan, or send the file.
• Known-original scan: Scan for known original values is an explicit, off-by-default assurance pass for captures up to 10 MiB. Its runtime varies with retained payload, replacements, reassembly, and protocol complexity. It checks for original values known to Anoncap; it does not prove that every unsupported or encrypted value is private.
• Collapsed detail: protocol coverage, integrity validation, the known-original scan, source retention, and field-level controls remain separate without competing with the initial decision.
• Anonymization details: an advanced section groups the private profile into understandable controls instead of exposing hundreds of rules:
  • Network and device identities is on by default.
  • Secrets and credentials is always protected and cannot be switched off.
  • Operational labels is on by default. Device, object, dataset, module, control-block, and site labels change while protocol behavior remains useful.
  • Preserve troubleshooting semantics is always on. Methods, status codes, opcodes, function codes, OIDs, counters, timers, state, quality, sequence, revision, and register or point addressing semantics are preserved.
  • Correlate selected identities is off by default and lists only maintained groups. Enabling the enterprise username group does not imply that FTP, SNMP, or every application username is the same person.
• What is protected?: a read-only summary shows affected protocol categories without downloading or rendering the raw rules profile.
• Sanitize pcapng metadata for section/application metadata, interface metadata, address info, name-resolution blocks, and decryption-secret blocks
• Sanitize comments for capture comments and per-packet comments
• Unsupported payload handling

The packet-slicing choices are different operations:

• Adaptive header boundary (the default) has no fixed byte target. Anoncap follows supported outer, tunnel, inner L3, and inner L4 headers, then omits later payload bytes.
• Fixed byte limit keeps up to the selected number of bytes from each packet. It is not protocol-aware and can cut inside a header or field.
• Adaptive boundary + byte floor cuts at the later of the decoded header boundary or the selected byte position, capped by the original packet length. For an unknown top-level encapsulation, the fixed floor is the fallback.
• No slicing keeps the complete payload while supported identifiers are still rewritten.
• Slice bytes
• deterministic mapping and address-shape preservation toggles

Both metadata and comment sanitization default to on in the upload workflow. The known-original scan and integrity validation default to off.

Encrypted or unsupported values may remain when PacketSafari cannot safely decode and rewrite their authoritative bytes. The controls describe supported field-aware protection; they do not claim that every encrypted value can be anonymized.

PacketSafari also has a narrow media-scrub option for --rtp-silence-replacement. It is opt-in and currently targets RTP v2 over UDP with static payload types 0 (PCMU) and 8 (PCMA).

PacketSafari vs standalone CLI

The standalone anoncap default uses boundary-only adaptive payload truncation: it preserves supported tunnel, L3, L4, and ICMP quote headers, then truncates at the computed boundary. Slice bytes is not the default adaptive behavior; it is an optional fixed floor for workflows that need a minimum retained byte count. Use full-payload keep mode when a private/deep rules profile must retain and rewrite L7 semantic fields.

Public CLI and private PacketSafari profiles

The public anoncap release is the open-source CLI artifact. It is useful for local baseline anonymization and public-share workflows.

Active premium SaaS subscriptions (Copilot Pro or Agent Pro), active Enterprise organization memberships, admins, and on-prem deployments can use PacketSafari-maintained anoncap configuration for deeper sanitization than the public baseline profile:

Runtime guidance

Anoncap is usually much faster when the capture is already minimal. If you can safely export only the time window, hosts, or conversations you need before upload, do that first.

Smaller captures mean less packet data to dissect, a smaller replacement set to carry through the run, and fewer rewritten packets to re-check afterward.

The product shows relative planning cost rather than a universal deadline. A bounded July 2026 local sample measured roughly 0.6 s for a 144 KB SIP capture and 3.6–4.8 s for a 1 MB complex telco capture, depending on whether unsupported payload was sliced or kept. Those figures exclude upload, queueing, sibling import, and Triage, and should not be extrapolated to large captures.

The isolated known-original scan overhead was negligible on the measured 144 KB and complex 1 MB samples, but representative 5–10 MB measurements do not yet exist. The 10 MiB product limit bounds exposure to long runs; it does not guarantee a small delay. PacketSafari therefore labels the scan as an extra pass whose time varies instead of presenting a numeric estimate.

If you want to trim first, see Make a PCAP File Smaller.

In the capture library

From the PCAP list actions, PacketSafari supports:

• Anoncap anonymize for an already uploaded capture

Library anonymize actions also run as background follow-up tasks. The source capture stays in place and the anonymized result is added as a clearly labeled sibling. The library dialog uses the same collapsed anonymization details, mandatory secret protection, troubleshooting guarantee, and explicit identity-group choices as the upload flow.

Mapping report and anon lookup

For completed anonymized captures, PacketSafari keeps a compact mapping report artifact. You can:

• download the JSON report from capture actions
• open the full mapping report inside the analyzed capture view
• use Anon lookup from the analyzer actions menu

Anon lookup gives you a small movable search overlay so you can search original values, anonymized values, fields, and replacement sources without leaving the analyzer.

Passes, validation, and leak checks

For deeper runs, it helps to think of the engine as a layered pipeline:

1. structured field-aware rewrite during the main dissection/write path
2. a finished-output payload postprocess pass that rescans payload ranges with the accumulated replacement set
3. a validation pass that redisects modified output packets and checks parser health
4. an optional leak-verification pass in the standalone CLI / deeper verification path that rescans for survivor values

The slow cases are usually the ones with reassembled or nested protocol ownership. Some SIP, Diameter, and similar TCP-stream fields are only authoritative in the reassembled view, so anoncap may need to patch that reassembled span and then back-project the edit into the owning packet or segment bytes while still keeping lengths, checksums, and parser state coherent.

Plan and deployment note

In hosted SaaS, anoncap workflows are part of Copilot Pro and higher plans. On-prem deployments can use the same workflow with additional admin policy control over whether AI is allowed on non-anonymized captures.

Related docs

• How to anonymize a PCAP
• Tool comparison
• Capability matrix
• Payload reduction modes
• anoncap reference