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.
Related
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.
First, my concrete question: In my attempt to access cursor raw data, my call to LockResource succeeds, but the SizeOfResource call tells me that the data is only 20 bytes, which is just too small...
What I'm really trying to do: I am exploring possibilities for remoting cursors from mixed code server application to a CLR client application. My (quite possibly naive) idea is to use LockResource to access the binary data of a resource (embedded in a native dll), pass this data to the client and treat it in the same way as resource data that has been retrieved from a local assembly using Assembly.GetManifestResourceStream to get the resource stream and Resources.ResourceSet to iterate through the resources. I am hoping that since .NET no doubt makes the same underlying system calls as native code, this makes sense. On the other hand...
Does anyone have any comments or better ideas ? (It would of course be easier to simply provide a compatible resource package on the client and remote some cursor id, but we seem to have a requirement for cursors to be dynamically added at runtime.)
Any comments gratefully received!
In the end, I used Win32 calls to get at the cursor bitmap, serialised this and the hotspot location to the client, and recreated the cursor there using the Win32 API again. Once you've got an HCURSOR cient-side, you can construct a .NET WinForms Cursor from it if you want (but such an object cannot be serialised using straightforward .NET - otherwise that would have been a much easier way to remote it!).
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.