Cheat Engine

[3x3y3z3t]

I found some cheat tables for the game Rec*ttear on this forum, but I want more. So I load the game into OllyDBG and modify some of the game's mechanic (raise the level cap, write a new EXP calculating formula).

I can do the above with the crack version of the game I found on the Internet, v1.105.

But for some reason, I can't do the same with the Steam version.
Exactly, I can still modify the game's code (in ASM) with the helping of the cheat table (to find address), but can't load the game into OllyDBG.
I've test the .exe with PEiD but scan shows nothing, so I think the .exe is not packed. All I can think is the problem is caused by the Steam Overlay UI.

So I post this here to ask for a way to "pass" the Stram Overlay UI when loading the .exe to OllyDBG.
Thanks.

[STN]

It is not Steam Overlay. What is the error you are getting exactly in Olly ?. Are you attaching to the game or loading it from Olly ?

There could be antidebug in the game (steamCEG at best enabled probably by default) that is removed by the crack. If you are using olly1, use some ant-antidebug plugins to bypass the checks.

Why not use CE ? You can simply use the VEH debugger to debug most games even with steam CEG and others.

[atom0s]

The game may be protected using Steam's personal packer / DRM (SteamStub).

You can check for it easily by opening the exe inside of any PE editor and check the sections of the file. If there is a .bind section then it is packed/protected with Steams DRM.

[3x3y3z3t]

[STN]

EDIT: I apologize for trying to help without providing intimate knowledge of steamstub working even though the OP is simply confused why CE shows different assembly than Olly. Sorry

[atom0s]

The SteamStub / DRM offers applications the ability to set personal options with the SteamDRMP.dll module that is loaded into the process at the time of launch and the .bind section is being unpacked and handled.

These options include a number of things, one of them being anti-debugging. It is entirely game specific on what can / cannot be opened in Olly (even after the game has loaded and attaching) as the flags are entirely up to the game developers to set.

A basic rundown of what happens with SteamStub would be:

1. Once the file is loaded into memory the new EP is executed, which resides in the .bind section.
   
2. The .bind entry point stub then decrypts the header block for the packer to understand how to continue unpacking the file.
   
   • Given that there are a few variants of the SteamStub, the header block contains different information between each version.
     
   • In pretty much all of the variants, the header block contains things such as:
     • Offsets to various basic API such as: LoadLibraryA/W, GetModuleHandleA/W, GetProcAddress
       
     • .bind section information (size, offset, crc)
       
     • .text section information (original raw size, etc.)
       
     • Encryption keys to decode various parts of the DRM. (.text section, SteamDRMP module, etc.)
       
     • Original entry point that was overwritten in the file.
       
     • And more depending on the variant.
       
   
   
3. The payload is then decrypted. (SteamDRMP.dll)
   
4. Depending on the variant, the SteamDRMP module is then loaded via manual mapping. This controls different things depending on the variant. (See below for more info on the SteamDRMP module.)
   
   • In SteamStub variant 2, the SteamDRMP module handles unpacking the .text section internally.
     
   • In SteamStub variant 3, the SteamDRMP module is mostly just for anti-debugging and some other minor things.
   
   
5. At this point the .text section is rebuilt based on the information either taken from the stub header, or that compiled into the SteamDRMP file itself.
   
6. The file header is then rebuilt with the unpacked section information.
   
7. The original entry point is restored then invoked.
   

SteamDRMP.dll
This module is responsible for different things depending on the variant of SteamStub that is being used.

In SteamStub variant 3, the SteamDRMP.dll module is mostly used as an anti-debugger module that handles a few things.

• When loaded and the main export is invoked it ensure that the header block has been decrypted properly.
  
• Next it checks for any debugger using a few methods, this only happens if the game has set the debuffer flags in the header blocks flags section.
  
• Another thing done here is that the current thread is hidden from debuggers using NtSetInformationThread.
  
• Next the current tick count is stored for anti-debugging purposes.
  
• Next it checks if the DOS stub is set and valid, again only if the flag is set in the stub header blocks flag section.
  
• Next it attempts to ensure that Steam is running and can run the current app being loaded.
  
• Next the text section is unpacked, if the encryption flag is set in the current files flag section.
  
• Last, the tick count is compared to the current tick count. (Only if the debug check flag is set.) This is checked to see if the last few steps took longer then 10 seconds to run, if yes then the DRM fails to load with the assumption that it is being debugged.

In variant 2 of the SteamDRMP module, things are a bit different.

• When loaded, it immediately checks for a local debugger. (IsDebuggerPresent)
  
• Next, it hides the current thread from the debugger.
  
• Next, it stores the current tick count for later debugger check usage.
  
• Next, it ensures the decryption of the header is valid.
  
• Next, it populates a local collection of variables for usage later in the call, this info includes stuff such as: flags, app id for Steam, the OEP, the .text section info (VA/size)
  
• Afterward are various calls and checks against the flags for decryption, unpacking, etc. of the .text section
  
• Some Steam API calls are done next as well to ensure the game is valid/runnable. (See the OpenSteamworks project for more info on what happens at this point: https://github.com/SteamRE/open-steamworks -- hint: it uses the following interface at this point SteamUtils004)
  
• Lastly the tick count is checked and if it ran more then 10 seconds it is considered to be debugged.

Anyway, once unpacked the file can still have anti-debugging methods in place to prevent you from attaching a debugger, setting breakpoints, or single stepping while debugging depending on how it is setup. It is entirely based on how the game is protected with the DRM and which flags are set. Not all games protected with the variants of SteamStub use the same flags so you may run into one game that is protected but can be debugged no problem, but another will die instantly when you attach a debugger.

This information is based on my personal analysis of various games that make use of the SteamStub DRM. I have written a full unpacker for 3 variants of the SteamStub DRM. Some parts are more brief then others in this since in the unpacking process, not everything from the DRMs stub(s) are needed to be recreated / emulated so they are skipped here or not given much detail.

Also keep in mind there is another known variant of the SteamStub, but the protection on that version is very weak and not worth explaining here. It's more of like.. UPX with some minor additions.

[3x3y3z3t]

Since I'm quite new with ASM language and Disassembly thing, trying to unpack the executable file is a real pain.
But since Olly is not being killed instantly, can I try to hide my Olly instead? Will it work?

[atom0s]