Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > License Key Management for Perl Web Application

Reply
Thread Tools

License Key Management for Perl Web Application

 
 
Yoogie
Guest
Posts: n/a
 
      07-25-2005
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

 
Reply With Quote
 
 
 
 
Manu
Guest
Posts: n/a
 
      07-25-2005
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

 
Reply With Quote
 
 
 
 
Paul Lalli
Guest
Posts: n/a
 
      07-25-2005
Manu wrote:
> 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

 
Reply With Quote
 
Paul Lalli
Guest
Posts: n/a
 
      07-25-2005
Paul Lalli wrote:
> Manu wrote:
> > 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.

>
> 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

 
Reply With Quote
 
Manu
Guest
Posts: n/a
 
      07-25-2005
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



---[quote]-----------
Manu wrote:
> 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

 
Reply With Quote
 
Keith Keller
Guest
Posts: n/a
 
      07-25-2005
On 2005-07-25, Manu <(E-Mail Removed)> wrote:
>
> 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

--
http://www.velocityreviews.com/forums/(E-Mail Removed)-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
see X- headers for PGP signature information

 
Reply With Quote
 
Mike
Guest
Posts: n/a
 
      07-25-2005
On 2005-07-25, Manu <(E-Mail Removed)> wrote:
> 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
>
>
>
> ---[quote]-----------
> Manu wrote:
>> 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
 
Reply With Quote
 
gargoyle
Guest
Posts: n/a
 
      07-26-2005
On 2005-07-25, Mike <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Michael Vilain
Guest
Posts: n/a
 
      07-26-2005
In article <TegFe.891$(E-Mail Removed)>,
gargoyle <(E-Mail Removed)> wrote:

> On 2005-07-25, Mike <(E-Mail Removed)> wrote:
> > 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.


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

--
DeeDee, don't press that button! DeeDee! NO! Dee...



 
Reply With Quote
 
Manu
Guest
Posts: n/a
 
      07-26-2005
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.

-----[quote]---------------------------
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Request for a downgrade from x64 OEM license to 32-bit OEM license =?Utf-8?B?SmVyZW15IFdvbmcg6buD5rOT6YeP?= Windows 64bit 58 09-22-2005 11:33 PM
What license to choose for Python programs? (PSF License vs. GPL/LGPL) Volker Grabsch Python 2 07-25-2005 12:06 PM
Replace Tab Key to Return Key (Enter Key) from Web Forms? M P ASP General 1 08-06-2004 08:32 AM
queue management with "application failure management" pouet Java 2 07-30-2004 09:59 PM
Pix 501 VPN License Issue - Not freeing License Jens Haase Cisco 1 01-29-2004 08:29 PM



Advertisments