I have no idea what your friend is saying. If I were you, I'd ask your friend to elaborate on exactly what he or she is trying to suggest.
Fundamentally, if you are going to deploy code written in any language to a server owned by an attacker, that attacker is going to be able to read and manipulate the code. No matter how encrypted and obfuscated the code, the attacker's computer has to be able to decrypt it in order to run it. If the attacker's computer can decrypt it, the attacker can decrypt it. If you truly need to prevent people from viewing your code, the best approach would be to use an architecture that doesn't involve deploying your code to their servers. If you build a product that is accessed over the internet, the code would only exist on your servers so the attacker would have no access.
That said, Pete Finnigan (the Oracle security guru) has a tool PFCLObfuscate. If you're really interested in top-end protection, that combines code obfuscation with wrapping (using older versions of the wrap utility) which makes it harder for the attacker to circumvent.
Be aware, though, that even if code is wrapped and the attacker can't unwrap it, if the code is running on the attacker's machine, the attacker can freely do things like look at v$sql where all the SQL statements will be visible in clear text, the attacker can trace the code to see everything that it is touching, etc. Without unwrapping code, I've submitted bug reports to vendors that shipped wrapped code and been able to tell them that a particular package was executing a particular SQL statement that was behaving incorrectly/ causing performance issues/ etc. I wasn't able to tell them exactly what line in the package to go to (because I didn't want to unwrap the code) but I was certainly able to get a pretty good idea of what the wrapped code was doing.
Of course, if you are implementing something in pure PL/SQL that is both highly non-trivial and likely to attract attackers that want to reverse engineer the process, maybe it makes sense to wrap and/or obfuscate the code. Most PL/SQL, though, is just a wrapper around SQL and it's easy enough to see the SQL getting executed even without worrying about unwrapping.
Thanks Justin, I did the same, I asked him to elaborate it for me.
well I don't think change our architecture be good idea since our clients are purchasing server and it is hard to justify why we are going to change our architecture and what they should do for their purchased IT infrastructure. Also speed wouldn't be impacted? I mean, our client won't have speed problem when we go for separate data and back-end architecture? our product is combination of PL\SQL and Oracle Form.(Insurance product)
I think Pete Finnigan solution looks more useful with less changes in system, what is your idea?
I'm not sure what you are asking with respect to speed. Presumably, if you host the entire environment, you could provide similar speed to what the customer would get if they installed everything in their environment. If you host some component that the customer's system then has to interact with, you'd have to architect that interface to provide appropriate levels of performance.
Personally, I'm not a huge fan of wrapping code in the first place. The odds that your insurance product implements some bit of PL/SQL logic that is so amazingly clever that someone would want to steal it and that they couldn't steal simply by tracing the code, looking at v$sql, etc. are not particularly high. Plus, companies that are purchasing insurance products are generally not companies that have any interest in reverse engineering that software in order to build their own. If you really are in the tiny minority that has something that amazing, my bias would be to architect the software so that you can host that small amount of "secret sauce" on your own servers.
If you really want to wrap your code, as I said initially, Pete's solution is going to be the top of the line in terms of what sort of protection you can get on code that is owned on an attacker's machine.