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:
| Channel | What it carried | What the collector observed | |---|---|---| | DNS heartbeat | A compact encoded message in a hostname lookup: run ID, checkpoint, and environment flags | A DNS request, often arriving from a recursive resolver | | HTTPS dossier | The fuller environment snapshot, encoded as CBOR | An outbound web connection and its submitted record |
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:
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.
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.
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.