Client never decrypts encrypted GRF, although GRF Editor itself decrypts it fine (2024/2025 clients)

[murilotaino]

The GRF is encrypted correctly (GRF Editor itself decrypts and previews the files fine with the password), the generated cps.dll matches the client, but the client never decrypts anything at runtime. I've isolated this pretty far and could use a pointer on where to look next.

Symptom

With encrypted sprites, the client window opens and then immediately shows an Error popup, followed by Gravity(tm) Error Handler (0xc0000005).

Control test (this is the important one): the exact same client executable and the exact same generated cps.dll, with a plain (unencrypted) GRF, runs fine — stays alive, no popup, no crash. So the exe/DLL pair itself is healthy; only decryption fails.

And the encryption itself is fine: opening the encrypted GRF in GRF Editor, entering the password, previews the .spr files without any issue.

Setup

• GRF Editor v1.9.1.2 (also reproduced on an older 1.5.x build)
• Clients tested (all reproduce): 2025-06-04, 2025-03-19, 2024-12-18 Ragexe
• Patcher: WARP
• Only data\sprite encrypted for the test; everything else left plain
• Gepard disabled during these tests to rule it out

What I verified

Import rewiring looks correct. The 2025-06-04 client imports cps.dll natively:

exe	imports from cps.dll
clean 2025-06-04	compress, uncompress
after Generate files	compress, giedaoodvr

and the generated DLL exports exactly compress + giedaoodvr. So the rename matches on both sides.

The exe patch is 20 bytes, two occurrences of uncompress → giedaoodvr, nothing else. From reading EncryptorDialog.xaml.cs that appears to be exactly what's expected (_binaryReplace for cps.dll and uncompress), so I don't think that's the problem — just noting it in case it is.

The generated cps.dll is byte-comparable to working ones. Two servers I have locally that do run fully encrypted GRFs ship a cps.dll of 175,616 bytes, PE timestamp 2024-10-31 12:54 — identical build to the one my older GRF Editor produced. The v1.9.1.2 one is 176,128 bytes / 2025-09-11.

GRF header key field (00 01 02 ... 0D) is identical between my encrypted GRF and both working servers' GRFs.

Key derivation is the same on both paths — GrfHolder.SetEncryptionKey(...) and EncryptorDialog._getKeyFromFile() both go through the same pair of functions with the same password, so I don't think there's a key mismatch.

On the "Resources weren't found in your client" error

On some of my builds Generate files throws this. On the 2025-06-04 client it does not throw — the check at EncryptorDialog.xaml.cs passes, since the renamed uncompress string is present afterwards. So that error isn't the cause here; the failure happens with a client that passes the check.

Question

Given that the encryption is valid (the editor decrypts it), the export/import names line up, and the same exe+DLL runs fine with a plain GRF — is there something else the client needs in order to actually route reads through cps.dll? Some additional client-side patch, or a client-version constraint I'm missing?

Happy to provide the executables, the generated DLL or a small encrypted GRF sample if that helps reproduce.

[murilotaino]

One more data point that I think narrows this down further.

I have two other clients locally that do run fully encrypted GRFs (both with Gepard, one on a 2018 client, one on 2024-12-18). Their cps.dll files are the same build as mine — 175,616 bytes, PE timestamp 2024-10-31 12:54.

Since they're the same binary, I diffed them against each other. Only two regions differ:

offset	size	content
163198	10 bytes	the renamed export (nsjvruqnah / kafraverse / mine giedaoodvr)
169121	271 bytes	key material

My generated DLL has both regions populated with its own values — nothing zeroed, nothing missing. So structurally the generated DLL looks equivalent to the two that work.

So at this point everything I can verify statically checks out:

• encryption is valid — GRF Editor decrypts and previews the files with the password
• the DLL is structurally complete and matches working ones from the same build
• imports/exports line up on both sides (compress + the renamed uncompress)
• the same exe + DLL runs fine with a plain GRF

The only thing left is the runtime behaviour inside the client, which I can't inspect. Any idea what else could keep the client from routing reads through the DLL?

[murilotaino]

Update: I found (and fixed) a genuine misconfiguration on my side, but it turned out not to be the cause — posting it because anyone using WARP will hit the same thing.

WARP's Inputs/DLLSpec.yml ships with:

- Name: cps.dll
  Funcs:
    - Name: "compress"
    - Ordinal: 1

But in the generated DLL the ordinals are:

ordinal 1 = compress
ordinal 2 = <renamed uncompress>

So the client ends up importing compress twice and never imports the decompression/decryption function at all. I changed it to Ordinal: 2, rebuilt, and confirmed the import table now reads ['compress', 'Ordinal 2'] against a DLL whose ordinal 2 is the renamed export.

It still fails the same way. So that was a real bug, just not this one.

For reference, a working client I have locally imports it as two separate import descriptors, both by name:

cps.dll -> ['compress']
cps.dll -> ['nsjvruqnah']

Also worth noting: the crash log shows the fault in UIWindowMgr.cpp:3824 with eax = 0x55555dd6 — an uninitialized-memory pattern, i.e. the client got garbage back instead of the decoded sprite and then dereferenced it. Consistent with the decryption simply never happening rather than happening incorrectly.

One more observation that may help narrow it down: when the generated DLL doesn't match the executable, the DLL clearly reports it (GRF Encryption - File not found / The client executable is invalid. Error code: 0x02). In the failing runs above that dialog does not appear — so the DLL accepts the executable, it just never decrypts.

[murilotaino]

Found it — the import is never actually called.

I compared cross-references to the IAT slots between my client and a working one (a server that runs fully encrypted GRFs).

Working client:

cps.dll  compress      slot 0x008db84c   3 refs  (2x call dword ptr [addr], 1x jmp)
cps.dll  nsjvruqnah    slot 0x008db850   6 refs  (5x call dword ptr [addr], 1x jmp)

My client:

cps.dll  compress      slot 0x01f73032   0 refs
cps.dll  Ordinal 2     slot 0x01f73036   0 refs

Zero references. The functions are imported, resolved by the loader, and never called by anything.

The reason is structural. In the working client the FirstThunk for cps.dll is at RVA 0x8db84c, which lands inside the original code section — the existing GRF reader already calls through those slots. In mine the FirstThunk is at RVA 0x1f73032, inside the .xdiff section that WARP appends at the end of the image. The original client code has no knowledge of that section, so it keeps using its own decompression path.

That accounts for every symptom:

• the DLL loads and validates the executable — the loader resolves the imports normally
• a plain GRF works — the untouched zlib path handles it
• an encrypted GRF fails — the ciphertext goes straight to the parser, which returns garbage (eax = 0x5555…) and then crashes in UIWindowMgr.cpp:3824
• every client build and tool version failed identically — none of them ever had a call site

So the missing piece isn't the key, the GRF, or the DLL: it's the call site wiring the GRF reader to the decryption export.

That's presumably what WARP's RestoreCpsDll patch is meant to create. On my clients it does apply (the output differs from a control build without it), but the resulting executable crashes at startup within ~5 seconds (BEX / 0xc0000005), even with a completely plain GRF — so whatever it patches, it isn't landing correctly on these builds.

Tested on 2024-12-18, 2025-03-19 and 2025-06-04 Ragexe, same result on all three.

Is there a supported way to get that call site in place on current clients — or is RestoreCpsDll simply the wrong/outdated approach for them?