SharpDevelop Community

I found that microsoft release a public obfuscator control for .net code. it includes licensing  by time and a lot of other goodies.

http://www.microsoft.com/SLPS/

i doenloaded the command line obfuscator aand tools, and really think this would be a wonderful think to incorporate. I stumbled across this 3 days ago, and it looks pretty good. the GUI tools will go after a complete assembly and and re-alias all kinds of internal material in obfuscation efforts, though i have barely had a chance to test it.

The licensing with expiration is also emminently good, allowing youbuild your own in coordination or just use theirs, and when the time is up, all you have to code by the documentation is an exception trap, most of the time you would make a drop out.

I usually don't flat-out reject feature ideas, but this time I do. Feel free to write such an addin (and eg host it on CodePlex), but it definitely won't ship in SharpDevelop.

Chris

Ok, struck a nerve in some fashion, but i would like to know the specifics.

I have become aware that the system i gave a link to is a server service, and therefor partially unfeasible, but an overall refusal strikes me as counter intuitive. After all, I am sure that a base mod code be designed to just perform transforms on IL, whether obfuscation or other code embeding, such as transformed dll exporting and similar, could be an easy after compile step of some kind. Maybe during, i need to study the construction system more.

The system the code protector is using is worth study, even if it is not directly implimentable or desirable.

So can we at least discuss the techniques that would be involved, or the reasons for refusal?

 Code Obfuscation and Open Source doesn't mix.

http://www.cs.princeton.edu/~boaz/Papers/obfuscate.pps

from http://www.cs.princeton.edu/~boaz/pubs.php see ref [ BGI+01  ]

Chris

Why not?

Encryption is a critical part of various open source materials, from ssl handling to document security.

just because the runtime code is obfuscated, (which can prevent hacking damage and other attacks) the Source code itself wouldn't be, especially with the way it is currently being done.

I guess this is a case where people have an all or none opinion. I such a case i will talk about it with some encryptiopn groups. I wasn't trying to offend anybody.

Hmmm, document security or encryption of traffic do not have anything to do with source code obfuscation. The latter is a means of making it more difficult for an attacker/competitor/whatever to understand the (source) code and structure of the application at hand, the former are means of securing confidential information outside the application itself.

Code obfuscation might well raise the bar of compromising the security of the application as such, but is not impossible to breach as has been demonstrated (http://www.cs.princeton.edu/~boaz/Papers/obf_informal.html). And if the source to your application is Open - who will prevent someone from building an "unfriendly" executable version? If your source code is not Open, well, then you might consider obfuscation as one measure to secure your application. And on the .net platform (as well as on Java) there are reflectors available due to the nature of the platforms which will allow you to more or less easily figure out what obfuscated code does.

If you are worried about executable versions of an application being breached, you should rather look at coding practices intended to make exploitation of code weaknesses harder - think "adress space layout randomisation", "canaries" and the like.

yes no encryption or obfuscation can ever be perfect, i am curious anybody needed to waste time proving it. I guess i am having trouble with a conceptual difference, that between runtime and source. One of the benefits i see to obfuscation strategies is that code would be more difficult to realiagn to a variety of mal-ware purposes, as attachment points internally would be non predictable, making mass malware piggy backers a non issue.

After all, your door to your house is easier to break than the lock to get in, but its noisy, giving chance to discovery of a the problem. This would be similar, as failed attacks would undoubtable raise exceptions, which could raise the alarm when attacks abound. as far as corporate tools, actually as many strategies as possible prove a different math theorem takes place, much like the door scenario. As long as its cheaper to use and buy licensed software than to break it, you use legitimate software(per the developing agent). The internet worlds adds on effect to this tho, your security could be nothing and as long as no one looks at your secure through invisibility.

Thats not good enough for some of us.