Accessing HTML / JS content for a Modern application from a Desktop application for Windows 8

Sometimes you need from one program to get to the contents of another program. Well, for example, get some content out of it, or automate actions. In the case of classic Windows applications, this problem is solved very simply - we find the parent window through FindWindow , then, knowing its HWND, we can list the child windows and controls on them. And then there is complete freedom - we can get the text written on these elements, change their size and position, send messages to emulate a mouse click or typing from the keyboard, even delete existing elements and create new ones.

But for Modern-applications everything is different. Let's take, for example, the Weather app from the standard Windows8 set. Suppose we opened it in the sidebar and want to somehow find out from our usual (Desktop) application, and what temperature it shows. If you look at the Weather window using Spy ++, you will see the parent window of the Windows.UI.Core.CoreWindow type and the Web Platform Embedding window attached to it. So we have a Modern-application written in HTML \ Js and living inside the embedded browser component. That is, the above-described manipulations with Windows controls do not make sense - they are simply not in this window, since all of its contents are rendered entirely.

But let's try to get the current temperature out of it.

')
Let's start with the fact that on MSDN, in its style, there are two articles with the opposite content - one warns us not to clap hands in IE, embedded in other components, because it is not safe and you can break everything ( “This function is designed If you’re referring to this function, you’ll not be able to call this function (blah blah bla ... blah bla bla bla ... And the second one says that everything is OK, it is possible, and even gives the code how to do it. The first is not of interest to us, and the second is KB 249232 .

True, there is an error in it - in the function call ObjectFromLresult they are trying to take the wrong interface and in the end nothing works. But this is generally MSDN style, you have to get used to it.

So, what is the essence of our venture?

1. Find the top-level window with the specified header and class ("Weather" and "Windows.UI.Core.CoreWindow", respectively).
2. We list its “children”, we find the window of the class “Internet Explorer_Server”.
3. We send a WM_HTML_GETOBJECT message to this window, we get a pointer in response, which can be converted to a pointer to the IHTMLDocument2 interface using the ObjectFromLresult function.
4. Having IHTMLDocument2 we can already do anything with the document - get its content, change, simulate a “click”, execute Javascript.

I was almost sure that somewhere in the 3-4 points area, the Windows security mechanism that separates Modern-applications from each other and from the desktop will be on the way, and I was ready to use some of the tools I described in the previous article . But ... It was not needed. Despite the fact that the Weather app seems to work in a sandbox, it seems to be with Low Integrity - we can safely send messages to it, get a pointer to IHTMLDocument2, exchange data with it. No security barriers had to be overcome - they simply did not exist.

Total:



All project on Github