Colin McRae Rally 04

Game Specs

Name	Colin McRae Rally 04
Release-Date	04/2004
Redump ID	37749
Protection	SecuROM v5.03.04
Cracked under	Win 10
Tested under	Win 10
Scene-Crack by	DEVIANCE

Needed Tools:

• x32dbg
• The fixed Scylla version from last article
• The original Game-CD of course ;)

Disclaimer

• The games are cracked for educational purpose and to regain compatibility with modern systems
• The games are more than 20 years old and can be found freely on the net via e.g. archive.org
• No parts of the game are distributed

How to Crack

Not much has changed OEP-wise in this version of SecuROM. We can still find the OEP in no time via using e.g. GetCommandLineA as ‘anchor’ and then having a look around. I was able to identify it to be located at 0x00542829. Also using the script from RollerCoaster Tycoon 2 to break at the OEP still works fine. But when it comes to fixing the intermodular calls, only a subset of the calls is restored. Upon analyzing the problem one can realize quite quick that there is now more than one SecuROM stub:

The thunks for these calls are all within the .bgxb section, but the stubs itself are spread all over the place. In order to fix them, let’s modify the script from the previous articles to perform the following algorithm:

• Search for all CALLs having a thunk in the .bgxb section
• Find the next CALL after the OEP
• Repair them in alternating fashion (see RCT2 article for that)

This worked for a handfull of imports then the script stopped working. Upon closer inspection I realized that there are now 4 different types of stubs that need to be handled a bit differently:

Type 1

This is the one we know already. It ends in a JMP EAX and we can simply read the address from EAX.

Type 2

This one pops the value of EBP into EAX and then performs a XCHG EBP, EAX. We can get the address via single-stepping until we land on a RET.

Type 3

This is nearly the same as Type 1 only with an additional level of indirection.

Type 4

In this type the values on the stack are re-organized thats why our breakpoint triggers early. We just re-enable the breakpoint, but this time on the address where EDI points to, then we let the stub continue and land on this bit:

Just a simple return, so the real address of the remote proc is on the stack and we can simply grab it.

So far, so good. Nothing special, just a few extra lines for our script. But when I tried to run the dumped game.exe it wouldn’t start. Upon closer inspection I realized that some of the indirect CALLS (FF 15) had been replaced by relative CALLS (E8) to a stub within the .geso section. The additional byte was replaced with a NOP or other 1-byte instructions that have no effect in the context of the call:

So we need to add another few lines to our script to search for relative CALLS that call an address in the SecuROM section (.geso). Unfortunately there are also some calls where the stuffed byte is appended to the call:

For this case I added a check to see if the preceding instruction is a PUSH or POP of some sort since they can not be ignored and thus must be an original instruction. To make things more complicated there is also a version with the stuffed byte after the call, but without a preceeding push/pop:

For this case, I checked if on one side of the call there is an instruction of length 1 and on the other there isn’t which was actually sufficient.

You can find my script here. It’s kind of a mess and some stuff is probably redundant, but well, it gets the job done ;)

So, as we see, SecuROM v5 is actually not that far from v4 and not super complicated to fix.

---