|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Best practice question: Protecting managed assembliesHi,
What is the best practice to avoid the end user tampering with installed managed DLLs. For example, a web application connects to a server to verify licenses. If licenses are valid, the application runs, if not an error page is displayed. However, if the web application (ASP.NET) is decompiled, modified and recompiled, and installed, the license check can be skipped. Our assemblies have a strong name, but my understanding is that it doesn't protect us, since the end user can find the assembly hierarchy and decompile - recompile the whole assembly to solve the strong name problem. So, what's the solution? Greetings Laurent Hi Laurent,
Actually strong name is the best practice to protect your assemblies. When you sign the assembly with your private key, it produces a hash value which is called public key token and put it into the assembly. When client side CLR loads the assembly, it recalculate the hash code value and compare with the public key token. If they don't match, the assembly is considered as another assembly and won't be accepted. The public key token is produced with some algorithm. If you changes the assembly content a little, it guarentees to produce another value. So, the end user will have no chance to substitute the assembly with another one, unless you leak your private key to others. http://msdn2.microsoft.com/en-us/library/wd40t7ad.aspx If anything is unclear, please feel free to let me know. Kevin Yu Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== (This posting is provided "AS IS", with no warranties, and confers no rights.) Hi Kevin,
Kevin Yu [MSFT] wrote: > Hi Laurent, Yes. However, if the "hacker" decompiles the whole assembly hierarchy, > > Actually strong name is the best practice to protect your assemblies. When > you sign the assembly with your private key, it produces a hash value which > is called public key token and put it into the assembly. When client side > CLR loads the assembly, it recalculate the hash code value and compare with > the public key token. If they don't match, the assembly is considered as > another assembly and won't be accepted. up to the EXE or the Web application, and then rebuilds the whole hierarchy again, then the new assemblies will be accepted, because the manifests will be recreated, am I wrong? Laurent Show quote > > The public key token is produced with some algorithm. If you changes the > assembly content a little, it guarentees to produce another value. So, the > end user will have no chance to substitute the assembly with another one, > unless you leak your private key to others. > > http://msdn2.microsoft.com/en-us/library/wd40t7ad.aspx > > If anything is unclear, please feel free to let me know. > > Kevin Yu > Microsoft Online Community Support You could add obfuscation, strong naming and run everything on the server.
That said, you may not have this luxury of running everything on the server. Show quote "Laurent" wrote: > Hi Kevin, > > Kevin Yu [MSFT] wrote: > > Hi Laurent, > > > > Actually strong name is the best practice to protect your assemblies. When > > you sign the assembly with your private key, it produces a hash value which > > is called public key token and put it into the assembly. When client side > > CLR loads the assembly, it recalculate the hash code value and compare with > > the public key token. If they don't match, the assembly is considered as > > another assembly and won't be accepted. > > Yes. However, if the "hacker" decompiles the whole assembly hierarchy, > up to the EXE or the Web application, and then rebuilds the whole > hierarchy again, then the new assemblies will be accepted, because the > manifests will be recreated, am I wrong? > > Laurent > > > > > The public key token is produced with some algorithm. If you changes the > > assembly content a little, it guarentees to produce another value. So, the > > end user will have no chance to substitute the assembly with another one, > > unless you leak your private key to others. > > > > http://msdn2.microsoft.com/en-us/library/wd40t7ad.aspx > > > > If anything is unclear, please feel free to let me know. > > > > Kevin Yu > > Microsoft Online Community Support > Hi Laurent,
The purpose of hacking is to substitute an assembly with the other one, to cheat the top level EXE or web app to behave in another way. If the hacker can change the top level stuff, is there any need for him to do this kind of hack? Also, if he re-build these assemblies, the public key tokens will be changed, and the end user or .NET framework security will identify it. Any comment is welcomed. :-) Kevin Yu Microsoft Online Community Support ================================================== (This posting is provided "AS IS", with no warranties, and confers no rights.) Hi Kevin,
Kevin Yu [MSFT] wrote: > Hi Laurent, Thanks for following up.> > The purpose of hacking is to substitute an assembly with the other one, to > cheat the top level EXE or web app to behave in another way. If the hacker > can change the top level stuff, is there any need for him to do this kind > of hack? Also, if he re-build these assemblies, the public key tokens will > be changed, and the end user or .NET framework security will identify it. > > Any comment is welcomed. :-) > > Kevin Yu > Microsoft Online Community Support Maybe I need to explain to you more in details how our licensing mechanism works: - We have an unmanaged server (legacy application) which uses a hardware dongle and a license file to check how many licenses are available for a given component of the application. For example, the user wants to start a "web alarm viewer" on the web browser. The web application connects to the legacy server (using remoting to a .NET wrapper), requests one license for the Web Alarm Viewer. If one license is available, the license server says OK. If not, it says No way. - The managed component then uses the returned value to either continue working, or to display an error page. So now, if the hacker uncompiles the managed assembly, removes the license check, recompiles everything (up to the web application), then in my understanding, he can start as many web alarm viewers as he want. I still can't see the flaw in that reasoning... Thanks for the help, Laurent -- Laurent Bugnion [MVP ASP.NET] Software engineering: http://www.galasoft-LB.ch PhotoAlbum: http://www.galasoft-LB.ch/pictures Support children in Calcutta: http://www.calcutta-espoir.ch Hi Laurent,
I'm sorry for the misunderstanding. In this case, it's not only a problem to .NET assemblies, but also to all kinds of components. But the assemblies are easy to be decompiled. To prevent this, I suggest you use some .net obfuscator. Here is an example. http://www.preemptive.com/products/dotfuscator/index.html Kevin Yu Microsoft Online Community Support ================================================== (This posting is provided "AS IS", with no warranties, and confers no rights.) On 16 jan, 02:46, v-k***@online.microsoft.com (Kevin Yu [MSFT]) wrote:
Show quote > Hi Laurent, Hi Kevin,> > I'm sorry for the misunderstanding. > > In this case, it's not only a problem to .NETassemblies, but also to all > kinds of components. But the assemblies are easy to be decompiled. To > prevent this, I suggest you use some .netobfuscator. Here is an example. > > http://www.preemptive.com/products/dotfuscator/index.html > > Kevin Yu > Microsoft Online Community Support > ================================================== > > (This posting is provided "AS IS", with no warranties, and confers no > rights.) May I suggest another example of .NET obfuscator, which is {smartassembly}? There are several .net protection and obfuscation solutions on the market, but {smartassembly} is unique on 2 major points: · Its comprehensive feature-set beyond obfuscation, with powerful post- deployment debugging capabilities (advanced unhandled exception reporting via 24x7x365 managed Web Service); · Its user-friendliness, which aims to allow every .NET developer to produce better software, improved and protected, whatever his level of competence or expertise. {smartassembly} offers every .NET developer an easy way to: - Secure his.net application (with advanced Obfuscation, Strings Encoding, Anti-disassembler & Anti-decompiler options, Strong Name signing...) - Deploy his.net application in one file (Dependencies Merging, Dependencies Compression and Embedding), - Remove all non-useful code and metadata (advanced Pruning), - Perform other code optimizations (Memory Management, Classes Sealing...) - Add automatic unhandled Exception Reporting, to radically simplify the debugging of his obfuscated / deployed assembly. A fully-featured evaluation version is freely downloadable at http://www.smartassembly.com/download. And more information is available on our website at http://www.smartassembly.com. Best regards, Marina {smartassembly} Team |
|||||||||||||||||||||||