I am creating an app with several DLLs and thought I could just call Assembly.GetPublicKey() at run time and see if the DLLs were signed by me. However, I now see there's a SetPublicKey
method on the Assembly. Doesn't it make it easy for anyone to spoof my DLLs?
Or am I checking the signature of the DLLs the wrong way?
Update: I have a plugin architecture and I am just trying to prevent someone hijacking my app by writing their own DLL.
Is your entire application in .NET? When you compile, any assembly that references another should require the assembly be properly signed, and .NET should be able to handle this, and it should be transparent to you. You should not have to check assemblies yourself.
http://msdn.microsoft.com/en-us/library/ab4eace3.aspx
Not probably the suggested route but what I do for my DLL's is create a class and pass a private key to it to activate it.
var secureClass = new MyDLL.SecureClass("Password")
then on any method inside SecureClass i call the following before I put any code:
if IsActivated() = false then
Alert_Not_Active()
Return False
End If
Maybe there is better options but this works perfect for me. Make sure to use an application like {Smart Assembly} to protect your code from Reflection if it's extremely important coding
Related
I am not sure the best way to explain this so please leave comments if you do not understand.
Basically, I have a few libraries for various tasks to work with different programs - notification is just one example.
Now, I am building a new program, and I want it to be as lightweight as possible. Whilst I would like to include my notification engine, I do not think many people would actually use its functionality, so, I would rather not include it by default - just as an optional download.
How would I program this?
With unmanaged Dlls and P/Invoke, I can basically wrap the whole lot in a try/catch loop, but I am not sure about the managed version.
So far, the best way I can think of is to check if the DLL file exists upon startup then set a field bool or similar, and every time I would like a notification to be fired, I could do an if/check the bool and fire...
I have seen from the debug window that DLL files are only loaded as they are needed. The program would obviously compile as all components will be visible to the project, but would it run on the end users machine without the DLL?
More importantly, is there a better way of doing this?
I would ideally like to have nothing about notifications in my application and somehow have it so that if the DLL file is downloaded, it adds this functionality externally. It really is not the end of the world to have a few extra bytes calling notification("blabla"); (or similar), but I am thinking a lot further down the line when I have much bigger intentions and just want to know best practices for this sort of thing.
I do not think many people would
actually use its functionality, so, I
would rather not include it by default
- just as an optional download.
Such things are typically described as plugins (or add-ons, or extensions).
Since .NET 4, the standard way to do that is with the Managed Exensibility Framework. It is included in the framework as the System.ComponentModel.Composition assembly and namespace. To get started, it is best to read the MSDN article and the MEF programming guide.
You can use System.Reflection.Assembly and its LoadFile method to dynamically load a DLL. You can then use the methods in Assembly to get Classes, types etc. embedded in the DLL and call them.
If you just check if the .dll exists or load every .dll in a plugin directory you can get what you want.
To your question if the program will run on the user's machine without the dlls already being present - yes , the program would run. As long as you dont do something that needs the runtime to load the classes defined in the dll , it does not matter if the dll is missing from the machine. To the aspect you are looking for regarding loading the dll on demand , I think you are well of using some sort of a configuration and Reflection ( either directly or by some IoC strategy. )
Try to load the plugin at startup.
Instead of checking a boolean all over the place, you can create a delegate field for the notification and initialize it to a no-op function. If loading the plugin succeeds, assign the delegate to the plugin implementation. Then everywhere the event occurs can just call the delegate, without worrying about the fact that the plugin might or might not be available.
I have a dll library that I use in one of my projects. I don't want others to be able to link and access the methods in the library. Is it possible to protect it? Thanks!
EDIT: Is there a way to 'hide' method names or make them random inside dll?
You can attempt to limit its use by requireing a key. If a wrong key is passed, your library will not work.
This however can be easily circumvented by decompiling your application and check what key you supply and simply use the same key.
Another possibility would be to add a check to every public method on every public class. That check would verify that the calling assembly is one of yours.
Depending on the implementation of this check, it is easily circumvented by creating a small proxy assembly that is named the same as one of yours.
In general: It is not possible to prevent it. Just like with copy protection, everything can be circumvented if the other party has access to your assembly - and I mean the compiled assembly, not the source code.
Short answer is no. If somebody wants access to your library they will find a way.
You can obfuscate your library to make things harder for them however, but there is no sure-fire way of preventing them.
One way is Friend Assemblies
You can mark your assembly internal and only specified assemblies can access your library.
But it just forbids to use your library in "easy way".
You can protect your libraries and executables from anuthorized using with help of third party products like Sentinel Hasp, but it will cost to your application in performance, cost to you some money and it is not garanteed that nobody will break it.
But to break protection pirates should work hard.
I want to create a single dll that is merged with a 3rd party dll. This means end consumers will only have to deal with 1 dll instead of 2.
For augments sake lets say that the 3rd party dll is nLog. How do I deal with cases where the consumer of the merged dll already has NLog as a reference in their project?
Ideally what I would like to be able to do is change NLog namespace within my project to "XyzNLog", meaning that the user wouldn't need to do any aliasing... Any idea how I might do this?
Now I know I can add aliases to my project for NLog so that I have to refer to it as XyzNLog, but I want the same to carry over to consumers of the merged dll so that there is never a conflict.
UPDATE - Solution
http://blog.mattbrailsford.com/2010/12/10/avoiding-dependency-conflicts-using-ilmerge/
Bingo! So by using ILMerge, it becomes
possible to merge the third-party
libraries DLLs in with the Providers
own DLL, meaning we will only have one
DLL to deploy. But that’s not all, we
can actually go one step further, and
tell ILMerge to internalize all
dependencies. What this does it
converts all the third party classes
to be declared as internal, meaning
they can only be used from within the
final DLL. Woo hoo! problem solved =)
Given this the problem where the consumer of my dll could also have NLog goes away... as my referenced NLog shifts to being all internal! This is exactly what I want.
Does anyone have any feedback or thoughts on this?
I agree with Hans, I would strongly suggest releasing with registering the DLLs separately.
Otherwise, you could be in DLL hell which would drive your consumers away.
You could then devise some clever deploy methods to detect if the DLL is already registered, etc.
I have to agree with #Hans Passant (and here's some info about the oft-discussed DLL hell), but since you've asked the question, I'll try to answer it.
You can bundle the third-party DLL as a resource. Please see this question for details.
As far as your other questions, I'd just expose the relevant classes from a third-party DLL under your own namespace, and maybe use extension methods to provide whatever additional functionality you want.
For instance, you can provide access to NLog's Log() method using a static method in your class, say XyzNLog.Logger.Log(), taking care of initialization, and whatever else internally, inside your code (static constructor or whatever else you fancy up).
Since you load the NLog assembly using the method above, you'll be the only one having access to the embedded NLog assembly directly and the user won't be able to access it. Now, you don't get the benefit of having all classes autoexposed from NLog, you still have to expose them manually in this case.
EDIT: Another approach would be to try to use ILMerge with /internalize flag as described here. You may not be able to completely resolve the issue, but look at this article to see if you can avoid the pitfalls the author described. Spoiler alert: it's not all peaches'n'cream on this one either, but it may work, with enough extra effort.
My .Net C# appliation is referencing a strong named dll,and my requiremnet is to redirect the application to use another dll with a different name ( version and key are same for both dlls), how can i achive this without recompiling the application.
Here is the offical doc on this: Redirecting Assembly Versions (check out the "Specifying Assembly Binding in Configuration Files" section, this is the most easy to do)
Reflection might be a solution.
At the point you know what dll you want to use pull in the dll by reflection.
If both dlls derive from the same interface then the rest of the code can be very generic no matter the dll you use.
You can't as far as i know. That's the beauty of it, strong named assemblies are produced with a signature, precisely to avoid what you're trying to do.
After all it wouldn't have much security if you could just substitute a DLL from another one and having the new DLL methods do whatever you want under the original caller context would it?
I have got a dll placed in a shared folder over development server. Is there any way to use that dll without adding reference in my application and without installing the same in GAC.
Thanks in advance.
Assembly asm = Assembly.LoadFrom(path);
See MSDN for late binding, reflection etc.
Small edit: A variable with the keyword "as" is asking for trouble. So "Assembly as" changed to "Assembly asm" should be safer.
You may want to look at the Managed Extensibility Framework or at Assembly.Load... in the base framework.
Why would you want to do this, though? You'd need to call any code within the Assembly via reflection (hence the suggestion that the MEF may be what you're really after).
Yes, it is possible...somehow. Have a look at the Assembly-Class. With it you can load assemblies from a file without knowing what you exactly load.
Using Assembly.LoadFrom would be the only way to have zero references, but you'd still need to share contracts.
What's the problem with adding a reference?
What are you going to do when someone wants to work on a laptop and the WiFi goes down?
Yes,
you can call Assembly.Load() and then make use of Reflection to call into the public interface (lowercase "interface" - what I mean is the methods, fields and properties) exposed by the assembbly.
But in order to do that you need to know what methods to call. It helps if you can be certain that the assembly includes classes that do conform to a known .NET interface.
This idea is the basis for "plug-in" architectures in many tools, where the tool loads any assembly in its "plugin" directory, instantiates classes, casts the result to an ISomething, and then invokes methods via that interface.
I also would read Suzanne Cook's .NET CLR Notes.
http://blogs.msdn.com/suzcook/default.aspx
If this assembly is in a shared folder, you may find that .NET security restrictions stop you working with classes in that assembly in quite the way you'd expect.
Rather than storing on a shared folder, you may want to consider checking in the assembly to your source code repository. (I've seen a "/lib" folder used to good effect for this). Then you can reference the assembly directly.
(There are also repository solutions such as Maven that can more properly control this. However, they don't play well with .NET, unfortunately.)