fix(DenuvoAuth): engage auth path when signature scan misses but an eticket is injected

[Peron4TheWin]

Problem

ProtectionScan only recognizes Denuvo via two signatures scanned on the on-disk PE: the OEP mov rcx, "DODENUVO" immediate, and the literal DENUVO string in a legacy section. Some titles ship a Denuvo build that slips both heuristics (the markers are absent / encrypted on disk).

When that happens, denuvoDetected stays false, the authorization window never opens, and GetAppOwnershipTicket falls back to the forged appid-7 ownership ticket instead of the genuine one from the credential store — which Denuvo's license server rejects (e.g. 885000051).

Change

In EnsureScanned, when signature detection misses, fall back to checking whether an EncryptedAppTicket has been injected for the app. setAppTicket/setETicket are only used for ticket-gated (Denuvo) titles, so an injected eticket is a strong "the user intends Denuvo auth" signal; treat the app as Denuvo and engage the auth path instead of giving up.

No behavior change for already-detected titles, or for apps without an injected eticket.

Verified

Sonic Forces (appid 637100): the scan misses both signatures (confirmed in pipe.log — no Denuvo match), so auth never engaged and Denuvo failed with 885000051. With this change the fallback fires (scan missed but injected eticket present; treating as Denuvo), the authorization window opens (handshakeCount=1), the real ownership ticket is served from the credential store, and the title launches.

Notes

Complements the size-floor miss in #121: that covers titles whose .exe falls under the 80 MB floor; this covers titles that pass the floor and are scanned but still slip both signature heuristics. The auth-window timing (kEndDenuvoVerificationHandshake) is left unchanged — for 637100 the ownership-ticket IPC lands within the existing window (handshakeCount stays at 1).

[OpenSteam001]

Thanks for the PR.

I understand the intention here. This does help with cases where the current Denuvo heuristic scan misses, similar to the detection miss discussed in #121.

However, I don't think treating the presence of an injected eTicket as equivalent to Denuvo detection is a good long-term solution. It works more like a fallback/workaround, but it doesn't actually improve the heuristic detection itself, and it may also not fully solve the account-switch authorization flow.

I'll spend some time optimizing the Denuvo heuristic rules directly, so the auth path can be triggered based on more reliable detection instead of relying on whether an eTicket was injected.

[Peron4TheWin]

Yeah it was a workaround, i know the best method is to find the correct way to scan denuvo, but it was a solution because there is a multitude of games that doesnt work

(Sonic forces, planet coaster, Suicide squad, mk1) etc

Hopefully a better method is found.