Obfuscation of Dynamically Generated PL/SQL Source Code

Obfuscation, or wrapping, of a PL/SQL unit is the process of hiding the PL/SQL
source code. Wrapping can be done with the wrap utility and DBMS_DDL subprograms. The wrap utility is run from the command line and processes an inputSQL file, such as a SQL*Plus installation script. The DBMS_DDL subprograms wrap a single PL/SQL unit, such as a single CREATE PROCEDURE command, that has been generated dynamically.

The advantages of obfuscating, or hiding, the source code of PL/SQL units with the wrap utility or wrap subprograms of the DBMS_DDL package are:

■ It is difficult for other developers to misuse your application, or business competitors to see your algorithms.

■ Your source code is not visible through the USER_SOURCE, ALL_SOURCE, or DBA_SOURCE data dictionary views.

■ SQL*Plus can process the obfuscated source files.

■ The Import and Export utilities accept wrapped files. You can back up or move wrapped procedures.


When obfuscating (wrapping) PL/SQL units note the following:

■ When wrapping a package or object type, wrap only the body, not the specification. This allows other developers see the information they need to use the package or type, but they cannot see its implementation.

■ PL/SQL source inside wrapped files cannot be edited. To change wrapped PL/SQL code, edit the original source file and wrap it again. You can either hold off on wrapping your code until it is ready for shipment to end-users, or include the wrapping operation as part of your build environment.

■ To be sure that all the important parts of your source code are obfuscated, view the wrapped file in a text editor before distributing it.

The following are limitations when obfuscating PL/SQL source code:


■ Although wrapping a compilation unit helps to hide the algorithm and makes reverse-engineering difficult, Oracle Corporation does not recommend it as a secure method for hiding passwords or table names. Obfuscating a PL/SQL unit prevents most users from examining the source code, but might not stop all attempts.

■ The wrapping does not obfuscate the source code for triggers. To hide the workings of a trigger, you can write a one-line trigger that calls a wrapped procedure.

■ Wrapping only detects tokenization errors, such as a runaway string, when obfuscating PL/SQL code. Wrapping does not detect syntax or semantic errors, such as tables or views that do not exist. Those errors are detected during PL/SQL compilation or when executing the output file in SQL*Plus.

■ Obfuscated PL/SQL program units cannot be imported into a database of a previous (lower) release. Wrapped compilation units are upward-compatible between Oracle releases, but are not downward-compatible. For example, you can load files processed by the V8.1.5 wrap utility into a V8.1.6 Oracle database, but you cannot load files processed by the V8.1.6 wrap utility into a V8.1.5 Oracle database.

Limitations of the wrap Utility:

■ Because the source code is parsed by the PL/SQL compiler, not by SQL*Plus, you cannot include substitution variables using the SQL*Plus DEFINE notation inside the PL/SQL code. You can use substitution variables in other SQL statements that are not obfuscated.

■ Most of the comments are removed in wrapped files.

Limitations of the DBMS_DDL wrap Function:

■ If you invoke DBMS_SQL.PARSE (when using an overload where the statement formal has datatype VARCHAR2A or VARCHAR2S for text which exceeds 32767 bytes) on the output of DBMS_DDL.WRAP, then you need to set the LFFLG parameter to FALSE. Otherwise DBMS_SQL.PARSE adds newlines to the wrapped unit which corrupts the unit.