Wrap (obfuscate) code
Rodrigo De Leon
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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
Jonah H. Harris
> 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 | jha...@enterprisedb.com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
Rodrigo De Leon
> 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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
Aaron Bono
On 7/4/06, Rodrigo De Leon <rdel...@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
Jonah H. Harris
> 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
> > 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 | jha...@enterprisedb.com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/
---------------------------(end of broadcast)---------------------------
Joshua D. Drake
> On 7/4/06, Jonah H. Harris <jonah....@gmail.com> wrote:
> > On 7/4/06, Aaron Bono <postg...@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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
Rodrigo De Leon
> 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.
Tom Lane
> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Joshua D. Drake
> "Rodrigo De Leon" <rdel...@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
---------------------------(end of broadcast)---------------------------
Jonah H. Harris
> 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.
Scott Marlowe
> "Rodrigo De Leon" <rdel...@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.
;^)
Joshua D. Drake
> 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/
Rodrigo De Leon
> 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