Authentication

VM Labs SDK Internal Release 0.86.2
June 14, 2001

What Is Authentication?

Authentication is the process that ensures that only authorized versions of your software run on NUON enhanced products.

What Happens

Authentication consists of two parts: blessing the application, which is done by VM Labs, and authenticating the application, which is done by the NUON enhanced product whenever the application is loaded.

Blessing

The during the blessing process, information is added to your application in an encrypted format. This information is used at load time to verify that the application being loaded is authorized to run on that particular product.

Some sanity checks and additional processing are also executed during the blessing process. These include:

• Checking to ensure that the application is loaded into MPE3. Virtually all NUON applications are written with the expectation that they will be executing on MPE3. If the .cof file headers specify that the application is to be loaded into an MPE other than MPE3, a warning is written to the authentication log. The application will still be bless, however it may not actually run when it is loaded. If you are experiencing load time crashes of your application, check the authentication log that was returned to you at the time the application was blessed.
  
  
• Padding the application. A few early NUON products have a bug in the authentication code that will cause the system to crash if the amount of application information to be processed is 8 bytes less than an integral multiple of 64 bytes. This problem is known as the "fencepost" problem, and is fixed in almost all NUON enhanced products produced after September 2000.
  
  The fix for this problem is to pad all applications to contain an integral multiple of 64 bytes of loadable information. This is done by introducing a new section (named bless_p) into the coff file which pads it out to the correct size. Although this section contains loadable 0x00 bytes, it is overlaid by your .bss section at load time, and thus does not actually occupy any extra memory. Files that already contain an integral multiple of 64 bytes of information will not be padded.
  
  Warning! If your application does not have a .bss section, the current blessing process cannot pad your file. If this is the case, a warning message will be placed in the authentication log file. If your application cannot be padded and is one that triggers the fencepost problem, a notification that it will not run on early NUON systems will be placed in the authentication log file. The workaround for this is to manually add some bytes (16 will typically be enough) to your loadable data and have the file blessed again. This restriction will be removed with a future SDK release.

Authenticating

Authenticating is the process of checking your application when it is loaded into a NUON enhanced system. This consists of two parts:

1. decrypting the blessings
2. checking the contents of the .cof file against the blessings.

If the file loading firmware detects a mismatch between the blessings and the other contents of the file, the application will not be loaded and the DVD media will be ejected.

Getting an application blessed

When you submit an application to VM Labs for blessing, it will usually be turned around with in one business day. You will receive 3 or 4 files back, depending on whether the application was padded during the blessing process. These files are:

Thus if you submit the application pong.cof, you could expect to receive the files pong.cof, pong.cof.padded (if padding was needed), pong.cof.app, and pong.cof.auth.

The authentication log

The authentication log file contains important information about your blessed application. You should always check this file for any error or warning messages relating to your application. The following information is contained in the authentication log:

• the date/time the file was blessed;
• the name of the file being blessed;
• the version of the blessing application;
• (optional) warning messages if the application is targeted to an MPE other than MPE3;
• (optional) information about padding;
• (optional) warning messages if the file required padding but could not be padded;
• (optional) for non-padded files, a warning if the application will encounter the fencepost problem;
• the name of the file that was actually blessed (either appname.cof or appname.cof.padded);
• the name of the encryption key used;
• the application type (either game or hybrid);
• checksum info for:
  1. the file that was blessed; and
  2. the .cof contents of the appname.cof.app file.

The checksum information is a 32-bit CRC generated using the Linux cksum utility (available under Windows as part of the MKS toolkit). This information can be used to verify that the contents of the file are correct.

The authinfo application

The authinfo application dumps some basic information about an authenticated application. authinfo can also be used extract the blessed .cof file from the authenticated application. It runs on both Windows and Linux platforms. More information is available in the authinfo documentation.

Please email comments or questions to SDK-Release@vmlabs.com

This page © Copyright 2001 VM Labs, Inc. Mountain View, CA. All rights reserved.

This page and the directories it links to contain information Confidential and Proprietary to VM Labs, Inc. Unless otherwise noted, all contents are covered by non-disclosure agreement.
All contents, unless otherwise noted, are:

Copyright © 1997-2001 VM Labs, Inc. All Rights Reserved

For VM Labs internal use only.