Brief Tutorial on CD Access Based Protection Schemes Under Windows
Cracking Virtua Fighter PC

by Aesculapius

(27 August 1997)

---

Courtesy of Fravia's page of reverse engineering

Well, a VERY welcome contribution by our Aesculapius! It was time that somebody took care of the CD-ROM checks, which btw, in general, are NOT very difficult to defeat. I hope that with the help of this addition many +crackers will be stimulated and work on such schemes, bringing ahead this poor and neglected (yet important) project 4!

  

  Brief Tutorial on CD Access Based Protection Schemes Under Windows

                         Cracking Virtua Fighter PC 

                               By Aesculapius



	It should be beneficial for all of us to dedicate some time on CD 

Access protection schemes reviewing, given the fact that ORC+ brilliant 

tutorial on this matter isn't complete yet (check 

http://207.30.50.126/fravia/howto51.htm) and there are few essays (although 

brilliant indeed) on this matter at the +HCU. Writing essays on DOS4GW 

Extender + CD Check would be a great addition for the +HCU.



	Theoretical digression: CD access based protection schemes are 

relatively frequent. These Schemes will basically, prevent the user from 

running the program if the original disk is not inside the CD drive. This 

assures that only one copy of the program runs at a time. In many cases, 

all information in the CD is copied to the hard drive at installation, 

making the presence of the disk in the unit a matter of copyright 

restriction, and being not strictly necessary from the technical point 

of view. In some cases, much of the info required stays in the CD drive, 

making impossible to dispense the original disk. Remember, we're dealing in 

this essay with those cases in which all the program is transferred from the 

disk to the hard drive; other cases would require further discussion.



	These schemes work all in a very similar fashion. The presence of 

certain 'I_didn't_do_it-looking' file inside the CD drive is checked every 

time the application runs. Primitive schemes could simply check for the 

presence of a CD-ROM drive in the system even if it is empty or the disk 

inside is not the right one. As CD-ROM units have become an standard 

peripheral in most basic PC configurations, this gadget has been abandoned 

or combined with the checking of some sort of information inside the CD 

itself.



	Given these facts, defeating CD access schemes could be achieved 

by means of several techniques. You could simply fool the program to believe 

that your hard drive is a CD unit (faking and relocating the right 

information to be read in your hard drive); altering the behavior of the 

program by means of assembly code editing is another possibility; using 

ready_to_use or made_by_yourself CD fakers. We will discuss the second 

possibility as it can produce a higher rate of successes (in my 

personal experience).



	Today's scapegoat is Virtua Fighter PC, a cool looking, third person 

3D fight game by SEGA. I'm not able to give you the trail of this program 

location as the gamez 'panorama' in the internet is a whirlpool of changing 

URL's. However the game is widely available in the shells.



	To achieve this crack you'll need SoftICE 3.x and your 

preferred Hex editor (Psedit 4.4 in my case). Earlier versions of 

SofICE will also work, but some of the SoftICE commands in this essay 

will apply to version 3.x only. (Note: Remember to load all necessary  

SoftICE exports and remove Virtua Fighter Compact Disk from the CD unit 

before proceeding any further). 



	Load the main executable file: vfpc.exe in SoftICE's loader. After 

SoftICE pops up, we should set a dense net (one at a time) of clever 

breakpoints to catch the scheme in _flagrante delictum_. Most frequently 

used Win32 application programming interface are:

	

	GetDriveType

	GetFileAttributesA **

	GetFileSize

	GetLogicalDrives

	GetlogicalDriveStrings

	GetLastError **

	ReadFile

	

	Any of these API's (and some others) can be used in one way or 

another to query the presence and authenticity of a compact disk. In some 

cases, the absence of the disk will force the API to return with an error 

code. Almost all API's (in case of failed procedure) return with an error 

code value of -1, 0xFFFFFFFF, equivalent to NULL. According to this, an 

appropriate breakpoint on GetLastError API could be set.



	In this particular case, SoftICE pops up when marked (**) 

breakpoints in the list are set. Let's take a closer look of the snippet 

where SoftICE pops up after pressing F12 one time:





* CALLs at Addresses:004AC3E6, :004AC42A ; As you can see, there is a double check!

|

:00535317 FF742404                push [esp+04]



* Reference To: KERNEL32.GetFileAttributesA, Ord:00D7h

                                  |

:0053531B FF155064C000            Call dword ptr [00C06450]

:00535321 83F8FF                  cmp eax, FFFFFFFF; Procedure failed? 

:00535324 7516                    jne 0053533C; No, then jump, otherwise

						go on

* Reference To: KERNEL32.GetLastError, Ord:00E1h 

| 

:00535326 FF15D463C000            Call dword ptr [00C063D4] ; Query error

:0053532C 50                      push eax 		    ; in detail

:0053532D E86E72FFFF              call 0052C5A0 

:00535332 83C404                  add esp, 4 

:00535335 B8FFFFFFFF              mov eax, FFFFFFFF ; Procedure failed

:0053533A EB28                    jmp 00535364      ; Retr with EAX=FFFFFFFF



		Some instructions eliminated!



:00535362 33C0                    xor eax, eax ;Procedure Successful

					                           ;Return with EAX=0

		Some instructions eliminated!

	

:00535364 C3                      ret



As you can see, a cleverly set breakpoint landed SoftICE right in the middle 

of the protection scheme check. The first API is checking attributes of 

certain hidden file located in the original compact disk, if the procedure 

fails, it returns with EAX=-1, therefore EAX=FFFFFFFF (Valid compact disk 

absent). If the API succeed, then EAX<>-1 and eventually EAX=0.



	Now let's take a look at the two procedures that CALL these 

API's



			FIRST LOCATION

			--------------

:004AC3CF 689C72B500              push 00B5729C 

:004AC3D4 8D45AC                  lea eax, dword ptr [ebp-54] 

:004AC3D7 50                      push eax 

:004AC3D8 E890C90700              call 00528D6D 

:004AC3DD 83C410                  add esp, 00000010 

:004AC3E0 6A00                    push 00000000 

:004AC3E2 8D45AC                  lea eax, dword ptr [ebp-54] 

:004AC3E5 50                      push eax 

:004AC3E6 E82C8F0800              call 00535317 ; Check File on CD

:004AC3EB 83C408                  add esp, 00000008 

:004AC3EE 85C0                    test eax, eax ; EAX=0 Success

:004AC3F0 0F850C000000            jne 004AC402  ; If Success then Jump

:004AC3F6 33C0                    xor eax, eax  ; Otherwise erase EAX

:004AC3F8 E953000000              jmp 004AC450  ; Beggar off! Display NAG

:004AC3FD E94E000000              jmp 004AC450



			SECOND LOCATION

			---------------



:004AC413 68A472B500              push 00B572A4 

:004AC418 8D45AC                  lea eax, dword ptr [ebp-54] 

:004AC41B 50                      push eax 

:004AC41C E84CC90700              call 00528D6D 

:004AC421 83C410                  add esp, 00000010 

:004AC424 6A00                    push 00000000 

:004AC426 8D45AC                  lea eax, dword ptr [ebp-54] 

:004AC429 50                      push eax 

:004AC42A E8E88E0800              call 00535317 ; Check file again

:004AC42F 83C408                  add esp, 00000008 

:004AC432 85C0                    test eax, eax ; EAX=0 Success

:004AC434 0F850C000000            jne 004AC446  ; If Success jump

:004AC43A 33C0                    xor eax, eax  ; Otherwise erase EAX

:004AC43C E90F000000              jmp 004AC450  ; Beggar off! Display NAG

:004AC441 E90A000000              jmp 004AC450





	Needless to say, both locations are exact mirrors. The code 

is self-explaining. Finally you can unveil the secret file by taking a 

closer look at the GetFileAttributes API parameters. Simply, trace inside 

the API and check all used memory locations. The file to be read is 

X:\VFPC\vfrright.txt, where 'X:' means the drive letter of your CD unit.



	Now that we know all the facts, let's discuss how the protection 

scheme works: 1. There are two mirror locations that CALL the same code 

segment where two API's will check the presence and authenticity of a certain 

file on the compact disk. GetFileAttributesA checks the file, if any error 

occurs, GetLastError API will query detailed information on that error. 

Result from the query sets the Flag in EAX (which follows the standard API 

convention, as EAX=FFFFFFFF is not successful). To crack this 

scheme all we have to do is fake the API result.



	

	Change:



:00535335 B8FFFFFFFF mov eax, FFFFFFFF 



	To:



:00535335 B800000000 mov eax, 00000000 



	When the API fails to check the file, it'll try to return at 

:0053533A with EAX=FFFFFFFF. If we change it to return with EAX=0, both 

mirror locations of the protection scheme are deactivated because they use 

the same common API's to accomplish their job.



	As always, if you have any comment or question, don't hesitate to 

write me.



(Note: I tried to keep the essay as short as possible).





						Aesculapius - August 97

						aesculapius@cryogen.com

						aesculapius.home.ml.org

Back to Project 4
homepage links anonymity +ORC students' essays academy database
tools cocktails antismut CGI-scripts search_forms mail_fravia
Is reverse engineering illegal?