Releases: CaYatur/CaYaTrace
Release list
v0.5.7 — getting the driver you need
Getting the packet driver, from inside the tool
An analysis machine is deliberately clean — so the most useful capture in CaYaTrace is
unavailable on exactly the machines that most need it, and "loopback capture was skipped"
written into a session log afterwards is not help.
Ticking Capture local conversations on a machine that cannot do it now says so
immediately, and offers the shortest honest route.
- What is actually missing, distinguishing the two cases because they have different
fixes. No driver at all means installing it. A driver with no loopback adapter means the
installer's Support loopback traffic option was cleared during setup — it is on by
default, so running the installer again and leaving it ticked is the entire fix. - A link to its authors, with the address as selectable text beside it, because a virtual
machine with no browser is a normal state rather than an edge case. - A button to start an installer already on the machine. Getting a file into an isolated
VM is the awkward part; hunting for it again in Explorer afterwards is busywork. It looks
beside the executable, on the desktop, and in the profile and Downloads folders, newest
version first. - Check again, which works without restarting — installing a driver while the tool is
open is precisely what somebody does after being told it is absent, so a missing driver is
no longer remembered for the life of the process.
What it deliberately does not do
CaYaTrace does not ship Npcap and never installs it unattended. Npcap's free licence covers
neither: redistributing it inside another product and installing it silently are both
reserved for their paid OEM licence, so a tool that quietly did either would put its user in
breach of terms they never read. The installer's own screens are also where those terms are
accepted and where the loopback option is chosen — a reason to send somebody through them
rather than around them.
Nothing is started on the strength of a file name
"Run the installer in your Downloads folder" is otherwise a way to be talked into running
whatever put a file called npcap-9.99.exe there — which, on a machine used to analyse
malware, is not a hypothetical arrangement.
- A found installer is offered only after its Authenticode signature says who published it.
- The publisher is shown next to the button, because that is the reason the button is safe to
press. - The signature is verified again at the moment of launching, not trusted from when the file
was found. - Starting it takes an explicit confirmation naming the signer, which also states that
CaYaTrace passes no arguments of its own.
Tested against a file with the right name and no signature, and against a signed binary from
somebody else. Both refused.
Download
CaYaTrace.exe — self-contained, no .NET install needed. Windows 10/11 x64.
SHA-256: AA538060C5B7DDFF99FAD041EE33AF448B5612A9E865540931286F2A3412933B
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 —
localhostresolves to
::1before127.0.0.1on 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
v0.5.5 — the place it hid
A program can now be removed from the place it hid
Everything under System32, SysWOW64 and the Windows directory was refused as
Windows-owned. That is right for Windows' own files and wrong for a program that put its
own there — and programs do it deliberately, because it is the one place an uninstaller is
guaranteed not to look.
Measured on a recording of an installer: forty-five files written into SysWOW64 — a
service binary, two libraries sitting beside Windows' own, and a folder of forty more. Every
one refused, and a plan to remove the program that listed six items, none of which was the
program. The recording had seen all forty-five and named the process that wrote each one.
The question is now whose file it is, not which folder it is in, and a recording answers
that: it was not there when the recording started, and the subject wrote it. Windows' own
libraries are never created during a recording.
What still holds the line
-
The directories themselves are never removable. No plan can name
System32, on any
evidence at all. -
A list of stores Windows keeps on every program's behalf stays refused whoever is
recorded writing to them — the signature catalog, the component store, the registry
hives, the driver store, Prefetch, the installer cache, Fonts.That list is not decoration. The same recording produced two creations under
catroot2
attributed to apowershell.exeinside the subject's own process tree: genuinely created,
genuinely in scope, and absolutely not the installer's. The catalog store is how Windows
knows whether anything on the machine is signed. -
The verdict is a confirmation, not a permission. These rows are marked in the plan and
carry their reason, so a path inside a Windows directory can never read like a path on the
desktop, and the runner re-checks the signature of what is actually on disk before moving
anything.
On that session the plan went from 6 items to 52, matching what a dedicated uninstaller
found on its own run of the same program — while catroot, catroot2 and Defender's own
platform libraries stayed refused. The previous session is unchanged at 7 items, which is
the check that nothing widened by accident.
A folder is called a folder
A directory is a file with a flag set, so creating one produces an ordinary file create and
the plan listed it as a file. That read wrong and ordered wrong — files are removed before
folders precisely so a folder is empty when its turn comes.
Which entries are folders is now read off the evidence rather than off the disk: anything
other recorded paths sit inside. The answer is then the same on the machine that recorded
the session and the machine that applies the plan, which a disk check could never be.
Download
CaYaTrace.exe — self-contained, no .NET install needed. Windows 10/11 x64.
SHA-256: 2CF0E186BE9616D4D9A614936CBC6A6695C70FDBDCB3E8614438B637DC1B9EE6
v0.5.4 — the program itself, and what will not move
The plan now contains the program
Its executable and the library beside it were missing from the plan to remove it, while the
recording had named both four different ways. The footprint was read off the disk at plan
time, which works exactly once — on the machine that still holds the files, before anything
has removed them. On the session this was measured against, an antivirus had quarantined
both between the recording and the plan, so the listing returned two files and the two that
had done all the work were gone.
The recording is the source now; the disk only ever adds to it.
- Every module the program loaded that Windows does not own. The strongest thing a
recording says about what a program consists of, and the only signal that reaches a
library side-loaded from somewhere it should not be. - Every file in its directory the recording shows being used — loaded, read, written —
as opposed to merely opened.
That last distinction does more work than it sounds like. The loader tries the application's
own directory first, so resolving imports opens a dozen Windows library names inside the
program's folder, for files that never existed — one of them cmd.exe, wearing a path
under the operator's profile that passes every check written to recognise a system location.
Thirteen probes rejected on the measured session, four real files kept.
It is also the same answer on every machine now. Observations are tokenized when written, so
a session recorded under one profile and read under another had the footprint resolving to
one form of the path and the recording to another — two strings that never met.
A folder has to be earned. Reading the directory finds what a program shipped and never
touched, which no recording can name. It also finds everything else in there, and a program
run straight out of a downloads folder has a "directory" that belongs to the operator. So
the proportion decides: most of the folder the program's, and the rest goes with it; a
minority, and nothing is taken but what the recording named.
What will not move
A locked file said "in use or locked" and stopped, which is nothing an operator can act on.
The Restart Manager knows what is holding it, so it is asked — and most of the time that is
the whole answer, because most of the time it is a preview pane.
Past that, a second pass you ask for, never automatic: clear the attributes that are
bookkeeping rather than protection, stop the processes holding the file, take ownership
where access is denied, and hand anything still immovable to the session manager to move
before anything else starts at the next restart.
Nothing on that ladder deletes. The restart-time move goes to quarantine like every other,
so a removal that finishes after a reboot is as reversible as one that finishes straight
away. Anything Windows marks critical is left alone.
Watching it happen
Every item carries its own status as the run proceeds — waiting, working, removed, kept, at
restart, in the way — with what stood in the way written beside it, and an offer to try
harder on whatever is left.
Also fixed
- The rollback journal was an exclusive handle held for the runner's lifetime, so a second
run against the same quarantine folder threw before doing anything — precisely the run
that retries what the first could not finish. - A folder that could not be removed said only that it was not empty. It now names what is
still in it. - Progress reports described an item rather than carrying it, so several values under one
registry key collapsed onto a single row. - Plan and remediation state is cleared when a session or package is loaded, and export is
guarded when the plan came from an imported package.
Download
CaYaTrace.exe — self-contained, no .NET install needed. Windows 10/11 x64.
SHA-256: EFC1324BB5F581A3BB9A30706A5ED7DF566F1E6E378AE041B8FBF55CAFC10115
CaYaTrace 0.5.3 — the plan now contains the program
The removal plan was removing a program's registry footprint and leaving the program on disk. This is the fix for that, and for four things around it.
The plan never contained the program
Everything in it came from watching the recording, so it could only ever hold what the subject created while being watched. A subject is normally downloaded, unpacked, and then recorded — its own executable and the folder it unpacked into already existed, and no event names them as created.
Measured on a real session: two registry values, and not one of the executables that had done all the work.
The program itself is a candidate now — its image, every image its process tree ran, and the contents of the directory those sit in, whether or not the recording watched them appear.
Windows' own binaries never are. A batch file that launches cmd.exe has not made cmd.exe its own; being inside the subject's process tree does not transfer ownership of a binary. The first attempt at this offered cmd.exe and conhost.exe for deletion, because a bare image name with no directory in it passes every check written to recognise a system location.
File by file, not folder by folder
Each file beside the executable is its own item. The directory is offered only when everything in it belongs to the program — a folder is a container, and a container can hold something you want. A program run out of Downloads never takes Downloads with it; one unpacked into its own folder takes the folder.
Your own folders are no longer offered
The guard added in 0.5.2 did not work. It compared raw paths against the folders of the machine reading the session, so a session recorded on one machine and read on another compared two different profiles and decided they were different. It also only covered directory-create events — and opening a directory is reported as a file create, which is the event that was actually firing.
Both fixed: compared on the tokenised path, applied to both events.
No more "protected — will not be touched"
Making a refusal visible by leaving it in the plan was the wrong place for it. One recording produced 107 registry keys under SystemCertificates, all Windows' own and all unremovable, burying the real findings. They are counted and reported now, not listed.
The plan options can be clicked
They were disabled from a session flag whose state went stale. Two fixes for that did not hold, so they are simply never disabled — they are choices about what a future plan should contain, setting one before a session is open costs nothing, and disabling them bought no safety.
Sample data from real investigations is anonymised throughout the repository. A real indicator in a public repository is both a disclosure and a pointer back to what is being investigated.
Download
CaYaTrace.exe — one file, no installer. Right-click → Run as administrator for kernel tracing.
SHA-256 974B14066CED1FA977EE1F5E5B481F656CCD3416E8B1146E0B34B8C727F60011
Authorized use only — see SECURITY.md.
CaYaTrace 0.5.2 — it offered to delete your Documents folder
Update if you use Remediate. One of these could have deleted your Documents folder.
The plan offered to delete your own folders
The kernel reports a directory create when a program opens a directory with a create disposition — which is what every program does to a folder it is about to read. That is indistinguishable from actually making one.
So a program that merely looked inside Documents produced an event reading "created by", and Documents appeared in the plan ticked, alongside the profile root, the desktop and the Internet cache.
Folders Windows maintains are no longer candidates. Resolved from the running machine rather than matched against a list of names — a profile can be redirected to another drive, and a name comparison would miss it in exactly the case where deleting it costs the most. A directory the program genuinely created is still offered, and there is a test for each half: a guard like this is easy to write in a way that quietly refuses everything.
Remediate said no session was loaded when one was
The build button and the three plan options are enabled from the loaded session, and nothing re-evaluated that when the view was opened. An operator who had just finished a recording arrived at a view telling them no session existed, with every option greyed out and no way to build a plan. Re-evaluated on entry now.
Download
CaYaTrace.exe — one file, no installer. Right-click → Run as administrator for kernel tracing.
SHA-256 21724B7A724366C90F07EED2D685A502A2C7FF5E84873338077FA0D2FDE79ECE
Authorized use only — see SECURITY.md.
CaYaTrace 0.5.1 — the removal plan that was empty
If you record system-wide, replace 0.5.0. A system-wide recording produced a removal plan of almost nothing, and no setting could have fixed it.
The removal plan was empty for system-wide recordings
Scope is marked relative to a root process, and a system-wide recording has none. So no process was ever in scope, every observation carrying an actor was discarded, and the only survivors were the handful that carry no actor at all.
Measured on a real recording of an installer: 759,179 file operations and 1,048,112 registry operations went in, and two items came out. Loosening the filters could never have reached the rest — the scope they were being tested against did not exist.
Scope cannot be the filter when there is no subject. Removing it outright was not the answer either: the machine is busy during any recording, and doing that filled the plan with Delivery Optimization counters, Explorer's pane state and Defender's timestamps.
What separates them is the signature of whatever made the change. All of that housekeeping is written by something Microsoft signed, and nothing a third-party installer drops is. The machine's own churn is excluded by who did it rather than by where it landed — which needs no list of paths to keep current, and cannot accidentally exclude a program that installs itself somewhere unexpected.
The same recording now yields 1,264 items — 536 individual files, 351 registry values, 375 keys — including the subject registering itself under SafeBoot\Minimal, which is how a program arranges to keep running in Safe Mode and was missing from the plan entirely.
Download
CaYaTrace.exe — one file, no installer. Right-click → Run as administrator for kernel tracing.
SHA-256 1665A83FFAAF4E0E01BCB34492BF1C58DD211976931C6FCE7D502133AC0701F7
Authorized use only — see SECURITY.md.
CaYaTrace 0.5.0 — request contents, and a sweep for leftovers
Two things the tool had the data for and would not show.
The contents of GET and POST requests
The requests table listed a method, a URL and a size. The headers and the body were in the session all along — written there by the proxy — with nothing in the view able to reach them, so a POST that uploaded 45 bytes was a row saying 45 bytes.
A row now opens to show every header it carried and a button for the body. Both travel with an exported report, so this works in a report you send to somebody else.
A sweep for what a program left behind
This is why removal was skipping things, and why loosening the filters was never going to fix it.
The plan is built from the recording: every item in it is something the tool watched being created. That is the right foundation and it cannot be the whole answer — a program installed before the recording started, or a component dropped by an installer that ran outside the traced scope, was never observed, so no filter setting could ever include it. The observation does not exist.
The sweep asks the opposite question: what on this machine is named after it. Four depths, because how hard to look is your choice and each one matches more loosely:
| Depth | Looks at |
|---|---|
| None | only what was recorded, as before |
| Safe | directories and registry keys carrying the name |
| Moderate | also uninstall entries, services, App Paths, startup values, scheduled tasks — matched on the names a person recognises, not the GUID the key is filed under |
| Advanced | also registry values anywhere under the software hives whose data points at it. Slow, bounded, and it says when it stopped early |
Nothing in it deletes. It produces candidates carrying the reason each one matched, every one still passes the safety policy, and you approve the plan. A sweep that matched too widely is a list to uncheck rather than damage — that is the only arrangement in which an aggressive search is safe to offer.
The terms it searched for are shown, so an unexpected match is explainable. A name with nothing distinctive left after the common words are stripped produces no sweep at all rather than a sweep of the whole machine.
A refused item stays in the plan, marked
It used to be dropped. Comparing the plan against what was still on the machine, you had no way to tell something the tool had not found from something it had decided not to touch — a gap to report versus a judgement to argue with, both arriving as silence. The runner still refuses it; this changes what the plan says, not what it does.
Download
CaYaTrace.exe — one file, no installer, no runtime to install. Right-click → Run as administrator for kernel tracing.
SHA-256 01BE9CFC2B7978F6680FE67A7F820A29A9CADD49133F384CEB6B8C10A18A88C8
Authorized use only. Recorded sessions can contain credentials, tokens, cookies and personal data — see SECURITY.md.
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.
CaYaTrace 0.4.1 — the assistant actually answers
If you downloaded 0.4.0, replace it. The assistant — the feature that release led with — could not answer anything.
The chat swallowed its own answers
Every reply carries a web field holding the lookup findings, normally an empty array. The page's chat handler used payload.web !== undefined as the acknowledgement for the web-lookup toggle, and an empty array is not undefined — so every answer matched that branch, ticked the checkbox and returned before the reply was rendered or the spinner stopped. Asking anything produced a spinner that never finished.
The control message has a name of its own now. A test reads both sides — the page's dispatch and the host's reply — and fails if any field can mean both. That test is the actual fix: nothing that drives the assistant can catch this, because the harness calls it directly and never crosses the bridge, which is precisely why it got out.
Web lookups had never once been called
The feature shipped with no execution path having ever run. Its search parsing keys on class names somebody else controls, so if those had moved it would return nothing and report nothing — the same shape of failure this release was spent removing from HTTPS interception.
There is now a test that performs a real search against the live endpoint, and one that pins the refusals: nothing leaves the machine until you switch it on, and a private or non-web address is never fetched — a name out of a recorded session was chosen by whatever was being recorded.
Fetching a page was unreachable code. Search snippets are two lines of marketing and rarely say what a file is; the top result's own page usually does, and is now retrieved and used in its place.
Everything in 0.4.0 still applies — HTTPS interception that works for the first time, the proxy restored even when the session is killed, scoped sessions that stay scoped, local conversations counted once, and an assistant that follows a conversation and answers about what you named.
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 FEFC27C6B976B3503DA25A1B763F9B49A8439E8805137AF9D14AA3F21AAE054E
Authorized use only. Recorded sessions can contain credentials, tokens, cookies and personal data — see SECURITY.md.