Best practice question: Protecting managed assemblies

[Laurent]

Hi,

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

 

[Kevin Yu [MSFT]]

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.)

 

[Laurent]

Hi Kevin,

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

 

[Kevin Yu [MSFT]]

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.)

 

[Laurent]

Hi Kevin,

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

Thanks for following up.

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

 

[Kevin Yu [MSFT]]

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.)

 

[Marina]

Hi Laurent,

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.)

Hi Kevin,

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