License Key Management for Perl Web Application

[Yoogie]

Hi,

I'm searching for a possibility to restrict the usage of an perl
application by license keys or something similar.

I'm not sure if there is any possibility besides writing an own web
server and hacking the perl-code in....

Hope someone can help me.

Thanks alot in advance

Manuel

 

[Manu]

Maybe I should specify this question a bit.

I found the appropriate entry and read (and probably) understand it,
but I want to know if there is something similar to the java-obfuscator
which makes pre-compiled source-code undecompileable.

Maybe there is a ready-to-use solution for this common task.

Thanks in advance.

Manuel

 

[Paul Lalli]

Maybe I should specify this question a bit.

What question? You haven't asked a question yet.

Oh, you're replying to a previous post, without quoting any context,
that was apparently written by you, but with a different From: name.

Have you read the posting guidelines for this group yet?

I found the appropriate entry and read (and probably) understand it,

You understand what? What did you read? It's difficult for anyone to
give you additional suggestions if we don't know what suggestions
you've already been given.

but I want to know if there is something similar to the java-obfuscator
which makes pre-compiled source-code undecompileable.

^^^^^^^^^^^^^^^^^^^^^^^^^^^

As far as I know, that's a myth. No such animal. But I won't preclude
the possibility that I'm wrong.

Maybe there is a ready-to-use solution for this common task.

If you want to deliver an executable program written in Perl without
the need for an external perl interpreter, have a look at perlcc
(included with perl) or perl2exe (not).

If you want to "protect" your source from people copying it, hire a
lawyer. Seriously. Trying to "hide" your source by compiling it is
simply not an effective way to prevent it being used without your
authorization. That's what trademark, copyright, and intellectual
property laws are for.

Paul Lalli

 

[Paul Lalli]

If you want to deliver an executable program written in Perl without
the need for an external perl interpreter, have a look at perlcc
(included with perl) or perl2exe (not).

If you want to "protect" your source from people copying it, hire a
lawyer. Seriously. Trying to "hide" your source by compiling it is
simply not an effective way to prevent it being used without your
authorization. That's what trademark, copyright, and intellectual
property laws are for.

Oops. Forgot to include the standard "See also:
perldoc -q hide
"

Paul Lalli

 

[Manu]

Hi Paul,

I'm really sorry for violating the group-guidelines.

I searched the web for "perl obfuscator" and found some scripts which
do nothing else than renaming variables and functions and removing line
feeds. But this doesn't give me security....

Let me explain what I want to do (maybe I should have done this 2 posts
before...)
I'm writing a web-application which consists of a bunch of
perl-scripts. I want to implement license management, so someone will
be able to buy a 100 user license, install it (from inside the
web-frontend) and then use the frontend until the 100 users are
created. My fear is that someone could uncomment the appropriate
function in the code and set for example "return 1000;".

I read about the Bytecode module. It precompiles perl-code to the
internal bytecode-format and from this point it isn't readable any
more, but it can be easily decompiled. So I thought that there must be
some thing like the java-bytecode-obfuscator which makes the
decompilation even more difficult.

Another thought was to use the Filter::... plugin and use a usual
cypher algorythm to decode the code which was first encoded with the
license or even a part of it. another idea was to invlove gnupg in this
process but it would be some sort of overkill and implementing this
sort of function wouldn't be safe because everyone could easily catch
the output/decryption-key and simplify this...

I don't know if perl-compiler like perlcc would work in a
cgi-environment.... so I came here and asked (granted, in very short
and unmeaningful sentences) you for a better solution or for your
thoughts...

Thanks anyway.

Best regards,

Manuel



---

-----------

Maybe I should specify this question a bit.

What question? You haven't asked a question yet.

Oh, you're replying to a previous post, without quoting any context,
that was apparently written by you, but with a different From: name.

Have you read the posting guidelines for this group yet?

I found the appropriate entry and read (and probably) understand it,

You understand what? What did you read? It's difficult for anyone to
give you additional suggestions if we don't know what suggestions
you've already been given.

but I want to know if there is something similar to the java-obfuscator
which makes pre-compiled source-code undecompileable.

^^^^^^^^^^^^^^^^^^^^^^^^^^^

As far as I know, that's a myth. No such animal. But I won't preclude
the possibility that I'm wrong.

Maybe there is a ready-to-use solution for this common task.

If you want to deliver an executable program written in Perl without
the need for an external perl interpreter, have a look at perlcc
(included with perl) or perl2exe (not).

If you want to "protect" your source from people copying it, hire a
lawyer. Seriously. Trying to "hide" your source by compiling it is
simply not an effective way to prevent it being used without your
authorization. That's what trademark, copyright, and intellectual
property laws are for.

Paul Lalli

 

[Keith Keller]

I'm really sorry for violating the group-guidelines.

Don't be sorry, just stop doing it. (The post to which I'm responding
was top-posted.)

I read about the Bytecode module. [snip]
Another thought was to use the Filter::... plugin and use a usual
cypher algorythm to decode the code which was first encoded with the
license or even a part of it. another idea was to invlove gnupg in this
process but it would be some sort of overkill and implementing this
sort of function wouldn't be safe because everyone could easily catch
the output/decryption-key and simplify this...

Hmm, have you read perldoc -q hide yet? It basically talks about many
of the issues you've raised. It also ominously says this:

If you're concerned about people profiting from your code,
then the bottom line is that nothing but a restrictive
license will give you legal security.

Since "profiting from your code" includes modifying your code to allow
more users than you wish to allow, I'd say that's your definitive
answer.

I don't know if perl-compiler like perlcc would work in a
cgi-environment.... so I came here and asked (granted, in very short
and unmeaningful sentences) you for a better solution or for your
thoughts...

If you can run something from the command line, you can run it after
it's been compiled by perlcc or perl2exe, as long as you've given the
options to compile needed libraries into the executable. But it won't
solve the decompilation issues perldoc -q hide raise.

--keith

 

[Mike]

Hi Paul,

I'm really sorry for violating the group-guidelines.

I searched the web for "perl obfuscator" and found some scripts which
do nothing else than renaming variables and functions and removing line
feeds. But this doesn't give me security....

Let me explain what I want to do (maybe I should have done this 2 posts
before...)
I'm writing a web-application which consists of a bunch of
perl-scripts. I want to implement license management, so someone will
be able to buy a 100 user license, install it (from inside the
web-frontend) and then use the frontend until the 100 users are
created. My fear is that someone could uncomment the appropriate
function in the code and set for example "return 1000;".

I read about the Bytecode module. It precompiles perl-code to the
internal bytecode-format and from this point it isn't readable any
more, but it can be easily decompiled. So I thought that there must be
some thing like the java-bytecode-obfuscator which makes the
decompilation even more difficult.

Another thought was to use the Filter::... plugin and use a usual
cypher algorythm to decode the code which was first encoded with the
license or even a part of it. another idea was to invlove gnupg in this
process but it would be some sort of overkill and implementing this
sort of function wouldn't be safe because everyone could easily catch
the output/decryption-key and simplify this...

I don't know if perl-compiler like perlcc would work in a
cgi-environment.... so I came here and asked (granted, in very short
and unmeaningful sentences) you for a better solution or for your
thoughts...

Thanks anyway.

Best regards,

Manuel



---

-----------

Maybe I should specify this question a bit.

What question? You haven't asked a question yet.

Oh, you're replying to a previous post, without quoting any context,
that was apparently written by you, but with a different From: name.

Have you read the posting guidelines for this group yet?

I found the appropriate entry and read (and probably) understand it,

You understand what? What did you read? It's difficult for anyone to
give you additional suggestions if we don't know what suggestions
you've already been given.

but I want to know if there is something similar to the java-obfuscator
which makes pre-compiled source-code undecompileable.

^^^^^^^^^^^^^^^^^^^^^^^^^^^

As far as I know, that's a myth. No such animal. But I won't preclude
the possibility that I'm wrong.

Maybe there is a ready-to-use solution for this common task.

If you want to deliver an executable program written in Perl without
the need for an external perl interpreter, have a look at perlcc
(included with perl) or perl2exe (not).

If you want to "protect" your source from people copying it, hire a
lawyer. Seriously. Trying to "hide" your source by compiling it is
simply not an effective way to prevent it being used without your
authorization. That's what trademark, copyright, and intellectual
property laws are for.

Paul Lalli

If this is a web app, what about having your app either use a stub
through xs or query your main server for authentication once daily.
Consider what you asking. Even if you send out a binary, the binary
codes can be reverse engineered. After all a CPU accepts binary codes
that the CPU interpretes. These codes can be reversed, too.

Anything you publish can be reversed. The deciding factor is how
much pain someone wants to go through to do the reverse engineering.

Mike

 

[gargoyle]

If this is a web app, what about having your app either use a stub
through xs or query your main server for authentication once daily.
Consider what you asking. Even if you send out a binary, the binary
codes can be reverse engineered. After all a CPU accepts binary codes
that the CPU interpretes. These codes can be reversed, too.

Better yet, only let the app run on a server that you control (clients
don't get root access). Then you can use some ACL system to set
restrictive access on the script, so that it can only be executed but
not read/copied. I don't know how many platforms can do this, but it's
possible in OpenBSD with systrace and execute-only file perms.

Anything you publish can be reversed. The deciding factor is how
much pain someone wants to go through to do the reverse engineering.

Yup. In the above case, they can steal your code if they hack the
OpenBSD server. Good luck. ;-)

 

[Michael Vilain]

Better yet, only let the app run on a server that you control (clients
don't get root access). Then you can use some ACL system to set
restrictive access on the script, so that it can only be executed but
not read/copied. I don't know how many platforms can do this, but it's
possible in OpenBSD with systrace and execute-only file perms.


Yup. In the above case, they can steal your code if they hack the
OpenBSD server. Good luck. ;-)

Solaris doesn't allow this. If a script can't be read, it can't be
executed.

 

[Manu]

A stub through xs is really a good point I haven't though of on my own.
xs is hard to learn and understand, but I think it should fit my needs.

Thanks alot for your answer, Mike.

-----

---------------------------
If this is a web app, what about having your app either use a stub
through xs or query your main server for authentication once daily.
Consider what you asking. Even if you send out a binary, the binary
codes can be reverse engineered. After all a CPU accepts binary codes
that the CPU interpretes. These codes can be reversed, too.

Anything you publish can be reversed. The deciding factor is how
much pain someone wants to go through to do the reverse engineering.

Mike

 

[Manu]

Unfortunately the server (and also the webapp) has to be run on the
client-side. Of course using a server which is under my control would
be the best opportunity, but this isn't possible for this sort of
application.

But thanks anyway.

----

--------------------------

If this is a web app, what about having your app either use a stub
through xs or query your main server for authentication once daily.
Consider what you asking. Even if you send out a binary, the binary
codes can be reverse engineered. After all a CPU accepts binary codes
that the CPU interpretes. These codes can be reversed, too.

Better yet, only let the app run on a server that you control (clients
don't get root access). Then you can use some ACL system to set
restrictive access on the script, so that it can only be executed but
not read/copied. I don't know how many platforms can do this, but it's
possible in OpenBSD with systrace and execute-only file perms.

Anything you publish can be reversed. The deciding factor is how
much pain someone wants to go through to do the reverse engineering.

Yup. In the above case, they can steal your code if they hack the
OpenBSD server. Good luck. ;-)