anoncap: A Pseudonym Is Never a Real Address Again

Two days ago we shipped the Anonymizer app for macOS and Windows. Today's release of the anoncap engine fixes something we found while auditing it with synthetic captures: an anonymized capture could still contain a real address from the same network, not because a value was missed, but because a pseudonym happened to be that address.

Anonymizer 0.1.2 and anoncap 4.7.3 (20261009.1) are available now for macOS, Windows, and Linux.

The problem: pseudonyms that collide with reality

anoncap rewrites addresses while keeping subnet shape, so an analyst or an AI agent can still reason about the traffic. Hosts in one /24 stay in one /24, and host numbers are handed out in order. That is what makes the result readable, but it has a side effect in a single streaming pass: the engine may hand out 10.57.31.10 as the pseudonym for the first host it sees, and 10.57.31.10 may be a real host that only appears a thousand packets later.

The result was still one-to-one, so nothing was mixed up. But the anonymized file carried a real address, and anyone who knew the network could recognize it. Our audit over 95 captures found nine such collisions for IPv4 and MAC addresses. Nine is small, and it is the kind of small that matters when the whole point is that the capture can leave your control.

What changed

Real identities are reserved before anything is rewritten. The engine now makes a header-only pass over the file first, with no protocol dissection, which runs at disk speed. Every real MAC, IPv4, and IPv6 address in Ethernet, VLAN, ARP, IP, GRE, VXLAN, and GTP-U headers is reserved, and pseudonyms are drawn from what is left. Every identity found later in payloads is reserved as it is mapped, and pseudonym subnets avoid subnets that carry real hosts.

The result is checked, not assumed. At the end of the run the engine compares every pseudonym with every original. If an address that only exists inside a payload collided with a value handed out earlier, the engine re-runs automatically with every real identity reserved. On the audit set this happened once in 95 files.

One host, one pseudonym, also in Diameter over TCP. Large Diameter messages are reassembled from several TCP segments. The scanner for those messages could see an address that a field rule had already rewritten, treat the pseudonym as a new original, and map it again. The same SGSN would then appear under two different pseudonyms in one file. The scanner now sees the true original bytes and never re-maps a pseudonym.

Padded DHCP names and transaction IDs. Padded and unpadded forms of the same client or host name share one pseudonym, and DHCP transaction IDs, DNS IDs, SNMP request IDs, and NTP timestamps whose bytes merely look like an address are left alone. Session IDs in SIP, SDP owner usernames, IMEIs written as urn:gsma:imei: URNs, and IPv6 literals in text are covered as well.

Faster. The audit set anonymizes in 153 seconds instead of 193, because the engine now knows which /24s exist up front and spends less time on retries and text scanning. No capture got slower by more than two seconds.

Why this matters for AI-assisted analysis

The reason we anonymize instead of redact is that the capture should remain analyzable. An agent working on an anonymized capture needs the same host to have the same name everywhere, subnet relationships to survive, and no address in the file to point back at a real machine. This release keeps the first two properties and makes the third one a guarantee that is checked on every run rather than a probability.

Download

Both downloads are on the anoncap page:

• the Anonymizer app 0.1.2 for macOS (Apple silicon, macOS 14 or later, notarized) and Windows 10 and 11 (x64 installer or portable zip)
• the anoncap CLI 4.7.3 (20261009.1) bundles for Linux x64, macOS Apple silicon, macOS Intel, and Windows x64, with release notes and checksums

The Windows installer is still not code-signed, so Windows SmartScreen may ask you to confirm before it runs. Checksums for every file are published next to the downloads.

Anonymization reduces what a capture exposes. It does not make every capture automatically safe to share or replace your data-handling policy. Review what you send, especially when you keep application payload.