Cracking the Mystique Patch for Tombraider
(the write random file trick)

by +Alt-F4


(17 October 1997, slightly edited by fravia+)

---

Courtesy of fravia's page of reverse engineering

Well, an interesting short essay... and we are awaiting more essays on this section... few have arrived... many had been promised: where are they?

Cracking the Mystique Patch for Tombraider.

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....

+Alt-F4

Back to Project 4 ("CD-Rom protections")

---

homepage links anonymity +ORC students' essays academy database
tools cocktails antismut CGI-scripts search_forms mail_fravia
Is reverse engineering legal?