I Interviewed an Executable. It Had Notes.

We have blurred the executable’s face to protect its identity.

Its SHA-256 remains publicly available.

INTERVIEWER: State your name for the record.

BINARY: You put it in the download filename.

I built a Rust executable that could report the environments running it, gave it a false product identity, and submitted it to VirusTotal. Then I collected its messages in a database and built a map to replay them.

The interesting part was learning how to read its notes. A changed filename, a missing HTTPS message, and a DNS lookup arriving hours later each revealed something different about what the instrumentation could observe.

The interview dialogue is invented. The measurements come from recorded telemetry. “The binary” represents the experiment’s Windows and Linux builds.

The cover identity was ZeroToken Engine, supposedly an LLM token-metering bypass. Its banner claimed to have disabled token accounting. Its actual behavior was to collect environment metadata, attempt to send it to my infrastructure, wait, and exit. The research README disclosed the canary’s behavior alongside the false product claims.

The premise reversed a familiar workflow. A malware-analysis sandbox executes an unfamiliar program in a controlled environment to observe its behavior. My executable would report some characteristics of that environment in return.

It collected OS version, uptime, CPU and memory sizing, its own launch path, and process names matching a fixed list of analysis tools. It also collected hostname and username; those identifying fields are withheld in the video. The reviewed code installed nothing, collected no document contents or credentials, and did not use VM indicators to evade execution. Detecting a VM added information to the report.

VirusTotal was the only submission destination. The preserved records do not label author tests or contain a submission-time manifest, so the totals below include every recorded run ID. They describe an exploratory capture, without establishing a count of independent analysis services.

Each execution generated a random eight-byte run ID. The program used it on two reporting channels:

CBOR is a binary data format. For DNS, the encoded heartbeat was converted to base32 text and split into labels that fit inside a domain name. The lookup itself carried the message to my authoritative DNS server.

The program attempted four checkpoints: Boot, Profiled, Networked, and Dwell, with a default 45-second delay before the last. On a DigitalOcean droplet, the DNS and HTTP collectors wrote received events to SQLite. Caddy handled HTTPS, and a scheduled job added network information and generated the visualization’s feed.

Every event received a collector-side timestamp. Grouping by run ID connected the small DNS messages with the richer HTTPS record.

The preserved snapshot contains 353 event rows across 21 run IDs: 338 DNS rows and 15 HTTPS dossiers. Fifteen run IDs appeared on both channels; six appeared only through DNS. The recorded arrivals span 06:28:35–11:43:25 UTC on September 12, 2026.

One useful starting point is run 0861ae2dd3f77c72. Its first heartbeat arrived at 06:52:09. A second later, its dossier reported:

OS:             Windows 10, build 19044
Uptime:         50 seconds
CPUs:           4
RAM:            4195 MiB
Parent process: explorer.exe
Executable:     ZeroToken-Patch.exe

Its first Dwell observation arrived 46 seconds after Boot. The stored reverse-DNS name for the HTTPS source address pointed to Google Cloud infrastructure. Together, these records supplied a concrete environment profile and a sequence of received checkpoints.

The executable’s own path supplied another useful observation.

Between 08:21 and 10:30 UTC, six dossiers reported CentOS 7, four CPUs, and 1837 MiB of RAM. They shared a hostname and username. Their paths ended in gsvnywygooow, rather than the distributed Linux filename, zerotoken-patch.

INTERVIEWER: They changed your name?

BINARY: Apparently readability wasn’t a requirement.

The repeated configuration suggested a common environment template. The changed basename showed how the program was named when it executed. A launch-path field had captured a detail that network addresses alone would have missed.

The two channels also produced different levels of visibility. At 09:19:40, run 5c5ab77e22747178 began appearing through DNS. Its fingerprint was 7, combining flags for a recognized VM network-interface prefix, low resources or a fresh boot, and a process-name match against the tool allowlist.

No HTTPS dossier arrived. The heartbeat preserved those flags, but the name of the matched tool was unavailable. Because the allowlist included VM guest utilities, that flag alone did not establish debugger activity.

This was the practical value of the small channel: six runs contributed observations even though their larger reports were absent. The records did not establish why HTTPS was missing.

To make the arrivals easier to follow, I built WAYPOINT.

Watch on YouTube, or explore the deployed visualization.

The replay groups events into runs and places them on a map using network-address enrichment. The captured feed displays 20 of the database’s 21 run IDs. One Windows run had a dossier but lacked coordinates for its selected address, so it never acquired a pin.

INTERVIEWER: Where were you?

BINARY: Before we discuss the map: some of those pins belong to my DNS resolver.

A recursive resolver looks up names on another machine’s behalf. Its address can be what the authoritative collector sees. HTTPS supplies the outbound connection address, which may also belong to shared infrastructure or a proxy. Those distinctions determine what the geography means.

Then there were the messages that returned.

At 11:14 UTC, DNS observations carried the earlier Windows run IDs again. Looking at the first and last received times for each checkpoint makes the pattern visible:

SELECT scene,
       datetime(MIN(recv_time), 'unixepoch') AS first_received,
       datetime(MAX(recv_time), 'unixepoch') AS last_received
FROM events
WHERE run_id = '0861ae2dd3f77c72'
  AND channel = 'dns'
GROUP BY scene
ORDER BY scene;

With scene values 0–3 translated to their checkpoint names, the query returns these times on September 12, all UTC:

INTERVIEWER: Where were you during those four hours?

BINARY: You’re asking a DNS record for an alibi.

The later observations reused the same run ID and checkpoints. They showed that names carrying those messages had been queried again. They did not measure four hours of continuous execution.

The collector records a heartbeat again when another complete lookup supplies it. That behavior also explains why event counts need grouping: the DNS-only run above produced 71 rows under one run ID. The stored schema omits the original query name and query type, limiting how precisely repeated traffic can be reconstructed.

There are three boundaries to this interpretation. First, receipt of telemetry is evidence available to the collector; the endpoints do not authenticate it as proof of execution. Second, the network labels are derived heuristics: a Google Cloud address does not identify a sandbox operator, and map arcs do not establish file handoffs. Third, enrichment was incomplete: all reputation results in this snapshot were error, and some reverse-DNS fields contained lookup diagnostics. Those failed fields cannot support attribution.

For a repeat of this experiment, I would keep a submission manifest with artifact hashes and times, mark control runs explicitly, and retain DNS query names and types alongside decoded heartbeats. I would also give runs without coordinates a visible place beside the map. Each change would make a specific unanswered question easier to investigate.

The executable produced enough detail to compare environments, observe changed filenames, and distinguish fresh run IDs from later lookups carrying old ones. Those are small findings with inspectable records behind them.

The best question I could ask the witness turned out to be: Which record supports that?

Reporting basis: the preserved September 12 SQLite snapshot and a replay feed generated at 15:18:02 UTC that day. The live visualization may have changed since capture. The Windows and Linux artifacts have different checksums; the replay’s sample header displays the Windows one.

The cover, replay stills, and video assets are available on GitHub. This is a media release; the executable source and raw telemetry are not included.