Обсуждение: Wrap (obfuscate) code
Good afternoon. I'm not sure if this is the correct list, so please forgive me if it's not. I was wondering if there's a mechanism (or if not, a workaround) to obfuscate server code (PL/PgSQL), a la Oracle's PL/SQL Wrap Utility: http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96624/c_wrap.htm#LNPLS016 Thanks for your time. Regards, Rodrigo
On 7/4/06, Rodrigo De Leon <rdeleonp@gmail.com> wrote: > I was wondering if there's a mechanism (or if not, a workaround) to > obfuscate server code (PL/PgSQL), a la Oracle's PL/SQL Wrap Utility: No, there is no such utility for PostgreSQL. And, even if there were, it wouldn't actually stop someone from reverse engineering it quite easily as the source code to PL/pgSQL itself is readily available. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On 7/4/06, Jonah H. Harris <jonah.harris@gmail.com> wrote: > No, there is no such utility for PostgreSQL. And, even if there were, > it wouldn't actually stop someone from reverse engineering it quite > easily as the source code to PL/pgSQL itself is readily available. I see. Thanks for the reply, both to you and Mr. Momjian. Regards, Rodrigo
On 7/4/06, Jonah H. Harris <jonah.harris@gmail.com> wrote:
I don't see how PostgreSQL being open source will stop obfuscation of the PL/pgSQL from being possible. Sure you can look at the code for a stored procedure but the point of obfuscation is to make it hard to understand, not impossible to see. A very long stored procedure could be quite difficult to read if it were obfuscated well - that would not stop someone from being able to understand what you did, just make it so hard that it would be unlikely that it is worth the effort.
-Aaron
On 7/4/06, Rodrigo De Leon <rdeleonp@gmail.com> wrote:
> I was wondering if there's a mechanism (or if not, a workaround) to
> obfuscate server code (PL/PgSQL), a la Oracle's PL/SQL Wrap Utility:
No, there is no such utility for PostgreSQL. And, even if there were,
it wouldn't actually stop someone from reverse engineering it quite
easily as the source code to PL/pgSQL itself is readily available.
I don't see how PostgreSQL being open source will stop obfuscation of the PL/pgSQL from being possible. Sure you can look at the code for a stored procedure but the point of obfuscation is to make it hard to understand, not impossible to see. A very long stored procedure could be quite difficult to read if it were obfuscated well - that would not stop someone from being able to understand what you did, just make it so hard that it would be unlikely that it is worth the effort.
-Aaron
On 7/4/06, Aaron Bono <postgresql@aranya.com> wrote: > I don't see how PostgreSQL being open source will stop obfuscation of the > PL/pgSQL from being possible. You're missing the whole point. Oracle doesn't obfuscate the code, they compile it into bytecode and then spit the bytecode back out as a textual "wrapped" version... this wouldn't work for an open source database because all you'd have to do is modify the PL/pgSQL engine to act as a code generator so that upon execution, it would nicely generate source code to the function. In short, childs play. In fact, the Oracle wrap utility doesn't totally prevent you from reverse engineering a procedure, function, or package... it just makes it *very* difficult. I had to do this for a company that paid a developer to write some code for them and the consultant only gave them the wrapped version (refusing to give them the actual source code). I had to reverse engineer his algorithm with nothing but wrapped code. Just remember, if you had the source code to Oracle, the wrap utility would be pretty much worthless as you could easily do the same thing as PL/pgSQL and PostgreSQL. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On 7/4/06, Jonah H. Harris <jonah.harris@gmail.com> wrote: > On 7/4/06, Aaron Bono <postgresql@aranya.com> wrote: > > I don't see how PostgreSQL being open source will stop obfuscation of the > > PL/pgSQL from being possible. Oh, and I forgot to add, obfuscation is lame and doesn't really work. Anyone with a good amount of compiler knowledge can easily get past obfuscated code. But hey, if it makes you feel like you've protected yourself, by all means... obfuscate away :) -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On Tuesday 04 July 2006 15:53, Jonah H. Harris wrote: > On 7/4/06, Jonah H. Harris <jonah.harris@gmail.com> wrote: > > On 7/4/06, Aaron Bono <postgresql@aranya.com> wrote: > > > I don't see how PostgreSQL being open source will stop obfuscation of > > > the PL/pgSQL from being possible. > > Oh, and I forgot to add, obfuscation is lame and doesn't really work. > Anyone with a good amount of compiler knowledge can easily get past > obfuscated code. But hey, if it makes you feel like you've protected > yourself, by all means... obfuscate away :) Obfuscation is good in the sense that it can allow a person paying for code to have a reasonable piece of mind that their customers can't just open the jar and steal the cookies. Although everything you say is accurate Jonah, it will cost more money to defang obfuscated code then non obfuscated code. Thus there is a financial detterant to stealing. I have more then once been in an environment where, "Oh we just "sampled" the function from *xyz*". Sincerely, Joshua D. Drake
On 7/4/06, Joshua D. Drake <jd@commandprompt.com> wrote: > I have more then once been in an environment where, "Oh we just "sampled" the > function from *xyz*". That's precisely the reason I was asking, because my colleagues and I had that same experience with Oracle packages when doing consulting work for a customer. After an incident where the customer's IT department had taken the decision to try and *improve* the code we delivered, we just gave them the original, untainted packages in wrapped format, and went on our merry ways. I would be quite a bonus to have equivalent functionality in PG.
"Rodrigo De Leon" <rdeleonp@gmail.com> writes: > I would be quite a bonus to have equivalent functionality in PG. Write your functions in C and give them precompiled libraries. Yes, also theoretically decompilable, but plenty hard ... plus they have to come back to you for an update on every major PG revision ;-) regards, tom lane
On Tuesday 04 July 2006 18:51, Tom Lane wrote: > "Rodrigo De Leon" <rdeleonp@gmail.com> writes: > > I would be quite a bonus to have equivalent functionality in PG. > > Write your functions in C and give them precompiled libraries. > Yes, also theoretically decompilable, but plenty hard ... plus > they have to come back to you for an update on every major PG > revision ;-) On that note, would it be possible to write a language handler in C that would wrap plPgsql? E.g; Write function in plpgsql, but call plpgsql_o plpgsql_o takes the plpgsql code and turns it into some kind of bytecode. When executed via postgresql, the handler defanges the bytecode and hands it off to plpgsql for proper processing? Just a thought. Joshua D. Drake > > regards, tom lane
On 7/4/06, Joshua D. Drake <jd@commandprompt.com> wrote: > Although everything you say is accurate Jonah, it will cost more money to > defang obfuscated code then non obfuscated code. Thus there is a financial > detterant to stealing. My bet is that it would take < 1 day to turn PL/pgSQL into a code generator, thereby making both the obfuscation and bytecode methods practically worthless. I agree with Tom... if you want to hide the code just write it in C. Of course, you could always take the "proprietary" shell script approach and hide the PL/pgSQL in C code so that, upon execution, the C code generates and calls the PL/pgSQL function and removes it on exit... but still, it wouldn't really be that hard to get around it. I've used Oracle's wrap utility on several products, but I've never really felt that it secured our code... just made it *very* difficult to decompile. I've never used obfuscation because I know how easy it is to hack one of the C or Java compilers to make the code much more readable and understandable. Just my 2 cents... but if someone wants to add obfuscation functionality to PL/pgSQL, by all means go for it. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On Tue, 2006-07-04 at 20:51, Tom Lane wrote: > "Rodrigo De Leon" <rdeleonp@gmail.com> writes: > > I would be quite a bonus to have equivalent functionality in PG. > > Write your functions in C and give them precompiled libraries. > Yes, also theoretically decompilable, but plenty hard ... plus > they have to come back to you for an update on every major PG > revision ;-) Or, just hire a crusty old perl programmer and have him write them all as one line, super compact perl scripts and use plperl. ;^)
On Wednesday > Or, just hire a crusty old perl programmer and have him write them all > as one line, super compact perl scripts and use plperl. I thought we were actually trying to *help* people on this list... ;) Joshua D. Drake > > ;^) -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
On 7/5/06, Scott Marlowe <smarlowe@g2switchworks.com> wrote: > Or, just hire a crusty old perl programmer and have him write them all > as one line, super compact perl scripts and use plperl. > > ;^) ROFLMAO! The plpgsql_o idea sounds cool, but it seems I'm the only one that presented such a need :( Maybe no one else really cares about such functionality... if that's the case, oh well... anyways, PG rocks! Regards, Rodrigo