2

Is it possible to sign or otherwise protect a managed (.NET) DLL from being modified? I'm looking for possible solutions that would detect changes to DLLs and prevent them from being loaded by the .NET runtime. I don't mind if someone can load the DLL in Reflector or ILSpy - as long as a modified DLL cannot execute, I'd be fine with that.

I did some searches on this topic, but most articles / discussions recommend obfuscation which is not what I'm looking for. I thought digitally signing the DLL would accomplish this but a chat with my colleagues made me doubt that and I only have superficial knowledge in this area.

Any advice would be appreciated.

xxbbcc
  • 16,930
  • 5
  • 50
  • 83

2 Answers2

4

Signing a DLL doesn't stop other people from decompiling and then modifying your DLL. What it does prevent is them doing that and then passing the result off as the original. In other words, the modified DLL will execute if the caller decides to trust it, but any code which expects it to have your public key token will reject it.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • `if the caller decides to trust it` of course *caller* can be modified too if it can be accessed. – L.B Oct 09 '12 at 22:22
  • Ok, so my coworker was correct then and I was wrong. :) Is there a a way to accomplish what I'm trying to do using other means? I'm not looking for IP protection but for a way to make sure that a certain DLL stays intact or is not executed. – xxbbcc Oct 09 '12 at 22:23
  • @L.B: Potentially. It depends on the context, which we're somewhat short on here. – Jon Skeet Oct 09 '12 at 22:23
  • @xxbbcc: We need more context - in particular, information about what's *loading* that assembly. If you can keep control of that, you're fine. Otherwise, anything goes. – Jon Skeet Oct 09 '12 at 22:23
  • @JonSkeet No, I don't think I can claim control over what loads the DLL in question. The application using this DLL would be an ASP.NET web application in fully compiled form but that's pretty much it. I wouldn't control any aspects of this application. – xxbbcc Oct 09 '12 at 22:25
  • @xxbbcc: In that case, there's not a lot you can do. If you accept that an attacker can extract any of the code they want and build it into a *new* DLL, how would you view that as being different to modifying *your* DLL? – Jon Skeet Oct 09 '12 at 22:26
  • 2
    @xxbbcc this is kind of a fundamental security question - the consumer needs to *care* whether the resources it is consuming are trustworthy. If it doesn't care, that's not up to you. You have the ability to guarantee your assembly is genuine, not whether anyone acts on that. – Rex M Oct 09 '12 at 22:26
1

Signing the library will prevent modification. The downside to that is once you've signed this library, you must sign all child libraries it consumes as well. That can be a pain in the butt if you are using something from the NuGet library.

In theory once the dll is signed a signature is created to ensure it has not been modified. If someone hacked it, then framework won't load it.

SASS_Shooter
  • 2,186
  • 19
  • 30