Everlock by Az-Tech: Reversing a Commerical Copy Protection Scheme - Part 1

12 December 1998
courtesy of fravia+'s searchlore
Well, Tomboy's style is very refreshing: precise, fact-oriented, sound. A very good DOS reversing essays that analyses in depth a tough protection $ scheme and therefore carries quite some teachings for advanced protectors and crackers alike. Moreover such 'weird track' - related protection schemes are bound to reappear 'en masse' with the whole DVD bazaar and the more and more diffused CD-ROM copy facilities. I perfomed some minor 'terminological' editing of this part, of course we are all awaiting part II!
Everlock by Az-Tech
Reversing a Commerical
Copy Protection Scheme
Part 1 (Introdution)

by Tomboy
December 7, 1998


Introduction

Everlock copy protection has been around since the mid-1980s.  It is
one of the few survivors from the hey-day of disk based copy
protection.   Its longevity is due to Az-Tech's continuous
improvement with each successive version of Everlock.  This has
managed to keep them one step ahead of the casual cracker.  Although
both DOS and Windows programs can be protected with Everlock, this
paper deals only with the protection of DOS programs.

Part 1 of this series will serve to familiarize you with some of the
features of this copy protection scheme and point out possible
weaknesses that can be exploited.  It should be noted that of late,
Az-Tech has been heavily promoting their hardware based copy
protection, EverKey (i.e. dongle) instead of Everlock.


Recommended Files

While there are no essential files for this study, it will be more
fun if you have:

- Everlock 3.21c upgrade file from www.az-tech.com
- CUP 3.4 from www.suddendischarge.com
- Any Everlock protected program you might have laying around
- The EVREAD.ASM program


Elements of the Protection Scheme

Everlock is composed of some or all of the following elements:

- Specially formatted track on the master (key) or working diskette,
- Install counter on master diskette,
- Hidden files (EV?1.SYS, EV?2.sys) containing install information,
- Deleted file in root directory if hard drive install (FILE0100.CHK),
- Copy protection transfer utility (EVMOVE),
- Wrapped version of copy protected program (loader),
- Liberal use of encryption in all important files

The master diskette and working copies created by Everlock (of
versions 2.x and up) cannot be copied by any known software only
program (e.g. COPYIIPC, COPYRITE...etc.).  However, copies can be
produced using a Deluxe Option Board (sadly discontinued by Central
Point Software cica 1990).  Although Business Neverlock by Copyware
states it can defeat Everlock, Az-Tech disputes this claim.

Many elements of this protection scheme are similar to other
commercial schemes (Prolok, Softguard,..etc.).  The common thread in
all these schemes is the use of a specially formatted track on the
floppy diskette.  The more difficult it is to reproduce this track,
the more secure the protection.


Features of the Master Diskette

Analysis of the special formatted track (track 6, side 0 for my key
diskette) on the Master diskette of an Everlock protected program
shows that all sectors except for the last one are normal and
readable from DOS.  Deeper analysis using the "Track Editor" in the
Deluxe Option Board package shows that the last sector is present,
but has a non-standard size of 8192 bytes (at least according to the
header information) and has an incorrect data CRC.  Obviously, the
sector data field crosses the index position of the floppy diskette
(in the case of 360K and 720K floppies it even crosses the index
position a second time).  Reading this huge sector gives the
protection scheme access to all sector data on the track and the
intersector information as well.  You would think that creating such
a bizarre track would be a major feat requiring special hardware
(like the Deluxe Option Board).  However, the copy protection
tranfer utility (EVMOVE) can create working copies of the key
diskette with the same format using a standard floppy drive and
controller.

If you are curious about the contents of these special sectors, an
assembly language program has been written to read and dump the
sector to a file.  The source code for "EVREAD.ASM" is pasted at the
end of this paper.  You may need to edit the "drive", "track" and
"sector" variables before assembling the file based upon the
characteristics of your particular master diskette.  It is
recommended that the program be run from your hard drive to avoid
writing the output file to your key disk.


How Everlock Works

The wrapped program (actually a loader) employs a combination of
encryption and anti-debugger tricks to keep the cracker away from its
true code.  After the locader decrypts itself in memory, it verifies
that the files EV?1.SYS and EV?2.SYS are present, have a hidden
attribute, and contain valid information.  If the protection is
floppy diskette based, it also verifies the presence of the
specially formatted track and the contents of the 8192 byte sector.
For a hard drive install, the information in the EV??.SYS files is
the primary means to assure a valid authorization.  However, a zero
byte length, deleted file (�ILE0100.CHK) is also placed in the root
directory for good measure.  The program will automatically search
all drives (including network drives) looking for a valid
authorization.  Failure to find a valid authorization causes the
program to reset all changed system parameters, erase itself out of
memory and exit to DOS.

If all goes right, eventually the original program is reconstructed
in memory and executes as normal.   On exit, as when the protection
check fails, the program resets all changed system parameters and
erases itself out of memory.


Brief Introduction to EVMOVE

EVMOVE (.COM or .EXE) is the name of Everlock's copy protection
transfer utility.  It is used to create working copies of the
program on diskettes or on a hard drive.  This program is often
renamed to something else like, AUTHORIZ.COM and AUTHMOVE.COM.
Because this program can create working copies of the protected
program and verify that the master disk is valid, it is a primary
target of our reverse engineering efforts.

Az-Tech is not dumb and has made this program very tough to attack.
It is encrypted (some parts are double encrypted), debugger hostile
(various versions commandeer some or all INTs 0, 1, 2, 3, 4 and 5),
and destroys itself in memory upon exit to DOS.  EVMOVE is an
impressive piece of pure assembly language programming that deserves
the cracker's respect.

EVMOVE can only be decrypted using a good virtual memory debugger to
get around some of its anti-debug tricks.  The "code digger"
debugger built into CUP386 version 3.4 is an excellent choice.  If
you aren't familar with CUP386, here is a typical command line:

C:\>CUP386 evmove.com /3 /d

Now start tracing through the code.  A standard feature of the .COM
versions of EVMOVE is a CALL xxxx to the main decryption routine
which is ~8-9 bytes before the encrypted code.  Instead of RETing
from the decryption CALL, there is a JMP to the decrypted code at
the end of the routine.  For example:

-0100  JMP   10CB
.
. (Data is stored here)
.
-10CB  MOV   AX,CS
.
. (Some initiation code)
.
-1106  CALL  32AC    ;Call to main decryption routine, ends at 330E
.
. (~8-9 Byte Gap)
.
-1110  CMP   WORD PTR [01C7],+00    ;First decrypted instruction
. (Program execution continues)
.
.
-32AC  LDS   BX,ES:[0004]    ;Main decryption routine
.
. (Main decryption routine)
.
-330E  JMP   1110    ;This is where you JMP to the decrypted code
                     ;There is no "RET" from the CALL 32AC!

At this point, most of the file is decrypted.  However, there are
usually one or more sections within the code that are still
encrypted.  These sections are not decrypted until just before they
are run and are immediately reencrypted after exit.  One known
example reads and decrypts the program's serial number.  This is
important information that is used to link the copy protection to a
particular program.  Therefore, you can't fool one Everlock
protected program into running with the valid installation
information from a different Everlock program.  So, you can see why
the serial decyption routine would be well protected.  However,
these special double encrypted sections are easy to recognize and
decrypt if you know what to look for.  They will be examined further
in part II of this series.


Wrap-up

As you can tell from the information presented, Everlock is a very
complex copy protection scheme.  Even after spending years reversing
this program, I still have only scratched the surface.  Hey, I could
use some help from experienced DOS reversers.  With enough
knowledge, we can write our own programs to create and strip this
protection from disks at our whim.


Source code for EVREAD.ASM
==========================
;/--------------------------------------------------------------\
;| Module..: readev.asm						|
;| Program.: readev.com						|
;| Author..: Tomboy						|
;| Date....: 09/17/93						|
;| Version.: 1.0 for MASM 5.1					|
;| Notes...: Reads data from special 8192 byte sector used in	|
;|           Everlock copy protection and saves it to a file	|
;\--------------------------------------------------------------/

stackseg	segment	stack		;This placates the linker
stackseg	ends

codeseg		segment			;This assures the the code
codeseg		ends			;segment will come first

dataseg		segment			;The data segment comes last
old_int_offset	dw	?		;address of old disk table
old_int_segment	dw	?
new_disk_table	db	0bh dup(00h)	;buffer for new disk table
sector		db	09h		;sector number of 8192 sector
track		db	06h		;track number
drive		db	00h		;floppy drive number, A=0, B=1
head		db	00h		;side to read, usually 0
error_code	dw	?		;diskette read error code
output_file	db	"8192byte.dat",00h
sector_buffer	label	byte		;offset to sector data buffer
dataseg		ends

groupseg	group	codeseg,dataseg
		assume	cs:groupseg
		assume	ds:groupseg
		assume	es:groupseg

codeseg		segment
		org	100h
main		proc	near

		call	save_vector	;save address of old disk table
		push	ds
		pop	es
		push	ds
		lea	di,groupseg:new_disk_table	;offset to new
		mov	si,groupseg:old_int_offset	;disk table buffer
		mov	ds,groupseg:old_int_segment
		mov	cx,000bh		;read old disk table info
		repz	movsb			;to new disk table buffer
		pop	ds
		mov	byte ptr groupseg:new_disk_table+3,06h	;change sector
		mov	al,groupseg:sector			;size to 8192
		mov	groupseg:new_disk_table+4,al	;last sector number
		mov	cl,al
		mov	ax,0
		mov	es,ax
		lea	ax,groupseg:new_disk_table
		mov	es:[0078h],ax		;point disk base table INT
		mov	ax,cs			;to new table location
		mov	es:[007ah],ax
		push	cs
		pop	es
		mov	bx,offset groupseg:sector_buffer	;setup for
		mov	ch,groupseg:track			;absolute
		mov	dl,groupseg:drive			;disk read
		mov	dh,groupseg:head
		mov	al,1
		mov	ah,2
		int	13h
		mov	groupseg:error_code,ax	;save error code
		call	restore_vector		;restore pointer to old
						;disk base table location
		sti
		xor	dx,dx			;reset diskette drive
		mov	ah,0
		int	13h
		clc

		call	write_file

		mov	ah,4ch			;exit
		int	21h

save_vector	proc	near
		push	ax
		push	es
		mov	ax,0
		mov	es,ax
		mov	ax,es:[0078h]
		mov	groupseg:old_int_offset,ax
		mov	ax,es:[007ah]
		mov	groupseg:old_int_segment,ax
		pop	es
		pop	ax
		ret
save_vector	endp

restore_vector	proc	near
		push	ax
		push	es
		mov	ax,0
		mov	es,ax
		mov	ax,groupseg:old_int_offset
		mov	es:[0078h],ax
		mov	ax,groupseg:old_int_segment
		mov	es:[007ah],ax
		pop	es
		pop	ax
		ret
restore_vector	endp

write_file	proc	near
		sub	cx,cx		;open output file
		mov	ax,3c00h	;and get handle
		mov	dx,offset groupseg:output_file
		int	21h

		xchg	bx,ax		;move file handle to BX
		mov	ax,4000h
		mov	cx,2000h	;number of bytes to write
		mov	dx,offset groupseg:sector_buffer
		int	21h

		mov	ax,3e00h	;close file
		int	21h
		ret
write_file	endp

main		endp
codeseg		ends
		end	main
links
+ORC
bots wars
tools
mail_fravia
Is reverse engineering illegal?