EVERKEY User's Manual - EVERKEY User's Manual

EVERKEY User's Manual


EVERKEY Feature Overview

Thank you for choosing the EVERKEY Copy Protection System. EVERKEY utilizes the most advanced methods available to protect your Product and keep it secure. By combining the most compatible secure hardware with the most sophisticated software protection, we can offer this unprecedented level of compatibility and security. Your Product deserves nothing less! We hope that the EVERKEY System becomes a vital part of your continued growth and success in the software industry.

  • EVERKEY is designed to protect your software by restricting usage to only one computer system at a time. It is completely transparent to the Customer, requiring no changes in operation or documentation. Compatibility with all USB, Parallel (LPT) and Serial (COM) ports means one less problem to deal with. Daisy-chaining of Parallel port holders is a standard feature with EVERKEY.
  • EVERKEY makes it very easy to embed specific and unique information into every program you ship. This information can be as generic as a serial number or as unique as the Customer's name and address. This data is encrypted and totally secured within the protected program. Any attempt to modify it will result in the program ceasing to operate. If desired, you may display this unique information each time your program is used.
  • EVERKEY uses encrypted code to prevent disassembly and reverse engineering. It also embeds a number of anti-debug devices to inhibit execution tracing.
  • EVERKEY lets you build an expiration date into your protected program. Any attempt to operate the program after this date results in your custom message being displayed. You may also specify a message to warn of impending expiration in so many days.
  • EVERKEY can also build an execution limit into your package. Both expiration dates and execution limits can be remotely reset with your authorization only. This allows you to produce demo packages and special versions of your Product without any modifications to your source programming.
  • EVERKEY makes it easy to control network Products. Just issue an Authorization Device for each Customer who needs access to the protected software. You need do nothing to the network server. The protected programs are ordinary files and may be copied to the network server. The programs can only be run from a workstation with an Authorization Device. USB Authorization Devices can be treated as "Floating Licenses" and carried on a key chain.
  • EVERKEY allows your Product's protection options to be stored in an encrypted format. You may also specify how those encrypted options may be used by those who do not know the decryption password. This feature allows for secure production environments where you can be sure that protection options are not being changed by unauthorized personnel.
  • EVERKEY opens up a new marketing approach with the use of our Renew process. With the use of the remote control features you can create new leasing and rental plans that will add to your Product's marketability.


EVERKEY Hardware

EVERKEY Authorization Devices support USB, Parallel (LPT) and Serial (COM) ports. It doesn't matter to your protected program where the Authorization comes from, as long as it contains your unique Product information. This means that your program accesses the Authorization Device the same way for all port types.

All EVERKEY Authorization Devices support Expiration-Dates and Execution Limits. These Limits may be remotely reset or removed (if authorized by you) using the provided Renew32.exe program.

The Authorization Device types that EVERKEY supports are called Rockeys and iButtons. The main differences between Rockeys and iButtons are:

  • Rockeys are USB and Parallel (LPT) devices. iButtons support Parallel (LPT) and Serial (COM) ports.
  • Rockeys are a one-piece unit. iButtons must be plugged into a separate Holder.
  • Rockeys can be READ an UNLIMITED number of times, but can only be WRITTEN 100,000 times. iButtons can be reprogrammed an UNLIMITED number of times, but have a maximum lifetime of 10 years.
  • Rockeys are less expensive than iButtons.

How do you decide which Authorization Device to use with your Product? If your Customers use newer computers with USB ports, Rockeys are the way to go. For older computers that don't support USB devices, both Rockeys and iButtons are a good choice. But remember, EVERKEY makes it easy to use both since your programs don't care where the Authorization comes from. And both Rockeys and iButtons are solid, dependable hardware with a proven track record for security.

Rockeys:

Rockey Authorization Devices contain a custom microprocessor, EEPROM memory and specialized circuitry for random number generation. The USB device has a translucent plastic case that allows an LED indicator to be seen when the device is in use. Also, the USB case design allows the device to be strung on a key ring to support a "Floating License".

Figure 1 Rockey Authorization Devices

Rockeys support Expiration-Dates and Execution Limits. These Limits may be remotely reset or removed (if authorized by you) using the provided Renew32.exe program.

Even with all these advanced features, these are our least expensive Authorization Device.

iButtons:

iButtons contain the electronic circuitry to store the unique Authorization for your Product. This circuitry is housed inside of a 17mm stainless steel can rugged enough to withstand being dropped, stepped on or even submersed in water. iButtons contain their own lithium power source to keep your Authorization safe and secure for up to 10 years.

Figure 2 iButton Parallel (LPT) and Serial (COM) Authorization Devices

iButtons support Expiration-Dates and Execution Limits. These Limits may be remotely reset or removed (if authorized by you) using the provided Renew32.exe program.

iButtons are connected to the computer via a Parallel (LPT) or Serial (COM) port Holder. Holders have no other function and don't contain any Authorization or protection information. Accessing the iButton is the same regardless of what type of Holder is being used.

Parallel (LPT) port Holders can be daisy-chained and are completely transparent to other bi-directional devices plugged into the same Parallel port. Serial (COM) port Holders cannot be daisy-chained and must be the only device plugged into that Serial port.


EVERKEY System Requirements

The minimum computer system required to protect your programs with EVERKEY is:

  • IBM PC Compatible running Windows 95 or later
  • CD-ROM drive (any speed)
  • One standard USB or Parallel (LPT) Port

To program Rockey USB devices, your production computer must be running Windows 98, Windows Millennium, Windows 2000 or Windows XP.


Types of Programs That May Be Protected

Your application program(s) can be virtually any executable file that exists in the Windows or DOS world. This will generally be in the form of an EXE file, but any executable that has the ability to "call" a DLL function can be protected. EVERKEY can NOT be used to protect data or non-executable files.

Typically, a program is "protected" by adding one or more "KECHK Calls" which check for the presence of your Authorization Device. Native DOS programs enjoy the option of "Point-&-Shoot" protection without changing any source code or recompiling.

EVERKEY supports programs which run under the following environments:

  • PC or MS-DOS v3.30 or later
  • Windows v3.10 and v3.11 Windows for Workgroups
  • Windows 95, including OSR2
  • Windows 98, including 98 SE
  • Windows Millennium
  • Windows NT v3.51
  • Windows NT v4.0 with Service Pack 2 or later
  • Windows 2000
  • Windows XP


Protected Program Compatibility

Programs protected by EVERKEY have the same compatibility requirements as the original unprotected program with the following exceptions:

  • It's very rare, but some older versions of Windows Power Management may not "turn on" the Parallel (LPT) or Serial (COM) I/O ports until after several accesses. This may prevent the protected program from finding your iButton Authorization Device. If you are having this problem, we recommend you disable Power Management.
  • If you protect your Product with a Rockey USB device, the Operating System must support USB devices in order to verify the Authorization. DOS, Windows 3.1x, Windows 95A and Windows NT4 do not support USB devices.

EVERKEY supports all known Networks by requiring an Authorization Device for each workstation which will use the protected program(s). USB Authorization Devices can be treated as "Floating Licenses" and carried on a key chain from workstation to workstation. EVERKEY does not support installing the Authorization Device to the Network Server.


EVERKEY Software Installation

Before you can protect your Product, the EVERKEY software must be installed to the production computer system which you will use to apply the protection. This computer must have at least one USB or Parallel (LPT) port for the Authorization Device to plug into.

EVERKEY uses a 32-bit SETUP program that requires Windows 95 or later.

If you are installing this version of EVERKEY on a system that already contains an older version, we recommend that you specify a different installation folder name. After installation, the existing Options files (files with an EVK extension) should then be copied to the new version's folder. This will leave your existing EVERKEY installation "untouched" while you become familiar with the new version.

To install EVERKEY from the CD-ROM:

  • Insert the EVERKEY CD-ROM.
  • The EVERKEY Setup Program should start automatically. If it doesn't, run the Cdsetup.exe program from the root folder of the CD-ROM.
  • Follow the on-screen prompts and instructions.

To install EVERKEY from the downloaded Kesetup.exe file:

  • Run the downloaded Kesetup.exe program.
  • Follow the on-screen prompts and instructions.

If you have installed EVERKEY to Windows 2000 or Windows XP, you need to start UserPort so Kebuild.exe and Keshow.exe can access iButtons. Do the following:

  • On the Windows taskbar, click Start->Run, enter "userport" and click "OK". The UserPort dialog should be displayed.
  • On the UserPort dialog, click "Start" and then "Exit".

If upgrading from a previous version of EVERKEY, copy your Options files (files with an EVK extension) from the existing folder to the new EVERKEY folder.


Upgrading The Protection On Your Product

Upgrading to this version of EVERKEY is required in order for your Product to start using Rockey USB or Parallel Authorization Devices.

This version of EVERKEY uses new Az-Tech Device Drivers that are installed by running the Azsetup.exe program. The older versions of EVERKEY used the Setup32.exe program. You should replace the Setup32.exe program with the latest version of the Azsetup.exe program.

If you have a 32-bit Windows Product:

  • Replace the Kechk32.dll and Renew32.exe files with the new versions.

If you have a 16-bit DOS Product:

  • If you are using Point-&-Shoot protection, you will need to re-protect your Product program(s). If you are using KECHK, you will need to re-link your Product program(s) with the new version of Kechkd.obj.
  • Replace the Renew.exe file with the new version.

If you have a 16-bit Windows Product:

  • We no longer supply the Kechk2.dll file. You will need to link your Product program(s) with the new version of Kechkd.obj.
  • Replace the Wrenew.exe file with the new version of Renew32.exe.

If you have a 16-bit DOS or Windows program that uses iButtons and will be installed to a Windows 2000 or Windows XP system, your documentation will need to be updated to tell your Customers how to start UserPort. For a detailed explanation, please refer to UserPort.


Moving the EVERKEY System

From time to time, the need to relocate the EVERKEY system might arise. EVERKEY can be freely installed to any number of computers. Don't forget to COPY any Options files that you have created (these are the files that have an EVK extension).


How EVERKEY Works

Now that you have installed your EVERKEY software, here is an overview of how the protection works, how it can be implemented and several other things you should consider before you start protecting your own Products.

Please read this chapter before attempting to protect a "production" Product that will be sent to one of your Customers. THEN, protect only ONE Product and thoroughly test the protection to make sure everything is working the way you expect.

The concept of how EVERKEY works is very simple if you think of the protection as having two separate parts:

  • Part 1 is an "Authorization check" within your program which verifies that your specific Authorization Device is present.
  • Part 2 is your Authorization Device which is unique and cannot be duplicated.

Figure 3 How EVERKEY Works

Your program containing the "Authorization check" can be freely copied, backed up, restored, etc. with no restrictions or special considerations. However, any copy of your protected program will require the presence of your unique Authorization Device. And since the Device can only be in one place at one time, you can be assured that your licensing terms are being enforced at the Customer site.

The reason your Authorization Device is unique is because we allow you to specify all the protection information that is programmed into it. Once you specify all the protection options, you use the Kebuild.exe program to actually program your device.

Adding an "Authorization check" to your program is as simple as copying and pasting one of our Source Code Examples and then re-compiling your program. DOS programs enjoy the option of "Point-&-Shoot" protection that does not require changing any source code or recompiling.


Steps to Protect Your Product

Producing an EVERKEY protected Product consists of the following steps:

  • Create an EVK Options file that is used to tell the Kebuild.exe program how to protect your Product. For a detailed explanation, please refer to Creating New Options Files or Editing Existing Options Files.
  • Add an Authorization check to your program(s) that will verify the presence of your unique Authorization Device. The Source Code Examples show how to call the KECHK function. (This step is optional if you are protecting a DOS program.) For a detailed explanation, please refer to KECHK Overview.
  • If you have a 16-bit DOS or Windows program that uses iButtons and will be installed to a Windows 2000 or Windows XP system, your documentation will need to be updated to tell your Customers how to start UserPort. For a detailed explanation, please refer to UserPort.
  • Add the required EVERKEY files to your Product. This will usually be the Kechk32.dll and Renew32.exe files. The Kechk32.dll file actually performs the Authorization check and the Renew32.exe program is required to allow your Customer to Renew the Authorization. You may rename the Renew32.exe program if you wish. For a detailed explanation, please refer to Files to Add to Your Product
  • Plug a Rockey or iButton Authorization Device into the computer where the EVERKEY software has been installed. For a detailed explanation, please refer to Plug in the Authorization Device
  • Run the Kebuild.exe program specifying the EVK Options file created in the first step. This will program the Authorization Device with your Product's protection options. If you are using the Point-&-Shoot protection method (for DOS programs only), Kebuild.exe will also encrypt your program(s) and add an Authorization check. For a detailed explanation, please refer to Running Kebuild.exe to Build Protection
  • Test the protected Product. For a detailed explanation, please refer to Product Testing


Kebuild Overview

The Kebuild.exe program is used to:

  • Create or edit your "Options" files (files with an EVK extension). Options files describe how your Product will be protected.
  • Program (Build) the protection options into your Authorization Device.
  • For DOS programs only, Kebuild.exe will also encrypt your program(s) and add an Authorization check. This is sometimes called "shell" or "envelope" protection.


Product Testing

During your initial familiarization with the Kebuild.exe program, all protected programs and Authorization Devices should be thoroughly tested. Use the Errcode.exe program to check out every Error message. Some are just warnings, but you should be aware of why they occur. If there is still a question as to why an Error occurs, please contact Az-Tech Technical Support.

NOTE: Each time you protect a new Product for the first time, it is a good idea to run the protected programs "through the paces" to make sure that no problems exist. If you do find a problem, you can correct it before the Customer finds it for you.


Creating New Options Files

Options files describe how your Product will be protected. They contain all of the options for how to protect your Products. For example, the Options file contains any Execution or Date Limits, the Serial Number and what type of device will be used to protect the Product. Options files are easy to identify because they will always have a file extension of "EVK", e.g. Defaults.EVK.

The Kebuild.exe program is used to create and edit Options files.

Unless told otherwise, Kebuild.exe always loads the Defaults.evk Options file. We've specified the most common protection options as the defaults, but you will probably want to specify your own defaults.

To create an Options file called Flash.evk:

  • Start Kebuild.exe using the Windows Start menu shortcut.
  • Press <F5> to select "View/Edit Main Options" from the menu.
  • Use the <Delete> key to erase "DEFAULTS.EVK" and then type "flash" and press the <Enter> key.
  • At the Comment field, type "My First Options File" and press the <Enter> key.
  • Press the <F9> key to save the Options file.
  • To see the created file, press the <F2> key.

NOTE: If you prefer to use the Command-Prompt, you can start the Kebuild.exe program by navigating to the EVERKEY folder and typing "kebuild <Enter>".

You can create as many Options files as you wish, and we recommend that you have a different Options file for each software Product you wish to protect. The name you choose for the Options file should come from the software Product it will be used to protect. For example, let's assume that you will be protecting two Products, one called "Flash" and the other called "Keeper". One Option file could be named "Flash.evk" and the other named "Keeper.evk". This naming system makes it very easy to keep track of which Options files to use with a particular Product. If you need more than 8 characters to describe an Options file, you can use the Comment field which allows for up to 30 characters of description.

Please note that the process of creating an Options file does not protect anything. It only specifies how a Product will be protected.


Editing Existing Options Files

The Kebuild.exe program is used to create and edit Options files.

To edit an existing Options file from the Windows Desktop:

  • Start Kebuild.exe using the Windows Start menu shortcut.
  • Press <F5> to select "View/Edit Main Options" from the menu.
  • To see the existing Options files, press the <F2> key.
  • Use the Up and Down Arrow keys to select the Options file that you wish to edit.
  • Press the <Enter> key to load the file.
  • Use the <Tab> and Arrow keys to navigate from field to field.
  • Press the <F9> key to save the changed Options file.

To edit an existing Options file from the Command Prompt:

  • Navigate to the folder containing the Kebuild.exe program and the Options file to edit.
  • Type "kebuild filename <Enter>" where "filename" is the name of the Options file to edit. For example, typing "kebuild flash <Enter>" would start the Kebuild.exe program and load the Flash.evk Options file.
  • Press <F5> to select "View/Edit Main Options" from the menu.
  • Use the <Tab> and Arrow keys to navigate from field to field.
  • Press the <F9> key to save the changed Options file.


Plug in the Authorization Device

Since EVERKEY relies on a combination of software and hardware to protect your Product, you must plug in a Rockey or iButton before running the Kebuild.exe program.

For USB Rockeys, just plug a Rockey into any available USB port. You may use a multi-port hub or extension cable if you wish.

iButtons and Parallel Rockeys must be plugged into a Parallel (LPT) port. If this computer has more than one LPT port, it makes no difference which one you use. For convenience, you might want to use an extension cable for the LPT port routed around to the front of the computer. This allows you to plug in each device into the cable from the front of the computer which is much easier than plugging in to the LPT port on the back of the computer.


Running Kebuild.exe to Build Protection

The Kebuild.exe program is used to program the Authorization Device (Rockey or iButton) with your unique Product protection information. This information is stored in your Options file. For DOS programs, Kebuild.exe will also Point-&-Shoot protect them which encrypts the program file and adds an Authorization check. This is sometimes called "shell" or "envelope" protection.

Let us assume you have created an Options file named "Keeper.evk".

To Build Protection from the Windows Desktop:

  • Start Kebuild.exe using the Windows Start menu shortcut.
  • Press <F5> to select "View/Edit Main Options" from the menu.
  • To see the existing Options files, press the <F2> key.
  • Use the Up and Down Arrow keys to select the Keeper.evk Options file.
  • Press the <Enter> key to load the file.

To Build Protection from the Command Prompt:

  • Navigate to the folder containing the Kebuild.exe program and the Keeper.evk Options file.
  • Type "kebuild keeper <Enter>"
  • Press <F5> to select "View/Edit Main Options" from the menu.

Your screen might look something like Figure 4.

Figure 4 Kebuild Main Options Screen

Before proceeding, be sure there is only one (1) Rockey or iButton plugged into the computer. Also, if you are using iButtons, be sure that the LPT Port field of the Options file contains the correct Parallel (LPT) port number.

To start the protection process, press <F10>. At this point a box will appear in the Protection Status area of the screen telling you "Press any key to protect (ESC to Quit)". This box will also display a list of options that may be a security risk. This list will also display options selected that may cause information to be suppressed. You should review this list to ensure these options are correct.

Now you can press any key to start protecting your Product or press <ESC> to quit the protection process. If you proceed, your Authorization Device will be programmed and after a few seconds, the prompt will be re-displayed. If you do not wish to program another device, just press the <ESC> key to quit the protection process. If you have protected any diskettes (DOS programs only), you will be taken to the Protection Status screen so you can review any messages generated. Press <ESC> again to exit the Protection Status screen.


Kebuild Command Line Parameters

When running Kebuild.exe from the Command Prompt, there are several command line parameters which override the protection options or modify the way Kebuild.exe operates. The following is a description of each one:

/? | This parameter displays all parameter options.
/B | This "Batch Mode" parameter allows Kebuild.exe to run without asking for keyboard responses. If you use batch mode, you must also specify an Options file. This parameter is very useful for setting up a totally automated batch file that creates and protects a single Product. If the protection cycle fails for any reason, the DOS ERRORLEVEL will be set to a non-zero value.
/C nnnn | This "Counts" value (nnnn) allows you to override the Options file's Execution Count Limit. If you use this parameter to override the Execution Count Limit, Kebuild.exe will not update the Options file. (Only available when using the "/B" parameter.)
/D nnn | This "Days/Date" value (nnn) allows you to override the Options file's Execution Date Limit. If you use this parameter to override the Execution Date Limit, Kebuild.exe will not update the Options file. (Only available when using the "/B" parameter.)
/F xx xx | This parameter allows you to specify one or both User-Data flags. Enter the hexadecimal value (xx) of the flags. (Only available when using the "/B" parameter.)
/H | This parameter displays all parameter options.
/L n | This value (n) allows you to specify an LPT Port number (between 1 and 3) and override any value you had previously placed in your Options file. (Only available when using the "/B" parameter.)
/N nnnnnnnnn | This "Number" value (nnnnnnnnn) allows you to override the Options file's serial number. Normally, Kebuild.exe saves the last serial number used in the Options file. If you use this parameter to override the serial number, Kebuild.exe will not update the Options file. (Only available when using the "/B" parameter.)
/P n | This "Partition" value (n) allows you to override the Options file's Partition to Program. If you use this parameter to override the Partition to Program, Kebuild.exe will not update the Options file. (Only available when using the "/B" parameter.)
/Q | This "Quiet" parameter suppresses the use of "bell" characters (beeps).
/S xxxxxxxxx | This "Startup Msg" value (xxxxxxxxx) allows you to append to the Options file's Startup Msg. The "/S" must be the last parameter on the command line. The "|", "<" and ">" can be appended to the Startup Msg. These characters must be enclosed inside "". For example, "<My|Disk>" is allowable. The "|" will still be translated as a special character.
d: | This parameter allows you to specify the drive to protect your diskette in where d: is the drive letter. (Only available when using the "/B" parameter.)


Kebuild Screen Navigation

You may choose to edit options from another Options screen. To accomplish this press <F4> from the Main Option screen. This will display a menu with seven (7) options. (see Figure 5)

Start Protection Process | <F10>
View/Edit Main Options | <F5>
View/Edit Message Options | <F6>
View Kebuild Log | <F8>
System Help | <F1>
How to Protect a Product |
Exit | <Alt-X>

To select one of the menu items, move the cursor down with the down arrow and press <Enter> or press the "speed key" listed for that option.

By selecting the "Start Protection Process" you will program your Authorization Device. For DOS Products, this will also protect and encrypt the Product programs.

The next three (3) options: "View/Edit Main Options", "View/Edit Message Options" and "View Kebuild Log" allow you to navigate from one screen to another in the Kebuild.exe program.

The last three options: "System Help" invokes the system level help. "How to Protect a Product" provides an overview of how to protect your Product. "Exit" ends the Kebuild.exe program.

Figure 5 Kebuild.exe Menu


Kebuild Main Options

This section describes each Main Options Screen option in detail. This information is also available "on-line" while using the Kebuild.exe program. You can invoke on-line field help at any time by pressing <F1>.

If you will refer to Figure 6 you will see the default options as they would appear when you first run the Kebuild.exe program. Please refer to this figure as you read about each option.

NOTE: The fields described in this section are those most commonly used by a majority of our Customers. Our example in Figure 6 shows the DEFAULTS.EVK Options file loaded. Since some options are chosen randomly, your screen will not show exactly what the figure displays.

Figure 6 Kebuild Default Main Options

Options Filename:

Your Options file contains all your specified protection options for a given software product. These files are used by the Kebuild.exe program when it programs your Authorization Devices. A complete list of available options files can be obtained by pressing the <F2> key.

It's recommended that you have a separate Options file for each Product you protect.

Options file names always end with an EVK extension.

Comment:

This field allows you to specify up to 30 characters of description for the current Options file. This description shows up on the Options file selection list displayed with <F2>.

Encrypt Options:

This field specifies whether or not the current Options file will be encrypted. No means the file will not be encrypted. Setting this field to Yes causes the Options File to be encrypted with a password (up to 8 characters, case sensitive) that you supply. Once an Options file is encrypted, no options can be displayed or modified unless the correct password is entered. The Options file can be used in its encrypted form only if the Allow Kebuild Use or Allow Kecodes Use fields are set to Yes.

Allow Kebuild Use:

Specifying Yes allows Kebuild.exe to run in batch mode without entry of the password. Setting this field to No causes the Options file to only be available to Kebuild.exe if the correct password is entered. This field is only activated when Encrypt Options is set to Yes.

Allow Kecodes Use:

Specifying Yes allows Kecodes.exe to run in batch mode without entry of the password. Setting this field to No causes the Options file to only be available to Kecodes.exe if the correct password is entered. This field is only activated when Encrypt Options is set to Yes.

Product Name:

This field specifies a unique "short" name (up to 8 characters) for the Product being protected. This name will be stored in the Authorization Device (Rockey or iButton) for later verification by your protected program. It is also used along with the Encryption Key option to determine the PIN for this Product. You may enter the Product Name in lower case or upper case. This field is case sensitive.

Encryption Key:

This field should specify a SECRET unique character sequence for the Product being protected. Up to 8 case sensitive characters may be specified. This information is used as an internal encryption key for the protection. It is used along with the Product Name to determine the PIN for this Product. The Encryption Key is only used internally by the protected program(s). The Customer will never be required to know this field's contents.

NOTE: If you create an upgrade to your software and do not intend to send out replacement Authorization Devices (this is the way it is normally done) the Product Name and Encryption Key of your upgrade must EXACTLY match the fields used to protect the original program. This match is also case sensitive.

Type of Device:

All EVERKEY Authorization Devices support Expiration-Dates and Execution Limits. These Limits may be remotely reset or removed (if authorized by you) using the provided Renew32.exe program.

The Authorization Device types that EVERKEY supports are called Rockeys and iButtons. The main differences between Rockeys and iButtons are:

  • Rockeys are USB and Parallel (LPT) devices. iButtons support Parallel (LPT) and Serial (COM) ports.
  • Rockeys are a one-piece unit. iButtons must be plugged into a separate Holder.
  • Rockeys can be READ an UNLIMITED number of times, but can only be WRITTEN 100,000 times. iButtons can be reprogrammed an UNLIMITED number of times, but have a maximum lifetime of 10 years.
  • Rockeys are less expensive than iButtons.

It doesn't matter to your protected program if the Authorization comes from a Rockey or an iButton device. Both work equally well.

Specifying 'None' as the Type of Device means that all Device processing will be skipped.

How do you decide which Authorization Device to use with your Product? If your Customers use newer computers with USB ports, Rockeys are the way to go. For older computers that don't support USB devices, both Rockeys and iButtons are a good choice. But remember, EVERKEY makes it easy to use both since your programs don't care where the Authorization comes from. And both Rockeys and iButtons are solid, dependable hardware with a proven track record for security.

Device Partition:

The iButton Authorization Device has three partitions that can be programmed. Enter the partition number (1, 2, or 3) to program.

Each partition is treated as separate Authorization Device.

LPT Port:

This field specifies which parallel port will be used to program the iButton during the protection process. The choices are 1, 2, or 3.

Log Session:

This field specifies if the Kebuild.exe session will be saved to a log file. If you specify Yes, then any output of the protection process will be written to a file in the current folder. The name of the file will be the name of the Options file with a BLD extension. If you choose No, then no file will be kept.

Start Timer:

If you specify When Protected and you use Kebuild.exe to build protection today, the timer will start today. It will expire, and the programs will cease to function on the date shown In the Expire-Date field.

If you select Upon First Use, the timer will not start until the first time one of your protected programs is executed. In this case, for example, if 30 is entered into the Expire-Days Limit field, then your Authorization Device will expire 30 days after the first time your Customer uses your software. The Expire-Date shown on your Kebuild.exe Main Options screen should be ignored.

PIN:

The PIN or Product ID Number serves as a unique identifier for your Product. It is used to authenticate the program calling KECHK. This number should be treated as a company SECRET. The Kebuild.exe options Product Name and Encryption Key determine the PIN of a Product.

Exec-Count Limit:

This field sets a total execution limit for the specified protected program(s). It determines how many times (1-9999) your files can execute before they expire. Specifying zero (0) causes your program to operate WITHOUT an execution limit.

NOTE: Remember, if you protect more than one program and want the limit to apply to all programs, you will need to calculate the total number of times all the programs will execute for your Exec-Count Limit . Use the following example:

  • Three (3) programs protected in my Product.
  • I want each program to run 4 times.
  • My Exec-Count Limit will be 3 (programs) x 4 (runs) or 12.

This limit can later be remotely reset or removed (if you allow it). If you wish to do this, you should add the Renew32.exe program to your Product. You may rename this program if you wish.

Expire-Days Limit and Expire-Date:

These two fields serve a similar purpose. You only need to enter information into one of the fields. If you enter data into one field, the other will be calculated for you on the screen. Each will be described separately.

Expire-Days Limit:

This field specifies the number of days (0-999), after the days count starts, that you want your programs to expire (stop operating). If you would rather specify a date for your programs to expire, use the Expire-Date field and this field will be calculated automatically. The actual expiration date depends on the current system date, not the date in this field. If you specify zero as the Expire-Days Limit, your programs will operate without a date restriction.

This limit can later be remotely reset or removed (if you allow it). If you wish to do this, you should add the Renew32.exe program to your Product. You may rename this program if you wish.

Expire-Date:

This field specifies the actual date you want your programs to expire (stop operating). If you would rather specify a number of days until your programs expire, use the Expire-Days Limit field and this field will be calculated automatically. Specifying the current date (filled in automatically) causes your programs to operate without a date restriction.

Please note that this is the actual date that your Authorization Device will expire only if you start the timer now. (Please refer to Start Timer above.) If you specify that the timer will not start until your customer uses your software for the first time, then your Authorization Device will actually expire at a date that is later than the date that is shown on your screen.

This limit can later be remotely reset or removed (if you allow it). If you wish to do this, you should add the Renew32.exe program to your Product. You may rename this program if you wish.

Build Path:

This field specifies the drive and path of the DOS program(s) to be Point-&-Shoot protected.

If you have modified your program to do a KECHK Authorization check, the 1st Program To Protect field should be set to NONE and this field will be ignored.

Program To Protect:

This field specifies the DOS program(s) to be Point-&-Shoot protected.

If you have modified your program to do a KECHK Authorization check, the 1st Program To Protect field should be set to NONE and all Build Path processing will be skipped. Also, if you wish to program Authorization Devices without protecting any programs, you should enter NONE in this field.

For DOS programs, enter '*.*' to protect all .COM and .EXE programs in the 'Build Path' or enter a specific program name including the .COM or .EXE extension. The program name may include the DOS wildcard characters '?' and '*'.

Although it's only necessary to specify one (1) program to be protected, you may specify up to four (4).

If you need to protect more than four, but not all the programs in the 'Build Path', use DOS wildcard characters to specify certain groups of programs, e.g. 'WP*.EXE', 'WP5?.EXE' or '*.COM'.

Specifying '*.*' causes ALL programs in the 'Build Path' to be protected, regardless of the number.

If you wish to apply a Count or Date limitation to only a specific program, or if you wish to exclude a certain program from a Date or Count limitation then you should specify actual program names in this field.

Use Limits:

This Y/N field specifies if any setup Exec-Count or Expire-Date limits will apply to your DOS Point-&-Shoot protected program. "Y" is the normal answer. Although, "N" means the program will not expire, it will still require the presence of your Authorization Device in order to function.

This option is normally used to exclude one protected program from a limit that applies to the rest of the Product.

In order to apply a limit to a specific program or exclude a specific program from a limit, you must specify actual program names in the Program To Protect field.

Expire Warnings:

The number you enter here specifies how many days or executions (0-99) prior to expiration that the Expire Warn Msg should be displayed when your DOS Point-&-Shoot protected program is run. Specify zero (0) for no warning.

User-Data:

This field allows you to enter data that will be stored in the secure memory of the Authorization Device. Later, this data can be accessed and updated using the KECHK function. You may enter up to 16 bytes of data. This data must be entered in hexadecimal format. The last two bytes (16 bits) are the User-Data flags and each bit flag can be turned on (set to 1) using the Renew .exe or Renew32.exe programs.

Serial Number:

This field specifies the serial number of the next Product to be protected. This number must be in the range between 1 and 4,294,967,293. This field is only used to contain the numeric portion of your Product's serial number. For information on how to set up an alphanumeric serial number, please refer to Special Characters and Startup Msg Data.

Serial Numbers provide an ideal database "key" or identification number for your Customers. They can also be used to keep track of the total number of Products you have sold. The Renew process uses the Serial Number to generate a unique code that can't be used by anyone else. Finally, Serial Numbers can be used to trace the source of software that has been illegally transferred or sold. If this is the case, you might want to know where it originally came from. Of course, in order to tell who owned the original product, you must keep a record (database) of Customer Serial Numbers.

Verify:

This field specifies if the Serial Number built into the Point-&-Shoot protected DOS program(s) will be verified against the Serial Number in the Authorization Device. Normally, you should specify Yes. However, if you are producing an Upgrade to an existing Product, you may want to specify No. If you answer No, your programs will function correctly with any Authorization Device that has the correct Product Name and Encryption Key, regardless of Product Serial Number. This is useful if you are sending upgrades, and you do not know the Product serial numbers, or you wish to create "generic" upgrades that will work for any of your Customers. If you answer Yes, your programs will not function correctly unless it finds both the correct Product Name and correct Serial Number in the installed Authorization Device. This is the most secure way to protect your Product.

Increment:

This field specifies the amount (0-9999) to increment the serial number each time a Product is protected. One use for this field is to keep the least significant digits of a serial number constant. Assume you want "101" to appear as the right most digits of all your serial numbers. To do this you would choose 1000 as the increment to be added to each serial number. If we started with 100101 as the first serial number, your serial numbers would then appear as:

  • 100101
  • 101101
  • 102101
  • 103101
  • etc.


Kebuild Message Options

This section describes each Message Options Screen field in detail. This information is also available "on-line" while using the Kebuild.exe program. You can invoke on-line field help at any time by pressing <F1>.

If you will refer to Figure 7 you will see the default options as they would appear when you first run the Kebuild.exe program. Please refer to this figure as you read about each option.

Figure 7 Kebuild Default Message Options

To exit the Message Options screen and return to the Main Menu just press <F4> or <Esc>.

Unauthorized Msg:

This message will be displayed when your DOS Point-&-Shoot protected program(s) cannot find your unique Authorization Device. This message will also be displayed if EVERKEY has detected that your Point-&-Shoot protected program(s) have been illegally modified. The actual Error Code will tell you more about the exact nature of the problem.

If you have modified your program to do a KECHK Authorization check, the Program To Protect field should be set to NONE and this field will be ignored.

Expired Msg:

This message will be displayed by your DOS Point-&-Shoot protected program(s) when the Expire-Days Limit has expired, or the Exec-Count Limit has been reached.

If you have modified your program to do a KECHK Authorization check, the Program To Protect field should be set to NONE and this field will be ignored.

Expire Warn Msg:

This message will be displayed by your DOS Point-&-Shoot protected program(s) to warn the Customer of an impending date expiration or execution expiration. The Expire Warnings option specifies how many days and/or Exec Counts remain before this message starts appearing.

If you have modified your program to do a KECHK Authorization check, the Program To Protect field should be set to NONE and this field will be ignored.

Startup Msg:

This message will be displayed by your DOS Point-&-Shoot protected program(s) at startup as long as the 1st character of the message is not an @ symbol. The Startup Msg is normally used to hold information that is unique for each Customer. This information can be as generic as the serial number or as specific as the Customer's name and address. The Startup Msg can be programmatically accessed and displayed in your own format.

If you have modified your program to do a KECHK Authorization check, the Program To Protect field should be set to NONE and this field will be ignored.

For more detailed information about the Startup Msg, please refer to Startup Msg Data.


Kebuild Log

The Kebuild Log is used during the protection process to display what product is being protected and any Error messages and informational messages that are generated during the process.

If your protection session generates more messages than will fit on the screen, you can choose to view just the Kebuild Log. By pressing <F8> the Kebuild Log will appear and you can scroll through the last 100 lines. You will notice small up and down arrows on the left side of screen. This indicates if you have messages above or below the viewing screen.

If the last 100 messages are not enough that you can indicate a log file name for this information to be placed in. You have the option of viewing all messages in a log file at a later time.

The Kebuild Log screen area is a read only, scrollable region. No entries can be made or changed. To exit this area press the <Esc> key and you will return to the Main Options screen.


Special Characters

EVERKEY Special Characters are used in messages which are only displayed by DOS Point-&-Shoot protected programs. Special Characters are not used by programs using KECHK.

EVERKEY allows you to supply your own custom message for a number of different situations. Special Characters are simply symbols (within a specified message) that will later be translated when the message is actually displayed. The use of Special Characters allows the message to be custom tailored to the Customer's particular Product and situation.

To illustrate, you may wish to tell the Customer how many days are left until their FLASH product diskette expires. Let us say you have set up the protection options so that once the product is within 10 days of expiration, the Expire Warn Msg will be displayed each time the Product is used. Without the use of Special Characters, the expire warning looks like this:

FLASH will expire soon. Please call 800-555-1212 to renew.

This warning is acceptable, but it lacks important specific information, such as how many days usage are left. With the use of Special Characters, you are able to specify the following Expire Warn Msg:

FLASH will expire in @. Please call 800-555-1212 to renew.^_

Notice the three Special Characters "@", "_" and "^" that are used in the preceding example message. When the message is actually displayed, each of these characters will be translated as follows:

@ | Is used to suppress the display of the Startup Msg when the protected program is run. In the Expire Warn Msg, it indicates a number of days or executions before expiration.
^ | Is replaced by the bell (beep) character to attract the Customer's attention.
_ | Pauses program operation until the Customer presses any key.

A typical display of the Expire Warn Msg that makes use of these three Special Characters would be:

FLASH will expire in 2 Days. Please call 800-555-1212 to renew.

(Beep) (Wait until a key is pressed)

In the following example, some special characters apply to all messages and others are unique for the specific message. While using the Kebuild.exe program to specify a custom message, you can easily see which Special Characters apply by invoking the context-sensitive help facility. This is done by positioning the cursor on the message in question and pressing <F1>.

Here is a complete listing of all Special Characters:

Special Characters Used For All Messages

Char | ASCII | Meaning
| | 124 | Replaced by a carriage-return and linefeed.
^ | 94 | Replaced by the bell (beep) character.
_ | 95 | Pauses program operation until any key is pressed.

Special Characters Used For Expire Warn Msg

Char | ASCII | Meaning
@ | 64 | "@" can be replaced by "nn Days" where 'nn' is the current number of days remaining. Also, it can be replaced by "nn more Use(s)" where 'nn' is the number of Execute Counts remaining before the product expires.

Special Characters Used For Startup Msg Message

Char | ASCII | Meaning
@ | 64 | Is used to suppress the display of the Startup Msg when the protected program is run. The first character of the Startup Msg would be an "@".
` | 96 | Replaced by a zero-suppressed serial number digit, i.e., if the digit that replaces this symbol is a leading zero, it will not be displayed.
~ | 126 | Replaced by a non-zero-suppressed serial number digit, i.e., the digit that replaces this symbol will always be displayed. Even if it is a leading zero.
% | 37 | Replaced by the serial number check digit.

Examples of using the "@", "`", and "~" symbols, are included in the section on Startup Msg Data.


Startup Msg Data

NOTE: Before reading this section, it is important that you have read the section on Special Characters.

The EVERKEY Startup Msg is only displayed by DOS Point-&-Shoot protected programs. The Startup Msg is not used by programs using KECHK.

The Startup Msg will be displayed by your DOS Point-&-Shoot protected program(s) at startup as long as the 1st character of the message is not an @ symbol. The Startup Msg is normally used to hold information that is unique for each Customer. This information can be as generic as the serial number or as specific as the Customer's name and address. The Startup Msg can be programmatically accessed and displayed in your own format.

Using the Startup Msg to display specific Customer information always allows a protected program's original owner to be determined. If you find out that your Products are being illegally transferred or resold, you will always know the original owner. This feature encourages and reminds Customers to abide by your license agreement. Since this Startup Msg information may potentially be very important, it is heavily protected by several layers of encryption and protection. Any attempt to modify the Startup Msg results in the protected program ceasing to function.

One way to have a unique Startup Msg for each Customer is to manually edit the Options file each time you protect a Product. For small volume this may be acceptable, but the Kebuild.exe program has several built-in features that make this cumbersome procedure totally unnecessary.

The most common Startup Msg setup is to display the developer's copyright notice and the Customer's alphanumeric serial number. Let us use an example where we want the automatically displayed Startup Msg to look like this:

Copyright (c) 2002

XYZ Software

Serial# K150-26001

The next Product's serial number would be "K150-26002" and so on. Given these requirements, let us examine how the Options file would be set up in order to achieve the above Startup Msg appearance.

Next, the first serial number should be "K150-26001", but you do not want to enter the new serial number for each subsequent diskette. For this, we would set the Serial Number option to "26001" and the Increment option to "1". These settings would cause the Kebuild.exe program to use "26001" as the first serial number and add one to it each time a Product is protected. Since we want the displayed serial number to include an alpha prefix, we will set up our Startup Msg as follows:

Copyright (c) 2002|XYZ Software|Serial# K150-~~~~~

The five '~' Special Characters will be replaced with the least significant digits of the current serial number.

Another common Startup Msg setup displays the Customer name to which the Product is registered. Again, you may wish to manually edit the Options file for each Product, but there is an easier way. Let us assume you want your Startup Msg to look like this:

This product is Registered to: XYZ Software

This can be done quite simply by setting up a Startup Msg like this:

This product is Registered to:

The Customer name may be specified with the "/S" parameter of the Kebuild.exe program. For example:

kebuild [Options file, drive-ID, etc.] /S XYZ Software

Anything that is entered after the "/S" parameter will be appended to the Startup Msg that resides in the Options file. The Kebuild.exe program allows for a Startup Msg of up to 120 bytes in length to be specified.

NOTE: Kebuild.exe displays the first 150 bytes of the Startup Msg in the Protection Status area and writes them to the log file if one is specified.

The display will look something like this:

==== EVERKEY ==== 05/16/2002 ==== 06:28p ====

Options File: KEEPER.EVK

Build Path: NONE

Device Type: Rockey

Serial #: 7001131

Startup Msg: KEEPER System by XYZ Software Inc.

Copyright (c) 2002 XYZ Software, Inc.

All Rights Reserved

Although, it is very handy to be able to display the Startup Msg automatically, you might want to have total control over the format and display of this information. You can do this by directly accessing the Startup Msg via the SIB. For information on how to do this, please refer to Accessing the Secure Information Block (SIB).


Making Product Upgrades

If you plan to send out protected upgrades for Customers who already have Authorization Devices, the new upgraded Product programs will have to be protected with the same Options file as the original programs. This is one reason why you should use a separate Options file for each Product you protect.

Your protected programs are "married" to a Authorization Device by four pieces of information:

  • The Product Name.
  • The Encryption Key.
  • The Product Serial Number.
  • The PIN.

The Options file will "remember" all of the necessary protection options except the Product serial number. We strongly recommend that you keep some kind of record (or database) of product serial numbers, even if you are not planning to send out upgrades. Creating an upgrade diskette simply consists of protecting the new version of your product with the same protection options as the original.

If for some reason you are unsure of the Product's serial number or, if you wish to create a "generic" upgrade diskette that will work for any of your Customers, you can bypass these internal checks by changing the Verify option. Once the upgrade has been produced, it can be shipped or emailed to the Customer who only has to copy the new protected upgraded programs over the old ones. These upgraded programs will function normally when used on a computer that has the proper Authorization Device plugged in.

If you are building upgraded protected programs, be sure to test at least one with a properly configured Authorization Device installed. This will ensure that your new upgraded program will have no problems when it is used by your Customer.


Keshow Overview

The Keshow.exe program used to show the Product ID, Serial Number and other useful protection information stored in your Authorization Devices. It can also be used as a protection verification tool; that is, it can be used to verify the integrity of the protection on your Product's Authorization Device before shipping it to the Customer. This is a DOS program which also runs in all Windows environments.

The Keshow.exe program does not show information about your protected program. Keshow.exe also cannot show information about EVERKEY iButtons on Serial (COM) ports.


Keshow Operation

Let us assume that you have used Kebuild.exe to program two Authorization Devices for your Keeper and Flash Products.

To run Keshow.exe from the Windows Desktop, simply start the program using the Windows Start menu shortcut.

To run Keshow.exe from the Command Prompt:

  • Navigate to the folder containing the Keshow.exe program.
  • Type "keshow <Enter>"

Your screen might look something like Figure 8.

Figure 8 Typical Keshow Display

Notice that Keshow.exe displays information on all the Authorization Devices it finds. Here's a description of each field on the display:

Authorization Device Type:

This field specifies the type of Authorization Device that was found. EVERKEY Rockey indicates a Rockey device on a USB Port or Parallel Port. EVERKEY iButton indicates an iButton device in a Parallel Holder or older DS1410 Holder. Please note that the DS1405 Brick (an older security device) has a non-removable iButton and will be listed as a EVERKEY iButton In DS1410 Holder. The Keshow.exe program cannot show iButtons in Serial Holders.

Prod ID:

This is the Product Name field that appears on the Kebuild.exe Main Options screen.

On Port:

This is the I/O Port where Keshow.exe found the Authorization Device. USB means any USB port. LPT means a Parallel port. Keshow.exe cannot show information about iButtons on Serial (COM) ports.

Device# and Status:

This field will show a number and then the status of the Authorization Device. The number indicates how many devices were found so far. The Status will either contain AOK or an Error Code. AOK means the device is a valid EVERKEY Authorization Device that has not expired due to a date or execution Limit. If an Error Code is displayed, please refer to Errcode Overview for more information.

Serial #:

This field is the Serial Number from the Kebuild.exe Main Options screen.

Execs Left:

This field indicates the number of executions left before the Authorization Device expires. If there is no Exec-Count Limit, this field will show "Unl", meaning "Unlimited".

Days Left:

This field is the number of days left until the expiration date. This field will contain "Unlimited" if there is no Date Limit. If you programmed the Authorization Device with the Start Timer option set to Upon First Use, this field may show Not Started if your Product has not been used yet.

Lasered-ID:

This field indicates the permanent device serial number of the Authorization Device. This field cannot be reprogrammed and is guaranteed unique for each EVERKEY Authorization Device.

Update-Count:

This field indicates how many times the memory of the Authorization Device has been updated.

User-Data:

This field is only displayed if you have entered the correct PIN for this Product via the /P command line parameter. If displayed, this field show the current User-Data from the memory of the Authorization Device.

When running Keshow.exe from the Command Prompt, there are several command line parameters which override the way Keshow.exe operates. The following is a description of each one:

/? | This parameter displays all parameter options.
/B | This "Batch Mode" parameter allows Keshow.exe to run without asking for keyboard responses.
/H | This parameter displays all parameter options.
/O | This parameter tells Keshow.exe to produce a log file of the information displayed. This log file is named Keshow.log and it resides in the same folder as the Keshow.exe program.
/P n | Using this parameter to enter the Product's PIN will display the User-Data from the Authorization Device. The PIN is available from the Kebuild.exe Main Options screen. For example: Keshow /p 123456789 <Enter>

By running in Batch Mode, you can make Keshow.exe part of your quality assurance tests for your Product.

When running Keshow.exe in Batch Mode, you can check the DOS ERRORLEVEL to determine if the Status of the Authorization Device is "AOK" or not. If the Authorization Device is "AOK", the ERRORLEVEL will be set to 0. If not, the ERRORLEVEL will be set to the last three (3) digits of the Error Code. For example, if the Authorization Device fails with a 6021 Error, the ERRORLEVEL will be set to 21. If you have more than one Authorization Device plugged into the computer, the ERRORLEVEL will be set to the first one that fails. If you are checking more than one Authorization Device and find the ERRORLEVEL is 0, all the devices are "AOK".


KECHK Overview

KECHK is a function which allows your program to directly verify or interrogate the status of an Authorization Device at any time. Your program has complete control over when KECHK is called and what action is taken if the Authorization check passes or fails.

KECHK is supplied in two formats: Kechkd.obj is used by DOS and 16-bit Windows programs and Kechk32.dll is used by all 32-bit Windows programs. To simplify the text, this manual refers to them both as KECHK.

Information is exchanged between your program and KECHK via a Secure Communication Block (SCB) data area that resides within your program. Before your program calls the KECHK function, it must set up an SCB area which tells KECHK what to check. Once KECHK is called, it performs a check for your Authorization Device, reports the results to your SCB area, sets a Error Code and returns control to your program.

The calling of KECHK requires only one parameter, a pointer to the SCB. The returned value of the KECHK function itself is always zero (0) and does not need to be checked. The results of the Authorization check is returned in the SCB.


When To Call KECHK

The best time to check for Authorization is when your program is NOT in the middle of doing something else. The reason for this is that you have to allow for the possibility of the Authorization not being present. If the Authorization is not present, then you can inform the Customer and provide the option of Retry or Cancel without having to deal with anything else.

Usually, a good time to check for Authorization is when your program first starts executing before it has opened any files or databases. If your program runs a long time, you might also want to verify the presence of the Authorization every so often or between major operations.

How often should you call KECHK? Try to make this a realistic time limit to protect your application without being overly paranoid. Calling KECHK when the program starts up is fine for most programs. However, if your program runs all day, you might want to verify the presence of the Authorization Device every 15 minutes. Calling KECHK more often than that is seriously discouraged.

Also keep in mind that the lifetime of a Rockey Authorization Device depends on how often you update its memory. The EEPROM memory in the Rockeys can be re-written up to 100,000 times. That's a lot of updates, but it's not an unlimited amount. These examples will show how to predict a Rockeys lifetime:

  • If you build a Rockey without an Execution or Date limit, you should expect to be able to read the Rockey for up to 100 years.
  • If you build a Rockey with an Execution or Date limit, the device's memory is updated each time you verify the Authorization. So in this example, the lifetime of the Rockey really depends on how often your protected program calls the KECHK function. If your program checks the Authorization five times per day, then the Rockey will last approximately 54 years (100,000 updates divided by 5 times per day divided by 365 days per year). On the other hand, if your program checks the Authorization fifty times per day, then the Rockey will only last approximately 5 years (100,000 updates divided by 50 times per day divided by 365 days per year).


Adding a KECHK Call To Your Program

The easiest way to add an Authorization check to your program is to copy and paste from one of our Source Code Examples and then re-compile your program. We've provided a number of examples in various languages. For more information, please refer to Examples Folder.

The only customization of the source code required is to specify your unique Product Name and PIN. These fields are displayed when viewing the Options file with the Kebuild.exe program.

The Authorization check is actually performed by our supplied Kechk32.dll module.

DOS programs enjoy the option of "Point-&-Shoot" protection that does not require changing any source code or recompiling. We have also provided a Kechkd.obj module for DOS programs which can be used to perform "custom" Authorization checks.

Once an Authorization check has been added to your program, it can be distributed in a compressed format.


SCB Layout

This section describes the Secure Communication Block (SCB) data area that is used to exchange information between your program and the KECHK function.

Since the SCB resides within your program, the layout must be defined (declared) in your program so information can be passed to and from KECHK. The size of your SCB definition MUST be 80 bytes. Double check your code because some of the provided Sample Source Code did not define the full 80 byte area.

Here is the field layout of the SCB:

Field | Type | Offset (decimal) | Size (bytes) | Description
Error Code | Unsigned Word | 0 | 2 | Main KECHK Error Code. It will be zero if the Authorization check passed.
Error Status 1 | Unsigned Word | 2 | 2 | This field is used for Error information if the Error Code field is non-zero.
Error Status 2 | Unsigned Word | 4 | 2 | This field is used for Error information if the Error Code field is non-zero.
Function Code | Unsigned Byte | 6 | 1 | This field is used for you to tell KECHK what you want it to do. Each function is described in detail in KECHK Calling Procedure.
SCB ID | String | 7 | 5 | "Signature" (ASCIIZ) to verify that this block of memory is an SCB. It should be set to "..?Z" prior to calling KECHK.
Product Name | String | 12 | 9 | Product Name (ASCIIZ) to check for. This was set from the Product Name option of the Kebuild.exe Main Options screen.
Reserved | Unsigned Byte | 21 | 3 | Reserved for future use.
Product Serial# | Unsigned Dword | 24 | 4 | Product Serial Number to check for. This was set from the Serial Number option of the Kebuild.exe Main Options screen.
PIN | Unsigned Dword | 28 | 4 | Product–ID to check for. This was set from the PIN field of the Kebuild.exe Main Options screen.
Exec-Count Limit | Signed Word | 32 | 2 | Number of uses left until the Authorization Device expires. This value is originally set from the Exec-Count Limit of the Kebuild.exe Main Options screen. If the Authorization Device does not have an Exec-Count Limit, this field will be returned from KECHK as –1 (negative one).
Expire-Days Limit | Unsigned Word | 34 | 2 | Number of days left until the Authorization Device expires. This value is originally set from the Expire-Days Limit of the Kebuild.exe Main Options screen. If the Authorization Device does not have an Expire-Date, this field will be returned from KECHK as FFFF (hex).
Expire Date | String | 36 | 9 | Expiration date (ASCIIZ) of the Authorization Device. This value is originally set from the Expire-Date of the Kebuild.exe Main Options screen. The returned date string is always returned in MM/DD/YY format. If the Authorization Device does not have an Expire-Date, this field will be returned from KECHK as "-n/a-".
User-Data | Unsigned Byte | 45 | 16 | The first 14 bytes of this data can be used for anything you like. The last two bytes (16 bits) are called the User-Data flags and each bit flag can be turned on (set to 1) by the Renew.exe or Renew32.exe programs. This data was originally set from the User-Data of the Kebuild.exe Main Options screen.
ROM Serial# | Unsigned Byte | 61 | 6 | Permanent serial number of the Authorization Device ROM. This field is not guaranteed unique. As of EVERKEY v2.31, you should use the Lasered-ID field instead.
Lasered ID | Unsigned Byte | 67 | 8 | Permanent serial number of the Authorization Device. This field cannot be reprogrammed and is guaranteed unique for each EVERKEY Authorization Device.
Reserved | Unsigned Byte | 75 | 5 | Reserved for future use.


KECHK Calling Procedure

The following steps are used to perform a KECHK function call:

1. | Define the Secure Communications Block (SCB).
2. | Initialize the required fields of the SCB. The fields that must be initialized are listed with the description of the functions.
3. | Call the KECHK function.
4. | Check the Error Code field in the SCB to see if the Authorization check passed. If this field is zero, the Authorization check passed, and you continue as normal with your application. If the Authorization check passes, all the fields in the SCB will be available for display or other use.
5. | If the Error Code field in the SCB contains a non-zero value, the Authorization check failed, and you know that your Authorization Device is expired, invalid or NOT plugged into the computer. You can take whatever action you feel is necessary. You can display a message on the screen or you can just shut the program down. It should be noted that NONE of the returned SCB fields should be considered valid if the Authorization check fails, i.e. the Error Code field is non-zero.

NOTE: It is recommended that you display the Error Code, Error Status 1 and Error Status 2 fields returned by KECHK in a hexadecimal format. If these are not displayed, you will not be able to determine exactly why a Authorization check failed. The Errcode.exe program and our Technical Support staff will also need this information to help you resolve any Errors that you may encounter.

Here is a description of each KECHK function:

Function #0 This function will be preserved for backward compatibility, but new EVERKEY Developers should use Function #4 instead.

If the ROM Serial# field contains all zeroes, this function will verify that any Authorization Device is plugged into the computer. If the ROM Serial# field is non-zero, this function will check for the existence of that specific Authorization Device.

Function #1 | This function allows your program to check for the presence of your specific Authorization Device by specifying the Product Name and PIN. This function does not update the Exec-Count Limit or User-Data of the Authorization Device.
Before calling KECHK setup the following SCB fields:
Error Code | 6240 (hex) It's a good programming practice to always set the Error Code to this value before calling KECHK. If KECHK doesn't find your SCB, it can't update this field, but it will already be set to the correct Error Code and your program will take the proper action.
Function Code | 1
SCB ID | "..?Z"
Product Name | (your Product Name from the Kebuild.exe Main Options screen)
Product Serial# | Normally, you will set this field to zero so the Authorization check will pass as long as KECHK finds an Authorization Device with your specific Product Name and PIN. If you want the Authorization check to depend on matching the Product Name, PIN and Product Serial#, then set this field to the specific Serial Number that you want to match.
PIN | (the PIN from the Kebuild.exe Main Options screen)
The remaining SCB fields will be ignored by KECHK.

Function #2 | This function allows your program to check for the presence of your specific Authorization Device by specifying the Product Name and PIN. This function will also update the Exec-Count Limit of the Authorization Device. This function does not update the User-Data of the Authorization Device.
Before calling KECHK setup the following SCB fields:
Error Code | 6240 (hex) It's a good programming practice to always set the Error Code to this value before calling KECHK. If KECHK doesn't find your SCB, it can't update this field, but it will already be set to the correct Error Code and your program will take the proper action.
Function Code | 2
SCB ID | "..?Z"
Product Name | (your Product Name from the Kebuild.exe Main Options screen)
Product Serial# | Normally, you will set this field to zero so the Authorization check will pass as long as KECHK finds an Authorization Device with your specific Product Name and PIN. If you want the Authorization check to depend on matching the Product Name, PIN and Product Serial#, then set this field to the specific Serial Number that you want to match.
PIN | (the PIN from the Kebuild.exe Main Options screen)
Exec-Count Limit | Set this field to the number of "counts" that you want to ADD to the Exec-Count Limit. For example, if you want KECHK to add one count, set this field to "1". If you want to take one count away, set this field to "-1" (negative one).
The remaining SCB fields will be ignored by KECHK.

Function #3 | This function allows your program to check for the presence of your specific Authorization Device by specifying the Product Name and PIN. This function will also update the Exec-Count Limit AND the User-Data of the Authorization Device. Be careful with this function! Whatever User-Data you provide here will overwrite the entire 16 bytes of User-Data in the memory of your Authorization Device. If you want to preserve part of the User-Data, use Function #1 or #2 first to read the existing User-Data, update what needs to be changed and then use this function to write it back to your Authorization Device.
Before calling KECHK setup the following SCB fields:
Error Code | 6240 (hex) It's a good programming practice to always set the Error Code to this value before calling KECHK. If KECHK doesn't find your SCB, it can't update this field, but it will already be set to the correct Error Code and your program will take the proper action.
Function Code | 3
SCB ID | "..?Z"
Product Name | (your Product Name from the Kebuild.exe Main Options screen)
Product Serial# | Normally, you will set this field to zero so the Authorization check will pass as long as KECHK finds an Authorization Device with your specific Product Name and PIN. If you want the Authorization check to depend on matching the Product Name, PIN and Product Serial#, then set this field to the specific Serial Number that you want to match.
PIN | (the PIN from the Kebuild.exe Main Options screen)
Exec-Count Limit | Set this field to the number of "counts" that you want to ADD to the Exec-Count Limit. For example, if you want KECHK to add one count, set this field to "1". If you want to take one count away, set this field to "-1" (negative one).
User-Data | Set this field to the 16 bytes of data that you want to store in the secure memory of your Authorization Device.
The remaining SCB fields will be ignored by KECHK.

Function #4 | The main purpose for this function is to allow for a very fast check for the presence of your Authorization Device. This function does not update the Exec-Count Limit or User-Data of the Authorization Device. Since the purpose of this function is to perform the Authorization check as quickly as possible, it does not return any SCB fields except the Error Code, Error Status 1 and Error Status 2.
Before calling KECHK setup the following SCB fields:
Error Code | 6240 (hex) It's a good programming practice to always set the Error Code to this value before calling KECHK. If KECHK doesn't find your SCB, it can't update this field, but it will already be set to the correct Error Code and your program will take the proper action.
Function Code | 4
SCB ID | "..?Z"
Lasered-ID | If this field contains all zeroes, this function will verify that any Authorization Device is plugged into the computer. If this field is non-zero, this function will check for the existence of that specific Authorization Device. The easiest way to get the Lasered-ID for your Authorization Device is to use Function #1 specifying your Product Name and PIN. As a successful result of that function, the Lasered-ID of your specific Authorization Device will be returned in the SCB. From then on, you can this function for a very fast Authorization check.
The remaining SCB fields will be ignored by KECHK.


KECHK Misc. Considerations

Your install process should copy the Kechk32.dll file to your Product's program folder, NOT the Windows "System" or "System32" folder.

For more security, you may want to rename the Kechk32.dll file to something that will blend in with the names of the files that are included with your Product, e.g. Keeper.dll.

You cannot use the /PACK or /CP1 options when linking in the Kechkd.obj with Microsoft compilers.


RENEW and Kecodes Overview

The Renew process allows you to remotely and securely control and reset Execution Limits, Date Limits and the User-Data flags. This provides for some very creative marketing of your software. For example:

  • Using the Execution and/or Date Limits, you can virtually set up any kind of software "lease", easily customized to each Customer.
  • Using the option of removing the Execution and/or Date Limits allows you to make full-function demos that are converted into unlimited-use once the Customer purchases the Product.
  • The User-Data flags allow you to "turn on" up to 16 different Product functions. These could even be separate add-on Products. That means one Authorization Device could be used for up to 16 different Products!

The only requirement to use the Renew functions with your Product is that the Customer must have a copy of the Renew32.exe program. (If your Customers are running DOS or Windows 3.1x, they'll need the Renew.exe instead.) If you don't include this program with your Product, you can send it to your Customers later via email or internet.

The steps required to Renew a Product are:

  • Your Customer runs the Renew32.exe program. The Product Name, Serial# and Reset Use-Count (RUC) are displayed for each Authorization "Key" connected to the computer.
  • The Customer provides this information to you (if you don't already have it) and you run the Kecodes.exe program and provide it with this information.
  • Then, you tell the Kecodes.exe program what you want to Renew, e.g. Date Limit, Exec-Count Limit, User-Data flags, etc.
  • Kecodes.exe generates a 15-digit Renew Code, which you give to your Customer.
  • The Customer enters this code to the Renew32.exe program and their Authorization Device is Renewed.

This entire process could easily be handled via email or internet. Note that the Customer has no control over what gets Renewed. All they see is a 15-digit code. Also, for security reasons, each Renew Code can only be used once.


RENEW Operation

The Renew.exe and Renew32.exe programs allow you to remotely change the Execution Limit, Date Limit and User-Data flags stored in your Authorization Device.

Both programs do exactly the same thing. Renew.exe is used when running under DOS or Windows 3.1x and Renew32.exe is used when running under any 32-bit Windows system.

To safeguard your Product, the Renew programs do not allow a Customer to attempt to guess valid Renew Codes. If ten consecutive invalid codes are entered, the Renew program will issue Error Code 6072 and the Authorization Device can no longer be Renewed until it is reprogrammed by Az-Tech. However, it can still be used until it expires.

To run Renew32.exe, simply start the program using the Windows Start menu shortcut.

Your screen might look something like Figure 9.

Figure 9 Typical Renew32.exe Display

To run Renew.exe from the Command Prompt:

  • Navigate to the folder containing the Renew.exe program.
  • Type "Renew <Enter>"

Your screen might look something like Figure 10.

Figure 10 Typical Renew.exe Display

For either program, the Customer can abort the Renew operation at any time by pressing the <ESC> key.

If more than one "Key" is shown, select the one you want to Renew. For Renew.exe, just enter the number of the Key. For Renew32.exe, use the pull-down menu.

Next, the program displays the System date and allows you to confirm that it's correct since the Renew Code may be set to expire. If it's not correct, press the <ESC> key to exit the program. Reset the System date and restart the RENEW program.

Finally, you need to enter the Renew Code that was generated by the Kecodes.exe program. You can enter the code with or without the dashes. For Renew.exe, enter the code and press the <Enter> key. For Renew32.exe, enter the code and click the "Finish" button.

If a correct, code is entered, the RENEW program will display messages indicating which limits were Renewed or updated.

If an incorrect code is entered, the RENEW program will display:

Error 6075-0000-0000 Renew Code is invalid.

If this Error occurs, you should confirm that:

  • The Customer has entered the Renew Code correctly.
  • The Options file used in Kecodes.exe is actually the Options file that was used to program the Authorization Device.
  • The Serial Number and Renew Use-Count used in Kecodes.exe match what the RENEW program displays.
  • The System date is set correctly. If the clock on the computer running the RENEW program is set prior to the time when the Renew Code was generated, this Error will occur.


Kecodes Operation

This program will generate Renew Codes based on unique information about your Authorization Devices. Your Product's Encryption Key, Serial Number, PIN and Renew Use-Count are all required in order to generate a valid Renew Code. The only items you need to keep track of are the Product's Encryption Key and PIN.

The Serial Number and Renew Use-Count can be determined by asking the Customer to execute the RENEW program. Keeping track of the Encryption Key and PIN is not usually a problem, since they are saved in your Product's Options file.

To run Kecodes.exe from the Windows Desktop, simply start the program using the Windows Start menu shortcut.

To run Kecodes.exe from the Command Prompt:

  • Navigate to the folder containing the Kecodes.exe program.
  • Type "kecodes <Enter>"

Your screen might look something like Figure 11.

Figure 11 Typical Kecodes Display

Here's a description of each field on the display:

Today's Date:

Since Renew Codes can deal with Date Limits, you should always ensure this date is correct.

Option File Name:

Since the Encryption Key and PIN are required to generate a Renew Code, you must specify the Product's Options file name. You can enter the file name or press <F2> for a list of the available Options files.

Renew Exec Limit:

Enter one of the following:

  • A value (up to 9000) to ADD to the Exec-Counts remaining.
  • "Unl" to remove the Exec-Count Limit.
  • "No" to not modify the Exec-Count Limit.

Note that once an Authorization Device's Exec-Count Limit has been removed (set to "Unlimited"), it can not be reset to another lower value.

Renew Date Limit:

Enter one of the following:

  • A number of days (up to 999) to ADD to the current Expiration Date. Please note that the Expiration-Date cannot be reset to more that 999 days from today's date.
  • A new Expiration-Date in the format MM/DD/YYYY.
  • "Unl" to remove the Expiration-Days Limit.
  • "No" to not modify the Expiration-Date.

Note that once an Authorization Device's Expiration-Date Limit has been removed (set to "Unlimited"), it can not be reset to another lower value.

Update User-Data Flags:

If you have been using the User-Data area to store information for your program, you can change the last two bytes of this area with the RENEW programs. To change this information, enter new values (in hexidecimal) for the last two bytes of the User-Data. If you don't want to update one or both of these bytes, enter "No".

You cannot Renew the User-Data flags at the same time as renewing the Exec-Count Limit or the Expiration-Date Limit. If you need to perform both, you will need to provide your Customer with two Renew Codes.

Serial Number:

Enter the Product Serial Number of the Authorization Device to be Renewed. If you are generating more than one Renew Code, this will be the Serial Number for the first Renew Code generated.

Renew Use-Count:

The Renew Use-Count is the number of times that Renew has been used successfully on your Authorization Device. This is the number that appears after the dash ("-") when the RENEW program displays the Serial Number. This number ensures that a Renew Code can never be used more that once. If your Authorization Device has never been Renewed, this number will be zero (0). If you are generating more than one Renew Code and the Amount of Serial # Increment field is set to zero (0), this will be the Renew Use-Count of the first code generated.

Number of Renew Codes to generate:

Enter the number of Renew Codes to generate into this field. Normally, this field will be set to 1, however, you may generate up to 999 Renew Codes.

Amount of Serial # Increment:

If you are generating more than one Renew Code, specify the amount to increment the Serial Number between each code generated. The number entered in the Serial Number field will be for the first Renew Code generated, and then each Serial Number will be incremented. If you enter a zero (0) into this field, the Renew Codes generated will be for the same Serial Number, but for successive Renew Use-Counts. The number entered in the Renew Use Count field will be for the first Renew Code generated, and then the Renew Use-Count will be incremented by one (1) for each code generated.

Log Session:

This field specifies if the Kecodes.exe session will be saved to a log file. If you specify "Yes", any output of the code generation process will be written to a file in the current folder. The name of the file will be the name of the Options file with a CDS extension. If you specify "No", no log file will be kept.

KECODES Session ID:

This field is entirely optional. You can enter any information that you would like to have output on the listing of Renew Codes. You may wish to enter the Product name or the Customer's name, and then redirect the output to a printer to keep a record of the Renews that you have provided.


Generating the Renew Code

After you have entered the necessary information, press <F10> to generate the Renew Codes. The screen might look something like this:

Figure 12 Typical Kecodes Renew Codes Summary

It's always a good idea to use this summary screen to verify that you have used the correct information to generate the Renew Code.

If you have generated more Renew Codes than will fit on the screen, you can use the cursor control keys to scroll through the list of Renew Codes. You will notice a small arrow to the left of the top or bottom serial numbers on the screen indicating that there are more Renew Codes, and that you can scroll through them.

When you are finished reviewing the screen of Renew Codes, you can press <F10> to return to the main screen to change the options for generating more Renew Codes.

You can press <ESC> at any time to exit the Kecodes.exe program.

Every time a Product is renewed successfully, the Use-Count is incremented. This allows you to quickly determine exactly how many times you have provided a Renew Code to any given Customer. Even more important is the fact that this Use-Count is one of the "keys" used to determine the valid Renew Codes for a Product. If nothing else changes between Renews, this changing "key" forces a new unique Renew Code every time the Product is renewed. Therefore, the code can be used one time only, because the incremented Use-Count will now be incorrect if an attempt is made to use it again.


Kecodes Command Line Parameters

When running Kecodes.exe from the Command Prompt, there are several command line parameters which override the protection options or modify the way Kecodes.exe operates. The following is a description of each one:

/? | This parameter displays all parameter options.
/A nnnn | Amount (nnnn) of serial number increment. The default for the serial number increment is one (1).
/B | This "Batch Mode" parameter allows Kecodes.exe to run without asking for keyboard responses. If you use batch mode, you must also specify an Options file, Serial Number and a function to Renew (with either /C /D or /F).
/C nnnn | Exec-Count limit. The number given (nnnn) will be the amount to add to the Exec-Count Limit. A value of zero (0) will set the Exec-Count Limit to 'Unlimited'.
/D nnn | Expire-Days Limit. The number given (nnn) will be the amount to add to the Expire-Days Limit. A value of zero (0) will set the Expire-Days Limit to 'Unlimited'.
/F xx xx | Enter the hexadecimal values (xx) for the two User-Data flags. You must specify values for both flags. If you do not wish to enter the value for one flag, enter "NO" for that flag.
/G nnn | Number of Renew Codes to generate. The default is one (1).
/H | This parameter displays all parameter options.
/N nnnnnnnnn | Serial Number (nnnnnnnnn) to use.
/P nnnnnnnnn | PIN (nnnnnnnnn) to use.
/R nnn | Renew Use-Count. The default is zero (0).


RENEW Marketing Strategies

Converting limited-use "demo" diskettes into full-blown product diskettes can be used as a very appealing marketing technique, both from your perspective as well as the Customer's. Basically, it gives you the capability to put your software in the hands of many prospective buyers without risking illegal copying. Those who do decide to buy can receive the Product immediately (via a phone call, fax or email), and you do not have to deal with the extra overhead of shipping another Product.

This marketing approach can be summarized as follows:

  • You send out limited-use demo Products to prospective Customers.
  • Some prospective Customers evaluate your product favorably and decide to buy. They contact you, guarantee payment (credit-card, PO, etc.) and receive their unique Renew Code. This code is input to the RENEW program which converts their "demo" Products to unlimited use.
  • Some prospective Customers call and say they were just getting familiar with your Product when it "expired". You provide a Renew Code that renews the original limit that was set up, e.g. 50 uses, 30 days, etc. This gives these prospects the chance to continue their evaluation.

The User-Data flags also allow one Authorization Device to be used for up to 16 separate Products. Each User-Data flag could represent Authorization to use one Product. Customers could start by purchasing Authorization for one Product. Later, as they decide they need more Products, you could provide a Renew Code that turns on the User-Data flags for those new Products. And there's no need for you to ship another Authorization Device that the Customer has to install.


Accessing the Secure Information Block (SIB)

The SIB is available only for DOS Point-&-Shoot protected programs.

Although, it is a standard option to display the Startup Msg and/or the Serial Number each time the program is run, you may want to reference this information from your protected program. Access to these fields as well as most of the protection options is made available via a Secure Information Block (SIB). Accessing this information requires a technical understanding of programming in an DOS environment. Do not attempt to access the SIB unless you completely understand the information that follows.

Each time a protected program is used, EVERKEY first gets control (from the Operating System) and performs a number of tasks depending on what protection options were used. One of the tasks it performs is to build a decrypted copy of the Startup Msg in RAM. It then passes the address of this decrypted copy to your program. This allows your program to use this information as necessary. Bear in mind that this is only a copy of the real encrypted Startup Msg. Changing the information in RAM has no effect on the contents of the real Startup Msg.

The SIB is simply a block of memory that contains a decoded copy of the Serial Number, Startup Msg, etc. The size of this block is always 64 bytes plus the size of your Startup Msg, which can be up to 1024 bytes. Before your protected program is given control, EVERKEY sets up a far pointer (segment and offset) at displacement FCh in the DOS Program Segment Prefix (PSP). Your program can access the SIB fields by utilizing this pointer.

This information should be read and stored in variables at the start of your program. If you do not read the SIB information as the first thing in your program, the information may be overwritten by your program, and may not be available.

The structure of the SIB is as follows:

Field | Type | Offset (decimal) | Size (bytes) | Description
SIB ID | Char | 0 | 4 | SIB ID signature "AZKE"
I/O Port | Char | 4 | 1 | LPT port# where iButton was found.
Reserved | Char | 5 | 2 | Reserved for future use.
Product Name | Char | 7 | 9 | Product Name (ASCIIZ string) of Authorization Device.
Reserved | Char | 16 | 4 | Reserved for future use.
Product Serial# | Long | 20 | 4 | Product Serial Number of Authorization Device.
Reserved | Char | 24 | 6 | Reserved for future use.
Exec-Count Limit | Short | 30 | 2 | Number of uses left until Authorization Device expires.
Reserved | Short | 32 | 2 | Reserved for future use.
Expire-Days Limit | Short | 34 | 2 | Number of days left until Authorization Device expires.
Expire Date | Char | 36 | 9 | Expiration date (ASCIIZ) of Authorization Device.
Reserved | Char | 45 | 19 | Reserved for future use.
Startup Msg | Char | 64 | <1K | Startup Msg (ASCIIZ string)

NOTE: An ASCIIZ string is a group of ASCII characters which ends with a null (0) character.

For Examples of how to access the Secure Information Block in various DOS programming languages, please refer to Examples Folder.


Contacting Technical Support

We offer Unlimited Free Technical Support!

There are some things you can try to remedy a problem before contacting Technical Support. Even if these do not solve your problem, they will narrow down what is causing it. They are:

  • If the Error is 6043-0000-0000, be sure that the Az-Tech Device Drivers have been installed. The easiest way to do this is to use the Start->Run menu from the Windows taskbar to run the Azshow.exe program. If the program isn't found, you need to run the Azsetup.exe program to install the Device Drivers.
  • Enter the Error Code into the Errcode.exe program to see if it offers any suggestions. For more information, you can refer to Errcode Operation.
  • The Support section of our web site always has the latest problem resolution information. It's located at www.az-tech.com.

Before contacting Technical Support, it is important to collect the following information pertaining to the hardware/software being used when the problem occurred. The more information you give us, the quicker we can fix the problem.

  • The full Error Code, if possible. For example, 6043-0000-FE54.
  • The version of EVERKEY that's being used.
  • Is the protected program a DOS, 16-bit or 32-bit Windows program.
  • When did the Error occur. For example, did the Error occur while running the protected program, running Renew32.exe, etc.
  • Is the Authorization Device an iButton or Rockey?
  • The Operating System being used. For example, Windows XP, Windows 98, etc.
  • The computer type, include make and model of PC.

Here's how you can contact us:

Email: tech@az-tech.com
Web: www.az-tech.com
Fax: (816) 776-8398 Attention Tech Support
9:00am-4:30pm Central Time (GMT-06:00)


EVERKEY System Upgrades

The EVERKEY Copy Protection System is upgraded as needed to allow your Products to receive state-of-the-art protection. These upgrades are always available free of charge via our web site at www.az-tech.com.


EVERKEY Hardware Warranty

If a Rockey, iButton or Holder fails due to a manufacturing defect (not physical abuse) within one year of purchase, Az-Tech will replace the defective part free of charge as long as you adhere to our "EVERKEY Returned Merchandise Policy". Please refer to EVERKEY Returned Merchandise Policy .


EVERKEY Returned Merchandise Policy

1. | You must obtain a Return Merchandise Authorization number (RMA #) from Az-Tech Software, Inc. before returning any Product.
2. | The Product must not be physically damaged by abuse.
3. | Upon receipt, all Products will be inspected and at our discretion, credit may be refused or a restocking fee may be charged.
4. | You must include a copy of the original paperwork with the return.
5. | The Return Merchandise Authorization Number (RMA #) must be clearly marked on the original paperwork and on the outside of the package you are returning. Packages returned without an RMA # will be refused.
6. | The Customer will be responsible for all shipping charges to return the Product.


Errcode Overview

The Errcode.exe program will display information about an EVERKEY Error Code that you or your Customers may encounter. When possible, Errcode.exe will also suggest a solution to address the problem.


Errcode Operation

Start the Errocde.exe program from the Windows Start menu shortcut and enter "6043" as the Error Code. Your display should look something like this:

Figure 13 Typical Errcodes Display

Errcode.exe displays the description of the Error and when possible, a solution to fix the problem. These suggestions have been compiled by our Technical Support staff over the years and may save you from having to contact Az-Tech. If you still have a question about this Error, please contact us.

You can also enter your own notes about a particular Error Code by typing in the note and clicking the <Save Note> button. From then on, these notes will be displayed along with the Az-Tech information.

It's important to provide as much of the Error Code to the Errcode.exe program as possible. However, if you are missing part of the Error Code, Errcode.exe can still give partial help. Just enter "0" to skip the missing field. Please note that providing a partial Error Code may not result in the most reliable interpretation of the Error.


Common Error Codes

For your program's security, we are unable to publish a complete Error message listing. We have made every effort, however, to make the non-secure Error messages as clear and explanatory as possible.

If you are not able to resolve the problem from the Error message, use the Errcode.exe program. If you still need help, contact Az-Tech Technical Support. You will be given any additional assistance you require. For more information, please refer to Contacting Technical Support .

6001 | Customer requested Exit from program.
6005 | EVERKEY has detected that the protected program has been corrupted or illegally modified.
6021 | The Rockey or iButton Authorization Device does not contain a valid Az-Tech signature. The device needs to be reprogrammed by Az-Tech.
6043 This Error means that the protected program is not finding the Rockey or iButton Authorization Device. The most common reasons that may occur are:
  1. Ensure that the Rockey or iButton is plugged into the computer. If you are using USB Rockeys, you can tell that the device is plugged in correctly when the LED is solidly illuminated. If the LED is blinking, the Az-Tech Device Drivers have not been installed properly.
  2. Verify that the Az-Tech Device Drivers have been installed. If you have used the Azsetup.exe program to install the drivers, you can use the Start->Run menu from the Windows taskbar to run the Azshow.exe diagnostic program. This program will tell if the drivers have been installed correctly . If the program is not found, then the drivers need to be installed. To do this, run the Azsetup.exe program.
  3. If you are using iButtons in Parallel Holders, verify that any connected printer is powered up and online. Also ensure that the latest version of the printer driver has been installed because some printer drivers don't like to "share" the printer port.
  4. If you are trying to access iButtons from a 16-bit program running under Windows 2000 or Windows XP, be sure that UserPort is active. To do this, first use the Start->Run menu from the Windows taskbar to run "userport". Then, on the UserPort dialog, click "Start" and then "Exit".
6051 | Specified program name not found on the Kebuild.exe Build Path. You can eliminate this Error message by correcting the spelling of this program name in the Options file.
6059 | Program file is not a valid DOS .EXE file. EVERKEY cannot Point-&-Shoot protect native Windows programs. They must be protected using the Kechk32.dll.
6060 | No programs specified to be protected were found on this diskette. Ensure the programs (valid .EXE or .COM) to be protected are on the diskette and the Options file specifies these programs.
6064 | The program indicated is already protected. Kebuild.exe will not re-add protection.
6066 | DOS or Language system file was left unprotected. This message is for your information to let you know which programs are not protected.
6072 | Customer entered an invalid Renew Code 10 consecutive times. The Authorization Device cannot be Renewed until it is reprogrammed by Az-Tech. However, it can still be used until it expires.
6073 | The System date is set incorrectly. If the clock on the computer running the RENEW program is set prior to the time when the Renew Code was generated, this Error will occur.
6074 | Could not Renew specified limits. Either they were already unlimited or at their maximum value.
6075 This Error is caused by:
  1. The Renew Code was entered incorrectly. Try again.
  2. The incorrect Options File, Serial Number or Renew Use-Count was specified to the Kecodes.exe program when the code was generated. In this case, the Renew Code needs to be re-generated using the correct information.
  3. A very old version of the RENEW program is being used and the code was generated with a different version of the Kecodes.exe program. To correct this problem, just email the latest version of the RENEW program to the Customer and try the code again.
6112 | Error opening, closing, or reading the file specified for containing the Startup Msg. Ensure file is not damaged, and resides in the folder specified by the Options file.
6113 | External Startup Msg file does not contain the '@' character. Ensure each Startup Msg in the file has an '@' following it.
6142 | The Authorization Device has expired due to the Execution Count Limit has been reached.
6143 | The Authorization Device has expired due to the Program being operated past the Expiration Date.
6144 | The Operating System Date/Time is set BEFORE the Date/Time recorded the last time the Authorization Device was accessed.
6146 | Exec-Count update value is larger than current Exec-Count.
6240 | KECHK could not locate the Secure Communication Block (SCB).
6241 | The Secure Communication Block (SCB) passed to KECHK contains an invalid Function code.


Files to Add to Your Product

The Kechk32.dll file will have to be added to your Product if your protected program is a 32-bit Windows program.

If you plan to allow the Customer to Renew the Authorization Limits, you will also need to add the Renew32.exe program to your Product. (DOS Products should use the Renew.exe DOS program.) This program may be renamed.

The Azsetup.exe program is used to setup all the necessary Az-Tech Device Drivers for all 32-bit Windows Operating Systems. This program should be included with your Product and executed prior to trying to access your Authorization Device. If your Product will ONLY be used on a DOS or Windows 3.1x Operating System, Device Drivers are not required.

If you want to install the necessary Device Drivers as part of your Product's installation process, please reference the section named Drivers Folder.


Main EVERKEY Folder

The following files are installed to the main EVERKEY folder that you specify when running the Setup program:

Kebuild.exe | EVERKEY System program used to create/edit Options files and program your Authorization Devices (Rockeys and iButtons). This is a DOS program which also runs in ALL Windows environments.
Kechk32.def | Module definition file that specifies which functions are exported from Kechk32.dll. (Used by Borland C++ v4 or later.)
Kechk32.dll | This is a dynamic link library that allows you to perform custom protection checks from a 32-bit Windows program.
Kechk32.exp | Contains the Exported function names for Kechk32.lib. (Used by Microsoft Visual C++ v4 or later.)
Kechk32.lib | Import library for Microsoft Visual C++ v4 or later.
Kechkd.obj | Linkable object module used to perform custom Authorization checks from DOS programs.
Kecodes.exe | EVERKEY System program used to generate unique codes used by the Renew.exe and Renew32.exe programs. These codes allow you to remotely change the Exec-Count Limit, Expire-Date and User-Data flags that are stored in Authorization Devices. This is a DOS program which also runs in ALL Windows environments.
Keshow.exe | EVERKEY System program used to show the Product ID, Serial Number and other useful protection information stored in your Authorization Devices. This is a DOS program which also runs in all Windows environments.
Renew.exe | Utility program that allows you to remotely change the Exec-Count Limit, Expire-Date and User-Data flags that are stored in Authorization Devices. This program is only provided to support DOS and Windows 3.1x environments. For all Windows 32-bit environments, we recommend you use the Renew32.exe program.
Renew32.exe | Utility program that allows you to remotely change the Exec-Count Limit, Expire-Date and User-Data flags that are stored in Authorization Devices. This is a 32-bit Windows program which will not run under DOS or Windows 3.1x.


Drivers Folder

In order for EVERKEY to access Rockeys and iButtons on all Windows 32-bit platforms, Az-Tech Device Drivers must be installed. Device Drivers are not required for DOS or Windows 3.1x. This folder contains all the various Driver files as well as the Azsetup.exe and Azshow.exe programs.

Since there are so many Windows systems to support, it's become very complex to install all the right Device Drivers for all the different platforms. We recommend that you redistribute the latest version of the Azsetup.exe program and let it handle installing the Az-Tech Device Drivers. If you want to setup the Device Drivers yourself, please refer to Device Driver Requirements.

The Azshow.exe program is a diagnostic program used to determine if all the necessary Device Drivers are installed correctly. It is installed automatically by the Azsetup.exe program and can be run by using the Start->Run menu from the Windows taskbar.

The following files are installed to the Drivers folder under the main EVERKEY folder. Here are the details about each Driver file, including where it should be placed on the Customer's Windows system:

Driver File | For O/S | Version | Size | Date (m/d/y) | <Windir> Folder
Downtvdd.dll | NT | n/a | 11,776 | 07/10/98 | System32
Ds1410d.sys | NT/2K/XP | n/a | 6,592 | 06/18/01 | System32\Drivers
Ib10e32.dll | 9x/ME/NT/2K/XP | 3,2,0,13 | 86,016 | 07/02/01 | System (9x/ME) or System32 (NT/2K/XP)
Ib97e32.dll | 9x/ME/NT/2K/XP | 3,2,0,12 | 90,112 | 06/18/01 | System (9x/ME) or System32 (NT/2K/XP)
Ib97u32.dll | 9x/ME/NT/2K/XP | 3,2,0,12 | 94,208 | 06/18/01 | System (9x/ME) or System32 (NT/2K/XP)
Ibfs32.dll | 9x/ME/NT/2K/XP | 3,2,1,0 | 131,072 | 10/03/01 | System (9x/ME) or System32 (NT/2K/XP)
Rockey9x.vxd | 9x/ME | n/a | 28,252 | 08/20/02 | System
Rockeynt.sys | NT/2K/XP | 4,0,1234,1 | 18,223 | 12/10/01 | System32\Drivers
Rockusb.inf | 98/ME/2K/XP | n/a | 2,098 | 12/10/01 | Inf
Rockusb.sys | 98/ME/2K/XP | 4,0,1000,1 | 23,384 | 08/20/02 | System32\Drivers
Rockvdd.dll | NT/2K/XP | n/a | 10,752 | 12/10/01 | System32
Userport.exe | 2K/XP | n/a | 11,776 | 05/29/01 | (<Windir> Folder)
Userport.sys | 2K/XP | n/a | 4,256 | 11/28/00 | System32\Drivers
Vsauthd.vxd | 9x/ME | n/a | 11,366 | 06/24/02 | System


Device Driver Requirements

These tables describe which Az-Tech Device Drivers are required for each Program Type for Operating System.

Drivers Required for running on DOS or Windows 3.1x:
Program Type | iButton in Parallel Holder | iButton in Serial Holder | Rockey Parallel | Rockey USB
DOS or Win16 | No Drivers Req'd | Not Supported | No Drivers Req'd | No Platform USB Support
Win32 | Win32 Programs will not run on DOS or Windows 3.1x Platform

Drivers Required for running on Windows 95A or 95B (OSR2):
Program Type | iButton in Parallel Holder | iButton in Serial Holder | Rockey Parallel | Rockey USB
DOS or Win16 | No Drivers Req'd | Not Supported | Rockey9x.vxd | No Platform USB Support
Win32 | Ib10e32.dll, Ibfs32.dll, Vsauthd.vxd | Ib97e32.dll, Ib97u32.dll, Ibfs32.dll | Rockey9x.vxd | No Platform USB Support

Drivers Required for running on Windows 98, 98SE or ME:
Program Type | iButton in Parallel Holder | iButton in Serial Holder | Rockey Parallel | Rockey USB
DOS or Win16 | No Drivers Req'd | Not Supported | Rockey9x.vxd | Rockusb.inf, Rockusb.sys
Win32 | Ib10e32.dll, Ibfs32.dll, Vsauthd.vxd | Ib97e32.dll, Ib97u32.dll, Ibfs32.dll | Rockey9x.vxd | Rockusb.inf, Rockusb.sys

Drivers Required for running on Windows NT4, Service Pack 2 thru 6:
Program Type | iButton in Parallel Holder | iButton in Serial Holder | Rockey Parallel | Rockey USB
DOS or Win16 | Downtvdd.dll, Ds1410d.sys | Not Supported | Rockeynt.sys, Rockvdd.dll | No Platform USB Support
Win32 | Ds1410d.sys, Ib10e32.dll, Ibfs32.dll | Ib97e32.dll, Ib97u32.dll, Ibfs32.dll | Rockeynt.sys | No Platform USB Support

Drivers Required for running on Windows 2000 or XP:
Program Type | IButton in Parallel Holder | iButton in Serial Holder | Rockey Parallel | Rockey USB
DOS or Win16 | Userport.exe, Userport.sys | Not Supported | Rockeynt.sys, Rockvdd.dll | Rockusb.inf, Rockusb.sys, Rockvdd.dll
Win32 | Ds1410d.sys, Ib10e32.dll, Ibfs32.dll | Ib97e32.dll, Ib97u32.dll, Ibfs32.dll | Rockeynt.sys | Rockusb.inf, Rockusb.sys

These Windows Registry entries are required:

For Kechk32.dll and Renew32.exe on All 32-Bit Windows Platforms:
[HKEY_LOCAL_MACHINE\Software\Az-Tech Software\EVERKEY]
"PortsToCheck"=string:"Lpt1, Lpt2, Com1, Com2, Usb1"
NOTE: "Usb1" means check all USB and Parallel ports for Rockeys but don't check any COM or LPT ports for iButtons..

For Ibfs32.dll on All 32-Bit Windows Platforms:
[HKEY_LOCAL_MACHINE\Software\Dallas Semiconductor\iButton TMEX\3.00]
"MainDriver"=string:"IBFS32.DLL"
"TYPE1"=string:"IB97E32.DLL"
"TYPE2"=string:"IB10E32.DLL"
"TYPE5"=string:"IB97U32.DLL"

For Downtvdd.dll on Windows NT4:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\VirtualDeviceDrivers]
"VDD"=multistring:"<WINDIR>\SYSTEM32\DOWNTVDD.DLL"
NOTE: This Registry entry can contain several strings from different vendors.

For Ds1410d.sys on Windows NT4, 2K and XP:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DS1410D]
"ErrorControl"=dword:00000001
"Group"=string:"Extended Base"
"Start"=dword:00000002
"Tag"=dword:00000002
"Type"=dword:00000001

For Rockey9x.vxd on Windows 95A, 95B (OSR2), 98 and ME:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\Rockey9x]
"StaticVxd"=string:"Rockey9x.vxd"
"Support"=dword:00000000
"TestBusy"=dword:00000001
NOTE: This entry is only required for 16-bit programs. If a 32-bit program accesses a Rockey, this entry gets built automatically.


UserPort

If you have a 16-bit DOS or Windows program that uses iButtons and will be installed to a Windows 2000 or Windows XP system, your Customers will need to start UserPort. This program is installed by the Azsetup.exe program.

Please note that UserPort is only required for iButton access by 16-bit programs running under Win2K or WinXP. It is not required by any other version of Windows. Also, Rockeys and 32-bit programs do not require UserPort.

UserPort must be manually started once and will thereafter start automatically each time Windows is booted. Of course, you can manually stop it at any time.

To START UserPort:

  • Be sure that the Az-Tech Device Drivers have been installed.
  • Be sure you're running on a Windows 2000 or Windows XP system.
  • Click "Run" on the Windows "Start" menu.
  • Enter "userport" and click "OK".
  • Click the "Start" and "Exit" buttons on the UserPort dialog.

To STOP UserPort:

  • Click "Run" on the Windows "Start" menu.
  • Enter "userport" and click "OK".
  • Click the "Stop" and "Exit" buttons on the UserPort dialog.


Examples Folder

This folder contains a number of subfolders, each containing Source Code Examples in various languages. Most of these examples show how to perform a KECHK Authorization check from your program. The DOS folder also contains examples for how to access the SIB from the Point-&-Shoot protected program.


Help Folder

The following files are installed to the Help folder under the main EVERKEY folder:

Azicon.dll | This dynamic link library is used as a container for the Windows icons used by the EVERKEY System.
Errcode.exe | Utility program that allows you to get detailed information about EVERKEY Error Codes. This is a 32-bit Windows program.
Errcode.hlp | This is the Help file for Errcode.exe.
Everkey.chm | Help file that contains the complete text of the EVERKEY Users manual. This is a 32-bit Compiled HTML Help file.
Everkey.reg | This is a text file used by the Windows Registry Editor. You may update this file to specify which I/O ports will be checked when EVERKEY looks for Authorization Devices.
Readme.txt | This text file contains the latest information which may not appear in the EVERKEY Users manual. Please review this informational file.


Redistributable Files

As a licensed owner of the EVERKEY Copy Protection System, you are entitled to distribute uncompressed or compressed versions of the following EVERKEY files:

Azsetup.exe | Azshow.exe
Downtvdd.dll | Ds1410d.sys
Ib10e32.dll | Ib97e32.dll
Ib97u32.dll | Ibfs32.dll
Kechk32.dll | Renew.exe
Renew32.exe | Rockey9x.vxd
Rockeynt.sys | Rockusb.inf
Rockusb.sys | Userport.exe
Userport.sys | Vsauthd.vxd

You may use the following EVERKEY files to link with your program:

Kechk32.def
Kechk32.exp
Kechk32.lib
Kechkd.obj

You may also incorporate any of our provided Source Code Examples into your Product for distribution.

You may not distribute any other file included with the EVERKEY Copy Protection System.


Document Conventions

This manual uses visual cues to help you locate and understand information easily. These conventions are:

This | Represents
Bold | Files, commands and the command line parameters that follow. You must type commands and their parameters exactly as they appear.
Italic Bold | Italicized, Bold items are response options.
ALL CAPITALS | Capitalized words indicate names of products and folders.
<key> | Letters surrounded by angled brackets indicate individual key or button presses.


EVERKEY License Agreement

This legal agreement ("AGREEMENT") is between you (either an individual or a company) and Az-Tech Software, Inc. ("AZ-TECH"). By installing, copying or otherwise using any of the EVERKEY computer programs ("SOFTWARE"), you are agreeing to be bound by the terms and conditions of this AGREEMENT. If you do not agree to the terms and conditions of this AGREEMENT, return the SOFTWARE, the provided written materials ("DOCUMENTATION") and all other package items, within thirty (30) days of purchase, to the place where you obtained them. This AGREEMENT may be modified only in writing signed by you and AZ-TECH.

  1. Grant of License: AZ-TECH grants you a non-exclusive limited license to use the SOFTWARE on a computer, and to use the DOCUMENTATION, in accordance with the terms and conditions of this AGREEMENT. This license is not altered by additions and upgrades to the SOFTWARE. AZ-TECH also grants you the right to reproduce and distribute executable programs protected by the SOFTWARE.
  2. Copyright and Other Proprietary Rights: The SOFTWARE and DOCUMENTATION are owned by AZ-TECH and protected by United States copyright laws and international treaty provisions. Programs protected by the SOFTWARE are not required to acknowledge that fact by printed or displayed notice. You may not copy the DOCUMENTATION. AZ-TECH retains all rights, title interest and ownership of, in, and to all copies of the SOFTWARE, and the DOCUMENTATION. AZ-TECH reserves the right to modify and/or enhance the SOFTWARE or DOCUMENTATION without obligation to notify you of such changes or to furnish them to you.
  3. Term: This license is effective from the date you receive the SOFTWARE and continues until terminated. You may terminate this AGREEMENT at any time by returning to AZ-TECH all copies of the SOFTWARE, the DOCUMENTATION, and all other package items. This license shall terminate immediately, if you fail to comply with any term or condition of this AGREEMENT. Upon such termination: (a) AZ-TECH shall have the right to seek any legal or equitable remedies that may be available to AZ-TECH; and (b) you shall immediately return all copies of the SOFTWARE, the DOCUMENTATION, and all other package items to AZ-TECH, without refund.
  4. Restrictions: You may not assign or transfer this license, any copies of the SOFTWARE, the DOCUMENTATION and/or any other package items. Any attempt to sublicense, assign, or transfer any of your rights, duties, or obligations under this AGREEMENT is void. You may not reverse engineer, decompile, or disassemble the SOFTWARE, and you may not modify, translate, or create derivative works from the SOFTWARE and/or DOCUMENTATION. You agree to protect the SOFTWARE and DOCUMENTATION from unauthorized publication, use, reproduction, and/or distribution.

    LIMITED WARRANTY

  5. Limited Warranty: AZ-TECH warrants that the physical media on which the SOFTWARE is provided, the DOCUMENTATION, and all other package items will be free from material defects under normal use for a period of one (1) year from the date you received delivery.
  6. Limitations of Remedies: AZ-TECH's entire liability and your exclusive remedy shall be, at AZ-TECH's option, either (a) return of the price paid or (b) repair or replacement of the SOFTWARE, the DOCUMENTATION, or other package items that do not meet AZ-TECH's Limited Warranty. This Limited Warranty is void if failure of the SOFTWARE, the DOCUMENTATION, or other package items has resulted from accident, abuse, or misapplication. Any replacement SOFTWARE, DOCUMENTATION, or other package items will be warranted for the remainder of the original warranty period.
  7. No Other Warranties: AZ-TECH disclaims all other warranties, either expressed or implied, to the maximum extent of the law. This includes but is not limited to warranties of merchantability and fitness for a particular purpose, with respect to the SOFTWARE, the DOCUMENTATION, and all other package items.
  8. No Liability For Consequential Damages: In no event shall AZ-TECH or its dealers or distributors be liable for any damages whatsoever (including, without limitation, damages for loss of business, business interruption, loss of business information, or other pecuniary loss) arising out of the use or inability to use the SOFTWARE, the DOCUMENATION, or other package items, even if AZ-TECH has been advised of the possibility of such damages. In no event shall AZ-TECH's liability, however founded, exceed the price paid by you for this license.


EVERKEY Copyright Notice

Copyright (c) 1990 - 2002

Az-Tech Software, Inc.

All Rights Reserved

THIS SOFTWARE AND MANUAL ARE BOTH PROTECTED BY U.S. COPYRIGHT LAW (TITLE 17 UNITED STATES CODE). NO PART OF THIS MANUAL OR THE REFERENCED SOFTWARE MAY BE REPRODUCED IN WHOLE OR IN PART, STORED IN A RETRIEVAL SYSTEM, OR TRANSMITTED BY ANY MEANS, ELECTRONIC, MECHANICAL, PHOTOCOPYING, RECORDING, OR OTHERWISE, WITHOUT PRIOR WRITTEN PERMISSION FROM THE PUBLISHER. UNAUTHORIZED REPRODUCTION AND/OR SALES MAY RESULT IN IMPRISONMENT OF UP TO ONE YEAR AND FINES OF UP TO $10,000 (17 USC 506). COPYRIGHT INFRINGERS MAY ALSO BE SUBJECT TO CIVIL LIABILITY.

Printed in the United States of America

First Printing – 1990

TRADEMARK ACKNOWLEDGMENTS

EVERLOCK and EVERKEY are trademarks of Az-Tech Software, Inc. within the United States and other countries. All other brand and product names are trademarks or registered trademarks of their respective companies.


Glossary of Terms

Authorization Device

Device Partition

Encryption Key

Exec-Count Limit

Expire-Date

Expire-Days Limit

iButton

KECHK

Options file

PIN

Point-&-Shoot

Product Name

Renew

Renew Use-Count

Rockey

SCB

SIB

User-Data


Authorization Device

This is the Rockey or iButton that's required for your Product to run. The Kebuild.exe program is used to program the Authorization Device with your unique protection information.


Device Partition

The iButton Authorization Device has three partitions that can be programmed. Each partition is treated as separate Authorization Device.


Encryption Key

This is an option on the Kebuild.exe Main Options screen that specifies a SECRET unique character sequence for the Product being protected. It is used along with the Product Name to determine the PIN for this Product. The Encryption Key is only used internally by the protected program(s). The Customer will never be required to know this field's contents.


Exec-Count Limit

This refers to the current number of times a Product can be used before the Authorization Device expires. This value is originally set from the Exec-Count Limit of the Kebuild.exe Main Options screen.


Expire-Date

This refers to the expiration date of the Authorization Device. This value is originally set from the Expire-Date of the Kebuild.exe Main Options screen.


Expire-Days Limit

This refers to the number of days left until Authorization Device expires. This value is originally set from the Expire-Days Limit of the Kebuild.exe Main Options screen.


iButton

An iButton is a type of EVERKEY Authorization Device that supports Parallel (LPT) and Serial (COM) ports. It contains the electronic circuitry to store the unique Authorization for your Product. This circuitry is housed inside of a 17mm stainless steel can rugged enough to withstand being dropped, stepped on or even submersed in water. iButtons contain their own lithium power source to keep your Authorization safe and secure for up to 10 years.


KECHK

KECHK is a function supplied by Az-Tech that allows your program to directly verify or interrogate the status of an Authorization Device at any time. Your program has complete control over when KECHK is called and what action is taken if the Authorization check passes or fails.


Options file

Options files describe how your Product will be protected. They contain all of the options for how to protect your Products. Options files are easy to identify because they will always have a file extension of "EVK", e.g. Defaults.EVK. The Kebuild.exe program is used to create and edit Options files.


PIN

The PIN or Product ID Number serves as a unique identifier for your Product. It is used to authenticate the program calling KECHK. This number should be treated as a company SECRET. The Kebuild.exe options Product Name and Encryption Key determine the PIN of a Product.


Point-&-Shoot

This is a method of direct software protection where Kebuild.exe encrypts your Product program(s) and adds an Authorization check. You do not need to change any source code or recompile. This is sometimes called "shell" or "envelope" protection. EVERKEY can only Point-&-Shoot protect DOS programs.


Product Name

This is an option on the Kebuild.exe Main Options screen that specifies a unique "short" name (up to 8 characters) for the Product being protected. This name will be stored in the Authorization Device (Rockey or iButton) for later verification by your protected program. It is also used along with the Encryption Key to determine the PIN for this Product.


Renew

This refers to the process of resetting the Exec-Count Limit, Expire-Date or User-Data stored in your Authorization Device. First, the Kecodes.exe program is used to generate a Renew Code based on your instructions for what is to be Renewed. When this code is provided to the Renew.exe or Renew32.exe program, the Authorization Device is updated per your instructions.


Renew Use-Count

This is the number of times that the Renew process has been used successfully on an Authorization Device. It is used by the Kecodes.exe program to ensure that each Renew Code is unique. This number is displayed by the Renew.exe and Renew32.exe programs.


Rockey

A Rockey is a type of EVERKEY Authorization Device that supports USB and Parallel (LPT) ports. It contains a custom microprocessor, EEPROM memory and specialized circuitry for random number generation. The USB device has a translucent plastic case that allows an LED indicator to be seen when the device is in use. Also, the USB case design allows the device to be strung on a key ring to support a "Floating License".


SCB

This refers to the Secure Communication Block that is an area of memory used to exchange Information between your program and KECHK.


SIB

This refers to the Secure Information Block which is an area of memory that contains information about a Point-&-Shoot protected DOS program. The Secure Information Block is not used by programs that use KECHK.


User-Data

This is 16 bytes of data that's stored securely in memory of the Authorization Device. The first 14 bytes of this data can be used for anything you like. The last two bytes (16 bits) are called the User-Data flags and each bit flag can be turned on (set to 1) by the Renew.exe or Renew32.exe programs. This data is originally set from the User-Data of the Kebuild.exe Main Options screen, but it can be freely updated using the KECHK function.