v0.5.6 — what two programs say to each other

Loopback capture: what programs on this machine say to each other

An established TCP connection over loopback is handled by a fastpath inside the Windows
stack and never becomes a packet on any adapter. Measured twice with the packet monitor
Windows ships, told to capture every component: 5,276 events and not one of them loopback.

So until now the tool could tell you a program opened a connection to 127.0.0.1 and moved
4,096 bytes, and nothing whatsoever about what those bytes were. That is the worst place to
be blind — a program coordinating with a local helper it just installed is exactly the
arrangement worth reading.

It now reads them, both directions, with contents.

How

Npcap's loopback adapter hooks the Windows Filtering Platform, so it
sits above the decision that makes loopback a fastpath. That is the same kernel-callout
mechanism this tool would otherwise have had to ship a driver of its own to reach — except
already written, signed, and maintained by somebody else. wpcap.dll is called directly
rather than through a capture program, because Npcap installs the library and the programs
that drive it come with Wireshark, which an analysis machine usually does not have.

The output is pcapng, so reassembly, direction, protocol detection, content extraction and
the blob store all apply unchanged.

What was verified against real sockets

• Both loopback families. IPv4 and IPv6, tested separately — localhost resolves to
  ::1 before 127.0.0.1 on current Windows, so a capture handling only IPv4 would have
  been missing the common half while looking exactly like a program that never talked.
• Oriented by the SYN. On loopback both ends are this machine, so addresses cannot say
  which end connected. What a program sent and what it received are different columns.
• Inside a whole session, not only on its own — which is where the two fixes below
  turned up.

Honest about its edges

• Off by default, and the switch says why: it needs a driver this tool does not install,
  and it records local traffic from every process on the machine rather than only the
  subject's. A recording made with it on contains more than one made without it.
• Never silently empty. A missing driver, a missing loopback adapter, a size cap
  reached, a machine where nothing spoke locally — each says which it was. A capture that
  quietly produces nothing is indistinguishable from a program that never talked.
• What it cannot see is named. Unix-domain sockets and named pipes carry no IP and are
  recorded as sizes without contents; a local conversation inside TLS is recorded as the
  ciphertext it was.
• Bounded at 512 MB, because local IPC is not a trickle.

Available as Capture local conversations in the workbench, --loopback on the CLI.

Fixed

One local conversation was recorded three times. The socket provider sees the client's
socket, sees the accepted socket as a second one, and the capture sees the traffic between
them. All three are true — and the operator was shown one conversation three times,
including a row saying its contents could not be captured directly above a row containing
them. Every record is still stored, because provenance is what an evidence file is for; the
reading view now shows one row per exchange, the one carrying the most.

An IPv4-mapped IPv6 address was treated as a different machine. A dual-stack listener
calls its peer ::ffff:127.0.0.1 where the client calls it 127.0.0.1. Treating those as
different split one conversation into two flows, with the bytes divided between them and the
process attribution landing on only one.

Download

CaYaTrace.exe — self-contained, no .NET install needed. Windows 10/11 x64.
Npcap is only needed for the loopback capture; everything else works without it.

SHA-256: 5559A69FDAB2AF13E1038816F0C5BCCDCFD5908FCC76C3A4DA454E21390E16C0