how many obfuscate?

  • Thread starter Thread starter Dandle
  • Start date Start date
D

Dandle

Hi all,

I am posting to the windows forms group because it occurs to me that
ASP.NET projects do not have the risks of code being decompiled like
distributed applications do.

My questions are:

1) How many people are using obfuscation to protect their code?
2) Is there alternatives to DotFuscator from PreEmptive?
3) It seems to me that win forms applications have not been adopted
nearly as much as ASP.NET. Do you think that the need for obfuscation
is a contributing factor?


BTW - Until I downloaded the FREE .NetReflector I had no idea it was so
easy to decompile to easy to read c# or vb.net code.


Thanks

Randy
 
Hi,

Thanks for the reply.

I agree with a lot of the web page you directed me too.

In our case there are several things that we have to protect (database
passwords, proprietary algorithms...)

So for us we have to address the issue or our competitors would gain
things we don't want them too.


~R
 
Dandle said:
In our case there are several things that we have to protect (database
passwords, proprietary algorithms...)

So for us we have to address the issue or our competitors would gain
things we don't want them too.
Click to expand...

In the case of passwords, you shouldn't have hard-coded passwords in
your code to start with. Obscuring the fact that you have won't make it
secure. It'll help a little bit, but you've still basically got an
insecure system there.

For algorithms, bear in mind that *all* code can be decompiled to one
extent or another. I guess it depends to what extent you really think
your competitors would risk legal ramifications (and expend effort) by
stealing your code...
 
Does Microsoft have any winforms applications in production?

If so are the obfuscated? If not, do you know when there will be?
 
Dandle said:
Does Microsoft have any winforms applications in production?
Click to expand...

I believe the SQL Server 2005 workbench (whatever it's called - the
successor to enterprise manager) is (at least largely) written in .NET.
I don't know whether or not it's obfuscated, but I'd be surprised if it
were.
If so are the obfuscated? If not, do you know when there will be?
Click to expand...

Well, put it this way - the framework itself doesn't have any
obfuscation as far as I've seen.
 
Does Microsoft have any winforms applications in production?

If so are the obfuscated? If not, do you know when there will be?
Click to expand...

Microsoft has published many assemblies written in .NET. Much of
Visual Studio itself is .NET, Office includes many components in .NET.
In general none of their assemblies are obfuscated. However Microsoft
is in a different position than most publishers since they are so
massive they can already absorb much of the loss associated with
reverse engineering their code. And most of the attacks on their
products are to obtain a license for the software without paying for
it - not necessarily for the algorithms and code in the products
themselves. All of the protection for their products however is in
native code - not .NET so the definately consider that an important
asset to protect.

My company (www.xheo.com) produces licensing and IP protection tools
that are far more effective then a basic obfuscator. Granted, any
individual given enough time and incentive will break even the best
protection schemes, it's silly not to make it as tough as possible as
long as it doesn't have a negative impact on your real customers.
 
My company (www.xheo.com) produces licensing and IP protection tools
that are far more effective then a basic obfuscator. Granted, any
individual given enough time and incentive will break even the best
protection schemes, it's silly not to make it as tough as possible as
long as it doesn't have a negative impact on your real customers.
Click to expand...

No, it's silly to do so unless you balance the cost of obfuscating
versus the probable cost of not obfuscating.

The costs of obfuscating, are, IME:
1) The cost of the obfuscator (for many small companies, the cost of
your obfuscator could be really quite significant. Of course,
there are free alternatives.)
2) The cost of amending the build process to use it
3) The increased difficulty of maintenance when one receives an
obfuscated stack trace from a log
4) The cost of finding and fixing bugs resulting from obfuscation
(e.g. due to reflection calls etc)
5) The disadvantage of making what the developer runs further removed
from what the customer runs (unless the developer always obfuscates)

These are not negligible costs, and it would be improper to brush them
aside. In other words, it's not nearly as simple a decision as your
post would suggest. While obviously you want to promote your product,
you don't do either your company or developers a service by ignoring
the costs above.
 
No, it's silly to do so unless you balance the cost of obfuscating
versus the probable cost of not obfuscating.

The costs of obfuscating, are, IME:
1) The cost of the obfuscator (for many small companies, the cost of
your obfuscator could be really quite significant. Of course,
there are free alternatives.)
Click to expand...

True, but so are all the tools that are used in creating software of a
quality worth purchasing. Visual Studio is not cheap, nor are the
development machines involved in creating the software. If something
increases profits - which is really the most important thing - the
upfront cost can be justified.
2) The cost of amending the build process to use it
Click to expand...

Yes every new tool involves a learning curve. But the initial
investment is worth the effort.
3) The increased difficulty of maintenance when one receives an
obfuscated stack trace from a log
Click to expand...

Yes this is an important issue, one that does have to be considered.
4) The cost of finding and fixing bugs resulting from obfuscation
(e.g. due to reflection calls etc)
Click to expand...

This can be eliminated if the protection tools are introduced into the
build process early in the development process rather than waiting
until the end.

5) The disadvantage of making what the developer runs further removed
from what the customer runs (unless the developer always obfuscates)

These are not negligible costs, and it would be improper to brush them
aside. In other words, it's not nearly as simple a decision as your
post would suggest. While obviously you want to promote your product,
you don't do either your company or developers a service by ignoring
the costs above.
Click to expand...

While you make a valid point on the importance of such aspects, the
fact that something is difficult is not a reasonable justification for
dismissing it when your livelyhood depends on it. Every aspect of the
sales process introduces signficiant issues into development process.
However you don't make things free just cause it's difficult.

Everything must be weighed and you're not likely to find any company
that will invest signifcant time and resources that does not wish to
protect the fruits of their efforts. Certainly many smaller developers
with a limited audience will find the efforts to protect their
software a significant part of their development cost. However they
also need protection most as they cannot absorb the cost of piracy as
easily as a larger corporation that derive their profits from value
added components like support, updates, training etc.
 
True, but so are all the tools that are used in creating software of a
quality worth purchasing. Visual Studio is not cheap, nor are the
development machines involved in creating the software. If something
increases profits - which is really the most important thing - the
upfront cost can be justified.
Click to expand...

Yes, but that's an "if" that you didn't include before.
Yes every new tool involves a learning curve. But the initial
investment is worth the effort.
Click to expand...

In your view - but again, you didn't mention this effort before. You
only talked about a negative impact on customers.
Yes this is an important issue, one that does have to be considered.


This can be eliminated if the protection tools are introduced into the
build process early in the development process rather than waiting
until the end.
Click to expand...

No, it just means the bugs will largely be found quickly as they're
introduced. It still makes the scope for bugs wider.
While you make a valid point on the importance of such aspects, the
fact that something is difficult is not a reasonable justification for
dismissing it when your livelyhood depends on it. Every aspect of the
sales process introduces signficiant issues into development process.
However you don't make things free just cause it's difficult.
Click to expand...

I didn't suggest dismissing it. I just suggested that you were implying
a cost of obfuscation which is much lower than it actually is.

Now, what's the cost of not obfuscating? I wonder how many .NET
companies have *actually* lost any money due to not obfuscating. Do you
have any concrete evidence of it happening? If one has to come up with
a balance between cost and potential benefit, there has to be some way
of estimating that benefit (in terms of avoiding lost revenues).
Everything must be weighed and you're not likely to find any company
that will invest signifcant time and resources that does not wish to
protect the fruits of their efforts.
Click to expand...

That entirely depends on what they deem the risk to be. The company I'm
working for doesn't obfuscate their assemblies, and while we've had one
individual reverse engineering something and causing a bit of support
trouble, I don't believe we've lost any revenue or IP due to not
obfuscating.
Certainly many smaller developers with a limited audience will find
the efforts to protect their software a significant part of their
development cost. However they also need protection most as they
cannot absorb the cost of piracy as easily as a larger corporation
that derive their profits from value added components like support,
updates, training etc.
Click to expand...

So, you have some concrete evidence of piracy of .NET applications due
to non-obfuscation?

I suspect it's more prevalent in consumer products, but I doubt that
many businesses would want to use reverse engineered and "cracked"
applications. It's one thing to not pay enough attention and
accidentally use more licences than you've paid for, but to
deliberately crack business software is more than most businesses would
stomach, IMO.
 
Just to elaborate on Jon's point of view, which I fully agree with, this
sort of issue has been around since about the time of the Gutenberg printing
press. That is, anything which can be published and consumed can be copied.
The argument here is that we are not talking about something human-readable,
but if it is computer-readable, since it is used on and with computers, the
point is moot. Since a computer can read and execute it, a computer can
"decode" it, no matter what sort of obfuscation is applied.

In recent years, I have seen many posts about the subject of preventing the
copying of JavaScript and images in web pages, and the conclusion is the
same. There are JavaScript "obfuscators" that make it very difficult for a
human being to parse JavaScript, but of course, once the obfuscation method
is known, a computer program can be created to do the parsing and
"de-obfuscation." With images, such techniques as embedding images in Java
Applets and SWF files have been promoted. However, since the computer
displays the pixels of the image on the screen, a simple screen scrape can
capture the image. Of course, we have also seen the same issues with audio
and video, and with much the same results. Yes, you can make it difficult
for amateurs to copy such things, but you cannot make it impossible. And
once the "Rubicks Cube" of whatever media has been solved, the solved "Cube"
can be redistributed, and copied across the globe.

This is why there are copyright and patent laws. The only real remedy (not
protection) against piracy is to take legal action. Companies like Microsoft
employ such tactics, which is why their software is activated, not
obfuscated.

--
HTH,

Kevin Spencer
Microsoft MVP

Help test our new betas,
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net
 
Back
Top