I have a COM inproc DLL that we are using in our product.
Now if someone finds out which interface and APIs we have exposed from the DLL then those APIs can be called easily.
Is there a way to stop unknown applications from calling my APIs?
Can we add some signature in COM?
The formal way of controlling use of your object is by implementing IClassFactory2 on the class factory that creates your COM objects.
Here's a link at MSDN explaining the interface.
IClassFactory2 at MSDN
The benefit of creating an implementation is that nobody can fetch an instance without clearing the hurdles of registration through IClassFactory2.
The downside is that you'll have to inspect all the locations where you are creating an object, to make sure that they haven't broken. Creating instances becomes more burdensome, although some languages already have facilities to make the process less painful (ex. VB6).
If you are trying to protect an object that has a lot of instantiation activity, you might want to go with Mastermind's method of adding a key parameter, or add an unlock method of some sort to your interfaces that must be called correctly before the component behind it can be used.
You could make your interfaces inheriting directly from IUnknown (without IDispatch) and not include the type library into the DLL. This way only those who have access to the type library will be able to find what interfaces are supported and the only other way to discover the interfaces will be to just guess. If you go this way you might also wish to minimize the number of classes exposed to registry (those that can be created with CoCreateInstance()) and use a set of factory methods of some dedicated registry-exposed class instead.
This implies that only vtable early-binding will work with your component. You will also be unable to use default call marshaling with this component (since no type library is included). And this is not real protection, just a way to hide things.
Nothing prevents you from adding a "key" parameter to the methods which will just return if the key is wrong.
Very simple but will do for starters.
Other than some sort of 'key' param, you can't prevent the curious from discovering your function and then calling it. All it takes is a debugger and some patience. To be totally secure you'd have to require some sort of certificate that authorized code could obtain but all others couldn't but that would mean you're code would have to be able to verify the certificate.
Related
As the subject line describes, I am in the process of exposing a C# library into a WCF Service. Eventually we want to expose all the functionality, but at present the scope is limited to a subset of the library API. One of the goals of this exercise is also to make sure that the WCF service uses a Request / Response message exchange pattern. So the interface /API will change as the existing library does not use this pattern
I have started off by implementing the Service Contracts and the Request/Response objects, but when it comes to designing the DataContracts, I am not sure which way to go.
I am split between going back and annotating the existing library classes with DataContract/DataMember attributes VS defining new classes which are like surrogate classes to the existing classes.
Does anyone have any experience with similar task or have any recommendations on which way works best ? I would like to point out that our team owns the existing library so do have the source code for it. Any pointers or best practices will be helpful
My recommendation is to use the Adapter pattern, which in this case basically means create brand new DataContracts and ServiceContracts. This will allow everything to vary independently, and will allow you to optimize the WCF stuff for WCF and the API stuff for the API (if that makes sense). The last thing you want is to go down the modification route and find that something just won't map right once you are almost done.
Starting from .NET 3.5 SP1 you no longer need to decorate objects that you want to expose with [DataContract]/[DataMember] attributes. All public properties will be automatically exposed. This being said personally I prefer to use special DTO objects that I expose and decorate with those attributes. I then use AutoMapper to map between the actual domain models and the objects I want to expose.
If you are going to continue to use the existing library but want to have control over what you expose as the web service API, I would recommend defining new classes as wrapper(s) around the library.
What I mean to say is don't "convert" the existing library even if you think you're not going to continue to use it in other contexts. If it has been tested and proven, then take advantage of that fact and wrap around it.
My first post here (anywhere for that matter!), re. Cocoa/Obj-C (I'm NOT up to speed on either, please be patient!). I hope I haven't missed the answer already, I did try to find it.
I'm an old-school procedural dog (haven't done any programming since the mid 80's, so I probably just can't even learn new tricks), but OOP has my head spinning! My question is:
is there any means at all to
"discover/find/identify" an instance
of an object of a known class, given
that some OTHER unknown process
instantiated it?
eg. somthing that would accomplish this scenario:
(id) anObj = [someTarget getMostRecentInstanceOf:[aKnownClass class]];
for that matter, "getAnyInstance" or "getAllInstances" might do the trick too.
Background: I'm trying to write a plugin for a commercial application, so much of the heavy lifting is being done by the app, behind the scenes.
I have the SDK & header files, I know what class the object is, and what method I need to call (it has only instance methods), I just can't identify the object for targetting.
I've spent untold hours and days going over Apples documentation, tutorials and lots of example/sample code on the web (including here at Stack Overflow), and come up empty. Seems that everything requires a known target object to work, and I just don't have one.
Since I may not be expressing my problem as clearly as needed, I've put up a web page, with diagram & working sample pages to illustrate:
http://www.nulltime.com/svtest/index.html
Any help or guidance will be appreciated! Thanks.
I have the SDK & header files, I know what class the object is, and what method I need to call (it has only instance methods), I just can't identify the object for targetting.
If this is a publicly declared class with publicly declared instance methods (i.e., you have the header for the class and it has instance methods in it), there is probably a way in this application's API to get an instance of the class. Either you are meant to create one yourself, or the application has one (or more) and provides a way to get it (or them). Look at both the header for the class in question and the other headers.
I initially said “there must be a way…”, but I changed it, because there is an alternative reason why the header would have instance methods: The application developer does not intend those instance methods for plug-in use (and didn't mark them appropriately), or did not mean to include that header in the application/SDK (they included it by accident). You may want to ask the application developer for guidance.
If it is not a publicly declared class or its instance methods are not publicly declared, then the application does not support you working with instances of the class. Doing so is a breach of the API contract—not a legal contract, but the expectations that the application has of its plug-ins. If you breach the API contract, you will cause unexpected behavior, either now (not necessarily on your own machine/in your own tests) or in the future.
If the class's public declaration contains only class methods, then perhaps what you're after is not an instance at all—you're supposed to send those messages to the class itself.
This is not possible without having you register each instance in a dictionary as it is created. I.e., override some common factory method at a higher level which does this bookkeeping work. This will fall down when you use delegates that you may not control though, keep that in mind.
I do question the need to even do this at all, but I don't know your problem as well as I perhaps would need to, to recommend a different, more apt way of accomplishing the actual task at hand.
Just as a corollary to the above; I did look at the runtime to see if there was anything that I actually forgot about, but there is not. So my above statement with regards to you requiring to do that bookkeeping yourself, still holds I'm afraid.
Edit:
Based on your diagram (my apologies, just noticed the link after I posted this answer); I would suggest that if you control the classes that are being returned to you, just add a property to them. I.e., add a "name" property that you can set and keep unique. Then just pass the message to each instance, checking whether or not that object is the one you want. It's not particularly clever or anything like that, but it should work for your purposes.
I am looking to write a plugin controller in Cocoa that loads bundles, and exposes a specific set of methods for the plugins to call.
My question is this: is it possible to know (any) info about the object that called a method in the controller. When an instantiated plugin calls a method in my plugin controller, I would like to know which of the plugin instances called the method, without having to rely on the plugin sending a pointer to itself as a parameter (I could always validate the pointer they send, but I want to keep the API methods as simple as possible).
There may be no perfect solution (and there are simple workarounds), but it's always good to learn some new tricks if possible (or the reasons why it's impossible).
Thanks in advance.
It's not possible without walking the stack, and possibly not even then. There's not even a guarantee that a given message was sent from within a method — and even if it was, it may not be the method that you think of as being the "caller." For example, assuming your plugins have access to Cocoa, your controller methods could be called by an NSTimer.
In general, this is not practical. The normal way to accomplish this is to have objects pass themselves around. If you're trying to do this for security reasons, you'll want a much more robust solution anyway, because Cocoa's object model was not designed with that in mind. It's way too easy for objects to lie about who and what they are.
Well, you could throw an exception, catch it and examine its stacktrace.
Assuming that Objective-C supports exceptions, of course.
Sending a reference to the calling object is how this is usually done. As an alternative, you could have your host code provide a proxy object for plugins to talk to. As each plugin is loaded, create a new proxy object for each to talk to.
I want to find a tool that can see all the interface, including the methods, properties, events, exposed by a COM(or ActiveX) component. Is such tool available?
It's not actually possible to build such a tool for ANY COM object, you might have some luck with specific objects. If a type library is available then you could use OLEView or you can programatically open and traverse the type library itself. Bear in mind that the contents of the type library is just what the developer wanted to include in it; there's nothing to stop objects implementing more interfaces than their type libraries say they do.
For objects without type libraries it's impossible to produce a general purpose tool:
Given the way that QueryInterface works you would have to ask the object under investigation if it supports every interface possible. Where would such a tool obtain a list of all possible interfaces that the object in question could support? Whilst it's true that some interfaces are registered in the registry due to proxy requirements not all interfaces are and it's by no means a requirement that they should be.
Once you know that an object supports a given interface how do you work out what methods that interface supports? If the interface derives from IDispatch then this is possible as that's the purpose of IDispatch, but for interfaces derived from IUnknown there is no way to programatically discover things about the interface.
You also have the added problem that some objects may have additional interfaces implemented for them by the proxy layer, for example, if an interface has been proxied then you will also be able to QueryInterface from it to IProxyManager though the object itself does not implement this interface (it's part of the proxy).
If the component has a typelib (in resources or shipped separately) you can use OLE View that comes with Visual Studio. You should use "View Typelib", not "Bind to File" there.
We have developed a s/w architecture consisting of set of objects developed in C#. They make extensive use of events to notify the client of changes in status, etc.
The intention originally was to allow legacy code to use these managed objects through COM interop services. That was easy to write in the design specification but, I'm seeing that actually implementing it is more problematic. I've searched for many hours looking for a good sample of event handling using this method. Before we march down that path, I want to make sure that COM interop is the best way to allow legacy code to call our new code.
It appears there are several different options: 1) COM interop, 2) write unmanaged wrapper classes 3) use the /clr compiler switch to enable calling of managed objects, 4) use some sort of reverse pInvoke call. Am I missing any?
Each option will have its benefits & drawbacks and I'm wondering what the best way to go is. Here are specific questions/comments for each
COM INTEROP - It appears event handling is a hurdle. We use events that have variable types as parameters. An event parameter may have an event ID and an object. Based on the event ID, the object will be of a certain type. Can this be handled with COM interop? Many of the objects that are exposed have properties. You can't declare properties in an interface so all properties will need a corresponding get/set method.
WRITE UNMANAGED WRAPPER - I assume this means creating a DLL using the /clr option to allow creating and calling managed objects and exposing unmanaged objects. Would the client of these unmanaged. I haven't done this before. What are benefits/drawbacks of this?
USE THE /CLR SWITCH - I understand this means to add support for managed objects. What are the drawbacks of this approach? Does this option support events as described above? Can we say, "here's the managed library. Use the /clr compiler option with your legacy code and have at it?" I don't know the ramifications of this. Is there a good sample of how this works around? (I'm sure there is, I just haven't found it)
USE A REVERSE PINVOKE - I'm not sure exactly how this would work but, from what I've been able to find, this is not a likely valid solution.
So, what does the decision tree look like to find the correct direction? Any help is appreciated.
DP
I think your initial solution is the best one. COM interop is stable and reasonably well documented. All you need to do is ensure that all the different event objects that might pop out of a given event handler implement the same COM-visible base event object interface (that has the event type id, etc). From there, individual objects can implement whatever other interfaces they want, and your unmanaged code can QI for the right "detail" interface based on whatever criteria you want to define. It's really not that hard. Have a look at this CodeProject article for an end-to-end sample including unmanaged event handlers.