Delay Signing

re: Delay Signing

Meno — Thu, 18 Mar 2004 05:41:00 GMT

brilliant article it hits the point. I hope that Microsoft will fix this in the future.

.NET delay signing in details

SiM Weblog — Thu, 18 Mar 2004 10:56:00 GMT

re: Delay Signing

Shawn — Fri, 19 Mar 2004 01:29:00 GMT

Hi Meno -- glad you liked the post. However, I'm not pointing out a shortcoming with delay signing. I'd like to clarify that there's really not anything to fix. Developers just need to be aware of what they're allowing when they register delay signed assemblies for skip verification.

Take Outs for 18 March 2004

Enjoy Every Sandwich — Fri, 19 Mar 2004 06:06:00 GMT

You have been Taken Out! Comments about your posting in this link. Thanks!

re: Delay Signing

Meno — Thu, 15 Apr 2004 10:23:00 GMT

Hi Shawn, sorry for the long delay. Ok but the important is not to fix this problem. I think you(MS) had to write it in the documentation. And in my point of view this feature is a good idea as it is, but it make no sense if you are care about security that are a little bit based on where the code that is executed is coming from. If you have an application which should only run your signed code you can`t use delayed signing. So your development process need a other technology to handle this. So there is the still question why is there this feature.

re: Delay Signing

Shawn — Thu, 15 Apr 2004 17:06:00 GMT

There actually is some documentation on MSDN about this. In the page titled "Delay Signing an Assembly" (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcondelayedsigningassembly.asp), step 4 says:

"4. Because the assembly does not have a valid strong name signature, the verification of that signature must be turned off. You can do this by using the –Vr option with the Strong Name tool.
The following example turns off verification for an assembly called myAssembly.dll.

sn –Vr myAssembly.dll
CAUTION Use the -Vr option only during development. Adding an assembly to the skip verification list creates a security vulnerability. A malicious assembly could use the fully specified assembly name (assembly name, version, culture, and public key token) of the assembly added to the skip verification list to fake its identity. This would allow the malicious assembly to also skip verification."

If you want an example of how this feature can be used, check back up in my post. I gave an example of how delay signing is used internally on the CLR team.

-Shawn

Checking For A Valid Strong Name Signature

.Net Security Blog — Tue, 08 Jun 2004 00:52:00 GMT

Checking For A Valid Strong Name Signature

.Net Security Blog — Tue, 08 Jun 2004 00:54:00 GMT

re: Delay Signing

Stefan — Wed, 28 Jul 2004 14:48:00 GMT

What if the software I write contains code for checking a license.
If the customer succesfully reverse engineers my assembly and he can rebuild it with the license checking code always returning true and with delayed key signing. Because the customer owns his own machine he/she can easily sn –Vr myAssembly.dll to replace my assembly with his cracked one and continue working without needing a license. Can this be prevented, isn't this a problem??

Stef

re: Delay Signing

Shawn — Mon, 02 Aug 2004 16:38:00 GMT

Hi Stef,

Yes if your customer has a physical copy of your code then he could reverse engineer it, delay sign it, then register it for skip verification. Any code that your customer has a physical copy of will be impossible to fully protect. You could raise the bar some by obfuscating your assembly, but if the customer is determined to bypass your license check, they will. Even in unmanaged code, people who want to bypass license checks generally can. Usually its just a matter of finding the magic "compare and branch" instructions that branch to the license check failed portion of your code, and switching the condition on the compare.

The best thing you can do if you want complete security is to not allow the customer to host the licensing code. Instead provide it via a web service, and you hold onto the licensing code. Again, this won't prevent really determined customers from bypassing your system, but it will continue to raise the bar.

-Shawn

Post Build Assembly Modification Or: Why Won't SN -Vr Work on Tampered Assemblies

.Net Security Blog — Sat, 21 Aug 2004 03:25:00 GMT

Booknotes

What Is The Sound Of One Hand Blogging? — Sat, 02 Oct 2004 05:11:00 GMT

A Few Observations about Raw Signatures

.Net Security Blog — Sat, 29 Jan 2005 05:05:00 GMT

re: A Few Observations about Raw Signatures

.Net Security Blog — Mon, 07 Feb 2005 21:24:00 GMT

Guiness and Beef stew

Rhonabwy — Sat, 19 Feb 2005 09:50:00 GMT

It's surprisingly easier and lower stress for me working late at night when I can take a route 4 bus...

re: Delay Signing

ds — Thu, 25 May 2006 16:08:51 GMT

what is private key in delay siging

re: Delay Signing

shawnfa — Fri, 02 Jun 2006 01:10:23 GMT

There is no private key in delay signing -- generally it is used on developer desktops where they don't have access to the company private key.

-Shawn

re: Delay Signing

Matthew Copeland — Thu, 22 Jun 2006 22:39:44 GMT

Hi Shawn,

Love that you are making the under the hood more accessible. I am a little confused though. You say "Yes if your customer has a physical copy of your code then he could reverse engineer it, delay sign it, then register it for skip verification."

Why would they even need to delay sign it? Couldn't they just SN -Vr *?

Which leads me to my main question.

Lets take a hypothetical application which contains 10 strongly named assemblies, all signed with the same key, with no obfuscation.

Is the following possible?

Disassemble all 10 assemblies.

Manually edit the IL of each assembly to remove the public key, and remove any reference public key tokens for the 10 assemblies.

Create a new Public/Private key pair, and sign the 10 assemblies.
-----------------------------------------------

I understand that it is impossible to fully protect code on a customers computer. If the above scenario is possible, protection becomes much more problematic.

As I see it now.

I can defend against the user manually removing all SN data from my assemblies by programmatically checking an executing assembly's PublicKeyToken value for null. If it is null (as it would be after removing the SN data from IL) I can have the application exit. Obviously, this code needs to be in as many places as possible to make it as difficult as possible for someone to change the IL to skip these checks (Obfuscation is a big help here).

I can defend against the user turning off SN verification with SN -Vr *. Using StrongNameSignatureVerificationEx it is possible to programmatically check if the file's signature is valid. As above, this code needs to be in as many places possible and obfuscated.

These two techniques would seem to be useless if the user can change the bits, AND then give the assembly a valid signature using a different key pair.

I would appreciate any thoughts you may have.

Matthew

re: Delay Signing

Matthew Copeland — Thu, 22 Jun 2006 23:14:49 GMT

After rereading my post... would it be possible to securely store the public key token of the key i used to sign my assemblies with, and double check against that even if the signature is valid?

re: Delay Signing

shawnfa — Fri, 23 Jun 2006 21:15:03 GMT

First the easy question -- SN -Vr is not a general purpose mechanism to allow tampering with assemblies. It only works if the assembly is not fully signed, so yes they would have to delay sign the assembly.

As I mention, if the attacker has physical acceess to the assembly, there's nothing you can do but raise the bar. Replacing the public key is certainly possible (although it will also change the identity of the assembly, so the -Vr route may be more desirable). The attacker can also disassemble your code and remove all checks for the public key (or cause StrongNameSignatureVerification to ignore the skip verification entry, or replace the public key you're checking for with their own, or replace the CLR with a hacked up version of a different CLI implementaiton which lies to your API call).

-Shawn

re: Delay Signing

Matthew Copeland — Mon, 26 Jun 2006 17:56:29 GMT

Hi Shawn,

Thanks for the response. I "get it" as far as raising the bar, and understand the fact that every bar can be overcome by someone who has the skills and is determined.

I would like to clarify something about your first statement. I can take a strongly named assembly, disassemble change the IL and reassemble without making any changes to the signature data. I will get an invlaid signature exception when the CLR attempts to load this assembly.

The command line, SN -Vr *, instructs the CLR to skip SN verification for all assemblies. It is not necessary to have a public key token. I can load the above assembly with no exception, and I have not delay signed it.

I understand you to be saying that I must delay sign the modified assembly. Am I missing something?

re: Delay Signing

shawnfa — Tue, 27 Jun 2006 06:45:16 GMT

I don't think I follow your example. If you do:

ildasm stronglynamed.exe /out=stronglynamed.il
ilasm stronglynamed.il

Without specifying a key file, the resulting stronglynamed.exe will not have a strong name.

The skip verification list only works for assemblies which are delay or test signed. If they are fully signed and tampered with, being on the list does not stop the runtime from throwing an exception when the assembly is loaded.

-Shawn

re: Delay Signing

aditya — Fri, 28 Jul 2006 09:39:36 GMT

Great article cleared my doubts

re: Delay Signing

Nitin Arora — Sat, 28 Apr 2007 22:42:03 GMT

Hi Shawn,

Yesterday night when I delay signed one of my assemblies. I noticed this abnormal behavior. Here is the scenario:

I have an asp.net application where in Page_Load event of private pages, i am doing comparison of values stored in session. Session values are added when user successfully logs In.

Session.Add("key1", "value1");

Session.Add("key2", "value1");

if(Session["key1"] != Session["key2"])

{

Response.Write("Keys not equal);

}

else

{

Response.Write("Keys are equal");

}

When my asp.net assembly was not delay signed it was showing "Keys are equal". But when i delay signed my app's assembly, it started showing "Keys not equal". I dont know what went wrong when i delay signed my assembly.

After a lot of brainstorming and debugging i changed to code to

if(Session["key1"].ToString() != Session["key2"].ToString())

{

Response.Write("Keys not equal);

}

else

{

Response.Write("Keys are equal");

}

Then everytime it showed Keys are equal.

Can you throw some light on this as what went wrong with the intial code when i delay signed it?

Many Thanks

Nitin Arora

re: Delay Signing

shawnfa — Mon, 07 May 2007 21:57:22 GMT

Hi Nitin,

Unfortunately I'm not going to be much help to you. From a CLR perspective a delay signed assembly vs a fully signed assembly (with the same public key) are the same assembly. That would indicate that something else is going on here.

-Shawn

David DeWinter » The AllowPartiallyTrustedCallersAttribute (APTCA) – #6

Fri, 22 May 2009 04:14:49 GMT

PingBack from http://blogs.rev-net.com/ddewinter/2009/05/21/the-allowpartiallytrustedcallersattribute-aptca-6/

re: Delay Signing

Ritesh — Mon, 29 Jun 2009 12:31:38 GMT

Hi,

My assemblies run perfectly if I run with sn -Vr commands but if I give sn -Vu command for my assembly, it gives exception as {"Could not load file or assembly 'ShaderEffectLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c199d42a01e99449' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)":"ShaderEffectLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c199d42a01e99449"}"

Kindly suggest.

re: Delay Signing

shawnfa — Thu, 05 Nov 2009 19:20:50 GMT

That indicates that you have a delay signed assembly which requires a skip verification entry to be used. When you do -Vu, you remove the entry, and the assembly will no longer load.

-Shawn