Trace Anti-Cheat Scanner, Trace_7TXBS1AV.exe

File identity

Srungoat Protector v1.0

The scanner is wrapped by a commodity protector that has left a marker section and nothing else. The .1337 section is 61 virtual bytes, entropy 1.01, well below the level of even compressed text. Its raw contents:

Offset (raw)  : 0x00302000
Size (virtual): 0x3d bytes
Entropy       : 1.01 bits/byte

00: 53 52 55 4E 47 4F 41 54  50 52 4F 54 DE AD BE EF   SRUNGOATPROT.....
10: 76 31 2E 30 00 00 00 00  50 72 6F 74 65 63 74 65   v1.0....Protecte
20: 64 20 62 79 20 53 72 75  6E 67 6F 61 74 20 50 72   d by Srungoat Pr
30: 6F 74 65 63 74 6F 72 20  76 31 2E 30 00            otector v1.0.

That is the full protection. Every other byte of executable code was emitted by MSVC unmodified. TLS callback table is empty; entry point at 0x140266520 is a stock CRT initialiser; strings live in .rdata at both UTF-8 and UTF-16-LE and are readable with any triage tool.

C2 map, everything talks to traceac.cc

Nine URLs. Two hostnames (traceac.cc for API, scanner.traceac.cc for downloads and UI). Every wide-character copy of these strings is emitted verbatim by the linker, no obfuscation, no runtime assembly. Auth is the ?pin=<PIN> query parameter on GETs plus a static header X-Trace-Scanner: TRACE-Scanner/QMSAPRSqM4xK2JnP on POSTs.

User-Agent: TraceScanner
Content-Type: application/json
X-Trace-Scanner: TRACE-Scanner/QMSAPRSqM4xK2JnP

# (except the /api/version ping, which uses a placeholder UA:)
User-Agent: blablublewidfjhsfhdshGFDSBSDUFGDFDSBNTRACE

WebView2 UI + injected JavaScript

The scanner renders its UI by embedding a Microsoft Edge WebView2 controller and navigating it to https://scanner.traceac.cc/send/ui/. A resource-request filter of https://scanner.traceac.cc/* permits fetches to that host and blocks everything else. On NavigationCompleted the C++ side calls ExecuteScript with a script built as three concatenated pieces: the constant prefix stored at .rdata:0x290E00, the user's runtime PIN and the constant suffix stored at .rdata:0x290C00. The prefix and suffix are quoted here verbatim from the binary:

// prefix, .rdata offset 0x290E00 (UTF-16-LE, constant)
(function() {
    function waitForElement(selector, callback, maxWait, interval) {
        maxWait = maxWait || 3000;
        interval = interval || 50;
        const start = Date.now();
        const check = setInterval(function() {
            const element = document.querySelector(selector);
            if (element) {
                clearInterval(check);
                callback(element);
            } else if (Date.now() - start > maxWait) {
                clearInterval(check);
                console.warn('Element not found: ' + selector);
            }
        }, interval);
    }
    waitForElement('#pin-input', function(pinInput) {
        pinInput.value = '<RUNTIME_PIN>

// suffix — .rdata offset 0x290C00 (UTF-16-LE, constant)
';
        pinInput.dispatchEvent(new Event('input', { bubbles: true }));
        waitForElement('#scan-btn', function(scanBtn) {
            if (!scanBtn.classList.contains('disabled')) {
                scanBtn.click();
            }
        });
    });
})();

The full set of state / event names passed between the WebView2 UI and the native side (via WebMessageReceived):

Auth flow, PIN + fixed header

Users obtain a numeric PIN from the vendor's website and paste it into the UI (or receive it via the PIN environment variable). All GET requests to scanner.traceac.cc append ?pin=<PIN>to the URL and on failure the UI is told scan_error = "Invalid, expired, or used PIN.". The consent chain before any scan can start is:

1. tos_accepted and privacy_accepted must both be true
2. check_security_before_consent, inventory Defender + third-party AV
3. if has_security_tools, display “Disable the blocking protection temporarily, then reopen the scanner” and set state security_blocked / antivirus_blocked
4. pin_validated, HTTP validation against traceac.cc
5. start_scan_consented, user pressed the button (or the injected JS pressed it for them)

YARA download chain

The scanner does not carry a YARA engine. It downloads one, at runtime, from its own CDN. The chain is:

1. Read PIN from UI / PIN env var.
2. GET https://scanner.traceac.cc/api/scanner/yara_manifest?pin=<PIN>, server returns a JSON with fields url, sha256, min_size. Manifest failures produce the strings YARA manifest HTTP failed, YARA manifest URL rejected, YARA manifest SHA256 is invalid, or YARA manifest JSON parse failed, all present verbatim in .rdata.
3. GET https://scanner.traceac.cc/static/bin/yara64.exe?pin=<PIN>, download and SHA-256 verify against the manifest.
4. GET https://scanner.traceac.cc/api/scanner/yara_rules?pin=<PIN>, download rules text; write to %APPDATA%\\trace\\custom_rules.yar.
5. Validate rules with the downloaded binary: yara64.exe -w -m --scan-list. Emit output to TRACE_YARA_VALIDATION_FILE.
6. Run YARA against the enumerated file list; every hit is turned into a UMemoryFinding or UFileFinding.

Directory exclusions embedded in the binary (fed to YARA's --scan-list): windows, program files, program files (x86), programdata, $windows.~bt, $windows.~ws, $recycle.bin, system volume information, recovery, perflogs.

Scan orchestration, 7 finding types

The C++ side runs its scan tasks via std::async / PPL and emits one of seven finding-vector types back to the UI. Each is a fully-mangled MSVC namespace visible with undname.exe, ?$vector@U<Type>@TraceScanner@@V?$allocator@U<Type>@TraceScanner@@@std@@@std@@.

The console-style status lines printed to the WebView2 UI during scanning are also embedded verbatim: [*] Scanning FiveM mods... · [*] Scanning admin-executed applications (Event Log 4688)... · [*] Scanning all services for unsigned kernel drivers... · [*] Scanning for newly installed drivers (Event Log 7045)... · [*] Scanning recent computer activity (BAM full dump)... · [*] Capturing desktop screenshot... · [*] Submitting.

Complete cheat family inventory (22)

Every FiveM cheat brand that the scanner searches for by file name. Each brand is checked in up to four variants, <name>.exe, <name>.dll, <name>menu.exe, <name>menu.dll, plus its known driver and registry markers.

Injector / loader / bypass tools

HWID / spoofer / cleaner tools

Cheat-vendor auth URLs (63), browser-history matches

The scanner reads typed-URL history from every installed Chromium browser and compares each entry against a list of 63 hardcoded cheat-vendor authentication panels. A hit becomes an UActivityEntry with severity suspicious. The full list, in the order it appears in .rdata:

Cheat-vendor hostnames (short form)

Forensic sources read

Cross-references: Discord username is read from the LevelDB store and matched against the SteamID and Steam username extracted from Software\\Valve\\Steam and the loginusers.vdf / config.vdf files. A match becomes an UActivityEntry with description "Same username used across platforms".

Event Log XPath queries (5 hardcoded)

Every Windows Event Log channel the scanner reads, with the exact XPath filter it emits to wevtutil. All are dropped verbatim into the binary, no runtime construction.

AV / EDR presence detection

The scanner enumerates process names against a hardcoded AV/EDR list. If Defender real-time is enabled or any third-party AV process is running, the UI displays "PIN accepted, but active protection is blocking the scanner. Disable the blocking protection temporarily, then reopen the scanner." and the scan will not proceed. The list embedded in the binary:

Reverse-engineering + analysis tool detection

Process names the scanner treats as evidence of an ongoing reversing session (turned into a USystemFinding with description "analysis or credential dumping"):

BYOVD driver watchlist

The full driver-services enumeration (HKLM\\SYSTEM\\CurrentControlSet\\Services) is compared against a whitelist of ~200 canonical Windows drivers embedded in the binary; anything not in the whitelist and not signed by Microsoft becomes a URegistryFinding.

Decoy JWTs + fake auth-response templates

The scanner carries a corpus of well-known example JWTs (from RFC/documentation samples and cheat-panel boilerplate) plus seventeen fake auth-response JSON shapes. They are matched against browser cache and LocalStorage entries as trip-wires: any of these values found in a browser storage file indicates the machine has been interacting with a cheat vendor's licensing panel.

JWTs (8 embedded)

JSON response templates (17 embedded)

Desktop screenshot capture

Before submitting, the scanner captures a full-desktop bitmap with GDI+, encodes it as a JPEG in memory, and includes the base64 payload in the JSON body posted to /api/scan/submit. Failure paths are visible in the binary as:

• "[*] Capturing desktop screenshot..."
• "[+] Screenshot captured (<bytes> bytes)"
• "[-] Failed to encode screenshot."
• "[-] Failed to initialize GDI+."
• "[-] JPEG encoder not found."

Windows with the WDA_EXCLUDEFROMCAPTURE / WDA_MONITOR display-affinity flag are handled explicitly, the scanner logs [!] Stream-proof window detected! Bypassing... and attempts to capture them anyway by cloning the DC. This is the standard technique for defeating “stream-proof” cheat overlays.

Secrets, keys, webhooks, none present

An exhaustive scan for every shape of embedded credential returned zero results in each of the following categories:

• Discord webhook URLs (discord.com/api/webhooks/, discordapp.com/api/webhooks/)
• Slack, Zapier, Telegram bot tokens / URLs
• AWS/GCP/Azure access keys (AKIA*, ASIA*, AGPA*, etc.)
• PEM-encoded X.509 certificates or RSA/EC private keys
• Cloudflare R2 SigV4 signing material
• SMTP / mailto: destinations
• High-entropy binary blobs > 4 KB in .rdata or .data (no encrypted regions)

The only tokenised strings the file contains are the eight decoy JWTs (all standard textbook examples), the fixed X-Trace-Scanner header value TRACE-Scanner/QMSAPRSqM4xK2JnP and 105 32-byte hex or base64 strings that on inspection are all MSVC template-instantiation hashes or C++ lambda IDs.

IOCs

File

Network

Host

Detection guidance

rule TraceAntiCheat_Scanner {
  meta:
    author      = "Clubhouse AC Research"
    description = "Third-party FiveM Trace Anti-Cheat scanner"
    reference   = "traceac.cc"
    hash_sha256 = "9d1b210b06d942863e49f0cf7baf629fcdc3cf76d33a5383a6caec65783eb4fc"
  strings:
    $marker    = "Protected by Srungoat Protector v1.0"
    $ua        = "TraceScanner" wide
    $ua2       = "blablublewidfjhsfhdshGFDSBSDUFGDFDSBNTRACE" wide
    $hdrname   = "X-Trace-Scanner" wide
    $hdrvalue  = "TRACE-Scanner/QMSAPRSqM4xK2JnP" wide
    $mutex     = "Global\\TraceAntiCheatScanner_Mutex" wide
    $wnd       = "TraceAntiCheatScannerClass" wide
    $ui        = "https://scanner.traceac.cc/send/ui/" wide
    $c2a       = "traceac.cc" wide
    $yaraep    = "/api/scanner/yara_manifest?pin=" wide
    $submit    = "/api/scan/submit" wide
  condition:
    uint16(0) == 0x5A4D and
    3 of them
}

Runtime capture attempt, fake C2 + LD_PRELOAD

Static extraction gave us the wire format for every endpoint, but not what a live request body actually contains once populated with real machine data. To grab that, we stood the binary up under Wine + Xvfb against a synthetic C2 and watched what it sent. The attempt reached the wire but stopped one step short of the payload and where it stopped is itself a finding.

Harness

• Fresh WINEPREFIX on Wine 9.0, Xvfb :99 (1280×800×24).
• A self-signed CA (CN=Trace-Fake-C2-CA) + leaf cert with SAN DNS:traceac.cc, DNS:scanner.traceac.cc, DNS:*.traceac.cc, EKU=serverAuth, KeyUsage=digitalSignature,keyEncipherment. The CA was imported into HKLM\\Software\\Microsoft\\SystemCertificates\\ROOT\\Certificates (and CA and AuthRoot for good measure) via a hand-built Blob registry value carrying property 0x14 (SHA-1) and 0x03 (encoded cert).
• LD_PRELOAD=libdns.so intercepts getaddrinfo(3) and rewrites any hostname containing traceac.cc to 127.0.0.1. It also intercepts connect(2) and logs every TCP connect the scanner attempts.
• A Python TLS server on 127.0.0.1:443 that accepts on a plain socket, logs the raw peer, does the ssl.wrap_socket handshake, logs the negotiated cipher, then reads and dumps every byte the client sends before replying with a synthetic version / manifest / yara-rules response.

What we captured

The DNS interposer fires, [libdns] getaddrinfo(traceac.cc) → 127.0.0.1 , and the binary connects to 127.0.0.1:443 with WinHTTP. Wine's Schannel completes the TLS 1.2 handshake against our CA (cipher ECDHE-RSA-AES256-GCM-SHA384, TLS 1.3 also negotiates cleanly when we allow it). And then, immediately after the handshake finishes, the client closes the connection without sending a single application byte:

[libdns] getaddrinfo(traceac.cc, ?) → 127.0.0.1
[libdns] connect(fd=240, 127.0.0.1:443)

# server side
[connect]     ('127.0.0.1', 43430)
[tls-ok]      ('127.0.0.1', 43430) cipher=('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256)
[body]        ('127.0.0.1', 43430) len=0
[send-error]  ('127.0.0.1', 43430): EOF occurred in violation of protocol

To sanity-check the harness, a curl to the same URL with the CA trusted goes all the way through and delivers the synthetic response body untouched. So the TLS stack, DNS interposer and server are all correct. What differs is whatever Wine's WinHTTP does after the handshake and before dropping WinHttpSendRequest's bytes on the wire.

Why it stopped there, what it isn't

The behaviour reads like classical certificate pinning, but the binary's imports rule that out cleanly. The full WinHTTP import table is:

WINHTTP.dll:
  WinHttpOpen
  WinHttpConnect
  WinHttpSetOption
  WinHttpCrackUrl
  WinHttpQueryHeaders
  WinHttpReceiveResponse
  WinHttpSendRequest
  WinHttpOpenRequest
  WinHttpQueryDataAvailable
  WinHttpReadData
  WinHttpCloseHandle

• No WinHttpSetStatusCallback, the binary cannot receive a WINHTTP_CALLBACK_STATUS_SENDING_REQUEST notification to inspect the server cert and cannot install a callback that closes the handle on mismatch.
• No WinHttpQueryOption(WINHTTP_OPTION_SERVER_CERT_CONTEXT), a search for the immediate mov edx, 0x4E returns nothing in .text. The binary never pulls the peer cert into user code.
• A scan for mov edx, 0x1F (WINHTTP_OPTION_SECURITY_FLAGS) matches once, inside CRT support code. There is no application-level SetOption on security flags either way — no SECURITY_FLAG_IGNORE_* and no explicit flag pinning.
• WINTRUST is imported (WinVerifyTrust, CryptQueryObject, CertGetNameStringA, CertFindCertificateInStore), but only against downloaded files, the shape is Authenticode verification of the yara64.exe drop, not TLS peer pinning.

That leaves the closure at Wine's Schannel layer, not in the sample's code. Wine's Schannel accepts the handshake because the CA lives in the store, but the subsequent chain-build inside winhttp.dll before it hands the socket back to WinHttpSendRequest fails and WinHTTP quietly drops the handle. Under a real Windows Schannel with a real Windows-trusted CA, the same handshake would be followed by the actual GET /api/version HTTP/1.1, which is exactly what we see when we curl the endpoint with our CA installed system-wide.

What this confirms

• The scanner really does dial out to traceac.cc the moment it comes up, unattended, before any UI action from the operator, the DNS/TCP hits are the first thing that happens after the mutex check.
• All C2 traffic runs over WINHTTP_FLAG_SECURE (0x00800000 shows up as an immediate at the WinHttpOpenRequest call sites). There is no plaintext fallback, no HTTP retry.
• Nothing extra rides in the SNI or TCP layer we couldn't already read out of .rdata: the connection is a stock WinHTTP call to traceac.cc:443, request path built from the wide-string constants documented in the C2 map above.
• Cert validation happens in Wine, not in the binary, so a Windows host with a policy-installed CA and a route pointing traceac.cc at a local sink would capture the full /api/scan/submit body. The shape of that body is already documented from the static parser above (JSON with a pin, results[], duration, type, description, details, severity and a base64 screenshot field). Runtime just confirms the field names get filled with real content, not the schema itself.

Second pass, Wine says the actual failure reason

Re-running under WINEDEBUG=+winhttp,+schannel named the failure directly. Wine imports the CA into HKLM, negotiates TLS and then Wine's own netconn_verify_cert refuses to trust it:

trace:winhttp:WinHttpOpenRequest 0x2, L"GET", L"/api/version", (null), (null), 0, 0x800000
trace:winhttp:open_connection connecting to L"127.0.0.1":443
trace:winhttp:netconn_secure_connect sending 221 bytes
trace:winhttp:netconn_secure_connect recv 1275 bytes
trace:winhttp:netconn_secure_connect InitializeSecurityContext ret 0x90312
trace:winhttp:netconn_secure_connect sending 93 bytes
trace:winhttp:netconn_secure_connect recv 242 bytes
trace:winhttp:netconn_secure_connect InitializeSecurityContext ret 0
trace:winhttp:netconn_verify_cert verifying L"traceac.cc"
trace:winhttp:netconn_verify_cert returning 0x2f0d          # CERT_E_UNTRUSTEDROOT
warn:winhttp:netconn_secure_connect cert verify failed: 12045  # ERROR_WINHTTP_SECURE_INVALID_CA
warn:winhttp:netconn_secure_connect Failed to initialize security context: 0
trace:winhttp:netconn_release Closing connection

The blob we wrote to HKLM\\Software\\Microsoft\\SystemCertificates\\ROOT\\Certificates\\... is loaded by Wine's crypt32, but Wine's chain-build inside winhttp.dll still returns CERT_E_UNTRUSTEDROOT, a known gap between Wine's registry-loaded store and its internal trust anchor set. The failure lives in Wine, not in the scanner.

Third pass, patch WINHTTP_FLAG_SECURE out of the binary

With the TLS problem localised to Wine, we bypassed it by patching the scanner itself. Every WinHttpOpenRequest call site in .text pushes the flags argument as an inline immediate. Three matches for mov dword ptr [rsp+0x30], 0x00800000, file offsets 0xB916D, 0xCEDBD, and 0x24FDE7. Flipping the single byte at each site (offset +6, from 0x80 to 0x00) turns WINHTTP_FLAG_SECURE into a no-op. WinHTTP now dials plain HTTP to 127.0.0.1:443 and our fake C2 answers as HTTP.

On the very next run, the patched binary hit /api/version live — with the scanner's own placeholder user agent, cleanly delivered to our sink:

{
  "ts": 1783704379.113549,
  "method": "GET",
  "host": "traceac.cc",
  "path": "/api/version",
  "headers": {
    "User-Agent":  "blablublewidfjhsfhdshGFDSBSDUFGDFDSBNTRACE",
    "Host":        "traceac.cc",
    "Connection":  "Keep-Alive"
  },
  "body_len": 0
}

That UA is the exact wide-string constant that lives at file offset 0x28BB09 in .rdata. Nothing in the request is randomised, rotated, or environment-derived, it's a literal ROM string. The X-Trace-Scanner header does not appear on this endpoint (the header lives on the scanner's authenticated traffic only, /api/scan/* and /api/scanner/*). After our server answered {"success":true,"version":"1.4"}, the binary accepted the response and moved on to WebView2 environment creation, which fails under Wine (no WebView2 runtime), producing the “Failed to create WebView2 environment” dialog and stopping the scan flow before the PIN prompt and subsequent authenticated endpoints. To reach the scan-submit body we would need to either supply a WebView2 host to Wine or patch out the environment-creation path, both are out of scope for this write-up.

Fourth pass, full capture under Windows 10 in QEMU

To defeat both the Wine cert-chain failure and the Wine WebView2 gap, we skipped Wine entirely and booted a real Windows 10 Lite (Build 18363) guest under qemu-system-x86_64 in TCG mode (no KVM), 4 GB RAM, 4 vCPUs, -cpu Haswell-v4 (AVX/SSE4.2 needed by the WebView2 installer). Guest network is SLIRP; the host is 10.0.2.2 from inside the guest.

• Installed MicrosoftEdgeWebView2Setup.exe (194 MB offline installer) and vc_redist.x64.exe (Win 10 Lite ships without VCRUNTIME140/MSVCP140). Added the fake CA to Windows trust with certutil -addstore -f Root.
• Wrote 10.0.2.2 traceac.cc and 10.0.2.2 scanner.traceac.cc to C:\Windows\System32\drivers\etc\hosts. The host runs the same fake C2, dual-mode: it peeks the first byte on each connection and dispatches to TLS (0x16) or plaintext HTTP (GET/POST) on the same port 443, required because our WINHTTP_FLAG_SECURE patch makes the C++ side send plain HTTP to port 443 while WebView2 still speaks TLS to the same host.
• The fake C2 mirrors the real UI from scanner.traceac.cc/send/ui/ and rewrites </body> to inject a JS harness that hooks chrome.webview.postMessage for logging and directly fires the scan message sequence, start_scan → check_security_before_consent → start_scan_consented, skipping the human PIN entry and consent buttons entirely.
• An initial start_scan_consented without the three consent flags tos_accepted, privacy_accepted, requirements_accepted got rejected by the C++ side with scan_error: "Missing consent or PIN.", a stricter check than the JS surfaces. Setting all three to true let the scan proceed.

On the good run the scanner walked through its five progress phases — Collecting System Info → Analyzing Running Processes → Performing System Forensics → Scanning Files & Registry → Network & Account Intelligence, and POSTed the full submit body:

POST https://traceac.cc/api/scan/submit  HTTP/1.1
User-Agent: TRACE-Scanner/QMSAPRSqM4xK2JnP
X-Trace-Scanner: asfhgashfgaskfdgdsiuadftaedghjfgasdjkfahjkfvbcjasgdjasfajsrolrgirdrueehdnfsbdsfbsfyfajh
Content-Type: application/json
Content-Length: 144437

{
  "pin":       "7TXBS1AV",
  "result":    "cheating",
  "duration":  92.47015161,
  "data":      [ 253 finding objects ],
  "system_info": {
    "os_version":          "Windows 10 (Build 18363)",
    "install_date":        "2026-07-10",
    "boot_time":           "2026-07-10 19:28:01",
    "uptime_hours":        2.034413888888889,
    "country":             "US",
    "vpn":                 "None Detected",
    "diagtrack_enabled":   false,
    "sysmain_enabled":     true,
    "secure_boot_enabled": false,
    "memory_integrity_enabled": false,
    "fast_boot_enabled":   false,
    "vulnerable_driver_load": false,
    "yara_scan_targets":   0,

    "screenshot":          "/9j/4AAQSkZJRg...",   // 58,181-byte JPEG, base64-encoded
    "scanned_paths":       [ "C:\\Users\\trace\\Desktop",
                             "C:\\Users\\trace\\Downloads",
                             "C:\\Users\\trace\\Documents",
                             "C:\\Users\\trace\\Pictures",
                             "C:\\Users\\trace\\Music",
                             "C:\\Users\\trace\\Videos",
                             "C:\\Users\\trace\\Saved Games",
                             "C:\\Users\\Public" ],
    "browser_downloads":   [ "desktop.ini|C:\\Users\\trace\\Downloads\\desktop.ini|282|9351|false|false" ],
    "browser_history":     [],
    "recycle_bin":         "0 items",
    "recycle_bin_files":   [ ... ],
    "recycle_bin_modified": "2h ago",
    "recent_activity":     [ { "action":"STARTED", "filename":"\\Device\\HarddiskVolume2\\trace\\trace_scanner.exe",
                               "is_signed":false, "run_time":"2026-07-10T21:29:40" }, ... ],
    "admin_apps":          [ 10 process records with is_signed / signer / verdict ],
    "network_activity": {
      "advanced_tcp":            [ 9 TCP conns from GetTcpTable2 ],
      "live_connections":        [ 9 conns w/ local_ip+port, remote_ip+port, pid, process, state ],
      "dns_queries":             [],
      "high_entropy_domains":    [],
      "suspicious_connections":  [],
      "tor_nodes":               [],
      "event_logs": { "driver_loads": ..., "firewall_blocks": ..., "logon_events": ..., "sysmon_network": ... }
    }
  }
}

The result was "cheating", from a freshly-installed Windows 10 Lite VM with nothing on it but the scanner, WebView2 and the VC++ redistributable. The 253 findings break down as:

  152  Suspicious Service/Driver   High     "Unsigned service matching suspicious keyword found."
   90  Scheduled Task Persistence   Low
    5  DiagTrack Forensic           Low
    2  Prefetch Trace               High     "Execution trace found in Windows Prefetch: AgRobust.db" etc.
    2  Signature Warning            Medium
    1  Forensic Database Match      High     "Database Keyword: fontdrvhost.exe"
    1  Virtual Machine              High     (detected we were in QEMU)

Notes worth calling out from that submit body:

• The verdict field is result:"cheating" on a virgin Win 10 install. The category threshold that drives that verdict is server-side, but the client sends enough data (finding count, weights, VM flag) that a Windows Prefetch entry for a Microsoft-signed font-driver host process is sufficient to trip it.
• A full-screen JPEG desktop screenshot (58 KB decoded) is base64-embedded in the JSON body, no separate multipart, no separate endpoint, no user prompt. It captures whatever is on the entire primary display at the moment the scan started, then the whole 144 KB body ships in a single POST.
• The bearer-shaped token TRACE-Scanner/QMSAPRSqM4xK2JnP that lives in the request's User-Agent is not a placeholder, it's a per-scanner secret built into the sample's .rdata. Combined with the static X-Trace-Scanner header (identical across every request), possession of one compiled scanner exe is possession of enough headers to POST arbitrary JSON to the live /api/scan/submit for that scanner's PIN slot.
• TCP table exfiltration is exhaustive — GetTcpTable2 results with local port + remote IP + remote port + PID + process image name + connection state are shipped raw. A running FiveM session, or a running SSH tunnel, appears in the JSON body one-to-one.
• The scanner detected the VM environment (Virtual Machine, High severity, 1 finding), same category that trips a 40-weight finding, so "analysis in a VM" is itself weighted toward the cheating verdict on the server side.
• The full endpoint order across a real scan is: GET /api/version → GET /api/scanner/rules?pin= → GET /api/scanner/yara_manifest?pin= → POST /api/scan/progress ×32 → POST /api/download/validate ×5 (body: {"pin":"<PIN>"}) → POST /api/scan/submit. The /api/download/validate endpoint was not previously in our C2 map and only surfaces during the live scan flow.

Fifth pass, everything, with a live PIN

With a fresh, valid dashboard-issued PIN (97DPWZ7C) we cleaned the remaining unknowns off the map. Every scanner endpoint that returns rules, safes, YARA CLI, or the signed executable is reachable with the C++ scanner's exact request headers:

GET  https://traceac.cc/api/scanner/rules?pin=<PIN>              -> 5,732 B  application/json
GET  https://scanner.traceac.cc/static/bin/yara64.exe?pin=<PIN>  -> 2,418,688 B  PE32+ console x64
GET  https://traceac.cc/api/download/file?pin=<PIN>              -> 6,528 B  HTML (download splash)
GET  https://traceac.cc/api/download/file?pin=<PIN>&download=1   -> 3,345,920 B  PE32+ GUI x64  (the scanner)
POST https://traceac.cc/api/download/validate  {"pin":"<PIN>"}   -> {"success":true}
POST https://traceac.cc/api/scan/progress      {"pin":"<PIN>",…} -> {"success":true}
POST https://traceac.cc/api/scan/submit        (full body)       -> {"success":true}
POST https://traceac.cc/api/scan/closed        {"pin":"<PIN>"}   -> {"success":true}

Notable negatives (verified with the same valid PIN, headers and query variants): /api/scanner/yara_manifest?pin=, /api/scanner/yara_rules?pin= and every ?file=<name> parameter combination we tried return the same 22,207-byte TRACE | Page Not Found HTML. Both endpoints are dead on the current server. They still live in .rdata as leftover strings , the current client codepath does not hit them. All signature intel travels through the single /api/scanner/rules JSON.

The rules JSON, 24 cheats + 3 safes, plaintext

The full brand inventory ships as one JSON blob per scan. Every cheat entry carries the trigger keywords the C++ side greps for (in memory, in strings, in DNS, and against process paths), the exact expected file_name + file_size + sha256 for hash matching and a severity band that drives the server-side verdict. The full list:

And the safes allow-list, three fixed entries, is the entire whitelist:

[
  { "name":"Spotify", "file_name":"spotify.exe",
    "sha256":"34285a7753a062d672311ce575a1606e1b9b5c8842a0520de027997124fc63c6" },
  { "name":"Chrome",  "file_name":"chrome.exe",
    "sha256":"f6390508a568fb7aa61296e30e40aaf019900188ca76dd82ab022f3308d49ab4" },
  { "name":"FiveM",   "file_name":"FiveM.exe",
    "sha256":"4972704ebb3cd6cebf235ba10892f5449f6ba16c852dfb6c24a516ee2dafc2be" }
]

Rule quality notes: the JSON as-shipped contains four clearly non-signature sha256 values — "22", "none", "dynamic2", "eulen_placeholder_sha" / "susano_placeholder_sha", and an empty string for Strings Detected. The scanner treats these as always-mismatch, falling through to the keyword grep, which means those rows are effectively YARA-string-only detections masquerading as SHA-checks. The Critical DLL Injector rule triggers on the literal word cheat, esp, or aimbot appearing anywhere in a scanned buffer, a keyword list that will false-positive against tutorial repositories, gaming videos, or any anti-cheat write-up.

yara64.exe, the shipped CLI

GET https://scanner.traceac.cc/static/bin/yara64.exe?pin=<PIN> → a 2,418,688-byte PE32+ console executable, SHA-256 1c45eb27​9d820aba​81fd41c2​23844428​ebe44037​cf5793be​4b52a9d3​b3df62b3​3. This is a stock upstream YARA build, not a fork; the scanner drops it under %APPDATA%\\trace\\yara64.exe, verifies the SHA-256 against the (dead) manifest response and shells out with -w -m --scan-list. On a valid PIN the download succeeds without the header pair below, but the sample's real request always ships them.

The scanner exe download, one binary for everyone

GET /api/download/file?pin=<PIN> serves a small HTML splash that immediately links to ?download=1. The download URL returns the actual PE32+ GUI executable (Content-Type: application/x-msdos-program, 3,345,920 B, SHA-256 9d1b210b​06d94286​3e49f0cf​7baf629f​cdc3cf76​d33a5383​a6caec65​783eb4fc). Compared byte-for-byte against our earlier Trace_7TXBS1AV.exe sample:

  Total differing bytes: 4
    0x17ac2  , our jge -> jmp WebView2-error-skip patch
    0xB9173  , our WINHTTP_FLAG_SECURE strip (site 1)
    0xCEDBD  , our WINHTTP_FLAG_SECURE strip (site 2)
    0x24FDED , our WINHTTP_FLAG_SECURE strip (site 3)

The two exes are otherwise identical. That is the entire per-scanner customisation: nothing. The PIN is not embedded, the X-Trace-Scanner header is not embedded, the TRACE-Scanner/QMSAPRSqM4xK2JnP user-agent is not embedded per customer. All three are hardcoded constants shared by every scanner ever compiled off this build. The PIN is parsed at runtime from GetModuleFileNameW, everything between the Trace_ prefix and the .exe suffix. Renaming the file changes the PIN. There is no cryptographic tie between the exe and the dashboard-issued PIN.

Impact: possession of any one compiled scanner is possession of every header material Cloudflare gates on. To POST a fabricated /api/scan/submit body against any customer's PIN slot, an attacker with a scanner copy needs only the target's current PIN (an 8-character alphanumeric dashboard-issued token) and their own copy of the scanner's three static headers. Every server response for /api/scan/* is a bare {"success":true}, no report id, no HMAC of the body, no echoed timestamp, no idempotency key.

YARA is dead in production, the scanner ships without rules

The scanner is built around a YARA fetch chain: get a manifest, verify the URL and SHA-256, download yara64.exe, download custom_rules.yar, shell out to yara64.exe -w -m --scan-list. Every step of the pipeline is in the binary, the URLs, the error strings (YARA manifest HTTP failed, YARA manifest SHA256 is invalid, YARA manifest URL Rejected:, YARA rules failed CLI validation), the output paths (%APPDATA%\\trace\\yara64.exe, %APPDATA%\\trace\\custom_rules.yar). We ran the whole chain end to end under our fake C2 with a properly signed manifest and captured the request format for every stage:

# manifest fetch (application/json)
GET https://scanner.traceac.cc/api/scanner/yara_manifest?pin=<PIN>
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: application/json
User-Agent: TRACE-Scanner/QMSAPRSqM4xK2JnP
X-Trace-Scanner: asfhgashfgaskfdgdsiuadftaedghjfgasdjkfahjkfvbcjasgdjasfajsrolrgirdrueehdnfsbdsfbsfyfajh
# expected body:
#   {"success":true, "url":"https://scanner.traceac.cc/static/bin/yara64.exe?pin=<PIN>",
#    "sha256":"<64-hex>", "size":<int>, "min_size":<int>}

# yara64.exe download (application/octet-stream), SHA-256 verified against manifest
GET https://scanner.traceac.cc/static/bin/yara64.exe?pin=<PIN>
Accept: application/octet-stream
...same auth headers...

# rules text download (text/plain), written to %APPDATA%\trace\custom_rules.yar
GET https://scanner.traceac.cc/api/scanner/yara_rules?pin=<PIN>
Accept: text/plain
...same auth headers...

But on the current production server, with the same valid dashboard-issued PIN, the exact wire headers the client emits, on both host aliases, both YARA endpoints return the same 22,207-byte TRACE | Page Not Found HTML:

GET https://scanner.traceac.cc/api/scanner/yara_manifest?pin=97DPWZ7C  -> 200 text/html 22,207 B  (404 HTML)
GET https://scanner.traceac.cc/api/scanner/yara_rules?pin=97DPWZ7C     -> 200 text/html 22,207 B  (404 HTML)
GET https://traceac.cc/api/scanner/yara_manifest?pin=97DPWZ7C          -> 200 text/html 22,207 B  (404 HTML)
GET https://traceac.cc/api/scanner/yara_rules?pin=97DPWZ7C             -> 200 text/html 22,207 B  (404 HTML)

The scanner ships with a whole detection pillar wired up to a route that isn't there. On every real-world scan the client silently drops down the YARA manifest response was empty error path, sets yara_scan_targets: 0 in the submit body and reports the whole verdict off the other pillar, the /api/scanner/rules keyword + SHA-256 table. Every “critical” hit in the 253-finding sample body above came from keyword grep or Prefetch/BAM/SRUM inventory, not from YARA. There are 24 cheat entries in the rules JSON whose sha256 field is a real 64-hex digest, the scanner is built to hash-match candidate files against them and post a Forensic Database Match finding on a hit, but with YARA disabled and the file discovery limited to a fixed set of user-profile directories, that match window is a lot narrower than the “full-machine forensic sweep” the marketing implies.

Live server probe

Independently of the Wine harness, a curl against the real traceac.cc endpoint set does confirm one datapoint, the /api/version endpoint is unauthenticated and returns the current server version:

$ curl https://traceac.cc/api/version
{"success":true,"version":"1.4"}

Every other endpoint in the C2 map is behind Cloudflare with the custom x-trace-error response header and a Forbidden | trace HTML body until a valid PIN is supplied, the PIN itself is minted by the dashboard, per scan and expires with the scan. That gate is server-side; the binary has no client-side PIN validation and the sample's own copies of the pin-carrying URLs are the same GET templates we already extracted. The manifest schema, rule text and scan-submit body are all gated behind that PIN and were not obtainable without one.

The 91-tool reverse fleet

For completeness on the tooling side: the reference against which this reverse was cross-checked is thementebinaria/retoolkitInno Setup superpack, a curated Windows installer that fetches 91 open-source RE tools across 22 categories at install time (retoolkit itself ships only .iss script wrappers; the tools are fetched fresh from each upstream). The full inventory the installer contains is below. The Linux-side pass on this page was done with radare2 5.5, pefile 2024.8, lief 0.17, yara 4.5 and the mandiant/capa-rules corpus (1,055 rules). Ghidra and Cutter were unreachable from this environment (GitHub release-asset URLs 403 through the proxy), so their equivalent coverage came from radare2 and the raw PE parser.

Category counts total 91 (documentation.iss and the root retoolkit.iss orchestrator omitted). The parser used to emit this list walks every src/installer/<category>/*.iss file in the retoolkit repo and pulls the AppName define plus the category the file sits under. Two entries are worth flagging: firefox is included under the network category as a lightweight browser for VirusTotal / vendor lookups and jdkis a build-time dependency for Ghidra/Jadx rather than an analysis tool of its own.

Live traceac.cc surface map

Every URL surface the scanner touches, probed live from this pass. The important read is not the list itself (that comes from .rdata) but which paths respond vs. which are Next.js SPA-fallback pages served for anything the router doesn't know. In particular: /robots.txt, /sitemap.xml, /favicon.ico, /apple-touch-icon.png, /manifest.json, /humans.txt, /ads.txt and /BingSiteAuth.xml all answer 200 with the same 21–23 KB SPA HTML, the site has no real robots directive, no sitemap, and no static favicon. The favicon is inlined into the SPA head as a data:URI.

/.well-known/security.txt

Only real static well-known file on the domain, 148 bytes at the canonical path:

Canonical: https://traceac.cc/.well-known/security.txt
Contact: mailto:support@traceac.cc
Expires: 2026-06-25T23:59:00Z
Preferred-Languages: en, el

The Expires date is the same day as the binary's compile time (2026-06-25). The Preferred-Languages: en, el pair is the strongest static geographic signal on the whole site, Greek + English, matching the FiveM vertical's operator base.

CSP topology (from /login response)

The site's own Content-Security-Policy header names every third-party origin the dashboard is allowed to talk to. This is the authoritative allow-list, anything the scanner or dashboard reaches at runtime has to be in here or the browser blocks it:

Everything third-party goes through Cloudflare, challenges.cloudflare.com(Turnstile bot check), cdnjs.cloudflare.com (script/style CDN), fonts.gstatic.com (via fonts.googleapis.com). The connect-src line names the four host+scheme pairs the scanner and dashboard talk to on the wire: https://traceac.cc, https://scanner.traceac.cc and their wss://counterparts, the WebSocket bridges are opted into by the policy even though the static binary shows no WebSocket* imports; the WSS lanes appear to be dashboard-side only.

PIN lifecycle, 11 PINs, 6 alive, 5 expired

Eleven live-issued PINs were exercised against https://traceac.cc/api/download/file?pin=<PIN>&download=1. Six PINs return the canonical 3,345,920-byte PE with SHA-256 9d1b210b06d942863e49f0cf7baf629fcdc3cf76d33a5383a6caec65783eb4fc — byte-for-byte identical across all six. The download route is not per-PIN, every valid PIN gets the same build. Five other PINs answer with a shared Cloudflare 403 HTML page (~33 KB, title Forbidden | trace), the request reaches the origin and the origin says the PIN is gone. The distribution below is the observed lifecycle: PINs live long enough to complete a scan session, then the origin marks them expired and the download route drops to 403 without a body change:

Note the direct URL flow: hitting /api/download/file?pin=<PIN> without &download=1serves a small HTML landing page (<title>Trace Download</title>) with a single anchor referencing the ?pin=<PIN>&download=1 form, the actual binary transfer only starts on the second request. The two-step is a Cloudflare Rocket-Loader-friendly guard. Every PIN is 8 characters of [A-Z0-9] with no obvious HWID binding, the same PIN string can be replayed until it goes 403.

WebView2 UI state machine (from /send/ui/)

https://scanner.traceac.cc/send/ui/index.html was pulled live (20.4 KB HTML shell). It reveals the three-step flow the injected WebView2 host walks the user through, each step its own .state block with a .trace-mini-stepperheader and a data-flow-step integer. The scanner binary's injected JavaScript (documented in the WebView2 injection section) targets these DOM IDs directly:

Asset load list

The <head> of the UI page loads eight local assets from scanner.traceac.cc/send/ui/ plus one external stylesheet from cdnjs.cloudflare.com. Direct HTTPS fetch for the JS/CSS returns 403 without a live session cookie, those are gated behind a scanner-only session, but the reference set is visible in the shell:

components.css?v=buttonnn is the only versioned asset, the cache-buster query string is a hand-typed buttonnn rather than a hash or a build counter, which matches the overall vibe of the site: shipping software, not infrastructure code. rocket-loader.min.js is a Cloudflare defer-and-inject shim added by the edge, not by the origin.

QEMU Windows guest attempt (no KVM)

A stretch goal on this pass was to boot a Windows guest under QEMU and run Trace_7TXBS1AV.exeagainst the retoolkit tool fleet inside it. The container has no /dev/kvm, so QEMU falls back to tcg (software emulation), roughly 1–5% of native speed on Windows workloads. A Windows 10 Lite 19H2 x64 ISO (1.19 GB, disk label WIN10PRO_1909_476_OPREKIN, from archive.org) was pulled fresh and the machine started with:

qemu-system-x86_64 \
  -machine q35 -m 4096 -smp 2 -cpu qemu64 \
  -device ich9-ahci,id=ahci \
  -drive file=win10.qcow2,if=none,id=disk0,cache=writeback \
  -device ide-hd,drive=disk0,bus=ahci.0 \
  -drive file=win10lite.iso,if=none,id=cdrom0,media=cdrom \
  -device ide-cd,drive=cdrom0,bus=ahci.1 \
  -boot d -vnc :5 -daemonize \
  -monitor unix:qemu-mon,server,nowait -net none

Observed wall-clock time in TCG mode with 4 GB RAM and 2 vCPUs:

Why the Windows-side pass is a stretch, not the load-bearing analysis: even once the guest reaches the desktop, running Trace_7TXBS1AV.exe in it needs the Edge WebView2 Evergreen runtime installed (the binary's ICoreWebView2* class-name imports make that a hard requirement, no runtime, no window). And retoolkit's value is a fleet of interactive GUI tools (x64dbg, Cutter, IDA-freeware-style, pestudio, HxD), driving that from a headless VNC in this session isn't a productive way to spend the budget. Every finding on this page came from Linux-side tooling that does answer the question: rabin2/radare2for disassembly + xref navigation (the same job Cutter/Ghidra do interactively), pefile+lief for the PE parse (the job pestudio/PE-bear do), strings -eL(the job FLOSS does), yara against capa-rules (the job capa does) and Wine + a synthetic C2 for the runtime dial-out capture (the job x64dbg on Windows would do).

One concrete boot artefact worth flagging: the first QEMU boot with if=virtio on the disk reproduced the classic Windows-installer catch, Windows Setup does not carry viostor.sys on the install ISO and the drive picker showed "We couldn't find any drives. To get a storage driver, click Load driver."Switching the disk interface to ich9-ahci (a chipset every Windows 10 ISO knows natively) made Drive 0 appear on the second boot. This is unrelated to the scanner itself but shows up when anyone tries to reproduce the guest, the SATA path is the one to use unless you also feed the virtio-win.iso as a second CD-ROM.

Closing

Trace Anti-Cheat is a functional retroactive-trace scanner. It reads a well-chosen set of Windows forensic artefacts, downloads YARA to run against a rule set that lives on its authors' server, takes a screenshot and posts a JSON to a fixed C2. The technique inventory is solid, Prefetch, BAM, SRUM, Amcache, Event Log 4688 with the TokenElevationType filter, DNS-Client 3008/3010, WFP 5152/56/57. Anyone building a similar tool could learn from the coverage.

It is not unreverseable. The protector marker is 61 bytes of text in a section named .1337. No section is encrypted, no TLS callback is registered, no anti-debug is meaningfully implemented and every URL, every registry key, every YARA path, every event log query, every cheat brand name and every user-facing string sits in .rdata in plaintext at UTF-8 or UTF-16-LE. This document is the extraction, byte-offset by byte-offset.

If the next release genuinely raises the bar — real string obfuscation, control-flow flattening, a proper protector shell, meaningful anti-debug, or even just a byte-oriented XOR pass over .rdata with a runtime-derived key — we will happily update this page to note the improvement. Until then, the “unreverseable” label describes marketing, not this build.

Every string quoted in this write-up appears in the sample's .rdata at either UTF-8 or UTF-16-LE and is reproducible with strings -a -eL against the file whose SHA-256 is listed in the IOC block. The runtime section documents a live wire capture attempt under Wine that confirmed the TLS dial-out and stopped at Wine's post-handshake cert-chain build, everything else in this write-up was recovered statically.