Re: make entire exe private
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Wed, 02 Jan 2008 11:01:17 -0800
On Wed, 02 Jan 2008 04:21:50 -0800, Bob <bshumsky06@xxxxxxxxx> wrote:
[...]
That is a very good point about not being able to make it "impossible"
to reverse engineer IP and the need to put important IP on a server.
I just want to make it a bit more difficult for competitors to reverse
engineer.
Well, okay. If you really want to, that's your prerogative. But you're still forgetting: if the IP has value, your competitors will be sufficiently motivated to get around whatever barriers you try to put in.
Your IP already has legal protection in the form of copyright and, if you play your cards right, patent protection as well (I'm not a big fan of the software patent process, but it does exist and is a legitimate point in this discussion). At the same time, copy protection techniques do not work and are a waste of time and effort. As I said, if your IP has enough value to make it worth protecting, it has enough value to make it worth bypassing your copy protection.
It's interesting to me that you found that dotObfuscator causes your program to crash. While I hadn't heard of this sort of problem before, it's not surprising to me. Copy protection techniques invariably hurt the legitimate consumer, even as they fail to actually prevent copying.
I would be very wary of taking a carefully constructed executable and running it through a third-party program for modification before delivery to the customer. At the very least, you are setting yourself up for a lot of extra work, as _all_ of your testing will need to be done on the obfuscated release of the program, and any anomalous behavior that occurs will require that you not only debug your own code, but that of the obfuscation system you're using.
And of course, no matter what you do, there's always a chance that some serious bug will be induced by the obfuscation system that isn't noted until the program's been released and is in use by the customer. The fact is that, unlike bug-fixes in your own code where you can take steps, especially near the end of the release cycle, to avoid making large changes that could introduce serious problems into other areas of the code, any obufscation technology will, since it's always applying some algorithm to your entire application, run the risk of creating a new bug for even the smallest change to the entire application.
To make things worse, there's no way to contain or restrict the potential risk of that new bug; unlike with a directed, limited approach with your own code, even the smallest change to your own code could result in an arbitrarily disastrous bug caused by the obfuscation.
At the very least, you will probably want to consider minimizing to the fullest extent possible _what_ code is obfuscated. If you must obfuscate, do so only on the smallest portion of your code necessary, and make sure that portion of code is _beyond_ thoroughly tested before release, with _any_ change to the code justifying a completely new test pass through that code, no matter how long that takes or how small the change.
Proceed at your own peril and wastefulness of your own resources.
Pete
.
- Follow-Ups:
- Re: make entire exe private
- From: Registered User
- Re: make entire exe private
- References:
- make entire exe private
- From: Bob
- Re: make entire exe private
- From: Bob
- Re: make entire exe private
- From: Peter Duniho
- Re: make entire exe private
- From: Bob
- make entire exe private
- Prev by Date: Re: binding a Generic.List to a repeater
- Next by Date: Re: binding a Generic.List to a repeater
- Previous by thread: Re: make entire exe private
- Next by thread: Re: make entire exe private
- Index(es):
Relevant Pages
|
