tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kranti™ K K Parisa <kranti.par...@gmail.com>
Subject Re: Securing Tomcat Applications from Reverse Engineering
Date Fri, 22 Jan 2010 07:53:14 GMT
Hi Leon,

Thanks for the notes, may be parallel to our sales we may spend some time on
the points you mentioned to protect our selves in the future.

Best Regards,
Kranti K K Parisa



On Thu, Jan 21, 2010 at 9:54 PM, Leon Rosenberg <
rosenberg.leon@googlemail.com> wrote:

> Hello Kranti,
>
> first of all I strongly believe in open source software and don't like
> to obfuscate things. But well.
>
> 1. If you have internet connectivity on the target server you could
> only deploy a skeleton of your application and load the
> protect-worthly classes
> directly from your servers with own classloading with some funny
> remoteid exchange system. This way even the compile version of the
> application will never be directly available on customers hard drive
> (you must consider swapping and memory snapshots, but modern OSes
> encode them). It's cheap but will probably add a load of complexity,
> which you have to manage and, logically, your customer have to pay.
>
> 2. precompile jsps and use a code obfuscator on the jsps and compiled
> classes (they replace all private methods and variables with a1,a2,
> and so on). There are some on the market, more or less good. Use also
> css/js minifier, they obfuscate as well.
>
> 3. create a genial encryption algorithm with some one-time passwords
> and let the customers call you each time they restart the server for a
> new password. Maybe charge them per password. The server can then
> decrypt the classes with the password before it starts the webapp.
>
> 4. put the code and tomcat onto a usb stick with unreadable filesystem
> and hack yourself into the usb protocol. Drawback: you'll have to
> patch the browsers to accept urls like usb://localhost/yourapp.
>
> 5. stop wasting your time and invest it into developing new features
> and actually selling your product. If its worth copying it will be
> copied this way or other. So far no one has managed to protect its
> software against copying, better concentrate on things you really CAN
> achieve.
>
> regards
> Leon
>
> 2010/1/21 Kranti™ K K Parisa <kranti.parisa@gmail.com>:
> > Well there are soo many comments on the cost of IP and other tools. when
> we
> > are a small team started working on a web based product with open source
> > tools, for sure we can't spend too much on the tools to protect the IP
> > rights. because once we deploy for few clients, if its a good product,
> what
> > if they steal the code and also ideas. i agree to have legal terms and
> all
> > that stuff. but that would be a big story for us being small.
> >
> > so just wanted to see if anything available to protect our work, ideas
> > (ideas at code implementation level by using different opensource
> > technologies, well there are many companies who started like this).
> >
> > anyways thanks for the comments, i would love to share if we invent
> anything
> > in this process, because small is big and it matters :)
> >
> > Best Regards,
> > Kranti K K Parisa
> >
> >
> >
> > On Thu, Jan 21, 2010 at 5:00 PM, André Warnier <aw@ice-sa.com> wrote:
> >
> >> Peter Crowther wrote:
> >>
> >>> 2010/1/21 Kranti™ K K Parisa <kranti.parisa@gmail.com>
> >>>
> >>>
> >>>> How could we achieve this without the above tool? Because the pricing
> of
> >>>> the
> >>>> above tool is very costly.
> >>>>
> >>>> Well, you could always spend the developer-years to create your own
> >>>> version
> >>>>
> >>> of that tool... which would probably be *more* costly.
> >>>
> >>
> >>
> >> I'll add something to that, just for the sake of it.
> >> I personally find this situation ironic : here we have someone who wants
> to
> >> protect their own code, presumably so that they can charge the customer
> for
> >> a copy of it, in order to get back their cost of development and some
> >> justified profit for their work.
> >> But the same people are apparently unwilling to pay for a product that
> >> would allow them to do so, and is sold on the same terms.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message