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.
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.
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.
We are using a third-party COM API from NET. Currently Visual Studio & presumably TLBIMP is used to generate the Interop wrapper DLL.
The generated interface of one specific method provided to NET is not the one we'd prefer to use. Is it possible to change the COM interop code so that the method signature presented to NET is different? We can't change the COM interfaces or TLB used because it's third-party code.
The actual example is as follows:
The method in question is where one passes a cleartext password. The current code goes as follows:
Our password handling returns a System.Security.SecureString (password is encrypted in memory).
We marshal the SecureString to a BSTR (annoyingly cleartext but can be zeroed afterwards to reduce exposure).
BSTR is converted to a System.String (Oops! This will be immutable, potentially never garbage collected, and keep the cleartext password around in memory).
COM Interop function wrapping third-party library takes System.String & marshals it again to a BSTR.
Third party COM API takes the BSTR and hopefully handles it in a vaguely secure way.
It is steps 2 & 3 I'd like to avoid. I can't change the fact that the third party API is handling a cleartext password, but I'd like at least the code we have control over to minimise the presence of the cleartext in memory.
I'd like to change the signature of the NET method to take a SecureString instead of a String - NET can already marshal a SecureString to a BSTR, so the COM interop code could still present the same data to the actual COM API, but without the horrible step of creating a String. Can this be done?
Yes, but you need to write the code for the interop interface manually, and then you can of course change the type of the parameters as you like.
I would probably start by creating the interop assembly using tlbimp. Then I would decompile it using Reflector and placing these sources in a separate class library project, modifying the interface as needed and use this assembly as the interop assembly.
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.