Sulution Software Bypass: Three Build Variants with March 2026 Timestamps

Defensive use only. Detection methodologies published for server administrators, DFIR practitioners, and anti-cheat researchers. No evasion guidance is provided.

Overview

"Sulution Software" — the vendor apparently did not notice the typo in their own product name, which tells you something about the QA process — is a FiveM bypass operation that distinguishes itself primarily by the speed at which it iterates builds. Three distinct compiled variants appeared within a 48-hour window between March 18 and March 20, 2026. Each build carries a unique SHA-256 hash, MD5, and Digital Signature Timestamp (DPS), but all three share structural characteristics that allow unified detection.

The rapid build cadence is not accidental. When a bypass is detected and its hash is added to a blocklist — whether by the server's anti-cheat, a file scanner, or a community hash database — the operator compiles a new build that changes the file's fingerprint. The underlying functionality remains largely identical; only the compiled binary differs. This is why tracking all known variants, not just the most recent one, is essential for any detection effort intended to cover the full population of Sulution users.

The loader ships with a professional-looking GUI that belies its functionally thin internals. The visual polish is aimed at buyers, not at anti-cheat researchers — a bypass that looks like commercial software is easier to sell at a premium, regardless of what is actually happening under the hood.

The DPS timestamp and PcaSvc offset are the most reliable cross-build identifiers. Even when the binary hash changes, these metadata artifacts provide a persistent detection surface that survives recompilation in most cases, unless the operator also explicitly resets the linker timestamp — which Builds 1 and 2 through 3 appear not to have done consistently.

Primary IOCs — All Three Build Variants

Build 1 — SHA-256 / MD5 / DPS: 2026/03/18

SHA-256: 9afb3f4b071e3052c4dc4ba9daeae0f96b5c7a162cb48a92779474f6fa2a7c5d

MD5: e015b447ebf58f5f876e49d72e42da40

Build 1 is the earliest variant, timestamped 2026/03/18 at 19:49:16 UTC per the PE's Digital Signature Timestamp. The associated PcaSvc offset is 0x169e000. This build appears to have had the shortest deployment window — it was replaced within approximately 48 hours, suggesting it was detected by at least one screening method shortly after release.

When checking for Build 1, compute SHA-256 using Get-FileHash -Algorithm SHA256 on any suspicious executable and compare against the hash above. The MD5 can be used as a secondary confirmation.

Build 2 — SHA-256 / MD5 / DPS: 2026/03/20 (first)

SHA-256: df699dca9cc5c01a6ec7a43b23205f94cb486dd2868cb883d48179fc8f4b24da

MD5: 6cce9c118084fd7c010833d10e116e8d

Build 2 carries a DPS of 2026/03/20 at 19:43:53 UTC, indicating it was compiled approximately two days after Build 1. PcaSvc offset shifts to 0x16b2000. The change in PcaSvc offset between Build 1 and Build 2 is consistent with a code change or added import that adjusted the loader's memory layout — not merely a relink of the same object files.

Build 2 and Build 3 share the same PcaSvc offset, which suggests Builds 2 and 3 are compiled from the same source tree with only minor surface-level modifications such as resource section changes or embedded string alterations to defeat hash-based detection.

Build 3 — SHA-256 / MD5 / Shared PcaSvc with Build 2

SHA-256: acd3124236b3d32093eabcf3eeae758b6bc65ffe564b0eb3bd89ab82b8f9b5dd

MD5: c9137c8c968e7ed211d5244c556a3385

Build 3 shares PcaSvc offset 0x16b2000 with Build 2, confirming they originate from the same source revision. The hash difference indicates a superficial binary mutation — likely a resource section or embedded timestamp modification rather than a functional code change. This is a common quick-rotation strategy to defeat file-hash-only blocklists.

When all three builds are blocked by hash, analysts should monitor for a fourth variant. The operator's demonstrated 48-hour turnaround suggests a fourth build would arrive quickly if the existing three are flagged simultaneously.

DPS Timestamp Window: 2026/03/18–20

All three builds fall within a two-day compile window. The DPS (Digital Signature Timestamp or PE TimeDateStamp) can be inspected using PE analysis tools such as DIE (Detect-It-Easy), pestudio, or the PowerShell command:

[System.IO.File]::ReadAllBytes("suspect.exe") | Select-Object -First 512

Any suspicious executable carrying a PE TimeDateStamp between March 18 and March 20, 2026 that cannot be attributed to a known legitimate application should be submitted for hash verification against all three Sulution builds. The timestamp alone is not definitive — it must be combined with hash or PcaSvc offset confirmation.

PcaSvc Registry Entry and Offset Correlation

The Program Compatibility Assistant service (PcaSvc) records execution metadata for applications in the registry underHKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers and related keys. The PcaSvc offset values documented for Sulution builds — 0x169e000 (Build 1) and 0x16b2000 (Builds 2 and 3) — are derived from the binary's compatibility shim mapping.

During a screenshare, instruct the reviewer to search the registry for entries matching these offsets. Their presence, particularly when the associated executable path is not a known application, is a strong corroborating signal. The PcaSvc records persist even after the executable is deleted, making them a useful post-execution artefact.

Multi-Build Tracking: Why All Variants Matter

A common mistake in bypass detection is maintaining only the most recently identified build in a blocklist. This approach fails against operators who distribute multiple build versions simultaneously to different buyer tiers or geographic regions. Sulution appears to have done exactly this: there is no guarantee that all three builds were deployed sequentially rather than in parallel. A user who purchased in the first wave may be running Build 1 while a user who purchased two days later is running Build 3.

Maintaining a complete variant catalogue also enables clustering analysis. When multiple confirmed bypass users on the same server are found with different builds but identical PcaSvc offsets, this pattern points to a shared source — valuable intelligence for identifying the operator's distribution channels. Partial build coverage breaks the clustering signal.

The Build 2 → Build 3 transition is particularly instructive. The shared PcaSvc offset and identical functionality, combined with different hashes, confirms that the Sulution operator understands hash-based detection and responds with surface-level binary mutations. Future builds from this operator are likely to follow the same pattern: functional code stays constant, surface fingerprints rotate. YARA rules targeting functional code patterns or embedded strings will outlast hash-only blocklists.

Analysts tracking Sulution should maintain all three hashes indefinitely. Users running older builds are still using a bypass; the age of their specific variant does not reduce the severity of the infraction or change the detection outcome.

Screenshare Check Methodology

Compute SHA-256 of Any Suspicious Executable

Ask the player to open PowerShell and run Get-FileHash "path\to\file.exe" -Algorithm SHA256. Compare the output against all three Sulution build hashes. If any match is found, the check is complete — do not proceed further before flagging and documenting the finding.

If no direct match is found but the executable is still suspicious (unusual name, path, or recent timestamp), proceed to the DPS check. A future Sulution build may carry a new hash not yet in this database.

Inspect PE Timestamp Using DIE or pestudio

Ask the player to open Detect-It-Easy (DIE) and load the suspicious file. The PE header timestamp displayed in DIE's info panel should be noted. Any file showing a compile timestamp in the March 18–20, 2026 range that is not a known legitimate application should be treated as a Sulution candidate, pending hash and PcaSvc confirmation.

DIE is portable and requires no installation, making it suitable for use during a screenshare where the player may be unwilling to install additional software. Alternatively, pestudio can be used if already present on the system.

Check PcaSvc Registry for Offset Signatures

Open Registry Editor (regedit) and navigate toHKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags. Search for any entries referencing unknown executable paths. PcaSvc entries for Sulution builds will reference the loader's drop path and can persist even after the file itself has been deleted.

The offsets 0x169e000 and 0x16b2000 appear in binary registry value data. Use a hex-aware registry viewer or export the key to a .reg file and search for the hex strings to locate matching entries.

Search Prefetch for Sulution Loader Executions

Navigate to C:\Windows\Prefetch\ and look for .pf files whose names correspond to recently run executables that cannot be identified as legitimate applications. Prefetch files record the last eight execution timestamps and the list of DLLs loaded during each run.

Even if the Sulution executable itself has been deleted, its prefetch file may remain. Open the .pf file with WinPrefetchView to extract the original executable path and run timestamps. This provides post-deletion evidence of bypass execution.

Loader GUI Identification — Visual Pattern

If the bypass is still present on disk and the player attempts to demonstrate they are not cheating, they may open various folders. The Sulution loader ships with a professional-looking GUI window. If you observe an application window that claims to be a "solution" or "bypass" product — misspelled or not — with a clean dark-themed UI but no clear legitimate application purpose, this is a strong visual indicator to request immediate hash verification.

The GUI's professional appearance is a social engineering element aimed at players who might otherwise be suspicious of crude tools. Do not let polished presentation deter you from running the hash check — visual quality has no bearing on the file's identity.

Detection Notes

The most operationally important characteristic of Sulution is the speed of its build rotation. A single-hash blocklist will be stale within 48 hours of a new build release. Detection infrastructure should be hash-set based, covering all known variants simultaneously, supplemented by behavioral or structural YARA rules that target the loader's functional code rather than its surface fingerprint.

PcaSvc offset correlation is the most durable signal currently available for Sulution detection. Until the operator explicitly changes their build configuration to produce a different memory layout, the documented offsets will match new builds compiled from the same source tree. Monitor for offset changes as an indicator of a more substantial source revision.

The "Sulution" misspelling in the vendor name is worth noting for attribution purposes: it appears consistently across marketing materials, the loader GUI, and any associated online presence. Searching for this specific misspelling on Discord servers, forums, or Telegram channels can surface distribution channels and buyer communities, which in turn enables broader player identification before a screenshare is even requested.