4

I've made some changes to the code in an existing .NET assembly dll. I do not have the keyfile used to sign the code. How can I force the .NET executable to load it, without registering it for skipping verification (not portable), without removing StrongNames (Damages application)?

Kurt Nauck
  • 339
  • 4
  • 15

2 Answers2

13

You can't, and that's the whole point of strong names.

Strong names verify that an executable file has not been tampered with by someone who is not the author. (Anyone with the original key file is assumed to be the author.) Since you do not have the key file, you must not be the author, and as such strong naming prevent you from doing the changes you want to do.

If you want to load your DLL, you'll have to use either solution you suggested.

EDIT Since .NET 3.5 SP1, strong name verification is bypassed provided at least one of the following conditions is met:

  • the assembly is fully signed with Authenticode;
  • the assembly is fully trusted (without any regards to its strong name evidence);
  • the assembly is loaded into a fully trusted AppDomain (which is what happens with desktop applications in most scenarios);
  • the assembly is loaded from a location under the AppDomain's ApplicationBase (i.e. the assembly is distributed with the application and exists in the same directory).

Basically, strong name verification was disabled for every use case except Silverlight. It's possible, however, for a system administrator to re-enable name verification by default with a registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"AllowStrongNameBypass"=dword:00000000

Microsoft says that the reason this change is allowed is that strong names were not an integrity checking mechanism but were an assembly identification mechanism. For actual integrity checking, Authenticode is the way to go.

This means that for all practical purposes, strong names aren't useful to prevent tampering, and anyone can tamper with any assembly and still have it load correctly, unless the system administrator prevents it.

To correctly answer this question, then, it should be mentioned that modifying an assembly will invalidate its strong name, and as such there is no way to edit a DLL without invalidating the strong name if the snk is not available. However, it will not prevent it from loading in most cases.

zneak
  • 134,922
  • 42
  • 253
  • 328
  • Please keep us posted if you do find one. Do you have access to the application's source code? – zneak Sep 10 '12 at 22:46
  • Not being funny, but I really hope you can't. – Tony Hopkinson Sep 10 '12 at 22:59
  • Like I said, I'm looking at a DLL that was edited and works with a non-modified .NET application. I'd really like to know how this individual did it. – Kurt Nauck Sep 10 '12 at 23:03
  • Of course you can edit it. You could export all of the source code via reflexil or ilspy and recompile. Hell you could simply export the MSIL assembly and port it into a new executable if you wanted to. Strong signing can absolutely be bypassed, can it be preserved? I don't believe so however this wasn't the question. – rollsch Jul 27 '16 at 06:16
3

You can edit a .NET dll in Reflexil (.NET Reflector addon) and preserve the original signature on the modified code. Thank you for your answers.

To those of you who wish to edit an assembly and not resign it, use Reflexil. Just because people are downvoting this answer, it doesn't mean that it is wrong.

Twenty
  • 5,234
  • 4
  • 32
  • 67
Kurt Nauck
  • 339
  • 4
  • 15
  • Really? The Reflexil page says you can remove strong names (and accordingly edit references from other assemblies) but it seems cryptographically dubious that you can preserve the original signature _and_ change the assembly. Mind to explain how you did this? – zneak Sep 10 '12 at 23:34
  • By taking the original dll, modifying your desired methods/etc..., saving the assembly, then doing a delayed sign. I have proof of this, but I am not sure if I am allowed to post the dll I did this to. – Kurt Nauck Sep 11 '12 at 04:03
  • 2
    [Delayed signatures don't constitute a valid strong name](http://msdn.microsoft.com/en-us/library/t07a3dye.aspx). Are you sure you did not just turn off the validation for your DLL? – zneak Sep 11 '12 at 18:14
  • You aren't reading what I'm saying. I'm not resigning it, I'm not changing the signature at all (delaying doesn't change it). I am 100% positive I did not just turn remove strongnames because a) that breaks the app, b) I didn't 'accidentally' press like 5 different buttons and remove strongnames, and c) there's about 50 people using my modified dll. Thank you. – Kurt Nauck Sep 12 '12 at 04:18
  • @KurtNauck, delay-signing puts no signature at all, only the public key. There is _no way in hell_ an assembly can pass SN validation after it has been edited, which means you're not telling us everything AND ignoring the input you've got so far. Stop wasting people's time. – staafl Sep 13 '12 at 19:21
  • @staafl, I am delay-signing IN ORDER TO not actually sign the binary, and leave the original signature intact. You CAN edit a dll with .NET Reflector + Reflexil and it will still pass strongname validation - because that doesn't recompile it - it edits the bytecode. Strong Names aren't a full file hash, you know. I have told all that there is to tell, so it is you who is wasting my time. – Kurt Nauck Nov 20 '12 at 22:07
  • Wrong. The strong-name signature is an RSA hash of the entire assembly less the checksum and authenticode PE headers - that have nothing to do with the bytecode that you say you have edited. There is no way for what you're describing to work. And your "it doesn't recompile it - it edits the bytecode" reply makes no sense. I won't bother to read anything further in this thread. – staafl Nov 22 '12 at 20:47
  • 6
    I emailed the author of Reflexil to be sure and got an [interesting answer](http://pastebin.com/bA9Kgd7E) (in French). Editing an assembly with Reflexil *does* remove the strong name and replaces it with a delay signature, but most of the time **this does not prevent the assembly from loading**. This answer is wrong in that it **does** remove the original signature, but in most cases it won't prevent the assembly from loading (and does not damage the application, as asserted in the question). – zneak Jan 19 '14 at 07:03
  • I don't understand why this was down voted. He is correct in that you can edit the MSIL, export it, do whatever you want and then load it seperately. I don't believe you can preserve the strong naming however that is irrelevant if your goal is simply to edit and run it. If it is a library you could simply remove the sign check from the parent application. There is always a way around the problem, it just might be extremely time consuming. – rollsch Jul 27 '16 at 06:19
  • Here is an example of editing the byte code and passing the check staafl http://ianpicknell.blogspot.com.au/2010/02/tampering-with-strong-named-assembly.html – rollsch Jul 27 '16 at 06:33
  • @rolls, this all started on the incorrect premise that invalidating a strong name damages the application, which led to the incorrect conclusion that modifying an assembly does not invalidate its *original* strong name, and insults to people trying to set the record straight. – zneak Jul 27 '16 at 16:52
  • The example in the link shows you can edit the assembly, leave the strong name unchanged and pass the strong name check despite editing the assembly. – rollsch Jul 27 '16 at 22:25
  • @rolls, it does not show the strong name check passing, it shows it being **bypassed**. The post even shows the `` configuration option as a solution. How can I convince you that this is what is happening, and that the strong name was indeed invalidated, if having to opt in to "disable bypass" is not evidence enough that bypass is otherwise happening? – zneak Jul 27 '16 at 23:32