hexedit assembly - snk, strong name, sing assembly question

[Peter]

Hello

How can I ensure that a assembly (dll) is not manipulated (e.g.
hexeditor).

I thought that sign the assembly (snk-File), this ensures.

I have tried the following.

1.
Create assembly Test.Dll with AssemblyVersionAttribute("1.1.*") and
sign with Test.snk (Property-Page and/or
AssemblyKeyFileAttribute(@"Test.snk")

2.
Create UseTest.Exe with reference to Test.Dll.

--> Now UseTest.Exe requires the desired Test.Dll, ok

However, I can manipulate Test.dll (Hexeditor) an use it !! e.g.
Class Test1 in Test.Dll

public class Test1
{
public static void SayHallo()
{
System.Windows.Forms.MessageBox.Show("Hallo Peter");
}
}

Change text Hallo Peter with hexeditor to Hallo Qeter


Do I something wrong ?
or is signing not at all thought my problem ?

Is there built in mechanism to "checksum" a assembly

thank you
Peter

 

[Peter]

Hi Peter,

At first, I also thought that the CLR would throw an exception (since
the assembly had been tampered!), but after checking that myself, yes
your observation is correct - the CLR did not verify the hash and just
happily execute the tampered assembly. It will only throw exception if
it is compiled using the old framework (version 1.1 and lower).

My first guess is probably for performance reason. Verifying the
assembly's hash each time the assembly is loaded would increase the
application start-up time. My second guess is unless the assembly is
installed in GAC, nothing can prevent the assembly from being tampered.
I had seen a lot of discussion on the internet on how to break/modify
the signed assembly.

As for the workaround, maybe you can install the assembly in GAC or
attach a digital certificate to it.

Regards.

--- news://freenews.netfront.net/ - complaints: (e-mail address removed) ---- Zitierten Text ausblenden -

- Zitierten Text anzeigen -

Tank you for your own test
This behavior is unfortunately not so great....

GAC is not an option at the moment.


How can I attach a digital certificate to my DLL ?

Thank you
Peter

 

[kndg]

[...] the CLR did not verify the hash and just
happily execute the tampered assembly. It will only throw exception if
it is compiled using the old framework (version 1.1 and lower).

I would like to make my own correction. Actually, this feature is
introduced on the framework ver 3.5 SP1 as from below blog post,

http://blogs.msdn.com/b/shawnfa/archive/2008/05/14/strong-name-bypass.aspx

How can I attach a digital certificate to my DLL ?

I'm no expert in this area, so my below reply may contains error -
apology in advance.
It is quite difficult for me to explain it actually, but basically first
you need a certificate to work with. You can either purchase it from a
certification authority (usually for software that you distributed) or
by setup a CA in your corporate environment (for software that is used
internally). You can also create a self-signed certificate for your
testing purpose by using a makecert.exe tool (installed by Windows SDK)
or by various other tool including the open-source openssl toolkit
(www.openssl.org). You can then attach the certificate to the assembly
using the signtool.exe (installed by Windows SDK). You may check below
website which explain it clearly.

http://www.tech-pro.net/code-signing-for-developers.html

As for your quest to make the assembly tamper-proof: as long as the
assembly is accessible to someone, nothing can prevent that 'someone'
from modifying your assembly. Although the digital certificate for the
tampered assembly will be marked as invalid, the CLR still allow the
application to run. You could apply a security policy to prevent
assembly with invalid certificate from running but I have no idea how to
do that.

Aside from this, I found that below articles are very interesting to read.

http://blog.paul-mason.co.nz/2010/02/tamper-proofing-your-code.html
http://blog.paul-mason.co.nz/2010/02/tamper-proofing-implementation-part-1.html
http://blog.paul-mason.co.nz/2010/02/tamper-proofing-implementation-part-2.html
http://blog.paul-mason.co.nz/2010/03/tamper-proofing-implementation-part-3.html

Someone would argue that tamper-proofing an assembly is a waste of time,
but I think the idea, the art and the mechanics of it is indeed a very
valuable knowledge.

Regards.

 

[Peter]

[...]  the CLR did not verify the hash and just
happily execute the tampered assembly. It will only throw exception if
it is compiled using the old framework (version 1.1 and lower).

I would like to make my own correction. Actually, this feature is
introduced on the framework ver 3.5 SP1 as from below blog post,

http://blogs.msdn.com/b/shawnfa/archive/2008/05/14/strong-name-bypass...

How can I attach a digital certificate to my DLL ?

I'm no expert in this area, so my below reply may contains error -
apology in advance.
It is quite difficult for me to explain it actually, but basically first
you need a certificate to work with. You can either purchase it from a
certification authority (usually for software that you distributed) or
by setup a CA in your corporate environment (for software that is used
internally). You can also create a self-signed certificate for your
testing purpose by using a makecert.exe tool (installed by Windows SDK)
or by various other tool including the open-source openssl toolkit
(www.openssl.org). You can then attach the certificate to the assembly
using the signtool.exe (installed by Windows SDK). You may check below
website which explain it clearly.

http://www.tech-pro.net/code-signing-for-developers.html

As for your quest to make the assembly tamper-proof: as long as the
assembly is accessible to someone, nothing can prevent that 'someone'
from modifying your assembly. Although the digital certificate for the
tampered assembly will be marked as invalid, the CLR still allow the
application to run. You could apply a security policy to prevent
assembly with invalid certificate from running but I have no idea how to
do that.

Aside from this, I found that below articles are very interesting to read..

http://blog.paul-mason.co.nz/2010/0...o.nz/2010/03/tamper-proofing-implementation-p...

Someone would argue that tamper-proofing an assembly is a waste of time,
but I think the idea, the art and the mechanics of it is indeed a very
valuable knowledge.

Regards.

Someone would argue that tamper-proofing an assembly is a waste of time.....

Perhaps so, but if you must implement an internal directive... and
your boss knows a hexeditor....

Aside from this, I found are very interesting article too

http://www.grimes.demon.co.uk/workshops/securityWS.htm


Regards