Copy Link
Add to Bookmark
Report

Tomb Raider

Cracking the Mystique Patch for Tombraider.

DrWatson's profile picture
Published in 
Hacking Tutorials
 · 25 Aug 2018
Tomb Raider
Pin it

Date: 11 October 1997
Target: Matrox Mystique patch for tombraider.
Where: On the patches page at http://www.matrox.com/mga/
Tools Used:
Softice 3.2 (Get it! The video card support is 100 times better!)
Wdasm 8.9 (Find the registered version on the web!)
FileMonitor


Well, a friend of mine just got Tombraider on warez, but then needed the Matrox Mystique video patch cracking for his video card. I thought this would be a perfect opportunity for me to try some DOS4GW cracking, and to see what a cd-rom protection was like.


First of all, I ran FileMon, whilst I ran Tombraider.
I noticed that it searched all drives (from a to z) for "\data\title.phd", obviously a CD-file.
It couldn't find it, so I used subst

 
eg: subst j: d:\games\tomb


Now I ran it again, and it succesfully found title.phd on the faked j drive
Then the target tries creating a file in the root directory of the drive where it found the file on (in my case j:).

I then tried to use fakecd, but for some reason this program allows file writes (or atleast it did on my system...) so it did not behave like a read-only media (a CD-Rom) would have done...

Ok, I now had a theory about what to crack, but no idea about how to crack it (I have never cracked a DOS4GW program before).

I wasn't sure if Dos files could be disassembled using Wdasm, but I gave it a try and it seemed to work.
In the dead listing of tomb.exe, there are only 3 interrupt 21's that have ah=3d (open file)
I wrote down the op codes for these instructions, and then loaded tombraider once more.

When the initial DOS4GW screen appeared, I pressed ctrl D, and then did a search for the byte-codes of my three interrupts.

Once found, I then set a bpx on them, and let the program run once more.

Only one of them ever seems to be executed, and that is the one at 82E1BAAD
Ok, So when it searches for its CD-file "title.phd" , this file must be found successfully, yet when it searches for the random file, this must NOT be found, and yet they both use the same code?
What's happening here?

Obviously the code at 82E1BAAD returns a value, and the value is checked further up the code tree.

So both times (when it expects a "good" open file, and when it expects a "bad" open file), I repeatedly press F12, to go back up the call tree, and wrote down the values as I went...

Good. Expects file to be opened successfully.
82E1BAAD, is called by
82E0FFFA, is called by
82E10079, is called by
82E1008E, is called by
82DE35A4

Bad. Expects file to NOT be opened successfully
82E1BAAD, is called by
8EE0FFFA, is called by
82E10079, is called by
82E1008E, is called by
82DE3624

Ahh, we have found some code that differ!

The code at 82DE35A4 and the code at 82DE3624 look like this...

 
call 82E1008E
test eax,eax
jz ....


Ok, this means that after each call, it checks for eax=FALSE. Eax will be = 0 when the file could NOT be created or opened successfully. 5which happens when you write on a CD-Rom, a very simple way to check if the media is a CD, btw).

We want to fool the program into thinking that the file was not created, like it would have happened on a "REAL" CD.

Thus we can just change

 
7410 jz ...


to

 
EB10 jmp ...


But if we were to do that, every time we ran tombraider, we would have a new random "checkCD" file added by our target to the tomb directory, not very elegant...
Why?
Because we don't allow the program to delete the file afterwards!

Here is the code that checks for the valid file:

 
624: E85DCA0200 CALL 086 //Try to Open file
629: 85C0 TEST EAX,EAX //File Opened successfully?
62B: 7410 JZ 63D

//This is only called when cd-rom is "writable"
//This happens when eax=1

62D: E826CD0200 CALL 358 < Maybe delete file?
632: 89D8 MOV EAX, EBX
634: E8CFD00200 CALL 708 < Maybe close file handle?
639: 31C0 XOR EAX, EAX < Set bad flag
63B: EB05 JMP 642 < Jump to end

//This is jumped to when the file could not be written to
//This happens when eax=0
63D: B801000000 MOV EAX, 1 < Set "good" flag
642: 83C410 ADD ESP, 10
645: 5A POP EDX
646: 5B POP EBX
647: C3 RET


So, what do the calls at 62d and 634 do? Who cares? They are evidently used to clean up the file, so we may as well use them ourselves.
The easiest way to change this is to nop out the jmp at 63b, so that it will fall through to 63D, and always set our good flag.

Therefore change

 
63B: EB05 JMP 642


to

 
63B: 31C0 XOR EAX, EAX ;ax is zero! Who cares?
;will be set true in the
;next instruction!

And it works!
Is this all? I wasn't sure, but it anyway no longer said "please insert tomb raider cd" at the start of the program, and there wasn't any files left in the tomb directory either... clean crack!

I couldn't test it any further (I don't have a matrox video card myself), but when I took it round to my friends house it seemed to work. If I later find it doesn't or anything, I'll update this tutorial....

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT