According to this article it is very easy to break strong names

http://www.codeproject.com/dotnet/NeCoder03.asp

Is there a way other than strong names to secure .Net assemblies

Any help is appreciated.
Thanks,
Vishal

Removal of a strong name from an assembly does not constitute "breaking" of
the strong name mechanism.


Exactly what kind of "securing" are you interested in applying?  Against
what threat(s) are you attempting to protect the users of your assemblies?

I would like to secure my assemblies.I would not like the users going in and
making changes in my assemblies.Once released i would like that my assemblies
be tamper proof.

Thanks,
Vishal

Show quoteHide quote

Hello vishal,

well - then don't ship them. as soon as you give me your binaries, they are
mine and i can do whatever i like. And if i want to hack the CLR to turn
of validation at all, i am fine, too.

There is no solution to this problem. There never was.

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

Show quoteHide quote

Like Dominick mentioned, your assembly will be subject to potential
decompilation once it's out of your hands.  The most common means of
attempting to minimize the impact of such decompilation is obfuscation,
where the underlying approach is to make the decompiled code sufficiently
difficult to understand that it's not worth the "reader's" time.



Show quoteHide quote

Nicole Calinoiu wrote:
Decompilation is different to turning off validation. Obsfuscation will
have no affect at all on the validation issue that Dominick mentioned.
Although, Dominick is right, there is a more insiduous problem.

The problem is that a cracker could get an assembly from a trusted
source, this will be signed with the trusted source's private key. The
cracker can then change some of the metadata and/or IL and distribute
that cracked assembly as if it is the legitimate assembly. It looks and
smells like the legitimate assembly, but it has a nasty payload.

If the assembly is tamperproof, the assembly will not be loaded by the
runtime. The 'tamperproof' facility in .NET is really a byproduct of
strong names - when the assembly is signed a hash is made and this is
signed with the private key and stored as the strong name. *Only* the
publisher will have the private key. The public key is put in the
assembly. The real reason for this signed hash is to 'validate' the
public key, but it has the side effect of validating the assemly.

However, there is a bug in v1.1 and v1.0 of the runtime where an
assembly can have a strong name (ie its Assembly table metadata will
have the public key information) but a cracker can set the StrongName
resource section in the metadata header to zero. This means that
although the assembly will be positively identified with the public key
(that is the *real* reason for the public key) the runtime will not
bother to check the hash of the assembly (because, umm, it does not have
a signed hash to check). So the 'tamperproof' aspect is disabled.

Why does this matter? Well as a naive user (with validation enabled on
my machine) I could run the assembly from the trusted publisher - after
all it does *look* like the publisher's assembly. On v1.1 the .NET
framework will load and execute the cracked assembly, and the cracker's
code can then do its nasty stuff. This issue has been fixed in .NET
v2.0.

Richard

Sure, but recompilation without a strong name signature after decompilation
is the concern that OP raised in the first place.  (See the
http://www.codeproject.com/dotnet/NeCoder03.asp article referenced in the
first message in this thread.)


Of course not.  However, OP appears to be looking for measures that will
protect his IP (or minimize some other risk not explained in this thread),
not necessarily something that will protect his users.


I know.  'Tis ugly, but it has nothing to do with the original question.
OP's explicit concern was that he "would not like the users going in and
making changes in my assemblies", which would still be quite possible even
if the bug weren't present.

Anonymous access + Windows Authentication
Custom Security Permission & Security Attribute troubles
X.509 "Bad Key" error - EnvelopedCms.Decrypt()
RSACryptoServiceProvider
Windows authentication only
Sending raw sockets without administrative privileges?
Are .NET Caches Secure from Memory Dumps etc?
Ensuring that calling assembly signed by certain keys
NTFS file system folder permissions by using Active Directory Serv
If my System.IO.StreamWriter Write method throws "The specified network name is no longer available.