Denuvo auth fails on titles missed by ProtectionScan (e.g. Sniper Elite 4 / appid 312660) — root cause + fix

[xingcheng1423-cmyk]

Follow-up to the symptom in #117 (Denuvo error 8850000A when a non-owner account plays with an owner's ticket injected). I traced it end-to-end with a Debug build + trace logs and found two concrete bugs in ProtectionScan, plus a fragile spot in the auth window. A one-line ProtectionScan fix is enough to make detection engage; PR incoming for that part.

Repro

• Game: Sniper Elite 4 (appid 312660), Denuvo-protected.
• Non-owner account logged in; owner's AppOwnershipTicket + EncryptedAppTicket injected via lua setAppTicket / setETicket.
• Result: game refuses to launch with Denuvo 8850000A.

Finding 1 — the size floor skips the game executable

kMinPackedModuleBytes = 80 MB in ProtectionScan.cpp is applied to every module including the main .exe. SniperElite4_DX11.exe is 70.97 MB, so it is skipped before any scan:

DenuvoAuth: module skipped below packed size floor path=...\SniperElite4_DX11.exe size=74420224 (70.97 MB) min=83886080 (80.00 MB)
DenuvoAuth: pid=... enumerated 0 candidate module(s)
DenuvoAuth: pid=... no Denuvo match scanned=0

→ denuvo=false → the authorization window never opens → GetSteamID returns the real (non-owner) SteamID while the owner ETicket is still served (it's not gated) → identity mismatch → 8850000A.

Fix (exempt the main executable from the floor; keep it for DLLs):

// EnumerateModules() in ProtectionScan.cpp
- if (module.size < kMinPackedModuleBytes) {
+ // Denuvo packs the .exe itself; some titles (e.g. Sniper Elite 4, 71MB) fall
+ // under the 80MB floor and get skipped. Always scan the main executable.
+ if (!executable && module.size < kMinPackedModuleBytes) {

Finding 2 — after lifting the floor, neither signature matches this build

With the .exe scanned, it is still not detected:

DenuvoAuth: OEP section timing  ... section=.edata raw_start=0x30CE00 scan_size=512 (0.00 MB) matched=false
DenuvoAuth: OEP section scanned ... section=.edata oep=0xF4C151 raw_start=0x30CE00 scan_size=512 matched=false
DenuvoAuth: legacy section present but DENUVO string not found ... section=.srdata
DenuvoAuth: no Denuvo match scanned=1

Two issues:

• The OEP (RVA 0xF4C151) resolved to section .edata (the export directory, 512 bytes). The OEP almost certainly shouldn't land in .edata; this looks like a SectionContainingRva resolution problem on this binary's (Denuvo-rewritten) section table, so the DODENUVO scan reads the wrong 512 bytes. Worth checking SectionContainingRva / EntryPointRva for PEs with this layout.
• The legacy path does find a known Denuvo section (.srdata) but bails because the literal DENUVO ASCII string isn't present in this build (newer Denuvo obfuscates it). So requiring section and literal string misses this title.

Most Denuvo titles trigger the OEP pattern or the legacy string and detect fine — this is specifically about titles that slip both heuristics.

Additional: the authorization window is timing-fragile (separate from detection)

Even once denuvo=true, DenuvoAuth.cpp closes the window after a fixed count of pipe handshakes:

constexpr uint32 kEndDenuvoVerificationHandshake = 2;
...
if (stage == Stage::Authorizing && handshakeCount >= kEndDenuvoVerificationHandshake) {
    stage = Stage::EndAuthorization; // window closed permanently; bound to the first pipe only
}
bool CanUseAuthorizedIdentity(const PipeKey& key) const {
    return denuvo && stage == Stage::Authorizing && authorizationPipe == key;
}

handshakeCount counts pipe handshakes for the process and increments on the selecting handshake itself, so the window effectively closes on the process's 2nd pipe handshake — which has no relationship to when Denuvo actually performs its ownership/SteamID verification (often later and/or on a different pipe). When that happens, GetSteamID is no longer spoofed and GetAppOwnershipTicket falls back to ForgeOnly, so Denuvo sees the owner ETicket paired with the real SteamID → mismatch.

For the "playing account ≠ owning account" case there is no real identity to restore, so we widened it downstream:

bool CanUseAuthorizedIdentity(const PipeKey& key) const {
    if (!denuvo) return false;
    if (!LuaConfig::IsOwned(authorizedAppId)) return true;          // non-owner: serve owner identity for the whole session, any pipe
    return stage == Stage::Authorizing && authorizationPipe == key; // owned: keep your narrow window
}

This is more of a design question for you than a clean fix, so I'm not putting it in the PR — just flagging it.

What worked

With Finding 1 fixed (or detection otherwise forced on for this app) plus persistent owner-identity spoofing, Sniper Elite 4 launches on a non-owner account. So the pipeline itself is sound; the blocker was purely that ProtectionScan didn't recognize this Denuvo build.

I'll open a PR for the Finding 1 one-liner (it's unambiguous). Happy to share full trace logs, the test binary, or help investigate the SectionContainingRva issue in Finding 2.

[OpenSteam001]

Thanks for the detailed investigation and analysis.

For Sniper Elite 4 / appid 312660, I think the main reason is that this game is very old. Its last update was around 2017, so the Denuvo version used by this title is also very old. My current heuristic rules are mainly based on newer Denuvo builds, so this older version may not be detected correctly. I will take some time to improve this compatibility issue.

About the authorization window timing:

handshakeCount counts pipe handshakes for the process and increments on the selecting handshake itself, so the window effectively closes on the process's 2nd pipe handshake

This behavior is based on both the intended design and practical testing. In most cases, unless the game developer and Denuvo have made some special handling, the Denuvo authentication stage uses its own Steam IPC pipe and then releases it after the authentication is finished. Other normal Steam IPC calls usually do not reuse the Denuvo authentication pipe.

There are exceptions, for example some 2K titles such as 1285190 Borderlands® 4 appear to have special handling after certain versions, where other Steam IPC calls may reuse the pipe from the Denuvo authentication stage. In that case, only one pipe may be created during the whole process.

However, most of the games I tested do not reuse that pipe and instead release it directly after the DRM authentication stage, which also matches the expected behavior of a DRM authentication flow.

So I agree that the old Denuvo detection compatibility needs improvement, but the current pipe handshake window logic is intentional and based on the common behavior observed in testing.

[xingcheng1423-cmyk]

Suggested fallback for the detection miss (also pushed to #121 as a 2nd commit):

Since setAppTicket/setETicket are documented as only being needed for ticket-gated (Denuvo) games, an injected EncryptedAppTicket for an app is a reliable signal that the user intends Denuvo authorization. So when ScanProtection misses (as for SE4 — it slips both the OEP pattern and the legacy-string check), we can fall back to that signal instead of giving up:

// EnsureScanned(...), right after the normal scan
auth.denuvo = ScanProtection(process.pid).denuvoDetected;
+ if (!auth.denuvo &&
+     !AppTicket::GetEncryptedTicketFromCredentialStore(appId).empty()) {
+     auth.denuvo = true;   // injected eticket => user intends Denuvo auth
+ }

(threading appId into EnsureScanned from Apply's ctx.appId).

This catches present and future detection misses for any ticket-injecting setup, not just specific titles.

Caveats (your call whether to take it):

• It's a fallback, only after signature detection fails — the precise fix is still teaching ScanProtection to recognize these builds (Finding 1 size-floor is in fix(DenuvoAuth): always scan the main executable, not just modules ≥80MB #121; Finding 2 OEP→.edata / legacy-string is separate).
• Small false-positive surface: a non-Denuvo game that legitimately uses EncryptedAppTicket (own-backend ownership checks) would also get the auth path enabled if a user injected an eticket for it. Narrow, but real.
• Independent of the auth-window fragility noted above — our end-to-end SE4 test also had that window widened, so detection alone may not suffice for every title until the window is addressed.

Happy to drop it from the PR if you'd rather keep that one to just the size-floor one-liner.

[xingcheng1423-cmyk]

Thanks, that makes sense — agreed on both points.

On the window: your rationale is convincing. To be clear, SE4's failure in our logs was purely the detection miss (denuvo=false), not the window — so I over-flagged the window here. The "serve owner identity for the whole session" tweak we use downstream is specific to the non-owner-with-injected-ticket case (no real local identity to restore), which is exactly why we kept it out of #121. Once detection engages for SE4 it isn't a pipe-reusing title like the 2K ones you mentioned, so your standard window should be fine.

On detection: glad it's on your radar. #121 has the two pieces that helped us — (1) the size-floor exemption so the sub-80MB .exe gets scanned at all, and (2) the eticket fallback as a generic safety net for builds the signatures don't recognize yet (old Denuvo like SE4). Take either/both, or just use them as reference while you improve the old-Denuvo heuristics — whatever fits. Happy to share the SE4 test binary or full trace logs if they'd help you tune the older signatures.

Thanks for maintaining this.