Need built in obfuscation support in C# compiler

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I made the suggestion "Need built in obfuscation support in C# compiler" to
Microsoft. Anyone here agree with me? If yes, please cast your vote on this
suggestion to raise its priority.
 
vincent said:
I made the suggestion "Need built in obfuscation support in C# compiler" to
Microsoft. Anyone here agree with me? If yes, please cast your vote on this
suggestion to raise its priority.
Click to expand...

I'll agree with that.
 
vincent said:
I made the suggestion "Need built in obfuscation support in C# compiler" to
Microsoft. Anyone here agree with me? If yes, please cast your vote on this
suggestion to raise its priority.
Click to expand...

Why on earth should it be part of the C# compiler? That means you've
got to have another obfuscator as part of the VB.NET compiler, and
another as part of the MC++ compiler - assuming that they're just as
worthy of obfuscation.

Having a single obfuscator which works with assemblies rather than
source is much simpler, IMO.
 
vincent said:
I made the suggestion "Need built in obfuscation support in C# compiler" to
Click to expand...

What technical problems would that solve?

Which specific features could an in-compiler implementation have, that a
separate obfuscater cannot?
 
Hi,

Agreed, What make more sense is to add obfuscation as part of the assembly
generation, the compiler compile the code as today and later (if a flag is
provided) invoke the obfuscation.
Now it's not trivial thing to do, as the obfuscation cannot be complete, you
have to leave the public symbols intact , a similar thing would need to be
done with the protected ones, only the private symbols can be obfuscated.

I think that maybe this is the reason why it was not included from the
beginning.

Maybe the best solution is leave it as it's today but provide a strong
obfuscator with the SDK, integrated with the IDE and put obfuscation as a
project property. in this way you can obfuscate a project output easily.

I guess this will be today's most posted thread :)

Cheers,
 
Jon Skeet said:
Why on earth should it be part of the C# compiler? That means you've
got to have another obfuscator as part of the VB.NET compiler, and
another as part of the MC++ compiler - assuming that they're just as
worthy of obfuscation.

Having a single obfuscator which works with assemblies rather than
source is much simpler, IMO.
Click to expand...

Here is my whole point, you may did not read my suggestion:

I strongly suggest to provide built-in obfuscation support in C# compiler,
here are the reasons:

1. Shipping a commercial product without minimum protection is unacceptable.
2. Current third party obfuscator all could get your final release broken,
you lose confidence on your own product. And if the tools you use has bug,
you will have more trouble.
3. The current obfuscator make it a very hard job to deliver a patch
assembly, you have to keep track what you did before. Once you lose the
mapping you used, you cannot deliver a patch any more. The easy deployment
features from .Net are totally lost with current obfuscation.
4. I believe the compiler knows the program better than any other third
party tools; it sure can do a better and safer job, and release the
obfuscation burden from developer.

My suggestion is to add a key based obfuscation option to the C# compiler,
it is up to you to turn it on or off. As long as you use the same key to
compile your entire solution, no matter how may times you do, the public
types always have the same obfuscated name, you don’t have to worry about
delivering a patch later on. The only thing you have to keep in mind is the
key, and I think is easy to do.
 
Vincent said:
Here is my whole point, you may did not read my suggestion:
Click to expand...

I read your suggestion, but your post doesn't address my objection
except for point 4:
4. I believe the compiler knows the program better than any other third
party tools; it sure can do a better and safer job, and release the
obfuscation burden from developer.
Click to expand...

What part of the code do you think the compiler knows better than
something which has access to just the compiled assembly and debug
information, which is also useful to an obfuscator? (The distinction
between 3rd party and 1st party is irrelevant, IMO. MS could write an
obfuscator which operated on assemblies - please address that scenario
to avoid red herrings.)

By the way, there are companies that *do* ship without any protection.
I don't think it's nearly as big an issue really as many people
perceive it to be.
 
OK. If you don't agree with me, that's fine. I am not trying to triger a war
on this issue; I just want to make our developer's life a little bit easier.
The dofuscator solution does not satisfy me, especially when you want to
deliver a patch assembly, which is shared by lots of .exe files.
 
I think what others are saying is you don't need obfuscation in the high
language level as obfuscators work at the IL level. So one common
obfuscator can be used for any IL regardless of the language. What your
really asking for (I think) is a good embedded/supported obfuscator in VS.
As you know, it ships with a community one. You can decide if it is good or
not. It is mainly a teaser to get you to buy their "real" product. That
said, I tend to agree with you. Some things can be left to third parties
and cottage industry. Some things should be shipped and tested with the
product and supported and be a first class citizen in the whole VS/CLR
combo. I think this is one of the things, but others may not agree.
Naturally, the obfuscator companies would have major heart attack over that.
 
vincent said:
Here is the link to my suggestion:
http://lab.msdn.microsoft.com/produ...edbackid=dad6f429-67d5-43f0-ae3b-81e8c76173d6
Click to expand...

Thanks for the pointer.

I see the basic problem you have with a non-compiler-builtin obfuscator as:

"current obfuscator make it a very hard job to deliver a patch assembly"

But I do not understand why you think your suggestion:

"a key based obfuscation"

would not be just as viable for a non-compiler-builtin obfuscator.

Couldn't your permise:

"As long as you use the same key to compile [obfuscate] your entire
solution"

just as easily be applied to the obfuscation-step as the compilation step?

It sounds a little bit like wishing for the coffee machine to make toast
too, even though the coffe-machine and toaster function very well each
by themselves.
 
Helge Jensen said:
vincent said:
Here is the link to my suggestion:
http://lab.msdn.microsoft.com/produ...edbackid=dad6f429-67d5-43f0-ae3b-81e8c76173d6
Click to expand...

Thanks for the pointer.

I see the basic problem you have with a non-compiler-builtin obfuscator as:

"current obfuscator make it a very hard job to deliver a patch assembly"

But I do not understand why you think your suggestion:

"a key based obfuscation"

would not be just as viable for a non-compiler-builtin obfuscator.

Couldn't your permise:

"As long as you use the same key to compile [obfuscate] your entire
solution"

just as easily be applied to the obfuscation-step as the compilation step?

It sounds a little bit like wishing for the coffee machine to make toast
too, even though the coffe-machine and toaster function very well each
by themselves.
Click to expand...
I know the obfuscator can do, if it wants, what I suggested , but if the
compiler can support it, you have the following extra benefit:

1. save time and money on integrating a third party product.
2. less chance to have bug, we don't see much bugs in a compiler, right ?
3. C# language is pretty new, and changing, so bfuscators have to keep up
with new changes, there could be a lag that will affect your project.
 
Vincent said:
I know the obfuscator can do, if it wants, what I suggested , but if the
compiler can support it, you have the following extra benefit:

1. save time and money on integrating a third party product.
Click to expand...

Again, that's a red-herring - the issue of "third party or built by
MS" is separate from "put it in the compiler or make it work on IL".

Making it separate is what saves time, because MS would only have to do
it once rather than three times (once for MC++, once for VB.NET, once
for C#).
2. less chance to have bug, we don't see much bugs in a compiler, right ?
Click to expand...

But adding more and more to the compiler is going to make it more and
more complicated, leading to a greater likelihood of bugs.
3. C# language is pretty new, and changing, so bfuscators have to keep up
with new changes, there could be a lag that will affect your project.
Click to expand...

It only has to keep up with the language if you build it into the
compiler. If you build it to work on IL, it only has to change when
*that* changes.
 
Back
Top