|
Feb
4
Written by:
Jeremiah Morrill
2/4/2010 7:18 PM
WARNING: Information and code here can easily be abused. Please do not use it as a crutch in application planning, but more for utter despair or experimentation. Thus I wrote this blog post from that perspective.' Double WARNING: This code is antiquated. I will release an updated version during or after Mix’10. Also having blog issues, so email me if you want the code. jeremiah.morrill at the gmail. Silverlight 4 + OOB + Elevated Trust gives us the ability to use COM. That would be extremely useful (vs. really useful), except we cannot use just any COM class. It has to support IDispatch (COM automation). It also has to have a ProgID associated to it. That leaves you still with quite a few built-in COM objects to work with, as Justin document's quite well here. What about running our own native or .NET code? One would have to register a COM object first, which requires administrator rights. That’s no fun for an end user! Optimally, it would be nice to be able to add your desktop CLR objects as resources to your XAP, and from Silverlight code, be able to instantiate and use your Desktop .NET classes. This is a hack to do just that. Huh? What does the hack do? Let me explain it in code. /* Create our Desktop .NET helper */ dynamic fullDotNetProxy = fullDotNetProxy = ComAutomationFactory.CreateObject("ClrProxy"); /* Have our .NET helper load up our .NET assembly we extracted from our SL app resources */ dynamic assembly = fullDotNetProxy.GetAssembly(m_assembliesPath + "\\Inject.Test.dll"); /* Get our .NET Type */ dynamic testClassType = fullDotNetProxy.GetDotNetType(assembly, " Inject.Test.TestClass"); /* Create an object instance of our .NET type */ m_testClass = fullDotNetProxy.CreateInstance(testClassType); /* Run our RunMe method on our .NET object */ m_testClass.RunMe();
Hold on a second! Where did “ClrProxy” ProgID come from? That’s not built in to Windows! I thought we didn’t have to register anything?
That’s where it gets complicated. Or hacky. We actually use COM interop to inject a native DLL into the Silverlight process. Once injected we override some native methods that Silverlight uses internally to instantiate COM. Our hooked methods listens for when a ProgID of “ClrProxy” is requested and then goes into action.
Not bored yet. Explain further.
- Use WScript.Shell's "Run" method to execute rundll32.exe
- Rundll32.exe executes my native.dll.
- My native.dll get's the process Id and hWnd of the process that started it up (The Silverlight OOB Process)
- The native.dll is injected into the Silverlight process's and hooks it's WndProc
- The Silverlight process the hooks two methods in ole32.dll used by all windows applications to create COM objects
- In Silverlight code, every time you call ComAutomationFactory.CreateObject("ClrProxy") my hook will detect it and return a .NET 2.0 CLR object. The real CLR proxy class is very simple and I only expose some reflection routines so I can load up any .NET Dll. Silverlight facing code still uses the dynamic keyword.
So where do I get the code and how do I run the demo?
How to run the demo:
- Load up the project. Set the Silverlight web app as start up.
- Run the project, and install the SL app OOB.
- Click the only button on the window and watch SL talk to a .NET class w/o any registration
I left all the compiled dlls in there in case you were having trouble compiling the C++.
Here is the code:
Tags:
9 comment(s) so far...
Re: Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration
Nice!
Btw, is there also a method to access native code in silverlight 3 for instance?
Tks
By Roberto Nunes on
2/5/2010 4:36 AM
|
Re: Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration
Hi Jeremiah,
I am unable to test this out. Hit this error. Can you help
"Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; MS-RTC LM 8; .NET4.0C; .NET4.0E)
Timestamp: Wed, 10 Feb 2010 03:22:00 UTC
Message: Unhandled Error in Silverlight 2 Application This operation is not supported in the current context. at MS.Internal.Error.MarshalXresultAsException(UInt32 hr, COMExceptionBehavior comExceptionBehavior)
at MS.Internal.XcpImports.CheckHResult(UInt32 hr)
at MS.Internal.ComAutomation.ComAutomationNative.CreateObject(String progID, IntPtr& nativeObject)
at MS.Internal.ComAutomation.ComAutomationServices.CreateObject(String progID, ComAutomationParamWrapService paramWrapService)
at System.Windows.Interop.ComAutomationMetaObjectProvider..ctor(String progID, Boolean create)
at Silverlight.Mainline.InjectionHelper.MainlineInjectorBase.GetSpecialFolder(Int32 folder)
at Silverlight.Mainline.MainPage..ctor()
at Silverlight.Mainline.App.Application_Startup(Object sender, StartupEventArgs e)
at MS.Internal.CoreInvokeHandler.InvokeEventHandler(Int32 typeIndex, Delegate handlerDelegate, Object sender, Object args)
at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, String eventName)
Line: 1
Char: 1
Code: 0
URI: localhost:58039/Silverlight.MainlineTestPage.aspx
By smitha on
2/9/2010 7:23 PM
|
Re: Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration
I am getting the same error as Smitha
"This operation is not supported in the current context."
What is the reason and solution for this?
By Nilay Kothari on
2/11/2010 9:38 PM
|
Re: Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration
Given what you said "User Agent: Mozilla/4.0", my guess is your running in browser, and it only works out of browser in prevledged mode.
By Devin on
2/13/2010 11:32 PM
|
Re: Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration
Very important information. I am going to keep it for my article and then for my new project. The information mentioned above is very useful and I would like to thank you for that. You do a great work!
By yoga pants and tops on
2/23/2010 3:27 PM
|
Re: Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration
Good stuff thanks. Do you think MS Silverlight team will eventually patch this "COM Injection" security breach?
By Interesting on
2/25/2010 5:07 AM
|
Re: Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration
I am interested in the last question as well. I have not dug into your code yet, but does it even do anything that would be considered a hack? The ability to create COM objects in elevated trust is a fully valid function introduced in SL4. It doesn't sound like there is anything wrong with using that to create that WScript object you use. In fact, you can even change your security settings in IE to be able to create that same object. I will be checking this method out further, to possibly avoid having to have a separate initial install for a COM component in my SL4 application. Thanks for posting this!
By Michael on
2/25/2010 6:11 AM
|
Re: Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration
I think the correct behavior should be that whenever SL 4 tries to inject a COM object from the server as described here the user should be notified for permission, just as it works when the browser tries to install an ActiveX control on the user's machine. This is because SL 4 is not just using COM objects that are installed on the user's machine but ones that are downloaded from the server at runtime. Pretty scary stuff. I'm sure virus writers will be very busy in the near future !
By Interesting on
2/25/2010 9:59 AM
|
Re: Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration
We had to deal with Script Injection and then SQL Injection and now SL COM Injection lol
By Interesting on
2/25/2010 10:01 AM
|
|
|
|