Pete Finnigan's Oracle Security Weblog

It has been possible to wrap PL/SQL for many years using Oracle tools and in the first iterations in Oracle 7 this was done with the Oracle 7 wrap.exe and this progressed through Oracle 8, 8i and finally 9iR2 also using wrap.exe. The format of the tool changed internally slightly and each version supported the later Oracle versions changes to the PL/SQL language itself.

In the first instance from Oracle 7 through to Oracle 9ir2 the wrap mechanism was a simple write to a file of the internal state of the PL/SQL compiler memory after the lexical and semantic analysis phases had completed. Then this file could be loaded into the database and the data was put back into the PL/SQL compiler memory structures and the compilation continued to generate the p-code and install into the database. One of the flaws of then Oracle 7 through to 9iR2 wrapped files was the fact that the symbol table was visible in the wrap file and whilst you could not re-construct a PL/SQL file from a wrapped file from the symbol table except in very limited cases this gave away a lot of detail of the protected PL/SQL. I showed back in 2001 that even wrapped (Oracle 7 to 91R2) that the wrapped file could be hacked by editing the symbol table to change its meaning BUT the PL/SQL still loaded and the code could then be hacked. The example I gave back then (I think, its a long time ago), was to change "..alter session set nls..." to "...alter user sys identified by a..." where the code was installed as SYS or a DBA or a user with ALTER USER this would change the SYS password and is an escalation to SYSDBA for the attacker. The attacker would of course need to have access to the PL/SQL wrapped files.

Then from Oracle 10.1 the wrap mechanism changed to stop the symbol table being visible and to do this the method of wrapping changed. In the 9iR2 the wrap file is the PL/SQL memory part way through compiling and in 10g and above its a pseudo obfuscation process on the PL/SQL file and not part of the compilation process. The PL/SQL file is simply protected by wrap.exe and then un-protected before loading into the database. This obviously shows that the wrapped file in 10g and above can be reversed. It has to be reversed to allow it to be loaded to the database and compiled. This means that unwrapping a 10g wrapped PL/SQL file is easy and there are free tools around and even websites that are available that can be used to unwrap this PL/SQL.

There are no public websites and unwrappers for 9iR2 and earlier PL/SQL

This means that the 9ir2 and earlier wrap format was in a sense better (apart from the symbol table being visible) as its harder to uwrap

OK, so why is all of this relevant now? Well because I get on average at least 1 or 2 emails a week sometime as many as 4 or 5 a week asking me if I can help retrieve PL/SQL as the person emailing me has lost the source code and they need to modernise the code or add features or whatever. Some are governments and major utilities as well as many SME companies.

The issue seems to be a lack of process years ago. The clear text source code has been lost maybe because the development project shut down and over time the only copy of the clear text code is lost or moved to backup tapes or....

If you use wrap.exe then ensure that its part of a process; i.e. develop clear text code, test, wrap, release to production. BUT ensure that a clear text copy of the code is preserved when the development stops and the development stack is removed in favour of new projects. Copy the code to CD, to paper, source repositories and store otherwise in 10 years, 15 years people will be asking people like me to help them get their PL/SQL code back

#oracleace #23c #21c #19c #plsql #wrapping #obfuscation