Encryption Techniques

Encryption Techniques

This tip was excerpted from the book Oracle PL/SQL Programming, Second Edition by Steven Feuerstein and Bill Pribyl, O'Reilly and Associates, 1997.

Working with Encrypted Code

I have found the following steps to be useful in working with encrypted code:

• Establish standard file extensions which clearly identify encrypted code. I use the following extensions:
  

   
   Expression		Contents
   sps			Readable package specifications
   spb			Readable package bodies
   pls			Encrypted package specifications
   plb			Encrypted package bodies
   

• In Windows NT and Windows 95, you will have to open an MS-DOS window and then execute the wrapNN command from there. My suggestion is that you do not execute the program from within the Oracle bin directory, but instead cd to the directory containing your source code and execute the wrapNN.exe file from there.
• Create batch files so that you can easily, quickly, and uniformly encrypt one or more files. In Windows NT, I create bat files in the directories containing my source code which contain lines like this:

  
   c:orantbinwrap73 iname=plvrep.sps oname=plvrep.pls
   

Of course, you can also create parameterized scripts and pass in the names of the files you want to encrypt.

Impact of Encrypting Code

These are several points to consider as you move to encrypting you PL/SQL code base:

If you are an Oracle VAR, you probably are supporting multiple Oracle versions, from 7.0 or 7.1 to Oracle 8.x. If you are a lucky Oracle VAR, you will have (in many cases) one version of PL/SQL code which will work across all of these versions. If this is the case, then you can decide whether you want to have different encrypted versions of that same program for each Oracle release. You can do this (execute wrap71, wrap72, etc., for each of your versions) or you can simply encrypt at the highest version number (say, wrap80). This most recent encryption will compile in earlier versions. Earlier versions of encrypted code will not, however, compile properly in later versions of Oracle.

To encrypt your source code, you must place that code in an operating system file. If you are working in a PL/SQL development environment which allows you to "dump" this code to a file, wrap it, and then compile it back into the database - thereby wiping out your original, readable, and maintainable source code. This is not an issue as you deploy software to customers, but it could cause some uncomfortable situations as you develop and maintain applications.

You can only encrypt package specifications, package bodies, and standalone functions and procedures. You can run the wrapNN binary against any other sort of SQL and PL/SQL statement, but those files will not be changed.

You can tell when a program is encrypted by examining the program header. If there are no comments in the program header, then you will see this text in the first line of USER_SOURCE for an encrypted package body:

 	PACKAGE BODY  WRAPPED
 

Even if you don't notice the keyword WRAPPED on the first line, you will immediately know that you are looking at encrypted code because the text in USER_SOURCE will look like this:

and you know that no matter how bad your coding style, it surely isn't that bad.

Comment lines are removed from the encrypted program (who's going to read them?) except for the comment text which appears in the header of the program definition. That is, and comments that appear before the AS or IS keywords are preserved. This allows you to provide documentation on usage and copyright to all users of your software without revealing any proprietary information. For example, the following program description will appear in readable format in USER_SOURCE.

 CREATE OR REPLACE PACKAGE
 /*
 || Author: Steven Feuerstein
 || Overview: Collect all financial calcs together.
 */
 financials WRAPPED
 

I have found that when using large, complex comment blocks, the wrapNN program (at least through wrap73) either rejects valid source code for encryption, or encrypts successfully but then fails to compile. You may find that you need to simplify or shorten your standard headers when using the wrap utility.

Encrypted code is much larger than the original source. I have found in my experience that a 57KB readable package body turns into a 153KB encrypted package body, while a 86KB readable package body turns into 375KB encrypted package body. These increases in file size do result in increased requirements for storing source code in the database. The size of the compiled code stays the same.

NOTE: As of fall 1997, no one has yet admitted to having been able to (or bothering to) crack the encryption of wrapped PL/SQL code. But don't get your hopes up too high!