You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Li <am...@gmail.com> on 2007/06/08 09:29:45 UTC
Embed license to tomcat
Hi guys,
Our company is going to deploy a system externally. In order to prevent
illegal deployment by our customer to other tomcat in case. My boss asked me
to embed our license ID into the tomcat by building our own tomcat. I had
done several work such as creating a manager for our customized tomcat to
checkout MAC ID of the machine and license ID of the deployed system. I am
not so sure this is a good solution for securing deployment and our system.
Any ideas?
--
Small win by playing smart
Big win by playing honest
Re: Embed license to tomcat
Posted by Leon Rosenberg <ro...@googlemail.com>.
it sounds rather sick :-)
I mean, if you secure and deploy your customized tomcat version, how
does it prevent the "pirate" from simply putting your webapp in a
vanilla tomcat?
regards
Leon
On 6/8/07, Li <am...@gmail.com> wrote:
> Hi guys,
>
> Our company is going to deploy a system externally. In order to prevent
> illegal deployment by our customer to other tomcat in case. My boss asked me
> to embed our license ID into the tomcat by building our own tomcat. I had
> done several work such as creating a manager for our customized tomcat to
> checkout MAC ID of the machine and license ID of the deployed system. I am
> not so sure this is a good solution for securing deployment and our system.
>
> Any ideas?
>
> --
> Small win by playing smart
> Big win by playing honest
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Embed license to tomcat
Posted by Kristian Rink <kr...@zimmer428.net>.
[Li <am...@gmail.com> @ Fri, 8 Jun 2007 15:29:45 +0800]
> Our company is going to deploy a system externally. In order to
> prevent illegal deployment by our customer to other tomcat in case.
Why do you want to keep people from deploying your application to
another tomcat installation? Do you want to keep them from running
"pirated" versions of your software, or do you rather need the
application to be run in a tomcat setup completely configured by and
thus (in case of support questions) known to your company?
If the latter applies, maybe you'd be better off having a contract
stating loss of any warranty and/or support in case the application is
run inside a "non-certified" environment. Surely this is not a _nice_
way to do things but it seems to be a common practise so obviously
customers are willing to accept things like that.
Otherwise (if you intend to keep people from "pirating" your software),
you possibly should give up on software development and do something
else. Trying to protect software from "pirates" (I hate this term, but
that's just my $0.02...) is something software industry has been doing
at least for the last two decades, and by now all mechanisms and ideas
to do so seems to have completely failed. You won't come up with a
reliable software-based solution to keep your customers from running
"illegal" deployments of your software. Period. You might consider
asking them to use a hardware dongle solution to at least tie a
tomcat/app installation to a given host (don't know whether there are
Java interfaces to access these things, but I guess so...).
Anyhow, a better way in my opinion would be to give away the software
"for free" (or charging money for it, as you like, but without wasting
time / energy on trying to keep people from copying it) and make sure
users will get back to you in order to actually _run_ the software.
What application are we talking about here? You know, we're a
proprietary DMS as an in-house solution... the software itself is not
free but rather inexpensive compared to the amount of money you have to
spend on adapting the rather "generic" solution it provides to the very
special needs of your business... If this is somehow applicable to your
software, I guess it would be the best way...
Cheers,
Kristian
--
Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/
jab: kawazu@jabber.ccc.de * icq: 48874445 * fon: ++49 176 2447 2771
"One dreaming alone, it will be only a dream; many dreaming together
is the beginning of a new reality." (Hundertwasser)
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: Embed license to tomcat
Posted by Li <am...@gmail.com>.
Hi Peter,
Thanks for your reply. I did few hack, the major problem is I need
instantiate classloader, but WebappClassLoader is not instantiated by
itself, it always failed so far. Do you know any recommendable resource so
that I can read up?
On 6/12/07, Peter Crowther <Pe...@melandra.com> wrote:
>
> > From: Li [mailto:ampyx.li@gmail.com]
> > Path 1. Make an independent classloader which extends URLClassLoader
> > Path 2. Modify WebappClassLoader
> > Path 3. As the classloading doc mentioned, configure
> > customized loader which
> > is located in shared folder
> >
> > I had tried Path 3 and it never gets me success. Any ideas about
> > implementing custom classloader for this special purpose?
>
> If you're distributing a custom Tomcat anyway, why not just hack
> WebappClassLoader?
>
> - Peter
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Small win by playing smart
Big win by playing honest
RE: [OT] RE: Embed license to tomcat
Posted by Peter Crowther <Pe...@melandra.com>.
> From: Li [mailto:ampyx.li@gmail.com]
> Path 1. Make an independent classloader which extends URLClassLoader
> Path 2. Modify WebappClassLoader
> Path 3. As the classloading doc mentioned, configure
> customized loader which
> is located in shared folder
>
> I had tried Path 3 and it never gets me success. Any ideas about
> implementing custom classloader for this special purpose?
If you're distributing a custom Tomcat anyway, why not just hack
WebappClassLoader?
- Peter
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: Embed license to tomcat
Posted by Li <am...@gmail.com>.
Hi all,
Thanks for you guys last time regarding my boss 'funky' idea for software
protection. Since I am still his employee and a responsible developer, I am
still planning to finish up this task. Now i am at in the forest which got a
bit lost. Let me clarify again what I am going to achieve:
1. Compile all JSPs into .class (done)
2. Create key generator in order to generate Key and later put it into both
Tomcat and our system
3. Create encryption key generator for the class files encryption
4. Create encrypt util class to do the encryption
5. Create my own classloader which can be used by tomcat to decrypt our
class files
1 and 2 seems ok for now .. 3 and 4 is also tested fine (I am using DES for
now). I had wrote a simple classloader which extends JVM's default
classloader. It's decryption works fine with simple class files.
When I was trying to make a similar implementation for tomcat. I found it's
not that easy. There are few paths in my head which made me dizzy:
Path 1. Make an independent classloader which extends URLClassLoader
Path 2. Modify WebappClassLoader
Path 3. As the classloading doc mentioned, configure customized loader which
is located in shared
folder
I had tried Path 3 and it never gets me success. Any ideas about
implementing custom classloader for this special purpose?
Li
[OT] RE: Embed license to tomcat
Posted by Peter Crowther <Pe...@melandra.com>.
> From: Li [mailto:ampyx.li@gmail.com]
> As a developer, sometimes it's difficult to decide whether
> should follow my heart or boss ...
If you're thinking that regularly, it's probably time to find a new
boss...
- Peter
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Embed license to tomcat
Posted by Li <am...@gmail.com>.
Hi thanks all you guys' comments. I agree with Filip's words that we should
spend more time on doing statis secure analysis, codes refine and bug fixing
instead of building a castle.
Thanks Kristian but unfortunately it is not that possible to persuade my
boss accept your suggestion.
Thanks David, I will dive deeper to see if I could get a better and strong
verification solution.
As a developer, sometimes it's difficult to decide whether should follow my
heart or boss ...
Cheers
Li
Re: Embed license to tomcat
Posted by David kerber <dc...@verizon.net>.
Kristian Rink wrote:
> David kerber schrieb:
> ...
>
>> hardware failures won't cause problems. If they move to a completely
>> new machine, but you politely post a nag screen that says something to
>> the effect "New hardware detected; please contact Mycompany within 30
>> days for a new license", then that's not likely to offend many customers.
>>
>
> Depends, I guess... Actually, our DMS vendor used to have its licensed
> coupled to several aspects of the hosts network configuration (MAC, IP
> address, DNS name), and they dropped this very idea already a bunch of
> years ago - it's annoying for honest customers, it generates unnecessary
>
Yes, it can be annoying, but I guess it depends on how often a routine
maintenance change would trigger a notice.
> maintaineance work, and, most notably, in the age of virtualization it's
> possibly pointless. We run tomcat nodes that live inside different
> VMWare ESX (or "Virtual Infrastructure" as they call it by now...)
> hosts. No matter what actually happens to the physical hardware - the
> machines inside are likely to "stay the same". You can have the same
> thing running VMWare Server free of charge on modest x86 hardware and
> will smoothly make your way 'round any machine-tied licensing mode...
>
Good point; I didn't think about what would happen in a virtual-server
environment.
>
>
>> You could also have it "phone home" once a day (or once a week, or
>> whatever) with an app's internal key value, and if you get two
>> connections from the same ID value, then you know there are multiple
>> copies running.
>>
>
> No.
>
> >From a customers point of view, I simply wouldn't deploy such an
> application, at least not in the "enterprise" market. Bad enough knowing
> most desktop software is likely to phone home, the very moment our
> network monitoring would capture any of these server-based applications
> establishing unwanted connections to some external site would be
> end-of-life for this application in our environment. Having an
> application phone home drastically reduces trust in this very
> application especially if it is meant to keep track of sensible business
> information. This IMHO is a way that should be strictly discouraged...
> just my $0.02 on that...
>
I don't like them either, but it's an option he should be aware of...
D
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Embed license to tomcat
Posted by Kristian Rink <kr...@zimmer428.net>.
David kerber schrieb:
...
> hardware failures won't cause problems. If they move to a completely
> new machine, but you politely post a nag screen that says something to
> the effect "New hardware detected; please contact Mycompany within 30
> days for a new license", then that's not likely to offend many customers.
Depends, I guess... Actually, our DMS vendor used to have its licensed
coupled to several aspects of the hosts network configuration (MAC, IP
address, DNS name), and they dropped this very idea already a bunch of
years ago - it's annoying for honest customers, it generates unnecessary
maintaineance work, and, most notably, in the age of virtualization it's
possibly pointless. We run tomcat nodes that live inside different
VMWare ESX (or "Virtual Infrastructure" as they call it by now...)
hosts. No matter what actually happens to the physical hardware - the
machines inside are likely to "stay the same". You can have the same
thing running VMWare Server free of charge on modest x86 hardware and
will smoothly make your way 'round any machine-tied licensing mode...
> You could also have it "phone home" once a day (or once a week, or
> whatever) with an app's internal key value, and if you get two
> connections from the same ID value, then you know there are multiple
> copies running.
No.
>From a customers point of view, I simply wouldn't deploy such an
application, at least not in the "enterprise" market. Bad enough knowing
most desktop software is likely to phone home, the very moment our
network monitoring would capture any of these server-based applications
establishing unwanted connections to some external site would be
end-of-life for this application in our environment. Having an
application phone home drastically reduces trust in this very
application especially if it is meant to keep track of sensible business
information. This IMHO is a way that should be strictly discouraged...
just my $0.02 on that...
Cheers,
Kristian
--
Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/
jab: kawazu@jabber.ccc.de * icq: 48874445 * fon: ++49 176 2447 2771
"One dreaming alone, it will be only a dream; many dreaming together
is the beginning of a new reality." (Hundertwasser)
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Embed license to tomcat
Posted by David kerber <dc...@verizon.net>.
Mark H. Wood wrote:
> As others have noted, this may be doable but it's the wrong approach.
> You are trying to solve a legal problem with information technology.
> It is very rare for such an approach to accomplish much, other than to
> irritate customers who are behaving properly.
>
> MAC address is a particularly poor choice:
>
> o Many hosts have multiple NICs. Which MAC address is used?
> o NICs fail and must be replaced. Now your legitimate customer's
> product accuses him of theft.
> o Customer backs up failing host A and restores on new host B.
> Legally licensed product again refuses to run, because host B has
> different NIC(s).
>
> Having to re-register a product for reasons unrelated to the product
> is a negative Customer Experience, and the marketplace will punish
> such designs.
>
>
IMO that kind of depends on exactly how you handle the detection of a
change. If you include MAC address, CPU ID, disk serial number, etc,
and allow 1 of them to change without any issues, then most random
hardware failures won't cause problems. If they move to a completely
new machine, but you politely post a nag screen that says something to
the effect "New hardware detected; please contact Mycompany within 30
days for a new license", then that's not likely to offend many customers.
You could also have it "phone home" once a day (or once a week, or
whatever) with an app's internal key value, and if you get two
connections from the same ID value, then you know there are multiple
copies running. That one can be defeated if a customer has the
technical skills and really wants to, but if the key has internal
checksums and is reasonably complex, it will catch most casual copiers.
Nothing short of a hardware dongle will stop a determined hacker, but
there are fairly simple ways to keep honest customers honest, by not
tempting them to take the easy, cheap way out.
JMHO,
D
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Embed license to tomcat
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
As others have noted, this may be doable but it's the wrong approach.
You are trying to solve a legal problem with information technology.
It is very rare for such an approach to accomplish much, other than to
irritate customers who are behaving properly.
MAC address is a particularly poor choice:
o Many hosts have multiple NICs. Which MAC address is used?
o NICs fail and must be replaced. Now your legitimate customer's
product accuses him of theft.
o Customer backs up failing host A and restores on new host B.
Legally licensed product again refuses to run, because host B has
different NIC(s).
Having to re-register a product for reasons unrelated to the product
is a negative Customer Experience, and the marketplace will punish
such designs.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Typically when a software vendor says that a product is "intuitive" he
means the exact opposite.
Re: Embed license to tomcat
Posted by David Tonhofer <d....@m-plify.com>.
Mikolaj Rydzewski wrote:
> Li wrote:
>> Our company is going to deploy a system externally. In order to prevent
>> illegal deployment by our customer to other tomcat in case. My boss
>> asked me
>> to embed our license ID into the tomcat by building our own tomcat.
>> I had
>> done several work such as creating a manager for our customized
>> tomcat to
>> checkout MAC ID of the machine and license ID of the deployed system.
>> I am
>> not so sure this is a good solution for securing deployment and our
>> system.
>>
>> Any ideas?
> It's Java. If they want they'll decompile and change license checking
> code.
BCEL is very handy for this *cough*
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Embed license to tomcat
Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
Li wrote:
> Our company is going to deploy a system externally. In order to prevent
> illegal deployment by our customer to other tomcat in case. My boss
> asked me
> to embed our license ID into the tomcat by building our own tomcat. I
> had
> done several work such as creating a manager for our customized tomcat to
> checkout MAC ID of the machine and license ID of the deployed system.
> I am
> not so sure this is a good solution for securing deployment and our
> system.
>
> Any ideas?
It's Java. If they want they'll decompile and change license checking code.
--
Mikolaj Rydzewski <mi...@ceti.pl>
Re: Embed license to tomcat
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
I would consider your license and mac id work to be a waste of time.
If they want to crack your software, they will.
Instead just attach your company's software license to it.
Instead spend the time building the application so good that they will
want to buy it from you, and buy support for it as well.
Filip
Li wrote:
> Hi guys,
>
> Our company is going to deploy a system externally. In order to prevent
> illegal deployment by our customer to other tomcat in case. My boss
> asked me
> to embed our license ID into the tomcat by building our own tomcat. I
> had
> done several work such as creating a manager for our customized tomcat to
> checkout MAC ID of the machine and license ID of the deployed system.
> I am
> not so sure this is a good solution for securing deployment and our
> system.
>
> Any ideas?
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.472 / Virus Database: 269.8.11/837 - Release Date: 6/6/2007 2:03 PM
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org