make entire exe private

[Bob]

Hi,
I have a very large project. I wasn't very careful in setting
visibility and many classes are "public" that should be "internal". I
would like to create a build of an exe in which nothing is exposed as
public. In other words, end users can use the application but won't
be able to use any of the classes in a program of their own. Is there
a compiler option that I can set to do this? I tried find and replace
"public" to "internal" but this creates a bunch of problems with
interfaces and operators.

Thanks,
Bob

 

[Peter Bromberg [C# MVP]]

Maybe you should investigate the differences between the protected and sealed
modifiers, or look at some of the CAS (Code Access Security) attributes for
your classes.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com

 

[Bob]

Maybe you should investigate the differences between the protected and sealed
modifiers, or look at some of the CAS (Code Access Security) attributes for
your classes.
-- Peter
Site:http://www.eggheadcafe.com
UnBlog:http://petesbloggerama.blogspot.com
MetaFinder:http://www.blogmetafinder.com

Thanks for quick response. I don't think that making class sealed or
changing code access level assumed in clr is quite what I want. The
issue is not that I don't want anyone to make changes to a class, its
an intellectual property one of I don't want people to be able to use
my classes (or do any type of reverse engineering such as even seeing
their names) simply by importing my exe into visual studio.

 

[Jordan S.]

RE:
"or do any type of reverse engineering such as even seeing their names"

You will need to obfuscate your assemblys then. Preemtive has an obfuscator
(DotFuscator) of which a free version ships with Visual Studio, and there
are others.

To understand why you will need to do this for any .NET assembly, you should
do some research on exactly what it means to compile a .NET assembly. It is
very difficult to make it "impossible" to reverse engineer any assembly,
much less a .NET assembly. I'm sure others will pile on here to further
explain if necessary.

-HTH

 

[Peter Duniho]

Thanks for quick response. I don't think that making class sealed or
changing code access level assumed in clr is quite what I want. The
issue is not that I don't want anyone to make changes to a class, its
an intellectual property one of I don't want people to be able to use
my classes (or do any type of reverse engineering such as even seeing
their names) simply by importing my exe into visual studio.

Visual Studio and other code inspection tools don't care about access
modifiers. "Private" versus "public", etc. is an API/compiler thing, to
protect some code from other code. At the development tool level, those
attributes are essentially irrelevant.

As Jordan says, obfuscation may be what you're looking for. But I will
point out, as I always do when this comes up, that it's unlikely there's
any real point to obfuscation tools. It is _impossible_ to make it
literally impossible to reverse engineer your executable. Jordan's
statement about it being "difficult" is only correct inasmuch as he put
the word "impossible" in quotes (and I expect he did that on purpose, for
that very reason). Don't make the mistake of thinking that there is in
fact any way to make it truly impossible to reverse engineer your code.

So: do you have intellectual property in your code that makes it
worthwhile to try to hide it from someone? Then it is worthwhile for
someone to bypass whatever protections you put on it. Conversely, if it's
possible for you to hide your IP well enough that it's not worth someone's
time to bother bypassing the protections, then your IP doesn't have enough
value to make it worth hiding in the first place.

You need look no further than the whole DVD and HD DVD fiascos to see the
futility of trying to hide IP that exists in your code. Don't you think
that if it were possible to prevent anyone from reverse engineering the
decryption for DVDs, that the big media companies would have done so?

If you don't want anyone to be able to reverse engineer your efforts, your
only true solution is to not deliver the results of those efforts to
anyone. For some applications, this is actually a practical alternative.
You put the sensitive stuff on a server that's controlled by you (and make
sure your network security is up to snuff), and the customer just gets a
client that can access that server. They never get the actual
implementation of your highly-valued IP. For other applications, only a
client-side implementation makes sense and in that case you just have to
trust that you can pursue copyright violations after the fact, inasmuch as
they actually become a problem (frankly, there's little evidence that
illegal copying represents a significant problem in the retail software
market, no matter what the SPA says).

Pete

 

[Bob]

Visual Studio and other code inspection tools don't care about access
modifiers. "Private" versus "public", etc. is an API/compiler thing, to
protect some code from other code. At the development tool level, those
attributes are essentially irrelevant.

As Jordan says, obfuscation may be what you're looking for. But I will
point out, as I always do when this comes up, that it's unlikely there's
any real point to obfuscation tools. It is _impossible_ to make it
literally impossible to reverse engineer your executable. Jordan's
statement about it being "difficult" is only correct inasmuch as he put
the word "impossible" in quotes (and I expect he did that on purpose, for
that very reason). Don't make the mistake of thinking that there is in
fact any way to make it truly impossible to reverse engineer your code.

So: do you have intellectual property in your code that makes it
worthwhile to try to hide it from someone? Then it is worthwhile for
someone to bypass whatever protections you put on it. Conversely, if it's
possible for you to hide your IP well enough that it's not worth someone's
time to bother bypassing the protections, then your IP doesn't have enough
value to make it worth hiding in the first place.

You need look no further than the whole DVD and HD DVD fiascos to see the
futility of trying to hide IP that exists in your code. Don't you think
that if it were possible to prevent anyone from reverse engineering the
decryption for DVDs, that the big media companies would have done so?

If you don't want anyone to be able to reverse engineer your efforts, your
only true solution is to not deliver the results of those efforts to
anyone. For some applications, this is actually a practical alternative.
You put the sensitive stuff on a server that's controlled by you (and make
sure your network security is up to snuff), and the customer just gets a
client that can access that server. They never get the actual
implementation of your highly-valued IP. For other applications, only a
client-side implementation makes sense and in that case you just have to
trust that you can pursue copyright violations after the fact, inasmuch as
they actually become a problem (frankly, there's little evidence that
illegal copying represents a significant problem in the retail software
market, no matter what the SPA says).

Pete

Thanks for all of your responses. I have been planning on changing as
much of accessibility as possible to internal from public and then
obfuscating the output. Does anyone have an obfuscator they like? I
have been playing around with dotfuscator but the exe I get from it is
throwing fatal exceptions that don't come up in the original.

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.

Thanks again,
Bob

 

[Peter Duniho]

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

 

[Registered User]

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.

There is no barrier to abstraction. This is important to consider
because to a competitor the black box is really opaque. The general
business process is already known to anyone in the business. Combine
this with the understanding that majority of the code involves generic
functionality and the amount of proprietary intellectual property can
become almost insignificant.

This is the way I see it.

regards
A,G,

 

[Peter Duniho]

There is no barrier to abstraction. This is important to consider
because to a competitor the black box is really opaque. The general
business process is already known to anyone in the business. Combine
this with the understanding that majority of the code involves generic
functionality and the amount of proprietary intellectual property can
become almost insignificant.

This is the way I see it.

I personally agree. I'm always skeptical of the assumed value of the IP
being discussed, whenever this sort of thing comes up.

But the fact is, even if one puts a high value on the IP, the nature of
the problem and the costs involved in protecting the IP always wind up in
the hacker's favor. There is obviously some limit to the amount of effort
that is considered a worthwhile investment in protecting the IP. This
limit goes up as the IP becomes more valuable, but so too does the extent
to which a hacker will go in order to get at the IP. These two increase
together, which means that the only way to actually protect your IP is to
apply way more resources to protecting it than is actually justified.

In other words, by definition there is no amount of effort one can put
into protecting IP in this way that can be both successful and justified
at the same time.

Pete

 

[Bob]

I personally agree. I'm always skeptical of the assumed value of the IP
being discussed, whenever this sort of thing comes up.

But the fact is, even if one puts a high value on the IP, the nature of
the problem and the costs involved in protecting the IP always wind up in
the hacker's favor. There is obviously some limit to the amount of effort
that is considered a worthwhile investment in protecting the IP. This
limit goes up as the IP becomes more valuable, but so too does the extent
to which a hacker will go in order to get at the IP. These two increase
together, which means that the only way to actually protect your IP is to
apply way more resources to protecting it than is actually justified.

In other words, by definition there is no amount of effort one can put
into protecting IP in this way that can be both successful and justified
at the same time.

Pete

I really appreciate all of your input. It is obviously a balancing
act but seems worth a day or two investment to me in this situation.
I will post if I have any problems with the obfuscated versions that
would further support all the obfuscation-skeptical views.

 

[Peter Duniho]

I really appreciate all of your input. It is obviously a balancing
act but seems worth a day or two investment to me in this situation.

Just FYI: there is no way you can adequately test the output of any
obfuscator in a day or two. Even if implementing the obfuscation itself
were a trivial task (and one would hope the tools would make it that easy
), the job is only getting started at that point. Because of what
obfuscation does, your final application can only be considered reliable
after obfuscation if it has gone through every little bit of testing it
would have from start to finish without obfuscation.

I suppose one could grind their application through an obfuscator and just
trust that it worked. But IMHO, that's just as likely to lose you
customers due to errors in the program caused by obfuscation.

I will post if I have any problems with the obfuscated versions that
would further support all the obfuscation-skeptical views.

I think it would be very much appreciated if you could post again
regardless of your experience. While a number of us are familiar with the
basic idea and some of the names of the tools involved, only a much
smaller subset of the people participating in this newsgroup have
first-hand, real-world experience with the obfuscators available (I'm
definitely not in that subset, due to my bias against obfuscation
obviously ).

Even (or perhaps especially) if your experience is good and you find it
simple and effective, that would be useful information in this context.
The newsgroup has very little in the way of first-hand accounts of using
obfuscation technology that's available for .NET. It would be especially
interesting to see just how resistant to reverse-engineering your
obfuscated code really is.

Thanks,
Pete

 

[Jon Skeet [C# MVP]]

Just FYI: there is no way you can adequately test the output of any
obfuscator in a day or two. Even if implementing the obfuscation itself
were a trivial task (and one would hope the tools would make it that easy
), the job is only getting started at that point. Because of what
obfuscation does, your final application can only be considered reliable
after obfuscation if it has gone through every little bit of testing it
would have from start to finish without obfuscation.

Not only that, but it adds cost in the maintenance side as well. Even
assuming you're using an obfuscator which keeps a reverse mapping so
you can run obfuscated stack traces through a tool and see the "real"
stack trace, that's still an additional hassle.