Addressing New Challenges in Software Protection for .NET


Published on

This white paper addresses the new challenges in software protection for the .NET Framework in addition to providing a variety means for protecting your applications.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Addressing New Challenges in Software Protection for .NET

  1. 1. Addressing New Challenges in SoftwareProtecting for .NETwhiTepaperThis white paper addresses the new challenges in software protection for the .NETFramework in addition to providing a variety means for protecting your applications.Table of ContentsExecutive Summary............................................................................................................. 2How secure is your code? ................................................................................................... 2What can be done to secure your code? ............................................................................... 3More sophisticated methods............................................................................................... 3Inside the class – Method level protection .......................................................................... 4Conclusion .......................................................................................................................... 5About SafeNet..................................................................................................................... 5Addressing New Challenges in Software Protection for .NET Whitepaper 1
  2. 2. Designed as the basis for executive Summarythe majority of new Windows .NET is a Microsoft Web services strategy allowing the connection of information, people,applications, the .NET systems, and devices through software. Integrated across the Microsoft platform, .NETFramework was built with technology provides the ability to quickly build, deploy, manage, and use connected, security-a variety of goals in mind enhanced solutions with Web services. .NET connected solutions enable businesses to integrateincluding: interoperability, their systems more rapidly and in a more agile manner helping them realize the promise ofportability, language information anytime, anywhere, on any device.independence, fast deployment,and enhanced security. Designed as the basis for the majority of new Windows applications, the .NET FrameworkAlthough very promising, the was built with a variety of goals in mind including: interoperability, portability, language.NET Framework also brings independence, fast deployment, and enhanced security. Although very promising, the .NETwith it inherent risks to the Framework also brings with it inherent risks to the developed applications, the in-house know-developed applications, the how, and a company’s most precious asset – its intellectual property (IP). This paper discussesin-house know-how, and a various approaches in securing .NET Framework based applications from potential’s most precious asset– its intellectual property (IP). how secure is your code?This paper discusses various Software developers are rapidly choosing .NET as their preferred platform due to the inherentapproaches in securing .NET advantages this Framework provides. Those responsible for new software projects must weighFramework based applications the possibility of security breaches within their Framework. This paper discusses two possiblefrom potential threats. security issues within .NET development: reverse engineering and unwanted code modification. .NET applications are (at least theoretically) platform independent. Compiled .NET programs do not contain native processor instructions. Instead, the compiler generates Intermediate Language (IL) code that is loaded and compiled by the target system’s runtime environment called Common Language Runtime system (CLR). This only makes a virtual difference to native code. Looking further into the structure of .NET files reveals much more. .NET may appear highly secure; however, developers need to be fully aware of these security considerations prior and during the development process in order to avoid throwing “code” stones onto a glass house. Intermediate Language (IL) files use the well-known PE (Portable Executable) file structure already used by Win32 files as their transport media. Most likely this was because it was easy for Microsoft to integrate a native PE stub that automatically fired up the CLR on older Windows versions when attempting to carry out the .NET executable. In fact, even pure .NET application files contain some native Intel x86 code as stubs to self load the CLR and transfer control to the core DLL (mscoree.dll). Newer Windows versions recognize the .NET file directly and make no use of the native stub – the .NET file gets directly handed over to the CLR. The true .NET part inside the file is described using a “new” tag known as Metadata. The Metadata reveals numerous details regarding your code, like the PE tables in native Win32 applications; the Metadata contains information about exported interfaces and imported items. Furthermore, all names of internal objects, methods, their positions, sizes, parameter names, signatures, and all strings are presented here in an organized table. This Metadata ensures there is no blind spot on disassembly. Every reference to other objects, whether internal or external, makes use of this table. For Win32 applications, there is the permanent problem that, on disassembly, the attacker must frequently guess the start address of the individual function and whether the region under investigation contains code or data. Yet, when analyzing .NET assemblies, all this uncertainty vanishes. The Metadata provides all the relevant the details. It is approximately the same information as if you were delivering your Win32 applications with all the debugging information. It is easy to imagine what competitors and software crackers can do with your fully transparent software. It is like all secret business-critical algorithms inside the software are left out in the open. License term verification and the actions upon it can be clearly seen. All parts of the code can be decompiled, modified to behave differently, and then securely reintegrated. Addressing New Challenges in Software Protection for .NET Whitepaper 2
  3. 3. This of course is a major setback for any company that seeks on the one hand full compatibility,portability sand other .NET benefits, and on the other security in terms of licensing and IPprotection.what can be done to secure your code?Code obfuscation is an old and very well-known approach when attempting to secure one’s code,relying on two main principles: • Computers (Operating Systems) do not care about human readability, thus, there is no need for nice, self-explaining object names. All internal, non-exported objects are usually given randomly chosen identifiers. As in most cases, the name itself has no meaning for execution. It is often the same for most objects. Information that is not mandatory for correct execution is stripped. Some obfuscators add additional ingredients, such as: random insertion of code that has no influence on the result of the function. • Introduction of small errors in assembly structure that cause standard tools such as ILDASM to produce incorrect results or lose track. ILDASM basically parses any .NET Framework .exe or .dll assembly file, and shows the information in human-readable format. It also displays namespaces and types, including their full interfaces.Obfuscation methods clearly and substantially degrade human readability, but do not provide afull solution as the code executed eventually sits in the file on disk completely unprotected. Allinformation to safely decompile the code with more sophisticated tools is still in place, and thereare no obstacles present to prevent modifications.As hackers have shown for Win32 applications, readability of variables is not an issuewhen it comes to getting inside applications and modifying them; thus, it is clear that moresophisticated measures are required to address cracking attempts.More sophisticated methodsIn addition to obfuscation, there are two more sophisticated security methods available eachwith its pros and cons providing both ease of implementation and added flexibility in terms oflicensing.Loader VariantThe first is the loader variant. The typical approach is inherited from the early Win32 protectiontools. These early Win32 protection tools were “plain loaders.” The original application filewas bundled in a proprietary format together with a loader that knew how to reconstruct theapplication from the proprietary format. On execution, the loader got control first, then broughtthe original application completely into memory or installed a filter that took control when theOperating System read a piece of code from disk and presented the decoded fragment to the OS.Once the code was in memory, the loader was completely disconnected from the application.For .NET applications, this scheme is only applicable for executables. It cannot be used onassemblies. Tools applying this technique make use of the fact that the .NET CLR can be invokedby the previously mentioned x86 stub attached to all .NET executables. They transform theoriginal .NET executable into a regular looking Win32 PE file.Upon execution, the Operating System hands over control to the PE entry point – the actualloader. The loader installs filters to intercept file I/Os relating to this process and finally handscontrol over to the mscoree.dll. At the point when the CLR loads the image from disk, the loader’sfilters intercept the data flow.The loader will present the original decoded image to the CLR, making it appear as if it isunchanged, and the application starts up as usual. The strength of this approach lies in the factthat the IL code is never unprotected on disk; rather, it lies only inside the temporary memory,between loading and first execution. At first execution, it is just-in-time compiled and, thus,modified. As the format in which the IL code is stored on disk is not known, the hacker wouldAddressing New Challenges in Software Protection for .NET Whitepaper 3
  4. 4. Developing for .NET presents need to completely reverse engineer the decoding process to be able to modify any part of thenew challenges for software application in a determinable way.developers, especially when The main drawbacks of the loader approach are:it comes to protecting theirapplication from reverse • This method can only be applied to executables and not to assemblies, as the x86 stubsengineering and illegal use by would not get executed. If a hacker manages to get hold of the data presented to the CLR,hacking. Modern obfuscators they typically have the plain unprotected original .NET file in hand stripped of all protection.can significantly raise the baragainst reverse engineering, • Companies developing protection tools using the loader must implement strong anti-but not always provide a debugging measures to prevent this type of attack.comprehensive solution. To Method-Level protectionachieve protection againsthackers, a very methodical The second approach, protecting at the method level is substantially different. It was inventedrequirements analysis is to to cure the main weaknesses of obfuscation and the loader approach. It is obvious that codebe carried out in order to fully obfuscation leaves the IL code machine readable.understand the threats along The Sentinel HASP .NET Envelope solves this problem by enabling encryption at the lowestwith the needs and the various level of executable code – Methods. This means that the developer can specify that individualsolutions offered as part of a Methods are encrypted separately and decrypted only at execution. The result is that smallercomprehensive platform. portions of code are exposed in memory for shorter periods of time, making the Intellectual Property (IP) contained in the code far less vulnerable. In addition these chunks of code are taken out of the context of physical .NET assemblies. They cannot simply be dumped from memory to form usable CLR code – even while fully decrypted. As an added benefit, each Method may be treated as a separate feature. This ensures unparalleled flexibility as the vendor is now free to license and control each individual Method separately. So, for example, you could separately license features that save to different file types, even if the individual Methods the application used were all included under the same .NET class. inside the class – Method level protection The obvious solution is operating in a Method level format; allowing the selection of which Methods inside respective classes receive the individual protection shields that are fully integrated into the usual execution flow, similar to Just-in-Time (JIT) compilation. It becomes an integral part of using the Method. Thus, each Method can have its own individual protection applied, making the data on disk absolutely useless, unless for its very own protection shield. As this protection scheme is self-contained, it can also be applied to .NET assemblies. In contrast to the loader method previously discussed, Method level protection requires a detailed very thorough understanding of the class structure and IL code that is to be protected. Compared to obfuscation, a complete new .NET file will be generated that is capable of hosting both protected and unprotected classes and methods. The ability to select the individual Method keeps load time low and allows the automatic addition of code on the same level (e.g., protecting different Methods of different classes with different licensing terms) opening a previously unknown flexibility option in Software Rights Management. Addressing New Challenges in Software Protection for .NET Whitepaper 4
  5. 5. Conclusion Developing for .NET presents new challenges for software developers, especially when it comes to protecting their application from reverse engineering and illegal use by hacking. Modern obfuscators can significantly raise the bar against reverse engineering, but not always provide a comprehensive solution. To achieve protection against hackers, a very methodical requirements analysis is to be carried out in order to fully understand the threats along with the needs and the various solutions offered as part of a comprehensive platform. If there is no need for assembly protection, or for licensing on a class basis, then a simple loader solution might do the job. But if a more comprehensive flexible solution is required, then Method-level security is definitely the right approach. SafeNet Sentinel Software Monetization Solutions SafeNet has more than 25 years of experience in delivering innovative and reliable software licensing and entitlement management solutions to software and technology vendors worldwide. Easy to integrate and use, innovative, and feature-focused, the company’s family of Sentinel® Software Monetization Solutions are designed to meet the unique license enablement, enforcement, and management requirements of any organization, regardless of size, technical requirements or organizational structure. Only with SafeNet are clients able to address all of their anti-piracy, IP protection, license enablement, and license management challenges while increasing overall profitability, improving internal operations, maintaining competitive positioning, and enhancing relationships with their customers and end users. With a proven history in adapting to new requirements and introducing new technologies to address evolving market conditions, SafeNet’s more than 25,000 customers around the globe know that by choosing Sentinel, they choose the freedom to evolve how they do business today, tomorrow, and beyond. For more information on SafeNet’s complete portfolio of Software Monetization Solutions for installed, embedded, and cloud applications or to download a free evaluation of our award- winning products please visit: To download a FREE SENTINEL HASP Developer Kit, visit: the ConversationSentinel Twitter LinkedIn YouTube Contact Us: For all office locations and contact information, please visit Follow Us: ©2011 SafeNet, Inc. All rights reserved. SafeNet and SafeNet logo are registered trademarks of SafeNet. BrightTalk All other product names are trademarks of their respective owners. WP (EN)-01.02.11 Addressing New Challenges in Software Protection for .NET Whitepaper 5