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.

1. Addressing New Challenges in Software
Protecting for .NET
whiTepaper
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.
Table of Contents
Executive Summary............................................................................................................. 2
How secure is your code? ................................................................................................... 2
What can be done to secure your code? ............................................................................... 3
More sophisticated methods............................................................................................... 3
Inside the class – Method level protection .......................................................................... 4
Conclusion .......................................................................................................................... 5
About SafeNet..................................................................................................................... 5
Addressing New Challenges in Software Protection for .NET Whitepaper 1

2. Designed as the basis for executive Summary
the 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, .NET
Framework 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 integrate
including: interoperability, their systems more rapidly and in a more agile manner helping them realize the promise of
portability, 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 Framework
Although 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 .NET
with 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 discusses
in-house know-how, and a various approaches in securing .NET Framework based applications from potential threats.
company’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 inherent
approaches in securing .NET advantages this Framework provides. Those responsible for new software projects must weigh
Framework based applications the possibility of security breaches within their Framework. This paper discusses two possible
from 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. 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 IP
protection.
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 a
full solution as the code executed eventually sits in the file on disk completely unprotected. All
information to safely decompile the code with more sophisticated tools is still in place, and there
are no obstacles present to prevent modifications.
As hackers have shown for Win32 applications, readability of variables is not an issue
when it comes to getting inside applications and modifying them; thus, it is clear that more
sophisticated measures are required to address cracking attempts.
More sophisticated methods
In addition to obfuscation, there are two more sophisticated security methods available each
with its pros and cons providing both ease of implementation and added flexibility in terms of
licensing.
Loader Variant
The first is the loader variant. The typical approach is inherited from the early Win32 protection
tools. These early Win32 protection tools were “plain loaders.” The original application file
was bundled in a proprietary format together with a loader that knew how to reconstruct the
application from the proprietary format. On execution, the loader got control first, then brought
the original application completely into memory or installed a filter that took control when the
Operating 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 on
assemblies. Tools applying this technique make use of the fact that the .NET CLR can be invoked
by the previously mentioned x86 stub attached to all .NET executables. They transform the
original .NET executable into a regular looking Win32 PE file.
Upon execution, the Operating System hands over control to the PE entry point – the actual
loader. The loader installs filters to intercept file I/Os relating to this process and finally hands
control over to the mscoree.dll. At the point when the CLR loads the image from disk, the loader’s
filters intercept the data flow.
The loader will present the original decoded image to the CLR, making it appear as if it is
unchanged, and the application starts up as usual. The strength of this approach lies in the fact
that 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 would
Addressing New Challenges in Software Protection for .NET Whitepaper 3

4. Developing for .NET presents need to completely reverse engineer the decoding process to be able to modify any part of the
new challenges for software application in a determinable way.
developers, especially when
The main drawbacks of the loader approach are:
it comes to protecting their
application from reverse • This method can only be applied to executables and not to assemblies, as the x86 stubs
engineering 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 bar
against 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 protection
achieve protection against
hackers, a very methodical The second approach, protecting at the method level is substantially different. It was invented
requirements analysis is to to cure the main weaknesses of obfuscation and the loader approach. It is obvious that code
be 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 lowest
with the needs and the various level of executable code – Methods. This means that the developer can specify that individual
solutions offered as part of a Methods are encrypted separately and decrypted only at execution. The result is that smaller
comprehensive 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. 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: www.safenet-inc.com/sentinel
To download a FREE SENTINEL HASP Developer Kit, visit:
http://www3.safenet-inc.com/Special/hasp/safenet-hasp-srm-order/default.asp
Join the Conversation
Sentinel Online
www.Safenet-inc.com/sentinel
www.LicensingLive.com
Twitter
twitter.com/LicensingLive
LinkedIn
http://bit.ly/LinkedInLicensingLive
YouTube Contact Us: For all office locations and contact information, please visit www.safenet-inc.com
http://www.youtube.com/user/LicensingLive Follow Us: www.safenet-inc.com/connected
©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
http://www.brighttalk.com/channel/5572
Addressing New Challenges in Software Protection for .NET Whitepaper 5