The truth behind DLL injection with metro applications, Nektra vs Komodia

Question

Komodia says:

DLL injection is not possible with Modern UI on Windows 8,It is possible to inject DLLs into Metro apps, BUT, you will not be able to redirect Winsock traffic to localhost.

In other words windows metro application working into sandboxed environment, which DLL injection can't be done.

Let's see what Nektra says:

We realized we needed to sign our DLL with a cross-certificate, like those used to sign kernel-mode drivers. We already had a method for injecting a DLL in WinRT applications: copy the DLL file inside the System32 folder and voilá!

As you can see Komodia and Nektra says a conflicting information, my question is what's the true behind DLL injection under windows 8, can I inject my code into metro application as usual(NT,win9x) like Nektra says?

Answer 1

I'm the author of Nektra's article. The research began when we wanted to add more features to the limited Metro Mail application that comes with Windows 8.

Although the process was not exactly the same than in desktop applications because usually metro apps are suspended, we hooked first DCOM service.

When DCOM service launches the Metro Mail application, in that point we inject the dll using the well-known method CreateRemoteThread/LoadLibrary call.

In the initial tests we tried to inject a dll located in the same folder were our test was located and discovered that, if the dll was in system32, it loads fine.

Later we do the further research to see why the dll was not loading if not on system32 folder.

About hooking winsock, we didn't test that but I think it should be possible because, at least on desktop computers, behind metro there are the commonly known dlls (kernel32, user32 and so on) and we hooked some api's without problems.

Answer 2

I'm the author of the Komodia article and our article doesn't conflict with Nektra, it is possible to hook Metro apps, or the sandbox that runs the Metro apps, but you can't connect to localhost, not because of hooking but because of Metro limitation on localhost connections. In our first test we used our Win7 WFP (which is a network driver) and modified the IP of packets to localhost which didn't work with Metro apps, NDIS will not work just the same, the only way to do so is using Microsoft's WFP proxy redirection.

Maybe someone will eventually find or already found a hack that allows for localhost direct connection, and as with any hacks, there are risks to consider. If you want an approved method, WFP proxy redirection is the only way to go.

Answer 3

I hereby answer because everyone else is out of point with this. The dll file needs to have read/execute permission to "All Application Packages" group. With this, the loader will allow you to load arbitrary dlls in Immersive apps(=metro apps).

Answer 4

In the initial tests we tried to inject a dll located in the same folder were our test was located and discovered that, if the dll was in system32, it loads fine.

Yes, because System32 is in the search order for Metro (Windows store) applications. There's no magic to it.

Likewise your test's folder was likely not in the DLL search order for the app (System32, the app's package dependency graph, etc), thus the Loader wouldn't find your DLL for the app.