Suppose I introduced a COM interface and don't want any third party to use it. I have full control over the sources of the COM component and the IDL file that holds the interface definition. My COM component will need marshalling stuff fro that interface, so I'll need to either implement IMarshal or provide a typelib or provide a proxy/stub.
Obviously if I provide a typelib anyone can inspect it and find what my interface is and how it can be used. That's not what I want.
What if I use proxy/stub? Will it expose the interface and let anyone inspect it or will it keep the interface details covert?
Unfortunately this is not possible. The idea of COM is that clients can discover the components and the interfaces.
In a previous job I worked on a digital rights equipped application and there we deliberately did NOT use COM just to make it more difficult for people to tap into our application. We had to build our own component infrastructure (in addition to other security measures).
Related
I'd like to pass an IShellItemArray to an out-of-process COM object residing within an exe. I'd prefer to use existing interfaces before creating my own, so I thought I'd try having the out-of-process object implement IShellExtInit. Seemed like a good fit.
Anyway, it appears that attempting to create/query interface for IShellExtInit fails for out-of-process COM servers. I found some additional evidence indicating that it's not possible because that particular interface lacks marshaling support.
Is there anything that can be done to fix that, short of defining my own similar interface (with the oleautomation attribute)? Alternatively, are there any other existing generic interfaces, that work out of process, for passing an IShellItemArray? Thanks for any info.
IExecuteCommand is supported out-of-proc where IObjectWithSelection is the way the array is passed. Might only work on Win7 and later.
IDropTarget is also supported out-of-proc but it is more work (fake dropping a data object). It works back to at least WinXP if you care about that.
In powershell, when using new-object to instantiate, or get a reference to (or whatever you want to call it), a COM object I recall that the COM object needed to have a certain property to be able to expose it's functionality (through the registry I think is how it did it, via its Class-Id or something).
I can't for the life of me remember what the technical term for the "exposing" was, just that if the object/module/dll/assembly wasn't configured appropriately, the object wasn't available for instantiating with new-object (so that you couldn't just start instantiating objects within 3rd party software I assume is why an explicit setting must be made).
If anyone knows what this term is called it would be very helpful. Its the first step I'm taking in reusing a clients software functionality from a webservice, so I don't have to rewrite all over.
Much appreciated...
You have to register the COM server (binary) which creates a number of registry entries. The primary one PowerShell needs is the ProgID. Also, register a typelib should help PowerShell provide you with member information on the created object. You typically use regsvr32 for a native COM binary and regasm for a managed COM binary.
I have some COM interface which I'd like to secure against attacks. The idea is to only allow the interface to be instantiated by compiled .exe files on the local computer and to find out, who tries to instantiate the interface. I can then check the signature of the .exe file and compare it so some hashes on in a database or something like that.
Is it possible to find out which program/process/whatever tries to instantiate a COM interface?
If it's in-process COM, then your COM DLL is loaded into the calling process and you can use GetCurrentProcessID function to find the ID of the current process. Then enumerate processes in the system to check which one is yours.
By the "traditional" way I mean registering the DLL in registry.
There seems to be another method to set up it by going to mmc->Component Services->COM+ Applications and adding the .tlb file.
I have a COM library that supports both methods. When it installs, it registers itself in the registry as a COM component and it works fine. However, when I added the .tlb file using the Component Services method, the behavior seems to be different and it starts giving out errors.
I suspect it has something to do with marshaling and inter-process object transfer? (Sorry, I'm really a noob in the COM area)
Can anyone point me to a good resource to clear my understanding?
COM+ (Component Services) provides a lot of infrastructure out of the box; for instance COM+ provides transaction, security, object pooling and some other services.
When you register a COM component under COM+ it will run "Out Of Process"; in this mode you are guaranteed to have a proxy between your COM server and its clients.
The best place I can think of for learning more about COM+ is the official MS site: http://msdn.microsoft.com/en-us/library/ms685978(VS.85).aspx
Agree with the previous post.
One thing to add: actually registering the type library (.tlb file) is normal for COM as well, not only for COM+.
The type library is generated automatically by IDL compiler. It contains a description of your interfaces and objects.
So that you can "import" your COM component into some project, and the definition of the interfaces and objects are visible.
I have an ATL C++ in-proc COM component. This component is not for external use - I only need it for use in our application.
Once in a while users put it into COM+ and this leads to all sorts of weird errors - "Access denied", etc which I'd like to just never hear about. The best way would be to do something that would prohibit putting the component into COM+ so that it can only be used as an in-proc server. Is there a way to do this?
Do you implement only your own interfaces? If so, you should be able to mark them "[local]" in the IDL, and then strip the module of all marshalling information (type library, P/S), etc.
If there's no basis for marshalling available, COM+ shouldn't be able to register the module. COM+'s mechanism for interception relies on forcing objects into a remote context and getting in between the proxy and stub and their corresponding parties. So, if you remove every opportunity for marshalling, it shouldn't be able to intercept your interface methods.
Prevent registering your module is finalized and then use your DLL as described in this article Creating COM objects directly from the dll.