Tomb Raider III
Understanding CD Protections Systems
Introduction
Greetings Reversers',
At the time of this essay their are currently around half-a-dozen or so commercial protection systems for PC CD games/utilities, they being:-
SecuROM
SafeDisc
SafeCast
LaserLock
ProtectCD
CD-Cops
DiscGuard
The Copy-Protected CD & The Bongle
In addition, there are a number of methods which can also be used to protect a CD, they being:-
OverSize/OverBurn the CD
Illegal TOC
Dummy Files
Physical Errors.
Of course, some CD's have a combination of the above which then complicates matters even worse when you try and backup your CD's as I do.
Tomb Raider III is considered as having a 'weak' protection system even though it uses a number of distinct protections systems/methods to prevent the non reverser from making a backup of their game CD.
About this protection system
Tomb Raider III employs the following CD Protection systems:-
Dummy Files
Illegal TOC
CD Checks
You may have come across references to 'Dummy Files' but may still be unsure to what they mean and how they work, therefore allow me to explain what they are.
Dummy Files are, in basic terms, simply a number of files (usually there are five of these on a CD) that, when you check their sizes in File Manager show that they are around 600+ megabytes in size!!. In fact, you will usually see four of these files with this huge file size while the other is around 116 bytes and is unreadable.
Currently, these Dummy Files are very easy to spot, they ALL have the file extension of .AFP, and will use different file names on different CD games but all end with the .AFP file extension.
In general, these large dummy files are checked in the following manner.
The program will often 'read' a number of bytes into these dummy files and look for a specific byte to make sure they are intact. Often the program will 'read' thousands or even millions of bytes into these files just to read a single number from them. Defeating this kind of check is -fairly- easy, all you would have to do is to delete these dummy files and replace them with a 1 byte text file using the original names of the dummy files. Then, you would locate where in the program it 'read's these dummy files and where it pushes the offset value for the number of bytes to -read- you would replace this value with '0', so that it reads the first byte in our dummy text files. You would also need to check what value it's going to look for and put this value into your 1 byte text file. This would have to be repeated within the program for each of the dummy files that it checks for.
On the Tomb Raider III CD the following files are the dummy ones:-
File Name Comments
Awcs.afp File size reported as 680 megabytes
Config.afp File size reported as 116 bytes
Neir.afp File size reported as 681 megabytes
Oket.afp File size reported as 680 megabytes
Vfaw.afp File size reported as 681 megabytes
Of course standard CD's cannot hold more than 650 megabytes of data so these reported file sizes are there only to confuse any program you use to copy them. In reality, these over-large files have been deliberately corrupted and it's data will be pointing to other parts of the CD. CD Writers, when they come across these types of files will often refuse to copy these files because they are not recognized as being part of the CD ISO standards that defines how files are to be stored on CD's.
In cases such as this, these files are know to use Illegal Table Of Contents (T.O.C) which only a few CD Copiers can handle. The two most talked about CD Copiers around are Nero and CDR-WIN which are able to ignore illegal TOC's. Under the CD ISO standards, all CD's are suppose to use a recognized format or structure that defines how files are to be stored on the CD. The Table Of Contents on CD's is very much like the FAT16 / FAT32 format used on our hard disks, which, if changed or damaged, will in most cases, prevent our hard disk from being recoqnised by our software programs that are not programed to accept any other type of directory system.
Have you noticed yet that the protection system Dummy Files are also related to Illegal (TOC's). This is often the case, one protection method is usually directly or indirectly related to other protection systems/methods. Solving them will often require you to go about backing up your software in some interesting ways, which, may at first look rather complicated for the newbie reverser to master.
For many newbies, the common question they all ask is "What is the thought process that goes into reversing a protection system?".
Well, lets take this question a little higher, here's how I reversed this CD Protection right from scratch. From knowing absolutely nothing about it to solving it so that I can back it up.
Yes, I'm aware that by writing this tutorial I'm in effect showing you how to pirate this and other games and if that's your intention then your a lamer. Backing up our legal software for our personal use is considered paramount because of the expense of the original software.
The Essay
After purchasing Tomb Raider III I had no idea what kind of protection system it used that would prevent me from backing it up. First thing I did was to open up the File Manager and have a look at the files and folders stored on the CD.
Because I have read a number of references on the web related to CD Protections systems I know that many of these can be recoqnised in a number of ways..
First, I looked at the CD itself to see if I could see a picture on the inside ring that would identify that this CD was protected by SecuROM. No picture was found. SecuROM protected CD's have an electronic marking printed on the CD surface which assigns a unique ID-Code to each CD. There are currently 4 versions of SecureRom, known as: SecuROM R1, SecuROM R2, SecuROM R3, SecuROM R4.
Next, I looked for a hidden directory on the CD called "LaserLock", which, if existed would tell me that it was protected by LaserLock. In this case no such directory existed. LaserLock uses a combination of encryption software and unique laser marking on the CD surface made during the special LaserLock mastering procedure, in order to make copying practically impossible. Every CD-ROM application has a unique locking parameter that provides a complete protection against illegal re-mastering and reproduction. LaserLock offers excellent protection for every application as each application package is characterized by a unique encryption parameter that is specified during LaserLocking procedure.
Next, while still looking at the files and directories of the CD I looked for the following files: 00000001.TMP, CLCD16.DLL, CLCD32.DLL and most important CLOKSPL.EXE.. If any or all of these files were found then I would know that this CD was protected by SafeDisc.None were not found.
Next, I checked the CD for any of the following files: CMS16.DLL, CMS_95.DLL or CMS_NT.DLL. None were found. However, had I found any of these files then I would know that this CD was protected by SecuROM.SecuROM is a patented CD-ROM copy protection technology that identifies a ‘genuine’ CD-ROM by a special authentication mechanism. During Sony DADC’s mastering process an electronic fingerprint is applied onto the glass master which assigns a unique number to each CD-ROM title.
SafeCast and CD-Copswere not checked for because little is known about them and or have no visible means to identify them or, as in the case of ProtectCDthey are not know to be used in any commercial program at this time.
This now leaves Illegal TOC's and Dummy Files..
Well what do you know, under the File Manager I see five files all ending with .AFP. Checking their reported file sizes I see four of them are well over 680 megabytes. Now if you check the properties for this CD while still in the File Manager you will see that the total size of this CD is 690 megabytes. Too big to backup on a standard CD. If, like me you have a CD Writer that doesn't have the Overburn option or, is not able to use 80 minute CD's then we may have a problem..
Okay, now if you have Nero installed then if you select your CD Drive under File Manager and right click on it you will see the menu option Properties. Select this and then click on the Volumes menu tab. You won't see the Volumes tab unless you have Nero installed. Right, can you see that we have:-
I. An ISO /Juliet track that is 534 megabytes in size.
II. Two Audio tracks
III A Second ISO / Juliet track that is ALSO 534 megabytes in size. Its this extra data track that fools many CD Copiers into giving up trying to copy this CD.
If your CD Writer is unable to 'OverBurn' CD's then trying to do a straight copy of this CD will result in an error message from Nero stating that this CD is too big to fit onto a standard CD. CDRWIN may also state the same although I didn't test this.
Now the fun begins...
Audio tracks on game CD's are 9 times out of ten optional. By optional I mean they are not always checked for when the game runs and that the game can run happily without them. At this point in my quest to backup this game I cannot be sure of this and will only know this for certain once I've done a test backup.
TIP. Everyone making backups should already know this. When making a test backup ALWAYS use a CD-RW first. That way, if you make a mistake somewhere and the game still does not work as you expect it to then you don't end up with a coaster, since your CD-RW disk can be re-written again, unlike a CD-R.
Okay, I've decided to leave out the two audio tracks and now left with two data tracks. Which one do I choose?. The answer is the First data track, since it's this first track that gets read by all CD Drives. The second data track is there to fool your copier software.
Right, we are now left with one data track, but how do we copy it?.. We could copy the whole CD but as already mentioned, my CD Writer can't handle CD's with more than 650 megabytes. The answer is we use Nero's ability to copy Selected Tracks.
This is how to do this under Nero..
Start up Nero and go into the CD-Recorder menu option. Select 'Choose Recorder' and make sure that Nero is told to use the 'Image Recorder'. This is important as this tells Nero to save the resulting track image onto your hard disk.
Next, go back into the menu option CD-Recorder and this time select the option Save Tracks. Nero should now bring up a new screen showing you all the tracks on our Tomb Raider III CD. You need to select the first track, leave all the others alone. Now fill in the data boxes telling Nero what filename to use and where to store this track image. Make sure the directory you choose already exists, else Nero won't accept this. Once you have done this, click on the Save button. Nero should now begin copying the first data track on our CD. Time for a cuppa I believe..:)
Once copying has been completed, there should have been no errors at this copying stage. Go back into the menu option CD-Recorder and again select 'Choose Recorder' and this time select your CD-Writer, which ever it is.
We should now have a 534 megabyte image file on our hard disk and now it's time to burn it on our CD-RW disk. Don't use a standard CD-R at this point, if we make a mistake at any point then we won't end up with an expensive coaster or two.
From Nero's File menu select 'Burn Image' and locate where you have stored your first Game Track image. Now follow the prompts and burn this image file onto our CD-RW disk.
Once completed, close down Nero and try and run Tomb Raider III. (You should have already installed the game before all this copying took place).
Opps, the game as expected has thrown up a message box telling us it needs the original game CD. Lets fix this bug..:)
Before we go any further it's time now to think like a reverser and analyse what we've done to our backup and what differences there might be that could trigger the game into not accepting our backup copy.. Right, we know we have all the dummy .AFP files intact so no problem there. We've left out two audio tracks that -might- be checked for but I doubt this. We have also left out a second, data track that is -not- used, it's there to help prevent the disk being copied, but it -could- still be checked?. They are the obvious things we notice, however, there are others, such as. Our backup CD is now 534 megabytes in size compared to the original of 690 megabytes, the program perhaps checks to see if there is 690 megabytes of data?, might use a CRC checksum?.
If you checked the game's directory you will see that Tomb Raider III installs about a two megabytes of files onto your hard disk, they being the 1MB executable file and the rest are made up of a few windows support .DLL files.
At this point some reversers may fire up Softice and begin tracking down where the program checks the CD and where it decides to reject or accept it but for me, I like to see where I'm going and what I'm up against first!.
Fire up W32Dasm and select the file: C:\ Program Files\Core Design\Tomb Raider III\tomb3.exe
If you checked the properties for your shortcut to Tomb Raider III then you will know that this is the file that gets executed, besides, it's the only executed file in this directory..:)
Now what do we look for?.
Lets take a look at the String Data Resources for this file.. Who know's, we might see something of interest to us?.
If we look for the message that the game gives us when it detected that our backup copy was not the original then we find that there are no references to this error message. Hardly surprising, that would have been too easy.. OK, what else can we see..
Well, there are four references to our dummy .AFP files..
"d:\VFAW.AFP"
"d:\NEIR.AFP"
"d:\OKET.AFP"
"d:\AWCS.AFP"
While we're in W32Dasm lets take a look at the four checks to our dummy files, and while we're there lets also make some notes for when we use Softice.
Okay, using the four reference strings (shown above) we can quickly locate where in the program's code they handled our four dummy files. Okay, now click on the String Reference to "d:\VFAW.AFP" and W32Dasm will take us to where in this program this string is referenced from. From here we must scroll up the window until we see where the beginning of this routine starts.
* Referenced by a CALL at Address: :004B2827
;Here's the beginning of four dummy file check routine, which is being called from memory
;address 004B2827. We should now note the following two memory address for when we use Softice.
;1. bpx 004B2827 --> Location of where the Call to the Dummy File checking routine
;2. bpx 0048D140 --> Start of the Dummy File checking routine.
:0048D140 56 push esi
:0048D141 57 push edi
:0048D142 E8F952FFFF call 00482440
:0048D147 85C0 test eax, eax
:0048D149 7521 jne 0048D16C
........
........
........ ;I will skip the rest of this routine for now to bring to your attention
........ ;the last few lines of this routine. While we may not know much about Assembly
........ ;we can at least make some educated (ZEN) guesses just by looking..:)
........
........
The Dummy File checking routine has two possible routes it can take when it has finished checking our four dummy files. We know this because there are two RET instructions that are referenced from within our file checking routine.
Two choices suggest a 'good cracker' and 'bad cracker' decision to me. The 'common' thing with both of these possible exits is it's setting of the AL register with a predetermined value.
The instruction XOR al,al will set the AL register to '0'
The instruction mov al,01 will set the AL register to '1'
The AL register is commonly used as a 'flag' to signal to the rest of the program wether or not a task was completed or not. Think of it as a True or False.
* Referenced by a (C)onditional Jump at Address: 0048D15D(C)
:0048D2C9 32C0 xor al, al ---> Register AL set to '0'
:0048D2CB 5F pop edi
:0048D2CC 5E pop esi
:0048D2CD C3 ret
* Referenced by a (C)onditional Jump at Addresses:
:0048D1CF(C), :0048D21B(C), :0048D267(C), :0048D2AF(C)
:0048D2CE 5F pop edi
:0048D2CF B001 mov al, 01 ---> Register AL set to '1'
:0048D2D1 5E pop esi
:0048D2D2 C3 ret
Okay, now save off your W32Dasm project, this will save us from having to disassemble the executable file again.
It's time to fire up Softice and do some work, this theory stuff is ok but we now need to verify our work and shed some more light on the way this program performs it's CD checks.
Press Ctrl + D to fire up Softice and lets try breaking in on that error message "Tomb Raider III CD?"
Type: bpx messageboxa
Type: X to exit softice.
Now try and run Tomb Raider III.
As you can see, we saw our CD being accessed but Softice failed to break on our error message.. Click the Cancel button to close this error message.
As we learn more and more about CD protection systems we learn that there are a number of API calls the protectionist can use to access the CD Disk.
Here's a few API functions we can use:-
GetDriveType
GetFileAttributesA **
GetFileSize
GetLogicalDrives
GetlogicalDriveStrings
GetLastError **
ReadFile
One of the most commonly used is the GetDriveTypeA api call. This function will return a value that corresponds to what drive types you currently have installed on your computer.
Here are the return values from the GetDriveTypeA API call.
Return Values Comments
0 Drive Cannot Be Determined
1 Root Directory Does Not Exist
2 Drive Is Removable (Zip drives etc)
3 A Fixed Disk (HardDrive)
4 Remote Drive(Network)
5 CD-Rom Drive
6 RamDisk
Right, lets use GetDriveTypeA as our Softice breakpoint. Fire up Softice ( Ctrl & D )
Type: bpx GetDriveTypeA
Type: bd 0 to disable our original messageboxa breakpoint which we now don't need anymore.
Type: x to exit softice
Run Tomb Raider III again.
Softice now breaks at system function: WritePrivateProfileStringA which was triggered by our
Press F11 once. This will tell Softice to continue executing our GetdriveTypeA function and break again once execution returns back to where it was originally called from, which we're hoping is within the Tomb Raider's code.
We're now back in the Tomb Raider III program code.
Okay, now remember those notes we made earlier in W32Dasm?. No?, well ok, I will remind you again. We found in W32Dasm where the four dummy files are handled and we also found where this routine was called from:-
;1. bpx 004B2827 --> Location of where the Call to the Dummy File checking routine
;2. bpx 0048D140 --> Start of the Dummy File checking routine.
So, while still in Softice type: bc * to clear all our previous breakpoints so that they won't interfere with our next set of breakpoints.
Next, lets take a look where the Call to our dummy file routine is located.
Type: u 004b2827
Then type: bpx 004b2827 to set a new breakpoint on this memory location.
Here's what our code section looks like:-
:004B2827 E814A9FDFF call 0048D140 ; Call CD Protection (Dummy File checks)
:004B282C 84C0 test al, al ; Does AL=0 (0=CD is not the original)
:004B282E 0F846A020000 jz 004B2A9E ; Display Error Message "Tomb Raider III CD?"
:004B2834 8B1594ED6C00 mov edx, dword ptr [006CED94]
:004B283A A190ED6C00 mov eax, dword ptr [006CED90]
:004B283F 52 push edx
:004B2840 50 push eax
:004B2841 6898ED6C00 push 006CED98
:004B2846 E8C5C1FDFF call 0048EA10
:004B284B 83C40C add esp, 0000000C
:004B284E C705E8ED6C00B0ED6C00 mov dword ptr [006CEDE8], 006CEDB0
:004B2858 C705E4ED6C0098ED6C00 mov dword ptr [006CEDE4], 006CED98
:004B2862 E8E9A1FDFF call 0048CA50
:004B2867 84C0 test al, al
:004B2869 7411 je 004B287C
Now type: x to exit softice.
Okay, run Tomb Raider III again. Softice now breaks at: 004b2827
If you we're to press F10 twice you will see that the register EAX = FFFFFF00 and that the Zero flag has been 'set' and that if we we're to press the F10 key again once more that Softice will jump to to memory location 004b2a9e where our error message will be displayed.. Since the test al,al instruction is testing the low byte of the EAX register we can type: al? to see the low value of the EAX register. Notice that the AL register has been given the value of 0?.
By all means test this out for yourself, it's the only way you will be able to slowly build up a picture of what is going off around. When you've done, simply re-run the game and you will once again break at memory location 004b2827.
Right press the T key once while softice is waiting on the call 0048D140 instruction. The T command simply tells Softice to (T)race into this function rather than skip over it. This will take Softice to the beginning of our four Dummy Files checking routine. We should now see this code section:-
I recommend that you study this code and try and visualize it's simplicity in it's execution. If I were to convert this routine into plain -English- then it would go something like this:-
Check in turn for the presence of each of our four dummy files. For each check, push onto the stack two numbers, a file offset number and another number that should exist at this file offset.
Use this file offset value to read through the dummy file and read what number is found at this file offset. Is the -read- value the same as the number on the stack?. If so then continue with checking the next dummy file. If not, then CD is NOT an original so zero the AL register using xor al,al. If however, everything checks out ok then set the AL register to 1 using the instruction: mov al, 01
* Referenced by a CALL at Address: :004B2827
:0048D140 56 push esi
:0048D141 57 push edi
:0048D142 E8F952FFFF call 00482440
:0048D147 85C0 test eax, eax
:0048D149 7521 jne 0048D16C ;1st check ok? then jump
:0048D14B A190ED6C00 mov eax, dword ptr [006CED90]
:0048D150 50 push eax
:0048D151 6A66 push 00000066
:0048D153 E838120000 call 0048E390
:0048D158 83C408 add esp, 00000008
:0048D15B 84C0 test al, al
:0048D15D 0F8466010000 je 0048D2C9 ;Bad Cracker jump, so set AL = 0
:0048D163 E8D852FFFF call 00482440
:0048D168 85C0 test eax, eax
:0048D16A 74DF je 0048D14B
:0048D16C A0203F6300 mov al, byte ptr [00633F20] ;-> AL = CD Drive Letter
:0048D171 A2A8EF4C00 mov byte ptr [004CEFA8], al ; Save CD Drive Letter
:0048D176 A2B8EF4C00 mov byte ptr [004CEFB8], al ; " " " "
:0048D17B A2C8EF4C00 mov byte ptr [004CEFC8], al ; " " " "
:0048D180 A2D8EF4C00 mov byte ptr [004CEFD8], al ; " " " "
:0048D185 68D47A4C00 push 004C7AD4 ;->"rb"
:0048D18A 68A8EF4C00 push 004CEFA8 ;->"d:\VFAW.AFP" ;Save Filename on the STACK
:0048D18F E88C8D0200 call 004B5F20 ;Check if file d:\VFAW.AFP exist?
:0048D194 8BF0 mov esi, eax
:0048D196 83C408 add esp, 00000008
:0048D199 85F6 test esi, esi
:0048D19B 7504 jne 0048D1A1 ;File exist? then proceed onto the next check.
:0048D19D 33FF xor edi, edi ;Else, set edi to 0
:0048D19F EB2C jmp 0048D1CD
:0048D1A1 6A00 push 00000000
:0048D1A3 6800508429 push 29845000 ;Save the file offset value 298545000h
:0048D1A8 56 push esi
:0048D1A9 E8F2970200 call 004B69A0 ;Goto the dummy file's offset value
:0048D1AE 83C40C add esp, 0000000C
:0048D1B1 56 push esi
:0048D1B2 E8B9970200 call 004B6970 ;Now read value found at this offset location
:0048D1B7 83C404 add esp, 00000004
:0048D1BA 33C9 xor ecx, ecx
:0048D1BC 83F87B cmp eax, 0000007B ;Does value in file = 7Bh?
:0048D1BF 0F94C1 sete cl
:0048D1C2 56 push esi
:0048D1C3 8BF9 mov edi, ecx
:0048D1C5 E8C6960200 call 004B6890
:0048D1CA 83C404 add esp, 00000004
:0048D1CD 85FF test edi, edi
:0048D1CF 0F85F9000000 jne 0048D2CE
:0048D1D5 68D47A4C00 push 004C7AD4 ;->"rb"
:0048D1DA 68B8EF4C00 push 004CEFB8 ;->"d:\NEIR.AFP" ;Save Filename on the STACK
:0048D1DF E83C8D0200 call 004B5F20 ;Check if file d:\VFAW.AFP exist?
:0048D1E4 8BF0 mov esi, eax
:0048D1E6 83C408 add esp, 00000008
:0048D1E9 85F6 test esi, esi
:0048D1EB 742C je 0048D219 ;File exist? then proceed onto the next check.
:0048D1ED 6A00 push 00000000
:0048D1EF 6800588229 push 29825800 ;Save the file offset value 29825800h
:0048D1F4 56 push esi
:0048D1F5 E8A6970200 call 004B69A0 ;Goto the dummy file's offset value
:0048D1FA 83C40C add esp, 0000000C
:0048D1FD 56 push esi
:0048D1FE E86D970200 call 004B6970 ;Now read value found at this offset location
:0048D203 83C404 add esp, 00000004
:0048D206 33D2 xor edx, edx
:0048D208 83F833 cmp eax, 00000033 ;Does value in file = 33h?
:0048D20B 0F94C2 sete dl
:0048D20E 56 push esi
:0048D20F 8BFA mov edi, edx
:0048D211 E87A960200 call 004B6890
:0048D216 83C404 add esp, 00000004
:0048D219 85FF test edi, edi
:0048D21B 0F85AD000000 jne 0048D2CE
:0048D221 68D47A4C00 push 004C7AD4 ;->"rb"
:0048D226 68C8EF4C00 push 004CEFC8 ;->"d:\OKET.AFP" ;Save Filename on the STACK
:0048D22B E8F08C0200 call 004B5F20 ;Check if file d:\VFAW.AFP exist?
:0048D230 8BF0 mov esi, eax
:0048D232 83C408 add esp, 00000008
:0048D235 85F6 test esi, esi
:0048D237 742C je 0048D265 ;File exist? then proceed onto the next check.
:0048D239 6A00 push 00000000
:0048D23B 6800288429 push 29842800 ;Save the file offset value 29842800h
:0048D240 56 push esi
:0048D241 E85A970200 call 004B69A0 ;Goto the dummy file's offset value
:0048D246 83C40C add esp, 0000000C
:0048D249 56 push esi
:0048D24A E821970200 call 004B6970 ;Now read value found at this offset location
:0048D24F 83C404 add esp, 00000004
:0048D252 33C9 xor ecx, ecx
:0048D254 83F875 cmp eax, 00000075 ;Does value in file = 75h?
:0048D257 0F94C1 sete cl
:0048D25A 56 push esi
:0048D25B 8BF9 mov edi, ecx
:0048D25D E82E960200 call 004B6890
:0048D262 83C404 add esp, 00000004
:0048D265 85FF test edi, edi
:0048D267 7565 jne 0048D2CE
:0048D269 68D47A4C00 push 004C7AD4 ;->"rb"
:0048D26E 68D8EF4C00 push 004CEFD8 ;->"d:\AWCS.AFP" ;Save Filename on the STACK
:0048D273 E8A88C0200 call 004B5F20 ;Check if file d:\VFAW.AFP exist?
:0048D278 8BF0 mov esi, eax
:0048D27A 83C408 add esp, 00000008
:0048D27D 85F6 test esi, esi
:0048D27F 742C je 0048D2AD ;File exist? then proceed onto the next check.
:0048D281 6A00 push 00000000
:0048D283 6800E08129 push 2981E000 ;Save the file offset value 2981E000h
:0048D288 56 push esi
:0048D289 E812970200 call 004B69A0 ;Goto the dummy file's offset value
:0048D28E 83C40C add esp, 0000000C
:0048D291 56 push esi
:0048D292 E8D9960200 call 004B6970 ;Now read value found at this offset location
:0048D297 83C404 add esp, 00000004
:0048D29A 33D2 xor edx, edx
:0048D29C 83F87B cmp eax, 0000007B ;Does value in file = 7Bh?
:0048D29F 0F94C2 sete dl
:0048D2A2 56 push esi
:0048D2A3 8BFA mov edi, edx
:0048D2A5 E8E6950200 call 004B6890
:0048D2AA 83C404 add esp, 00000004
:0048D2AD 85FF test edi, edi
:0048D2AF 751D jne 0048D2CE ;If all checks complete, then jump to
;Good Cracker Exit Point.
:0048D2B1 A190ED6C00 mov eax, dword ptr [006CED90]
:0048D2B6 50 push eax
:0048D2B7 6A66 push 00000066
:0048D2B9 E8D2100000 call 0048E390
:0048D2BE 83C408 add esp, 00000008
:0048D2C1 84C0 test al, al
:0048D2C3 0F85BCFEFFFF jne 0048D185 ;CD Verified so jump and set AL = 1
* Referenced by a (C)onditional Jump at Address: :0048D15D(C) ( Bad Cracker Exit )
:0048D2C9 32C0 xor al, al
:0048D2CB 5F pop edi
:0048D2CC 5E pop esi
:0048D2CD C3 ret
* Referenced by a Jump at Addresses: :0048D1CF(C), :0048D21B(C), :0048D267(C), :0048D2AF(C)
:0048D2CE 5F pop edi
:0048D2CF B001 mov al, 01
:0048D2D1 5E pop esi
:0048D2D2 C3 ret
If you study the above code fragment you will no doubt notice that we -could- nop or change just two conditional jumps at memory location(s):-
1. :0048D15D 0F8466010000 je 0048D2C9 ;Bad Cracker jump, so set AL = 0
2. :0048D2C3 0F85BCFEFFFF jne 0048D185 ;CD Verified so jump and set AL = 1
However, these are pretty obvious locations to change if you are thinking to distribute this game in a pirate form since in which case you would not include the four dummy files, which in any case are not required for the game to run and therefore would be considered as excess baggage. Remember, our backup of this game DOES contain these dummy files so therefore any checks made by the program on our four dummy files WILL prove true and will be accepted by the checking routine. However, in creating a backup of the original game there are other changes to it that we couldn't help but make that, in turn, the protection routine does detect. Okay, enough rambling...
If you follow through the above routine using Softice you will see that we are sent to the 'Bad Cracker' exit point here:-
:0048D2AF 751D jne 0048D2CE ; If all checks complete, then jump to
;Good Cracker Exit Point.
Therefore, all we need to do is to change the conditional jump into an unconditional jump, one that will ALWAYS jump to the Good Cracker Exit point and which will set our AL register to 1.
Our line therefore should read:-
:0048D2AF EB1D jp 0048D2CE ; Always jump to Good Cracker Exit Point.
Notice that all we have done is to change one byte which has changed a conditional jump into an unconditional jump.
Job Done.
Final Notes
A common mistake people -still- keep making when they go about reversing CD Protection systems is to try and crack a heavily protected CD rather than starting from scratch and learning the basic principles of CD Protection systems first. Look kid, unless you are already a highly talented programmer then you just ain't gonna make it and will find the going extremely tough.
To a newbie, no protection system is -easy- to understand, however, looking at this tutorial you will - i hope- see some of the kind of thinking you will need to make in order to progress any further. If you can understand the general outline of this tutorial then you will be able to use it's guidelines on a great many other similar protected CD's. Eidos, the maker of Tomb Raider III uses this CD Protection system on many of their games in one form or another, and while they will use variations of what has been explained in this tutorial you -should- still be able to backup -most- of them simply by following the guidelines I have already explained here.
