Post-Mortem: When a New Detection Polluted Its Own Evidence (v0.0.15)

1. Summary

• What: scans made with AACGUARD 0.0.15 reported dozens of "cheat site looked up recently" findings on PCs that had never visited those sites.
• Impact: 27 of the 30 most recent scans at the time of discovery were marked SUSPICIOUS, with scores over 2,000. No scan became CHEAT DETECTED, because these findings are medium-strength and a CHEAT DETECTED verdict by score requires at least one strong finding.
• Duration: from the release of 0.0.15 to the release of 0.0.16, both on 24 October 2026. Uploads from 0.0.15 were blocked once 0.0.16 was out.
• Root cause: a new check resolved every cheat domain itself, which put all of them into the DNS cache that an older check reads as evidence of the player's own lookups.

2. Background: two checks that share one source

Windows keeps a short-lived cache of the website names it has recently resolved to addresses (the DNS client cache). For several versions, AACGUARD's DNS cache check reads that cache, without any network request, and reports cheat sites the PC looked up recently. It is a weak lead on its own: a medium finding per site.

Version 0.0.15 added a connection check. Paid cheats stay connected to their license server, so the check lists open connections, finds which program owns each one and compares the remote address with the addresses of known cheat sites. To learn those addresses it first used the DNS cache. If the cache had nothing, a fallback resolved every cheat domain on the list (about a hundred) every 30 minutes, in full scans and in AACGuard Live.

3. What happened

Resolving a domain puts it into the DNS cache. After the first connection check (in a scan, or after AACGuard Live had run for a while), the cache contained every cheat site on our list. The next DNS cache check found them and reported each one as a site the player had looked up, between 70 and 176 findings per scan depending on timing. Medium findings at that volume pushed scores far above the SUSPICIOUS threshold.

The evidence was entirely created by AACGUARD. The players had done nothing.

4. Why our tests missed it

• The test PC kept no Windows DNS cache. Its network setup resolves names without Windows' client cache, so the lookups left nothing behind there, and the DNS cache check found nothing to report. We tested the connection check's address resolution end to end, but on a machine where its side effect could not appear.
• The two checks were never run together with AACGuard Live in the loop. Each passed its own tests.
• No test compared per-check finding counts before and after the release on a normal PC. A jump from zero or a few DNS findings to more than seventy would have been obvious.

5. The fix (0.0.16, same day)

1. No more lookups. The connection check only uses addresses already in the cache, read with a cache-only query that never touches the network. The client no longer resolves cheat domains at all.
2. A cap per source. DNS cache findings now count at most 75 points per scan together, however many there are. One event can never fill a scan with dozens of findings again.
3. Shared addresses are leads. A program connected to an address that many sites share, such as a Cloudflare address, counts as a medium finding instead of a strong one.
4. Old uploads blocked. The minimum client version was raised to 0.0.16, so 0.0.15 can no longer upload scans.

6. The leftover problem

A few scans made with 0.0.16 on PCs that had run 0.0.15 still listed the entire cheat-site list: the entries placed there by 0.0.15 had not expired yet. Because of the new cap they could no longer cause a high score, but they were confusing to read.

For a reference point we went back to the October scan archive: before 0.0.15, no real scan had more than five cheat sites in its DNS cache. A cache holding far more than that is not a player's browsing; it is a list being looked up by some program or page. A follow-up change, prepared for the next release, treats such a cache as a list and reports no findings from it, and stops the connection check from giving full weight while such a list is present. A matching change to the website hides those lists on scans that were already uploaded and shows the score without them, without altering the stored data.

Scans marked SUSPICIOUS only because of this incident are being reviewed and cleared, and a new scan with 0.0.16 shows the player's real result.

7. What we changed in how we work

1. A scanner must never create the evidence it reads. The client does not query DNS, open websites or touch any other system state for cheat-related names. This is now a written rule for every new check.
2. Before a release, a full scan and AACGuard Live run together on an ordinary PC, and the number of findings per check is compared with the previous version.
3. Every evidence source has a cap, so a fault in one check can raise a score only so far.
4. Test machines must have the side effects real PCs have. A test that cannot observe a side effect cannot catch it.

8. Takeaways for other tool builders

Forensic tools read state that the tool itself can change. Antivirus scanners update file access times, browsers pre-load links, and network checks fill caches. Whenever a check reads a shared source, ask what else writes to it, including your own code, and test the checks together, not one at a time. The release notes for 0.0.16 describe the fix for players.