Defensive use only. Detection methodologies published for server administrators, DFIR practitioners, and anti-cheat researchers. No evasion guidance is provided.
Overview
Stainless is among the more technically sophisticated FiveM bypasses documented in this research series. Rather than relying on userland injection or simple loader tricks, it employs a Bring Your Own Vulnerable Driver (BYOVD) chain: the binary loadsRTCore64.sys, a legitimately signed but vulnerable ASUS GPU Tweak II driver, and exploits its kernel-mode write primitive to disable anti-cheat kernel callbacks. This approach bypasses user-mode protection entirely by operating at the kernel level before the anti-cheat has an opportunity to establish its monitoring hooks.
The binary presents as telephon.cpl — a Control Panel applet extension, typically associated with the Windows telephony configuration applet. CPL files are DLLs with the EXECUTABLE_IMAGE characteristic set and a CPlApplet export. Running a CPL file directly is unusual user behavior and is not something a normal user would do as part of routine computer use, making it an inherently suspicious execution event in any logging system.
The developer left their full desktop PDB path in the release build:C:\Users\ddrac\Desktop\bypass gringo\x64\Release\stainless.pdb. The "bypass gringo" directory name is unusual and suggests a Spanish-speaking developer — "gringo" is a colloquial Spanish term for a foreigner, typically North American. The PDB string survives in the release binary because the developer did not strip debug symbols from the build, which is a common oversight in unprofessional bypass operations.
In addition to RTCore64.sys, the binary embeds path strings for two additional vulnerable drivers: AsUpIO.pdb and iqvw64e.pdb (the latter being the Intel Network Adapter Diagnostics driver, another commonly used BYOVD target). This suggests Stainless either has fallback driver logic or was designed to support multiple BYOVD chains.
Primary IOCs
File Hash — SHA-256, SHA-1, MD5
SHA-256: 9104158b8ee2f545697504a368be7fd264cadac2ed38ecd80a8dcc9f42e27097
SHA-1: 9de9d0bd5f9595b2fb6011447b434886398025e6
MD5: a229fa1a200ee5338ede3bbeba84cb2b
The binary is 6.35 MB, AMD64, presented as a DLL with the EXECUTABLE_IMAGE characteristic. Compute SHA-256 using PowerShell'sGet-FileHash and compare against the above values. The relatively small file size for a BYOVD loader reflects efficient construction — the driver itself is loaded from disk rather than embedded in the binary.
DPS Timestamp — 2026/03/21:21:37:36
The PE TimeDateStamp is 2026/03/21 at 21:37:36 UTC. This timestamp is embedded in the COFF header and readable by any PE inspection tool. The PcaSvc offset is 0x660000, which is notably smaller than other documented bypass offsets, consistent with the binary's 6.35 MB footprint.
Any CPL file found on disk with a compile timestamp in late March 2026 and no legitimate telephony or control panel purpose should be treated as a Stainless candidate. CPL files at unusual paths — outside of System32 and SysWOW64 — are inherently anomalous and warrant immediate hash verification.
PcaSvc Entry — Offset 0x660000
The PcaSvc offset 0x660000 will appear in AppCompat registry records if the telephon.cpl binary was executed on the system. As with other bypasses in this series, PcaSvc records persist after file deletion.
Search AppCompatFlags registry keys for any CPL-related entries that reference paths outside of the Windows system directories. A CPL file executed from Desktop, Downloads, AppData, or any game directory is a clear anomaly that should be flagged regardless of the specific filename.
RTCore64.sys Presence on Disk
After execution, Stainless drops or references RTCore64.sys on disk. This driver file is not a standard Windows component. Run a filesystem search for this filename:
Get-ChildItem -Path C:\ -Filter "RTCore64.sys" -Recurse -ErrorAction SilentlyContinue
Any instance of RTCore64.sys on a gaming PC with no legitimate ASUS GPU Tweak II installation is a critical finding. The driver may be placed in temp directories, the Windows driver store, or custom paths specified by the bypass loader. Its presence alone — combined with absence of the ASUS application that legitimately ships it — is strong evidence of BYOVD activity.
YARA — stainless.pdb String in Binary
The string stainless.pdb appears in the binary as part of the full PDB path C:\Users\ddrac\Desktop\bypass gringo\x64\Release\stainless.pdb. This string is a highly specific YARA anchor. A rule matching on this substring will identify all copies of this binary regardless of filename changes or superficial packing:
strings: $pdb = "stainless.pdb" nocase ascii
condition: $pdb
The full path string including "bypass gringo" is even more specific and less likely to produce false positives. Include both the short and full path variants in any deployed YARA rule set.
YARA — RTCore64 Driver Path Strings in Binary
In addition to the PDB string, Stainless embeds filesystem path references to the RTCore64 driver and companion vulnerable drivers (AsUpIO.pdb, iqvw64e.pdb). These strings appear in the binary's data or rdata section and are detectable with a strings analysis tool or YARA rule. Running:
strings telephon.cpl | findstr /i "RTCore64"
will reveal path references if present. A YARA rule anchoring on the RTCore64 driver name string within a non-driver binary provides a second detection layer that catches the binary even if the PDB section is stripped in a future build. The combination of both rules ensures detection robustness across build iterations.
RTCore64 and BYOVD: What It Means for Detection
Bring Your Own Vulnerable Driver (BYOVD) attacks abuse the Windows kernel's driver loading mechanism. A legitimately signed driver from a hardware vendor — in this case, RTCore64.sys from ASUS — contains a vulnerability (typically an arbitrary kernel-mode read/write primitive exposed through IOCTL) that an attacker can exploit to operate with kernel-level privileges without writing their own unsigned driver.
RTCore64.sys is one of the most widely documented BYOVD targets. It exposes a kernel memory read/write interface that Stainless uses to disable anti-cheat kernel callbacks — specifically, the PsSetLoadImageNotifyRoutine and similar callbacks that anti-cheat software registers to monitor process and module loading events. Once these callbacks are removed, the anti-cheat loses visibility into subsequent injection activity.
Detection of BYOVD activity at the kernel level requires EDR or kernel callback monitoring, which may not be available during a standard screenshare session. However, the artifacts left on disk and in registry are detectable through standard user-mode tools: the driver file itself, the service registry entry created to load the driver, and the PcaSvc records for telephon.cpl are all accessible without kernel-level tooling.
Note that Microsoft has added RTCore64.sys to the Windows Driver Block List (WDAC policy) in recent updates. On fully patched Windows 11 systems, loading this driver should be blocked by the kernel. However, players using bypass software often disable or configure around WDAC policies as part of their setup, so the presence of a loaded RTCore64 driver on a gaming machine should still be treated as a critical finding.
Detection Notes
Stainless represents the upper tier of technical sophistication among the bypasses documented in this research series. The BYOVD chain requires more operational setup than a simple loader injection, and the kernel-level callback disabling it achieves is a genuine threat to anti-cheat integrity. However, the developer's failure to strip PDB symbols from the release build creates an unusually rich YARA detection surface that will outlast hash rotation.
The "bypass gringo" PDB path string is both an attribution artifact and a persistent detection anchor. Unless the developer cleans their build process to strip PDB references — a separate step from compilation that many developers overlook — every new build will carry the same string, allowing YARA rules written against this sample to identify future variants.
Server administrators should treat any screenshare that reveals an unexplained CPL file outside of System32 as an immediate escalation. The legitimate use cases for a custom CPL file on a gaming machine are effectively zero. Even before hash verification is complete, an unusual CPL file combined with the player's inability to explain its origin should result in a provisional suspension pending investigation.