CaYaTrace 0.4.2 — what was sent, and to whom

Found by an operator who could see that a program had talked to something and not what it said. Three defects between the capture and the report, all in the part that turns bytes into an answer.

Conversations were reported backwards

The two halves of a conversation are held by whoever opened it — forward from the initiator, reverse back to them — while the key that files them is ordered by sorting the two endpoints so both halves land in one entry. Those are unrelated facts, and the code picked between the halves using the sort. Where the two happened to agree the answer came out right; where they did not, the report said the subject had sent what it had received.

Measured on a real capture: a program's twenty-one connections to one address each reported 29,940 bytes sent and 5,076 received, when it had sent 5,076 and received 29,940. The bytes filed as "sent" opened with a ServerHello — a message no client ever sends, and the tell that the halves were swapped.

For anyone reading a report, this is the difference between exfiltration and an update check.

Which is why the server name was usually missing

The name a program asks for lives in the client hello, so a swapped conversation kept the handshake in the half nothing looked at. Both halves are tried now, which also covers a capture that began after the connection did.

On the same capture, conversations carrying a name went from 138 to 159 — and one of the new ones turned x.x.x.x, which says nothing, into example.com, which says everything.

Exported reports carried byte counts and no bytes

Contents were attached only at the full scope, so a default export left every "what was sent" button disabled: you could see that a program sent 6.6 KB to an address and had no way to find out what was in it. They now travel with every export except the deliberately cut-down one — volume is what the scopes are for, and contents are the reason a conversation is recorded at all.

Why a conversation on this machine still has no contents

Now established rather than assumed, because both obvious remedies were tried and both fail:

• The Winsock provider hands over a kernel address, not the caller's buffer, so reading the sending process's memory does not reach it — and no privilege changes that.
• Established loopback traffic never becomes a packet. Capturing every component produced 5,276 events with not one of them loopback; the only loopback packets that appear are ones to a closed port, which take the ordinary route in order to be rejected.

What remains would be a kernel callout driver or injecting into the subject, and neither belongs in this tool. So a local conversation is reported completely except for its contents, and the report says exactly why.

Note on sessions recorded before this

Server names and directions are worked out while recording and stored, so an existing session keeps what it was given. The capture itself is intact — network/capture.pcapng in the session directory holds every byte, and re-recording is not needed to re-read it.

Download

CaYaTrace.exe — one file, no installer, no runtime to install. Right-click → Run as administrator for kernel tracing; everything else works without it.

SHA-256  22D51343C28E65D91F3489CED18400A0997EDFBBCFCD99F5CFC9C4C4E1B0225D

Authorized use only. Recorded sessions can contain credentials, tokens, cookies and personal data — see SECURITY.md.