Dotfuscate or Not ?

[Vincent]

To protect your C# program from decomplication, the Dotfuscator is the
recommanded way by Microsoft. But if you dotfuscate your final release, your
program could break down, and also you will probably fall in a "Dotfuscator
hell", which is even worse than the famous DLL hell. So dotfuscate or Not ?

[Cowboy \(Gregory A. Beamer\)]

Dotfuscate the inner workings and you are fine. Touch any public interface
portions and you are on your own.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside the box!
*************************************************
"Vincent" <Vi*****@discussions.microsoft.com> wrote in message
news:CE**********************************@microsof t.com...

To protect your C# program from decomplication, the Dotfuscator is the
recommanded way by Microsoft. But if you dotfuscate your final release,
your
program could break down, and also you will probably fall in a
"Dotfuscator
hell", which is even worse than the famous DLL hell. So dotfuscate or Not
?

[Steve McLellan]

That's what testing is for. A lot of obfuscators will let you debug the
obfuscated code (the one we use, Xenocode, allows you to generate a map
between the original and ofuscated names that can be applied during
debugging). In any case, a good obfuscator doesn't functionally change code.
That said, as the other poster said, if you change public interfaces you may
be in trouble.

Steve

"Vincent" <Vi*****@discussions.microsoft.com> wrote in message
news:CE**********************************@microsof t.com...

To protect your C# program from decomplication, the Dotfuscator is the
recommanded way by Microsoft. But if you dotfuscate your final release,
your
program could break down, and also you will probably fall in a
"Dotfuscator
hell", which is even worse than the famous DLL hell. So dotfuscate or Not
?

[Cor Ligthert]

Vincent,

How can anybody advise you in a newsgroup not to close your frontdoor.

This depends always on your particular situation. When the software is by
instance only for your private use and you have not the intent to make any
part of it commercial, than you probably know my answer.

Just my thought about your question.

Cor

[Vincent]

"Steve McLellan" wrote:

the one we use, Xenocode, allows you to generate a map
between the original and ofuscated names that can be applied during
debugging

Steve

I don't know Xencode, is it much better than dotfuscator? By the way,
personally I don't like the idea of any obfuscation, it makes you less
confident on your own product, but it seems to be the only way with any .Net
language. After some test and discussion, the company I work for is not
satisfied with any solution on this issue, and decide to stay on C++ . So
..Net is totally out here, how is .Net getting along in your company?

[Helge Jensen]

Vincent wrote:

I don't know Xencode, is it much better than dotfuscator? By the way,
personally I don't like the idea of any obfuscation, it makes you less
confident on your own product, but it seems to be the only way with any .Net
language. After some test and discussion, the company I work for is not
satisfied with any solution on this issue, and decide to stay on C++ . So
.Net is totally out here, how is .Net getting along in your company?

Are you saying that the company lets obfuscation decide which language
to do implementation in? Perfectly good decompilers for C++ exists ;)

Selecting an implementation language based on obfuscation probably not a
wise move in general. C++ is definatly a more expensive
(price/functionality) language than most.

Some of the relevant questions/answers about obfuscation are:

- What does obfuscation defend against?
- Other people copying the code: No
- Other people changing the code: perhaps
- Other people find out how code is structured at source level: yes
- Who does obfuscation defend against:
- Professionals out to do code-theft: Not really
- Random programmers: Yes
- Why isn't the legal protection of copyright and EULA's enough?

Bottom line: I think the ones really prevented of doing anything through
obfuscation are J. random user, and not "customers".

From my point of view, the only real argument for obfuscation is if you
wish to:

- Make life harder for supporters
- Make 31337 groups claim glory by breaking it
- Make customers not see your bad code (this seems to be #1 :)

--
Helge

[Vincent]

"Helge Jensen" wrote:

Vincent wrote:

I don't know Xencode, is it much better than dotfuscator? By the way,
personally I don't like the idea of any obfuscation, it makes you less
confident on your own product, but it seems to be the only way with any .Net
language. After some test and discussion, the company I work for is not
satisfied with any solution on this issue, and decide to stay on C++ . So
.Net is totally out here, how is .Net getting along in your company?

Are you saying that the company lets obfuscation decide which language
to do implementation in? Perfectly good decompilers for C++ exists ;)

Selecting an implementation language based on obfuscation probably not a
wise move in general. C++ is definatly a more expensive
(price/functionality) language than most.

Some of the relevant questions/answers about obfuscation are:

- What does obfuscation defend against?
- Other people copying the code: No
- Other people changing the code: perhaps
- Other people find out how code is structured at source level: yes
- Who does obfuscation defend against:
- Professionals out to do code-theft: Not really
- Random programmers: Yes
- Why isn't the legal protection of copyright and EULA's enough?

Bottom line: I think the ones really prevented of doing anything through
obfuscation are J. random user, and not "customers".

From my point of view, the only real argument for obfuscation is if you
wish to:

- Make life harder for supporters
- Make 31337 groups claim glory by breaking it
- Make customers not see your bad code (this seems to be #1 :)

--
Helge

From a developer's view, I don't believe anyone wants to obfuscate the
product, but from the company's view you must find a way to protect yourself
beside legal protection. If you are using C#, serial number/activation code
method is just too easy to crack, even with obfuscation.

Given a situation like this: You developed a good desktop product using C# ,
and have several dealers to distribute it for you. The dealer definitely has
the incentive and will fiture out the way that you generate the serial
number/activation code. Once that happen, you lose control on the dealer,
they can sell your product freely and you get nothing.

[Helge Jensen]

Vincent wrote:

From a developer's view, I don't believe anyone wants to obfuscate the
agreed :)
product, but from the company's view you must find a way to protect yourself
beside legal protection. If you are using C#, serial number/activation code
method is just too easy to crack, even with obfuscation.
Have you seen *anything* protected by any kind of scheme which isn't
readily downloadable on the internet?
Given a situation like this: You developed a good desktop product using C# ,
and have several dealers to distribute it for you. The dealer definitely has
the incentive and will fiture out the way that you generate the serial
number/activation code. Once that happen, you lose control on the dealer,
they can sell your product freely and you get nothing.

That may be true, but obfuscation will really not protect you against
the "bad guys"(TM) only the random users.

Once the cat is out of the bag, a keygen is distributed and your
obfuscation doesn't mean anything other than making it more interesting
to "crack".

Well, the company is of course free to take any route it chooses, but
selecting an implementation-language on the basis of (seemingly, rather
imprecise analysis of) the obfuscation of source-code seems like a
really good strategy for non-optimal development ~= failure, atlest to mee.

People "out there" have cracked every scheme sofar, they *will* crack
yours, if your app is worth anything to them, and maybe even if it
isn't. There is no obfuscation-defence against that.

--
Helge