The Complete Guide to Wrapped PL/SQL

What is Oracle PL/SQL Wrapping?

Oracle PL/SQL wrapping, also known as obfuscation, is a built-in security feature that transforms readable PL/SQL source code into an encoded, unreadable format. When you "wrap" a procedure, function, package, or type body, the original source text is replaced with a block of seemingly random characters. To the Oracle database, however, the wrapped code is perfectly valid and executes exactly like the original.

The wrapping process is performed using either the command-line wrap utility or the DBMS_DDL.WRAP procedure. The output always begins with a header like CREATE OR REPLACE ... wrapped, followed by a long Base64-like encoded string.

Why Do Developers Wrap PL/SQL Code?

Despite its reversibility, wrapping is still widely used in enterprise Oracle environments. Here are the primary reasons:

• Intellectual Property Protection: Prevent competitors or clients from viewing proprietary business logic, pricing algorithms, or trade secrets embedded in the code.
• Security Through Obscurity: Hide sensitive information like hardcoded passwords, encryption keys, or table names from unauthorized database users who might have access to DBA_SOURCE.
• Licensing & Vendor Requirements: Many third-party Oracle applications (like Oracle E-Business Suite) are delivered wrapped to enforce licensing agreements and prevent modification.
• Accidental Modification Prevention: Discourage well-meaning developers from making ad-hoc changes to critical production code without proper change control.
• Compliance & Auditing: In some regulated industries, wrapping provides a layer of defense to satisfy auditors that source code is not easily accessible.

The Evolution of Oracle Wrap: From 9i to 23c

Oracle has strengthened the wrap algorithm over the years, making older versions much easier to reverse than newer ones. Understanding the version is critical for any unwrapping attempt.

Note: Our online tool uses the public-domain algorithm for Oracle 10g and newer to achieve full or near-full recovery.

How Oracle Wrap Works: A Step-by-Step Breakdown

To understand unwrapping, it helps to see the exact transformations Oracle applies. Here is the 10g+ wrapping pipeline:

1. Tokenization: The PL/SQL source is parsed into tokens (keywords, identifiers, literals).
2. LZ Compression: The token stream is compressed using a standard LZ algorithm (similar to gzip). This reduces the size of the final wrapped code.
3. SHA-1 Hash: A 20-byte SHA-1 hash of the compressed data is generated.
4. Concatenation: The hash is prepended to the compressed data: [20-byte hash] + [compressed source].
5. Byte Substitution: Every byte in this combined array is replaced with a different byte according to a fixed, 256-byte mapping table (the "substitution table"). This is the core obfuscation step.
6. Base64 Encoding: The substituted byte array is encoded in Base64 format.
7. Header Addition: A header containing the object type, name, and the word "wrapped" is added. A checksum line (e.g., 1e2 21d) may also be included for validation.

The unwrapping process simply reverses these steps: Base64 decode → reverse substitution → discard hash → LZ decompress.

Example: Before and After Wrapping

Original PL/SQL Procedure:

CREATE OR REPLACE PROCEDURE calculate_bonus (emp_id IN NUMBER) AS
  v_salary NUMBER;
BEGIN
  SELECT salary INTO v_salary FROM employees WHERE employee_id = emp_id;
  UPDATE employees SET bonus = v_salary * 0.1 WHERE employee_id = emp_id;
END calculate_bonus;

Wrapped Output (10g+):

CREATE OR REPLACE PROCEDURE calculate_bonus wrapped 
a000000
369
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
7
4e 8e
gH3k3xYD5Q3h0S6hZgJW8B+9Vv8wgxDJ2fIGyC9NCL8YG4vIR5RnP0ZpN5VJv1L0X2kM
3nO8pQrS5tU7vW9xY0zA2bC4dE6fG8hI0jK1lM2nO3pQ4rS5tU6vW7xY8zA9bC0dE1fG2h
I3jK4lM5nO6pQ7rS8tU9vW0xY1zA2bC3dE4fG5hI6jK7lM8nO9pQ0rS1tU2vW3xY4zA5bC6
/

Can Wrapped PL/SQL Be Unwrapped? The Truth

Yes, completely. For Oracle 10g and later, the wrapping algorithm is fully reversible using publicly available knowledge. The original source code, including all logic, variable names (except for some local variables in 12c+), and structure, can be recovered with near 100% fidelity.

This has been demonstrated by security researchers and is the basis for many unwrapping tools. The "secret" is not a cryptographic key but a fixed substitution table that was reverse-engineered from the Oracle binary. Because the table is the same for every database of a given version, anyone can replicate the unwrap process.

What Information is Permanently Lost?

• Comments: All comments are stripped during tokenization and are gone forever.
• Formatting/Whitespace: The original indentation and spacing are not preserved; the unwrapped code will be formatted according to Oracle's tokenization.
• Local Variable Names (12c+): In newer Oracle versions, local variable names may be replaced with generic names like V0001.
• Original Line Numbers: Line numbers from the source file are not retained.

For most recovery scenarios (lost source code, debugging, security audits), the unwrapped output is perfectly usable and functionally identical.

Legal and Ethical Considerations

Legitimate use cases include:

• Recovering your own lost source code when backups are unavailable.
• Performing security audits on in-house applications to identify exposed secrets.
• Debugging legacy wrapped code where the original source is missing.
• Educational purposes to understand how Oracle obfuscation works.

Alternative Methods for Protecting PL/SQL Code

If you need stronger protection than Oracle's native wrap, consider these alternatives:

• PL/SQL Native Compilation: Compiles PL/SQL to native machine code (C code). This makes static analysis significantly harder, though not impossible.
• Oracle Database Vault: Restricts access to the DBA_SOURCE and ALL_SOURCE views, preventing even privileged users from seeing the wrapped source.
• Third-Party Obfuscators: Commercial tools like Irdeto or Arxan provide stronger, multi-layered obfuscation with control-flow flattening and string encryption.
• Externalizing Logic: Move the most sensitive business logic out of PL/SQL entirely and into a compiled language (Java, C#, Go) hosted on a secure application server.

Frequently Asked Questions (FAQ)