4

After a quite exhaustive search, it would appear that there is no real and reliable way to hide code within Oracle's database (i.e. protect the code of routines, functions, packages and triggers).

The obfuscation (WRAP), though initially promising, turned out to be useless as it is very easy to UNDO the obfuscation and get the original (readable) code back.

So, before I give up, is there any way supported by Oracle that enables real hiding of the code? (I mean, besides of blocking access using credentials).

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
FDavidov
  • 3,505
  • 6
  • 23
  • 59
  • Why won't you consider using privileges to block access? If you're worried about DBAs having access, there are even ways to restrict them with [Oracle Database Vault](http://www.oracle.com/us/products/database/options/database-vault/overview/index.html). But having dealt with that product as a DBA I can tell you that it's really painful to limit administrators like that. – Jon Heller Jun 28 '15 at 16:01
  • Thanks for your comments Jon. I'm aware of the implications entailed by blocking the DBA from accessing the code but (as you can imagine), there are environments/applications where this condition is almost a must. – FDavidov Jun 29 '15 at 12:42

2 Answers2

0

Althought I do not like the idea of wrapping at all. As it is not benefitial for both sides (client/vendor). I have to say that wrapping of procedures/functions works differently then for packades.

While for packages wrapping simply substitutes bytes. For proceduers Oracle stores ADA virtual machine p-code. Which is much harder to reverse engeneer.

But anyway there is NO way to hide session tracing. So DBAs will always be able to see SQL statements executed by PL/SQL code.

ibre5041
  • 4,903
  • 1
  • 20
  • 35
  • Thanks for your prompt reply. I just checked unwrapping a function, a routine, and a whole Package using the serviced offered here: http://www.codecrete.net/UnwrapIt/. All three were PERFECTLY returned to the original source code. Hence, obfuscation is not an option (not because of its disadvantages as you mentioned, but because it is useless). – FDavidov Jun 28 '15 at 12:32
  • Surprising. I thought that nobody yet invested enough effort to reverse ingenneer ADA bytecode(or whatever it involved into over the years). Anyway due to some bug DBAs might need to re-compile PL/SQL with or without optimalizations, so there must be some way how to get original source code back. Maybe you could hide some really important part of the code in Java stored procedure. But even java bytecode can be decompiled. It is just a matter of effort invested. PS: Java stored procedures are much easier to maintan then C ones. – ibre5041 Jun 28 '15 at 12:44
0

This is perhaps one of the remaining advantages of pre-compiler languages like Pro-C, Pro-COBOL. True, queries can always be revealed via tracing/monitoring, but non-SQL logic in the languages will be hidden since what you deliver will be compiled objects. You do have the option to call out to C libraries (see CREATE LIBRARY) from PLSQL to do your computation, but to dip in, out of this just to partition between SQL and logic flow I think will be cumbersome. This method tends to get used to take advantage of external utilities (e.g. Bank Wizard libraries for validating bank accounts, PAF validation, etc).

TenG
  • 3,843
  • 2
  • 25
  • 42
  • Well.... Realizing business logic that required heavy interaction with data would be going back to the previous century. Wouldn't you agree? The REAL solution would be to have ORACLE introduce some RELIABLE protection to the source code... – FDavidov Jun 28 '15 at 12:42
  • This is pretty much what oracle does for a lot of their programs. – hdost Jun 28 '15 at 19:17