Signing An Assembly Then Disabling the Verification of the Assembly

Question

1.00/5 (1 vote)

See more:

I have an assembly, for example SomeDLL.dll. I have signed it using the "Sign the assembly" functionality of the VS-2010 in order to protect tampering.
Then, I have referenced it in a project and it did not work and throws some error related to verification. Then, I have disabled the verification using the command of:
sn -Vr SomeLL.dll.

My question is after I have disabled the verification using the above command, does this signing still effective?

Thank you.

Posted 16-Apr-12 11:45am

MuhtarQong

Updated 16-Apr-12 11:48am

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 16-Apr-12 18:10pm

No, you should not disable the verification, ever. Please explain how you reference the signed assembly and the detail of the problem. What do you mean by "did not work"? This is not informative.
--SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-04-16T12:25:00

Solution 1

You can only skip verification (with -Vr) to simplify development. But this is not your purpose. You reported a problem. So, if you really need strong names (and I strongly suggest you should always sign everything you ever deploy anywhere beyond your development machine), you problem well pop up again. Please see my comment to the question and answer my question. Perhaps I could see where do you screw up things and how to fix them. But first, please read below.

You almost never need to skip verification. Normally, you can develop your solution with signed assemblies without any problems if you choose one of the following principles or their combination: 1) You should put all the projects producing assemblies in on solution and references them by projects; that is: use the tab "Projects" of the window "Add Reference". This is the best way to reference your assemblies: the run-time references will be created on the fly; the project references do not contain key tokens, the references will be modified appropriately when you add or change signatures, as this information is taken from the project files, not from assembly meta-data. 2) You can reference assemblies by their executable module files (using "Browse…" tab of the same window), but in this case you should sign the assemblies before referencing them.

If you already failed to follow the rules listed above, you can fix the problem by re-referencing assemblies in question. Just remove a reference from the referencing project which gives you some trouble and add the same reference again. Then again, prefer reference assemblies by projects which you should better keep in the same solution. There is no need in skipping of signature verification.

—SA

Posted 16-Apr-12 12:25pm

Sergey Alexandrovich Kryukov

Comments

MuhtarQong 16-Apr-12 18:47pm

SA,

Thank you very much for your answer and solution. When I deploy the signed DLL on other machine, where can I put the public key or how can I put it?

Thank you again.

Sergey Alexandrovich Kryukov 17-Apr-12 11:10am

As I say, you can sign every at the very beginning. You can 1) sign with the key of default size and Visual Studio using project properties, "Signing" tab. In the "Choose a strong name key" you can chose "<New...>" or "<Browse...>", so, 2) you can use an externally created key (for example, if you want the keys of bigger size), in this case, you can use sn -k <file_name>.

Please see:
http://msdn.microsoft.com/en-us/library/6f05ezxy%28v=vs.100%29.aspx

If you agree it makes sense, please accept the answer formally (green button) -- thanks.
--SA

VJ Reddy 17-Apr-12 1:30am

Nice answer. 5!

Sergey Alexandrovich Kryukov 17-Apr-12 11:11am

Thank you, VJ.
--SA

MuhtarQong 17-Apr-12 13:02pm

SA,
Thank you for your answer and solution.For a confirmation I write the while procedure:
1) I have a SomeDLL.dll
2) Sign the DLL (now it has strong name)
3) Then, using VS-2010's Dotfuscator functionality obfuscated it.
4) Referencing this obfuscated DLL in a project. At this stage verification error has been thrown. Strong named DLL has been changed during
the obfuscation (?)

In this case, should I use "Delay" signing and after delay signing obfuscate it and finally sign the DLL?

I need you help.

Thank you.

Sergey Alexandrovich Kryukov 20-Apr-12 16:27pm

You did not mentioned the obfuscation before. With obfuscation, the things are different. I don't know if delay signing can work. I tried Dotfuscator and was not satisfied; and I heard it's still not working properly. Anyway, the schema should be different. Basically, you should never reference anything obfuscated. Apparently, obfuscator is designed to make it impossible, among other things.

You should build the whole project with all assemblies signed. Then you should obfuscate all together. Only in this case, it can be done coherently. If Dotfuscator cannot do it, it is defunct.
--SA

MuhtarQong 20-Apr-12 16:45pm

SA,Thank you again. I just did a test.
1) Signed the DLL
2) Obfuscate the signed DLL. It did not work. The error message is:

Could not load file or assembly 'SomeDll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=61f90efab037fd5b' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)":"SomeDll, , Version=1.0.0.0, Culture=neutral, PublicKeyToken=61f90efab037fd5b

Thank you.

Sergey Alexandrovich Kryukov 20-Apr-12 17:19pm

Is it the message from Dotfuscator? When I tried it, I faced with the problem if fails to complete the work. 1) Does everything works before obfuscation? 2) Is SomeDLL fed to the obfuscator (I think it is, asking just in question). You see, I'm not sure this obfuscator is reasonably functioning.

By the way, how about work without obfuscation? You see, this one is a hassle, but it does not really protect from reverse engineering even in case of success. The idea is: most those who cannot reverse engineer through the obfuscator will not even try anyway; for those who know reverse engineering very well, this is not a difficult lock, and the number of people in between does not count. So, by using this obfuscator, you don't really protect anything. Think about it.

--SA

MuhtarQong 20-Apr-12 18:45pm

SA,

Thank you for your answer. I have decided to prefer Singning only.
However, inside a system (VS-2010) two things, signing and obfuscation, are conflicted each other.

Muhtar

Sergey Alexandrovich Kryukov 20-Apr-12 19:24pm

I had to work with the project using pretty expensive anti-reverse-engineering which did it all perfectly. This process is coherent, you cannot it in separate stages. I would at least not using Dotfuscator is a wise solution. As to signing, it's a great thing anyway.

Good luck, call again.
--SA