Cheat Engine

[Csimbi]

Hi all,
I am having a hard time testing AA scripts I am building for Risen 2: Dark Waters (Steam).

None of the debuggers work, the only one that seems to work is DBVM.
Setting any breakpoint with any other debugger causes a crash when resuming the game. Tried x32debug, same result there.

Anyhow, I got to a point with DBVM where I have a working AA script that allows player to change the jump speed.
The script I built works while DBVM has active cloaking on the right section of the code.
If I disable the cloaking, there is no instant crash, it works until the code is supposed to run (when the player tries jumping - hits the jump key).

I set a watch to see what's happening and I found some weird code that reads the jump code and does some XORing and bit shifts. These operations are way too long to trace; I did a trace with 10k instructions and it was still not finished.

I am fine with playing the game with DVBM cloaking active, but I would like to be able to share the AA scripts with others to make the game more run, and I expect regular users will not be that tech-savvy.

I am seeking advise on what to search for - what's the right term to get good search hits related to this type of validation mechanism and what techniques are recommended to work around them.

This is an old game by today's standards, and it's a single player game so I was very surprised to find such anti-fun measures included. I can see it's taking up a lot of CPU cycles (10k+ instructions to check integrity of a single call that's ~1k bytes altogether!), which explains why it performed so slowly on older hardware and it might be reason why people has had so many crashes in the past. My preference would be disabling this anti-fun mechanism entirely, if possible.

I am hoping someone will throw me a life vest.

Thank you!

PS.
Anyone feeling adventurous should set a breakpoint at risen2.exe+56D740. This should be mov edx,[edi], this is the code that reads the byte code (of the hook I set) when I hit jump.
Start a new game, set a breakpoint here with DBVM, and hit the jump key.

[Dark Byte]

find what accesses the code, and find out what accesses the code that accesses the code (in case there's multiple checks) and then adjust it to read an unmodified copy of the exe

Also, try the stealthedit plugin by virusposter (latest version should still work with the latest ce version)

[Csimbi]

Thank you for the tip.
It did not occur to me there might be code checking the code checking the code

I found StealthEdit 2.4.2 on FRF, I assume that is the latest.

Thank you!

[Dark Byte]

Don't forget to force enable DEP if the target is 32-bit

[Csimbi]

Enabling DEP for all did the trick to launch the Stealthedit plugin.
It asks me how many pages before and after; I enter 10, that should be plenty.
I enable my script - at this point I see nothing changing in the Memory Viewer.
Then, I go back to the game and hit jump.
The game hangs the same way it does without Stealthedit.
Seems I need to find an alternative to Stealthedit.

Thank you for the suggestion though!

[Dark Byte]

try just 1

[Csimbi]

Same result (that is, hang when trying to jump)

I found an interesting mod called Risen 2 Remaster, it's on Nexusmods:
https://www.nexusmods.com/risen2/mods/5

This mod, when you start the game using the launcher, creates a DLL file that is night identical to Risen2.exe, it's about 0.5Mb larger.
This DLL then become the game - Risen2.exe is not loaded.
The DLL can be fully debugged using VEH, for example and code can be injected as well, using the same AOB signatures as in the EXE and there's no crash.
So, it's clearly doable as someone has already done this. The author has been banned on nexus, so cannot be reached.

Can someone help me figure out what the author of this mod disabled in that DLL? Since the files are different a byte-by-byte is out of the question.

I wonder if there's a way to dump assembly code somehow from both and compare that.

Any ideas?

[SunBeam]

The game uses Steam CEG protection. You can tell from the exe showing up a "PUSH 8000DEAD" at OEP. The first time you start the game, it will run the usual DX installer and download several sections into the exe, patching it basically. If you check the exe after the first game run, you will see it looks different, repaired, from the original one. Furthermore, CEG will leave certain blocks of code to be repaired only when the game is run.

Aside from this, you will face having to defeat exception handlers which are set in place to catch the most common breakpoints, from INT 3s to INT 2Ds (software and hardware). In which case the traps are freezing main game thread, described as you said it.

As far as the "mod" goes, that launcher dumps "Egl_Risen2.dll" which is an actual fixed game executable. If you rename it back to Risen2.exe (after backing up the original), you'll see the game runs just fine. Checking the PE header of the Steam original Risen2.exe we see that the file is dated 5-May-2012 with a compiler-stamp of 0x4FA54C06. Looking at the renamed dll to exe, we see that the compiler-stamp is 0x52CE7C7D, from 9-Jan-2014. Either a manually rebuilt exe.. or just a clean one from some leak So why not use that exe directly instead of bothering with CEG in current one?

Best regards,
Sun

P.S.: I went out of my way to check the GOG build and lo and behold...



I have a super bad opinion about Nexus and this pretty much confirms it. The "mod" is nothing but a wrapper loader that dumps the GOG exe as a dll to game folder and runs it instead of the Steam exe T_T. And just to make it more "proprietary" that "mod" author changed the icon and some other resources, so that the file looks "original" Pathetic..........

[Csimbi]

Thank you for the insights, much appreciated!

[TomDizzle]

Can I pm you Mr. Sunbeam?