Obfuscators Make .NET More Secure
-
Hello, the CPians around the world.;) Obfuscators Make .NET More Secure [^] I'm looking for the free Obfuscators to make my C# code secure.:confused: -Masaaki Onishi (eCoolSoft)- ASP.NET Web and Windows Application Development by C# and MFC. eCoolWebPanelBar(BETA) is availabe now. http://www.ecoolsoft.com
Masaaki Onishi wrote: I'm looking for the free Obfuscators to make my C# code secure. Learn to code "obfuscatingly" :laugh: MyDUMeter: a .NET DUMeter clone
"Thats like saying "hahahaha he doesnt know the difference between a cyberneticradioactivenuclothermolopticdimswitch and a biocontainingspherogramotron", but with words you have really never heard of." -
Masaaki Onishi wrote: I'm looking for the free Obfuscators to make my C# code secure. Learn to code "obfuscatingly" :laugh: MyDUMeter: a .NET DUMeter clone
"Thats like saying "hahahaha he doesnt know the difference between a cyberneticradioactivenuclothermolopticdimswitch and a biocontainingspherogramotron", but with words you have really never heard of."leppie wrote: Learn to code "obfuscatingly Comes naturally to me. Most people think I write poor code, little do they realise it is naturally obfuscated. *sigh, throws hand onto brow and tilts head back in despair* I will never be understood in my time. :rolleyes:
Paul Watson
Bluegrass
Cape Town, South AfricaMacbeth muttered: I am in blood / Stepped in so far, that should I wade no more, / Returning were as tedious as go o'er Bluegrass is looking for a few good men
-
Hello, the CPians around the world.;) Obfuscators Make .NET More Secure [^] I'm looking for the free Obfuscators to make my C# code secure.:confused: -Masaaki Onishi (eCoolSoft)- ASP.NET Web and Windows Application Development by C# and MFC. eCoolWebPanelBar(BETA) is availabe now. http://www.ecoolsoft.com
Some topics the article doesn't show: 1. Write all your important code in Managed C++. It is not more complex than writing code in C#, once you get used to the weird syntax, but you'll lose the UI designers and the compiler is much slower. This will generate assemblies mixing native code and CLR calls, rendering useless the efforts of decompilers. 2. Obfuscating code will create a support problem to you. I suspect this is the reason MS didn't include an obfuscator in the first edition of VS.NET (there are other natural suspects, like budget and time, but who cares?): One of the most useful diagnostic features of the .NET framework is the stack trace that comes with an exception description. This stack trace becomes obfuscated too, when you obfuscate your assemblies. Some obfsucators even obfuscate your custom exception names, too! I know this behavior can be bypassed, but it's manual and cumbersome. You'll need to save the obfuscator's results and write an "exception stack trace deobfuscator". I see dumb people
-
Hello, the CPians around the world.;) Obfuscators Make .NET More Secure [^] I'm looking for the free Obfuscators to make my C# code secure.:confused: -Masaaki Onishi (eCoolSoft)- ASP.NET Web and Windows Application Development by C# and MFC. eCoolWebPanelBar(BETA) is availabe now. http://www.ecoolsoft.com
Quite honestly, I don't know why you should fear someone reverse engineering your code. After all, if that's about understanding the SDK you expose (reduction of customer support cost), helping you fix your bugs, or even let you know about possible implementations, then I don't see what might be wrong about it. In practice, MSIL code is very hard to rip even if you use a clean C# decompiler (such as ...). Indeed, since your classes may refer to an arbitrary set of other classes, contexts, other namespaces, other assemblies, etc. I think it's very hard even for an expert to actually steal your code. Besides that, MSIL code does not bring the comments from your source code. (this would be the goal of retrodocumentation tools. Oh I love the business idea here :-O ). I have been asking some of the obuscation guys about whether they were neutral, about whether they were preventing the JIT from producing optimized code, and of other possible side effects of obfuscation. Believe me or not, I have never got other answer but "trust in us". This looks to me a bit too much the MS marketing way of doing things. X| <aparte>MS recently patented 48 things around .NET, including the framework and the CLR.</aparte> I don't know if the people behind obfuscation tools are going to be stupid enough to spread fear such that they have the key to deobfuscate your code (since they have publicly exposed only half of the algorithms...) and intend to do harm if you don't buy new licenses. :omg:
-
Some topics the article doesn't show: 1. Write all your important code in Managed C++. It is not more complex than writing code in C#, once you get used to the weird syntax, but you'll lose the UI designers and the compiler is much slower. This will generate assemblies mixing native code and CLR calls, rendering useless the efforts of decompilers. 2. Obfuscating code will create a support problem to you. I suspect this is the reason MS didn't include an obfuscator in the first edition of VS.NET (there are other natural suspects, like budget and time, but who cares?): One of the most useful diagnostic features of the .NET framework is the stack trace that comes with an exception description. This stack trace becomes obfuscated too, when you obfuscate your assemblies. Some obfsucators even obfuscate your custom exception names, too! I know this behavior can be bypassed, but it's manual and cumbersome. You'll need to save the obfuscator's results and write an "exception stack trace deobfuscator". I see dumb people
I have my doubts on obfuscation, I somewhere read that code obfuscation would nullify any optimisations that can be performed during the run-time, is there any truth to this. regards Kannan
-
Quite honestly, I don't know why you should fear someone reverse engineering your code. After all, if that's about understanding the SDK you expose (reduction of customer support cost), helping you fix your bugs, or even let you know about possible implementations, then I don't see what might be wrong about it. In practice, MSIL code is very hard to rip even if you use a clean C# decompiler (such as ...). Indeed, since your classes may refer to an arbitrary set of other classes, contexts, other namespaces, other assemblies, etc. I think it's very hard even for an expert to actually steal your code. Besides that, MSIL code does not bring the comments from your source code. (this would be the goal of retrodocumentation tools. Oh I love the business idea here :-O ). I have been asking some of the obuscation guys about whether they were neutral, about whether they were preventing the JIT from producing optimized code, and of other possible side effects of obfuscation. Believe me or not, I have never got other answer but "trust in us". This looks to me a bit too much the MS marketing way of doing things. X| <aparte>MS recently patented 48 things around .NET, including the framework and the CLR.</aparte> I don't know if the people behind obfuscation tools are going to be stupid enough to spread fear such that they have the key to deobfuscate your code (since they have publicly exposed only half of the algorithms...) and intend to do harm if you don't buy new licenses. :omg:
.S.Rod. wrote: I think it's very hard even for an expert to actually steal your code. I had a nice attempt at getting a specific designer marked private in the Systam.Design. Everytime I though I had a all references resolved, new ones popped up exponentially. No point in distributing a complete dll for just one "feature" by marking class public. I feel this is the way one should approach writing code by making internal objects co-dependant, thus discouraging "learning" the whole system to put all the pieces back together. MyDUMeter: a .NET DUMeter clone
"Thats like saying "hahahaha he doesnt know the difference between a cyberneticradioactivenuclothermolopticdimswitch and a biocontainingspherogramotron", but with words you have really never heard of." -
There is a lite version included in the VS.NET 2003. Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
Hello, the CPiand around the world.;) After I posted this, I search the open source obfuscators tool, and I found this. Dan Appleman's Obfuscator[^] He writes the core obfuscator by Unmanaged C++, and the other by VB.NET.:cool: If I have my time, I try to rewrite these from VB.NET to C#. But, I don't use this for my DLL by ASP.NET yet. -Masaaki Onishi (eCoolSoft)- ASP.NET Web and Windows Application Development by C# and MFC. eCoolWebPanelBar(BETA) is availabe now. http://www.ecoolsoft.com
-
Some topics the article doesn't show: 1. Write all your important code in Managed C++. It is not more complex than writing code in C#, once you get used to the weird syntax, but you'll lose the UI designers and the compiler is much slower. This will generate assemblies mixing native code and CLR calls, rendering useless the efforts of decompilers. 2. Obfuscating code will create a support problem to you. I suspect this is the reason MS didn't include an obfuscator in the first edition of VS.NET (there are other natural suspects, like budget and time, but who cares?): One of the most useful diagnostic features of the .NET framework is the stack trace that comes with an exception description. This stack trace becomes obfuscated too, when you obfuscate your assemblies. Some obfsucators even obfuscate your custom exception names, too! I know this behavior can be bypassed, but it's manual and cumbersome. You'll need to save the obfuscator's results and write an "exception stack trace deobfuscator". I see dumb people
Hello, the CPians around the world.;) Daniel Turini wrote: 2. Obfuscating code will create a support problem to you I believe that we obfuscate only DLL for the production, but DLL befoer we publish will not be obfuscated. So, we can support DLL for the other ppl inside the company. -Masaaki Onishi (eCoolSoft)- ASP.NET Web and Windows Application Development by C# and MFC. eCoolWebPanelBar(BETA) is availabe now. http://www.ecoolsoft.com
-
Quite honestly, I don't know why you should fear someone reverse engineering your code. After all, if that's about understanding the SDK you expose (reduction of customer support cost), helping you fix your bugs, or even let you know about possible implementations, then I don't see what might be wrong about it. In practice, MSIL code is very hard to rip even if you use a clean C# decompiler (such as ...). Indeed, since your classes may refer to an arbitrary set of other classes, contexts, other namespaces, other assemblies, etc. I think it's very hard even for an expert to actually steal your code. Besides that, MSIL code does not bring the comments from your source code. (this would be the goal of retrodocumentation tools. Oh I love the business idea here :-O ). I have been asking some of the obuscation guys about whether they were neutral, about whether they were preventing the JIT from producing optimized code, and of other possible side effects of obfuscation. Believe me or not, I have never got other answer but "trust in us". This looks to me a bit too much the MS marketing way of doing things. X| <aparte>MS recently patented 48 things around .NET, including the framework and the CLR.</aparte> I don't know if the people behind obfuscation tools are going to be stupid enough to spread fear such that they have the key to deobfuscate your code (since they have publicly exposed only half of the algorithms...) and intend to do harm if you don't buy new licenses. :omg:
Hello, the CPians around the world.;) .S.Rod. wrote: I don't know why you should fear someone reverse engineering your code Simple saying, I want to keep my intelletual right. I made my DLL by C# decompiled, and I found that some level of C# programmer can copy my code. My code maybe be simple.:laugh: If my competitors decomple my code, and they enhance their code, my product will lose some advantage....:(( -Masaaki Onishi (eCoolSoft)- ASP.NET Web and Windows Application Development by C# and MFC. eCoolWebPanelBar(BETA) is availabe now. http://www.ecoolsoft.com
-
I have my doubts on obfuscation, I somewhere read that code obfuscation would nullify any optimisations that can be performed during the run-time, is there any truth to this. regards Kannan
Kannan Kalyanaraman wrote: I have my doubts on obfuscation, I somewhere read that code obfuscation would nullify any optimisations that can be performed during the run-time, is there any truth to this. This is simply not true: the obfuscation process consist only of changing the name of the fields, methods and properties of a class for unfriendly names. This would not hinder optimization. You can obfuscate you source code, if you want. Some others can rearrange the order of the code execution. A code optimizer like JIT will not be affected by this, because the graph prunning phase would remove the extra unconditional jumps. But there are some obfuscators that can add constant strings encryption on-the-fly. These obfuscators obviously have a performance hit, but if you coded it by hand, you would achieve the same result. I see dumb people
-
leppie wrote: Learn to code "obfuscatingly Comes naturally to me. Most people think I write poor code, little do they realise it is naturally obfuscated. *sigh, throws hand onto brow and tilts head back in despair* I will never be understood in my time. :rolleyes:
Paul Watson
Bluegrass
Cape Town, South AfricaMacbeth muttered: I am in blood / Stepped in so far, that should I wade no more, / Returning were as tedious as go o'er Bluegrass is looking for a few good men
Aren't you just destroying a business opportunity for hard-working companies creating obfuscators? Shame on you! ;)
If you go to war, you will destroy a great country a stoned greek chick to the richest man of the world
[sighist] | [Agile Programming] [doxygen]